Cloud Design Patterns - Hong Kong Codeaholics
- 1. TaswarBhatti
- 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 • Native Hong Kong, but live in Canada now • 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 • Questions
- 7. Bad Design
- 8. Bad Design
- 9. Bad Design
- 10. Bad Design?
- 11. Itunes when I use it
- 12. 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.
- 14. 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
- 16. Storing Configuration in file
- 18. Problems • Configuration becomes part of deployment • Multiple applications share the same configuration • Hard to have access control over the configuration
- 20. 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
- 21. 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
- 22. Cloud Solution Offerings • Azure Key Vault • Vault by Hashicorp • AWS KMS • Keywhiz
- 24. 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.
- 27. 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
- 28. When not to use • Don’t use it for data that changes very often
- 29. 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
- 30. Cloud Offerings • Redis (Azure and AWS) • Memcache • Hazelcast • Elastic Cache (AWS)
- 32. 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
- 34. Problem
- 35. 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
- 37. 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
- 38. When not to use it • You already have a single application and have custom code that allows you to login
- 39. 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
- 40. Cloud Offerings • Azure AD • Gemalto STA and SAS • Amazon IAM • GCP Cloud IAM
- 42. 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
- 43. Typical Application Client App Storage
- 44. Problem Client App Storage Client Client Client Client
- 45. Valet Key Pattern Client App Generate Token Limited Time And Scope Storage
- 46. 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
- 47. When not to use it • When you need to transform the data before upload or download
- 48. Cloud Offerings • Azure Blob Storage • Amazon S3 • GCP Cloud Storage
- 50. 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
- 52. Problem
- 54. When to use it • Sensitive information (Health care, Authentication) • Distributed System where perform request validation separately
- 55. When not to use • Performance vs security
- 56. 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)
- 58. Circuit Breaker Pattern • To handle faults that might take a variable amount of time to recover • When connecting to a remote service or resource
- 60. Problem
- 61. Client Circuit Breaker Api Closed State Timeout Closed State Open State Half Open State After X Retry Closed State
- 62. Circuit Breaker
- 63. 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
- 64. 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
- 65. Libraries • Polly (http://www.thepollyproject.org/) • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
- 66. Retry pattern
- 67. 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
- 69. Retry Pattern • Retry after 2, 5 or 10 seconds
- 70. When to use it • Use retry for only transient failure that is more than likely to resolve themselves quicky • Match the retry policies with the application • Otherwise use the circuit break pattern
- 71. 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
- 72. Libraries • Roll your own code • Polly (http://www.thepollyproject.org/) • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
- 74. 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
- 77. When to use • Gradually migrating a back-end application to a new architecture
- 78. 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
- 79. 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.
- 80. Questions? Taswar Bhatti System Solutions Architect (Gemalto) Microsoft MVP http://taswar.zeytinsoft.com @taswarbhatti
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.