This week I gave a talk on Cloud Design Patterns at the Ottawa .NET Community. I wanted to share the sides here and will most likely write on articles on the topic using real world examples. Samples in C# and node.js, in AWS and Azure.

For the talk I went through, what Cloud Design Patterns are and mainly focused on the patterns below without using any platform specifications. (i.e cloud agnostics)

  • The External Configuration Pattern
  • The Cache Aside Pattern
  • The Federated Identity Pattern
  • The Valet Key Pattern
  • The Gatekeeper Pattern
  • The Circuit Breaker Pattern

For each of them I also went through when you should use the pattern and when not to use it, I also provided Cloud Solutions Offering that one can use to implement the pattern.

Enjoy the slides 🙂

The Transcript:

  1. 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
  2. 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.
  3. 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
  4. Typical Application
  5. Storing Configuration in file
  6. Multiple application
  7. Problems
    • Configuration becomes part of deployment
    • Multiple applications share the same configuration
    • Hard to have access control over the configuration
  8. External Configuration Pattern
  9. 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
  10. 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
  11. Cloud Solution Offerings
    • Azure Key Vault
    • Vault by Hashicorp
    • AWS KMS
    • Keywhiz
  12. 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.
  13. Typical Application
  14. Cache Aside Pattern
  15. 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
  16. When not to use
    • Don’t use it for data that changes very often
    • 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
    • Cloud Offerings
      • Redis (Azure and AWS)
      • Memcache
      • Hazelcast
      • Elastic Cache (AWS)
    • 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
    • Typical Application
    • 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
    • Federated Identity Pattern
    • 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
    • When not to use it
      • You already have a single application and have custom code
      • that allows you to login
    • 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
    • Cloud Offerings
      • Azure AD
      • Gemalto STA and SAS
      • Amazon IAM
      • GCP Cloud IAM
    • 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
    • Typical Application Client App Storage
    • Problem
    • Valet Key Pattern
    • Client App Generate Token Limited Time And Scope Storage
    • 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
    • When not to use it
      • When you need to transform the data before upload or download
    • Cloud Offerings
      • Azure Blob Storage
      • Amazon S3
      • GCP Cloud Storage

    • 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
    • Typical Application

    • Problem

    • Gatekeeper Pattern

    • When to use it

      • Sensitive information (Health care, Authentication)
      • Distributed System where perform request validation separately

    • When not to use

      • • Performance vs security

    • 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)

    • Circuit Breaker Pattern

      • To handle faults that might take a variable amount of time to recover
      • When connecting to a remote service or resource
    • Typical Application

    • Problem

    • 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
    • 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
    • Libraries
      • • Polly (http://www.thepollyproject.org/)
      • • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
    • 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
    • Typical Application has Network Failure

    • Retry Pattern
      • • Retry after 2, 5 or 10 seconds
    • 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
    • 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
    • Libraries
      • Roll your own code
      • Polly (http://www.thepollyproject.org/)
      • Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
    • 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
    • Monolith Application
    • When to use
      • Gradually migrating a back-end application to a new architecture
    • 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
    • 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.

Related posts:

  1. Azure Key Vault – Azure Saturday satazureday Ottawa
  2. Cloud Design Patterns – Hong Kong Codeaholics
  3. FowardJS Ottawa – Cloud Design Patterns
  4. 8 Cloud Design Patterns – Update Conference Prague