Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud patterns forwardjs April Ottawa 2019

107 views

Published on

Cloud Design Patterns at ForwardJS Conference April 2019 Ottawa
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

Published in: Software
  • Be the first to comment

  • Be the first to like this

Cloud patterns forwardjs April Ottawa 2019

  1. 1. TaswarBhatti
  2. 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. @taswarbhatti
  3. 3. Who am I • Taswar Bhatti – Microsoft MVP since 2014 • Global Solutions Architect/System Architect at Gemalto/Thales • In Software Industry since 2000 • I know Kung Fu (Languages) @taswarbhatti
  4. 4. 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 @taswarbhatti
  5. 5. Bad Design @taswarbhatti
  6. 6. Bad Design @taswarbhatti
  7. 7. Bad Design @taswarbhatti
  8. 8. Bad Design? @taswarbhatti
  9. 9. Itunes when I use it @taswarbhatti
  10. 10. 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. @taswarbhatti
  11. 11. External Configuration Pattern @taswarbhatti
  12. 12. 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 @taswarbhatti
  13. 13. Typical Application @taswarbhatti
  14. 14. Storing Configuration in file @taswarbhatti
  15. 15. Multiple application @taswarbhatti
  16. 16. Problems • Configuration becomes part of deployment • Multiple applications share the same configuration • Hard to have access control over the configuration @taswarbhatti
  17. 17. External Configuration Pattern @taswarbhatti
  18. 18. 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 @taswarbhatti
  19. 19. 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 @taswarbhatti
  20. 20. Cloud Solution Offerings • Azure Key Vault • Vault by Hashicorp • AWS KMS • Keywhiz @taswarbhatti
  21. 21. Cache Aside Pattern @taswarbhatti
  22. 22. 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. @taswarbhatti
  23. 23. Typical Application @taswarbhatti
  24. 24. Cache Aside Pattern @taswarbhatti
  25. 25. 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 @taswarbhatti
  26. 26. When not to use • Don’t use it for data that changes very often @taswarbhatti
  27. 27. 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 @taswarbhatti
  28. 28. Cloud Offerings • Redis (Azure and AWS) • Memcache • Hazelcast • Elastic Cache (AWS) @taswarbhatti
  29. 29. Federated Identity Pattern @taswarbhatti
  30. 30. 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 @taswarbhatti
  31. 31. Typical Application @taswarbhatti
  32. 32. Problem @taswarbhatti
  33. 33. 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 @taswarbhatti
  34. 34. Federated Identity Pattern @taswarbhatti
  35. 35. 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 @taswarbhatti
  36. 36. When not to use it • You already have a single application and have custom code that allows you to login @taswarbhatti
  37. 37. 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 @taswarbhatti
  38. 38. Cloud Offerings • Azure AD • Gemalto STA and SAS • Amazon IAM • GCP Cloud IAM @taswarbhatti
  39. 39. Valet Key Pattern @taswarbhatti
  40. 40. 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 @taswarbhatti
  41. 41. Typical Application Client App Storage @taswarbhatti
  42. 42. Problem Client App Storage Client Client Client Client @taswarbhatti
  43. 43. Valet Key Pattern Client App Generate Token Limited Time And Scope Storage @taswarbhatti
  44. 44. 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 @taswarbhatti
  45. 45. When not to use it • When you need to transform the data before upload or download @taswarbhatti
  46. 46. Cloud Offerings • Azure Blob Storage • Amazon S3 • GCP Cloud Storage @taswarbhatti
  47. 47. Gatekeeper Pattern @taswarbhatti
  48. 48. 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 @taswarbhatti
  49. 49. Typical Application @taswarbhatti
  50. 50. Problem @taswarbhatti
  51. 51. Gatekeeper Pattern @taswarbhatti
  52. 52. When to use it • Sensitive information (Health care, Authentication) • Distributed System where perform request validation separately @taswarbhatti
  53. 53. When not to use • Performance vs security @taswarbhatti
  54. 54. 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) @taswarbhatti
  55. 55. Circuit Breaker Pattern @taswarbhatti
  56. 56. Circuit Breaker Pattern • To handle faults that might take a variable amount of time to recover • When connecting to a remote service or resource @taswarbhatti
  57. 57. Typical Application @taswarbhatti
  58. 58. Problem @taswarbhatti
  59. 59. Client Circuit Breaker Api Closed State Timeout Closed State Open State Half Open State After X Retry Closed State @taswarbhatti
  60. 60. Circuit Breaker @taswarbhatti
  61. 61. 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 @taswarbhatti
  62. 62. 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 @taswarbhatti
  63. 63. Libraries • Polly (http://www.thepollyproject.org/) • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki @taswarbhatti
  64. 64. Retry pattern @taswarbhatti
  65. 65. 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 @taswarbhatti
  66. 66. Typical Application Network Failure @taswarbhatti
  67. 67. Retry Pattern • Retry after 2, 5 or 10 seconds @taswarbhatti
  68. 68. 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 @taswarbhatti
  69. 69. 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 @taswarbhatti
  70. 70. Libraries • Roll your own code • Polly (http://www.thepollyproject.org/) • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki @taswarbhatti
  71. 71. Demo @taswarbhatti
  72. 72. Strangler Pattern @taswarbhatti
  73. 73. 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 @taswarbhatti
  74. 74. Monolith Application @taswarbhatti
  75. 75. Strangler Pattern @taswarbhatti
  76. 76. When to use • Gradually migrating a back-end application to a new architecture @taswarbhatti
  77. 77. 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 @taswarbhatti
  78. 78. 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. @taswarbhatti
  79. 79. Questions? Taswar Bhatti System Solutions Architect (Gemalto/Thales) Microsoft MVP http://taswar.zeytinsoft.com @taswarbhatti @taswarbhatti

×