8 cloud design patterns you ought to know - Update Conference 2018
- 1. 8 Cloud Design Patterns you ought to know Taswar Bhatti System/Solutions Architect at Gemalto (Canada) Microsoft MVP
- 2. Ponder • For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity. • There is seldom one best design solution to a software problem. • If cars were like software, they would crash twice a day for no reason, and when you called for service, they’d tell you to reinstall the engine.
- 3. Who am I • Taswar Bhatti – Microsoft MVP since 2014 • Global Solutions Architect/System Architect at Gemalto • In Software Industry since 2000 • I know Kung Fu (Languages)
- 4. What I am not
- 6. Agenda • What are Patterns? • The External Configuration Pattern • The Cache Aside Pattern • The Federated Identity Pattern • The Valet Key Pattern • The Gatekeeper Pattern • The Circuit Breaker Pattern • The Retry Pattern • The Strangler Pattern • Demo • Questions
- 7. Bad Design
- 8. Bad Design
- 9. Bad Design
- 10. Bad Design
- 11. Bad Design
- 12. Feature doesn’t make sense????
- 13. Anger
- 14. Bad day at work
- 15. Happy family
- 16. Next day at work
- 17. Ship it
- 18. Customer Feature didn’t make sense
- 19. Bad Design?
- 20. Itunes when I use it
- 22. What are Patterns? • General reusable solution to a recurring problem • A template on how to solve a problem • Best practices • Patterns allow developers communicate with each other in well known and understand names for software interactions.
- 24. External Configuration Pattern • Helps move configuration information out of the application deployment • This pattern can provide for easier management and control of configuration data • For sharing configuration data across applications and other application instances
- 26. Storing Configuration in file
- 28. Problems • Configuration becomes part of deployment • Multiple applications share the same configuration • Hard to have access control over the configuration
- 30. When to use the pattern • When you have shared configuration, multiple application • You want to manage configuration centrally by DevOps • Provide audit for each configuration
- 31. When not to use • When you only have a single application there is no need to use this pattern it will make things more complex
- 32. Cloud Solution Offerings • Azure Key Vault • Vault by Hashicorp • AWS KMS • Keywhiz
- 33. Demo KeyVault
- 35. Cache Aside Pattern • Load data on demand into a cache from datastore • Helps improve performance • Helps in maintain consistency between data held in the cache and data in the underlying data store.
- 38. When to use the pattern • Resource demand is unpredictable. • This pattern enables applications to load data on demand • It makes no assumptions about which data an application will require in advance
- 39. When not to use • Don’t use it for data that changes very often
- 40. Things to consider • Sometimes data can be changed from outside process • Have an expiry for the data in cache • When update of data, invalidate the cache before updating the data in database • Pre populate the data if possible
- 41. Cloud Offerings • Redis (Azure and AWS) • Memcache • Hazelcast • Elastic Cache (AWS)
- 43. Federated Identity Pattern • Delegate authentication to an external identity provider. • Simplify development, minimize the requirement for user administration • Improve the user experience of the application • Centralized providing MFA for user authentication
- 45. Problem
- 46. Problem • Complex development and maintenance (Duplicated code) • MFA is not an easy thing • User administration is a pain with access control • Hard to keep system secure • No single sign on (SSO) everyone needs to login again to different systems
- 48. When to use • When you have multiple applications and want to provide SSO for applications • Federated identity with multiple partners • Federated identity in SAAS application
- 49. When not to use it • You already have a single application and have custom code that allows you to login
- 50. Things to consider • The identity Server needs to be highly available • Single point of failure, must have HA • RBAC, identity server usually does not have authorization information • Claims and scope within the security auth token
- 51. Cloud Offerings • Azure AD • Gemalto STA and SAS • Amazon IAM • GCP Cloud IAM
- 53. Valet Key Pattern • Use a token that provides clients with restricted direct access to a specific resource • Provide offload data transfer from the application • Minimize cost and maximize scalability and performance
- 54. Typical Application Client App Storage
- 55. Problem Client App Storage Client Client Client Client
- 56. Valet Key Pattern Client App Generate Token Limited Time And Scope Storage
- 57. When to use it • The application has limited resources • To minimize operational cost • Many interaction with external resources (upload, download) • When the data is stored in a remote data store or a different datacenter
- 58. When not to use it • When you need to transform the data before upload or download
- 59. Cloud Offerings • Azure Blob Storage • Amazon S3 • GCP Cloud Storage
- 61. Gatekeeper Pattern • Using a dedicated host instance that acts as a broker between clients and services • Protect applications and services • Validates and sanitizes requests, and passes requests and data between them • Provide an additional layer of security, and limit the attack surface of the system
- 63. Problem
- 65. When to use it • Sensitive information (Health care, Authentication) • Distributed System where perform request validation separately
- 66. When not to use • Performance vs security
- 67. Things to consider • WAF should not hold any keys or sensitive information • Use a secure communication channel • Auto scale • Endpoint IP address (when scaling application does the WAF know the new applications)
- 69. Circuit Breaker Pattern • To handle faults that might take a variable amount of time to recover • When connecting to a remote service or resource
- 71. Problem
- 72. Client Circuit Breaker Api Closed State Timeout Closed State Open State Half Open State After X Retry Closed State
- 73. Circuit Breaker
- 74. When to use it • To prevent an application from trying to invoke a remote service or access a shared resource if this operation is highly likely to fail • Better user experience
- 75. When not to use • Handling access to local private resources in an application, such as in-memory data structure • Creates an overhead • Not a substitute for handling exceptions in the business logic of your applications
- 76. Libraries • Polly (http://www.thepollyproject.org/) • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
- 77. Retry pattern
- 78. Retry Pattern • Enable an application to handle transient failures • When the applications tries to connect to a service or network resource • By transparently retrying a failed operation
- 80. Retry Pattern • Retry after 2, 5 or 10 seconds
- 81. When to use it • Use retry for only transient failure that is more than likely to resolve themselves quickly • Match the retry policies with the application • Otherwise use the circuit break pattern
- 82. When not to use it • Don’t cause a chain reaction to all components • For internal exceptions caused by business logic • Log all retry attempts to the service
- 83. Libraries • Roll your own code • Polly (http://www.thepollyproject.org/) • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
- 84. Demo Retry
- 86. Strangler Pattern • Incrementally migrate a legacy system • Gradually replacing specific pieces of functionality with new applications and services • Features from the legacy system are replaced by new system features eventually • Strangling the old system and allowing you to decommission it
- 89. When to use • Gradually migrating a back-end application to a new architecture
- 90. When not to use • When requests to the back-end system cannot be intercepted • For smaller systems where the complexity of wholesale replacement is low
- 91. Considerations • Handle services and data stores that are potentially used by both new and legacy systems. • Make sure both can access these resources side-by-side • When migration is complete, the strangler façade will either go away or evolve into an adaptor for legacy clients • Make sure the façade doesn't become a single point of failure or a performance bottleneck.
- 92. Questions? Taswar Bhatti System Solutions Architect (Gemalto) Microsoft MVP http://taswar.zeytinsoft.com @taswarbhatti
- 93. Credits • For the background • www.Vecteezy.com
Editor's Notes
- #3: For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity. There is seldom one best design solution to a software problem. If cars were like software, they would crash twice a day for no reason, and when you called for service, they’d tell you to reinstall the engine.