This document discusses 8 cloud design patterns: External Configuration, Cache Aside, Federated Identity, Valet Key, Gatekeeper, Circuit Breaker, Retry, and Strangler. It provides an overview of each pattern, including what problem it addresses, when to use it, considerations, and examples of cloud offerings that implement each pattern. It aims to help developers understand and apply common best practices for cloud application design.

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.

23. External Configuration Pattern

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

25. Typical Application

26. Storing Configuration in file

27. Multiple application

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

29. External Configuration Pattern

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

34. Cache Aside Pattern

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.

36. Typical Application

37. Cache Aside Pattern

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)

42. Federated Identity Pattern

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

44. Typical Application

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

47. Federated Identity Pattern

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

52. Valet Key Pattern

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

60. Gatekeeper Pattern

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

62. Typical Application

63. Problem

64. Gatekeeper Pattern

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)

68. Circuit Breaker Pattern

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

70. Typical Application

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

79. Typical Application
Network Failure

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

85. Strangler Pattern

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

87. Monolith Application

88. Strangler Pattern

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