Cloud Design Patterns – Talk at Ottawa .NET Community

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

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

• Configuration becomes part of deployment
• Multiple applications share the same configuration
• Hard to have access control over the configuration

• When you have shared configuration, multiple application
• You want to manage configuration centrally by DevOps
• Provide audit for each configuration

• When you only have a single application there is no need to use this pattern it will make things more complex

• Azure Key Vault
• Vault by Hashicorp
• AWS KMS
• Keywhiz

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

• 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

• 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