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 Native Architecture Patterns Tutorial


Published on

As presented at the 2017 O'Reilly Software Architecture Conference in New York City.

Published in: Software
  • I like this service ⇒ ⇐ from Academic Writers. I don't have enough time write it by myself.
    Are you sure you want to  Yes  No
    Your message goes here
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ ◀ ◀ ◀ ◀
    Are you sure you want to  Yes  No
    Your message goes here
  • I still can't believe how great this worked. My drill battery, several AA and AAA batteries, and my camera battery work great again! This is super fun to do too. ◆◆◆
    Are you sure you want to  Yes  No
    Your message goes here
  • MADE $30 ON MY FIRST DAY! Being a fresh graduate and having lots of free time, I stumbled upon your site when I was searching for work at home opportunities, good thing I did! Just on my first day of joining I already made $30! Now I'm averaging close to $80 a day just for filling out surveys! ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ ◀ ◀ ◀ ◀
    Are you sure you want to  Yes  No
    Your message goes here

Cloud Native Architecture Patterns Tutorial

  1. 1. Cloud Native Architecture Patterns Tutorial 2017 O'Reilly Software Architecture Conference - NYC Matt Stine ( )@mstine
  2. 2. Introduction
  3. 3. Your Instructor 17 years in the Enterprise IT industry 5 years as a Cloud Platform and Application Architect Frequent speaker on the conference circuit Host of the Software Architecture Radio podcast
  4. 4. Your Instructor architectures.csp
  5. 5. Workshop Components Lecture Socratic Q&A Sessions Architecture Kata Sessions
  6. 6. Agenda Class Introduction Cloud Native Architecture Fundamentals 1:30 - 2:15 PM Socratic Q&A Session 2:15 - 2:30 PM Cloud Native Architecture Patterns 2:30 - 3:30 PM Socratic Q&A Session 3:30 - 3:45 PM
  7. 7. Agenda Cloud Native Architecture Katas - Setup 3:45 - 4:00 PM Cloud Native Architecture Katas - Create 4:00 - 4:30 PM Cloud Native Architecture Katas - Present 4:30 - 5:00 PM
  8. 8. The Business Drivers for Architectural Change
  9. 9. Agility Disruption
  10. 10. Agility - Mark Andressen Software is eating the world.
  11. 11. Agility Disruptive Characteristics Software is primary engagement model New and innovative business models Fast and frequent deliveries Hypothesis-driven development
  12. 12. Agility The Waterscrumfall
  13. 13. Agility Waterscrumfall Consequences Slow Delivery Large Batch Sizes Infrequent Feedback Increased Waste
  14. 14. Agility Digital Transformation
  15. 15. Resiliency Disruptive companies are also approaching resiliency differently.
  16. 16. Resiliency Stop trying to prevent mistakes.
  17. 17. Resiliency Embrace failure.
  18. 18. Resiliency From MTBF to MTTR
  19. 19. Resiliency We need better tools and techniques.
  20. 20. Resiliency Visibility
  21. 21. Resiliency Fault Isolation
  22. 22. Resiliency Fault Tolerance
  23. 23. Resiliency Scalability
  24. 24. Resiliency Automated Recovery
  25. 25. A High-Level Overview of DevOps and Continuous Delivery
  27. 27. DevOps My Definition: DevOps represents the idea of tearing down organizational silos and building shared toolsets, vocabularies, and communication structures in service of a culture focused on a single goal: delivering value rapidly and safely.
  28. 28. DevOps THE THREE WAYS
  29. 29. DevOps
  30. 30. DevOps The First Way: Flow
  31. 31. DevOps The Second Way: Feedback
  32. 32. DevOps The Third Way: Continual Learning and Experimentation
  33. 33. Continuous Delivery My Definition: Technically supporting the concept to cash lifecycle by proving every source code commit to be deployable to production in an automated fashion.
  34. 34. Continuous Delivery Ingredients Configuration Management Continuous Integration Automated Testing
  35. 35. Continuous Delivery CI Developer Workflow
  36. 36. Continuous Delivery The Deployment Pipeline
  37. 37. The Unique Characteristics of Cloud Infrastructure
  38. 38. Cloud Infrastructure My Definition: Any computing environment in which computing, networking, and storage resources can be provisioned and released elastically in an on-demand, self-service manner.
  39. 39. Cloud Infrastructure Deployment Models Public Amazon Web Services Google Cloud Platform Microsoft Azure Private VMware vSphere OpenStack Community Hybrid
  40. 40. Cloud Infrastructure Service Models The *aaS Pyramid
  41. 41. Cloud Infrastructure API Driven Automation Audit Authorization Accounting
  42. 42. Cloud Infrastructure Speed If you need a component, create it! Load Balancers Databases (SQL/NoSQL) Message Queues Private Networks Storage Volumes
  43. 43. Cloud Infrastructure Speed Can eliminate: Ticket Systems Approval Processes Waiting Queues Configuration Errors
  44. 44. Cloud Infrastructure Speed As fast as you can design the system architecture that you need, you can usually provision and begin using it.
  45. 45. Cloud Infrastructure Elastic Goodbye Capacity Planning!
  46. 46. Cloud Infrastructure Elastic Capacity Planning Peer into the crystal ball... "What's the most capacity we'll need?" Guess incorrectly... Blow available capacity on Black Friday Hundreds of idle CPUs
  47. 47. Cloud Infrastructure Elastic As demand increases, we simply expand capacity by provisioning more resources to service that demand.
  48. 48. Cloud Infrastructure Elastic As demand decreases, we simply contract capacity by returning resources to the pool.
  49. 49. Cloud Native Architecture Concepts
  50. 50. Architecting for DevOps Modularity
  51. 51. Architecting for DevOps Think About the Three Ways We want a quantum of this experience.
  52. 52. Architecting for DevOps Decomposition Strategies What's yours? Bounded Contexts Value Streams Single Responsibility Princple Failure Domains Anti-Corruption Layers
  53. 53. Architecting for DevOps Strategies are not mutually exclusive!
  54. 54. Architecting for DevOps So What About Modularity? Loose Coupling High Cohesion Encapsulation Well-Defined Interface
  55. 55. Architecting for DevOps Gratuitous Nod to Microservices!
  56. 56. Architecting for DevOps If a microservice isn't giving you Three Ways Value, you probably don't need it.
  57. 57. Architecting for DevOps Conway's Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
  58. 58. Architecting for DevOps If your architectural and and organizational decomposition strategies don't align well, then CONWAY WILL FIGHT YOU!
  59. 59. Architecting for DevOps Observability
  60. 60. Architecting for DevOps Think About the Three Ways We need feedback to create a safer system of work and to (in)validate our hypotheses.
  61. 61. Architecting for DevOps See Failure When It Happens
  62. 62. Architecting for DevOps Measure Everything
  63. 63. Architecting for DevOps What is Normal? Values Rates of Change Mean? P95/99/99.9?
  64. 64. Architecting for DevOps What is Normal?
  65. 65. Architecting for DevOps
  66. 66. Architecting for DevOps
  67. 67. Architecting for DevOps This is an Architectural Responsibility Architecture can make observability harder! Overhead Concerns Tools don't know your business.
  68. 68. Architecting for Continuous Delivery NOTE: Architecting for DevOps aids in Continuous Delivery!
  69. 69. Architecting for Continuous Delivery Adding some layers...
  70. 70. Architecting for Continuous Delivery Think About Full Lifecycle Architecture
  71. 71. Architecting for Continuous Delivery Neal Ford Architecture is abstract until it is operationalized.
  72. 72. Architecting for Continuous Delivery Architectures that aren't operationalized exist only on whiteboards!
  73. 73. Architecting for Continuous Delivery Deployability Testability We'll examine these qualities by asking questions of our architectures.
  74. 74. Architecting for Continuous Delivery Deployability
  75. 75. Architecting for Continuous Delivery Have you automated ALL of your deployment tasks?
  76. 76. Architecting for Continuous Delivery Can you transform a brand new deployment environment into your running architecture without manual work?
  77. 77. Architecting for Continuous Delivery Can you vary configuration across environments without rebuilding code?
  78. 78. Architecting for Continuous Delivery Do you deploy like this EVERYWHERE?
  79. 79. Architecting for Continuous Delivery Can you do this without your users noticing?
  80. 80. Architecting for Continuous Delivery Testability
  81. 81. Architecting for Continuous Delivery Have you automated ALL testing tasks that you possibly can?
  82. 82. Architecting for Continuous Delivery Do you have to deploy all the things to test anything?
  83. 83. Architecting for Continuous Delivery If testing is an experiment, can you control everything except your experimental variable?
  84. 84. Architecting for Continuous Delivery Can you run the same tests against any environment (including production)?
  85. 85. Architecting for Continuous Delivery Can you verify that you continue to meet your contractual obligations?
  86. 86. Architecting for Cloud Infrastructure Cloud Capabilities API-driven Speed Elasticity Geography Specialized Services
  87. 87. Architecting for Cloud Infrastructure Exploiting the capabilities of Cloud can enhance our ability to practice DevOps and Continuous Delivery!
  88. 88. Architecting for Cloud Infrastructure Disposability Replaceability We'll examine these qualities by asking questions of our architectures.
  89. 89. Architecting for Cloud Infrastructure Disposable adjective 1. designed for or capable of being thrown away after being used or used up: disposable plastic spoons; a disposable cigarette lighter. 2. free for use; available: Every disposable vehicle was sent.
  90. 90. Architecting for Cloud Infrastructure Replace verb 1. to assume the former role, position, or function of; substitute for (a person or thing): Electricity has replaced gas in lighting. 2. to provide a substitute or equivalent in the place of: to replace a broken dish.
  91. 91. Architecting for Cloud Infrastructure Consequence noun 1. an act or instance of following something as an effect, result, or outcome. 2. importance or significance: a matter of no consequence.
  92. 92. Architecting for Cloud Infrastructure Disposability Can I destroy a service instance at any time without consequence?
  93. 93. Architecting for Cloud Infrastructure Disposability Can I repave the entire architecture at any time without consequence?
  94. 94. Architecting for Cloud Infrastructure Disposability Can I respond to changes in demand by adding or removing instances of a service without consequence?
  95. 95. Architecting for Cloud Infrastructure Replaceability Can I replace a sick service instance with a brand new copy without consequence?
  96. 96. Architecting for Cloud Infrastructure Replaceability Can I route traffic to any available service instance without consequence?
  97. 97. Architecting for Cloud Infrastructure Replaceability If I lose an AZ or Region, can I route traffic to another without consequence?
  98. 98. Architecting for Cloud Infrastructure Replaceability Can I swap between multiple implementations of the same service contract without consequence?
  99. 99. Architecting for Cloud Infrastructure Replaceability Can I swap between multiple running versions of a service without consequence?
  100. 100. Architecting for Cloud Infrastructure These are Architectural Responsibilities Architecture can make disposability impossible. Architecture can make replaceability impossible. Architecture must take charge of removing the consequences of disposing and replacing service instances.
  101. 101. Summary Architectural Decision Making Can: Enhance or Detract from Our Ability to Practice DevOps Enhance or Detract from Our Ability to Practice Continuous Delivery Exploit or Waste the Characteristics of Cloud Infrastructure
  102. 102. Summary We could have called this "DevOps Native" or "Continuous Delivery Native" Architecture!
  103. 103. Summary DevOps Native Architecture
  104. 104. Summary Balancing: Agility and Resilience
  105. 105. Summary Supported By: DevOps and Continuous Delivery
  106. 106. Summary On a Foundation of: Cloud and Architecture
  107. 107. Socratic Q&A
  108. 108. Cloud Native Architecture Patterns
  109. 109. Overview Pattern-Oriented Software Architecture, Volume 1: A System of Patterns Patterns described uniformly. This helps us to compare one pattern with another...
  110. 110. Overview Design Patterns: Elements of Reusable Object-Oriented Software We describe design patterns using a consistent format...making design patterns easier to learn, compare, and use.
  111. 111. Overview Brick and Mortar Pattern Template Context The basic situation in which we find ourselves working. Problem Presents the problem as a system forces which must be balanced. Solution Describes the components that make up the general solution, how they relate to one another, and their runtime interactions.
  112. 112. Overview Brick and Mortar Language Structure Brick Patterns Patterns for constructing individual (micro)services. Mortar Patterns Patterns for composing bricks into complete distributed systems.
  113. 113. Overview Brick Patterns Externalization Patterns Structural patterns for creating deployable, disposable, and replaceable bricks. Externalized Configuration Externalized State Externalized Channels Runtime Patterns Behavioral patterns for creating deployable, replaceable, and observable bricks. Runtime Reconfiguration Concurrent Execution Brick Telemetry
  114. 114. Overview Mortar Patterns Distributed Systems Patterns Composition patterns addressing common distributed systems challenges. Service Discovery Edge Gateway Fault Tolerance Integration Patterns Composition patterns addressing integration and observability challenges. Event-Driven System Contract Management Integration Telemetry
  115. 115. Overview Brick and Mortar Language Relationships
  116. 116. Brick Patterns Externalized Configuration Externalized State Brick Telemetry
  117. 117. Externalized Configuration
  118. 118. Context and Problem Context An application's configuration will vary independently from its code throughout its lifecycle.
  119. 119. Context and Problem Problem Traditional techniques for managing configuration tightly couple these two orthogonal concepts.
  120. 120. Context and Problem Forces Different environments will have different configuration settings: resource handles to the database (e.g. a JDBC URL) credentials to external services (e.g. Amazon S3) per-deploy values such as the canonical hostname (e.g. vs. blog- features that are toggled on or off
  121. 121. Context and Problem Forces Configuration is often bundled within deployment artifacts (e.g. Java properties files). Build processes often modify configuration based on arguments. The Deployment Pipeline should only build each deployment artifact once, and deploy the same artifact to multiple environments.
  123. 123. Externalized State
  124. 124. Context and Problem Context Disposability and Replaceability require the elimination of "snowflake deployments" from the architecture.
  125. 125. Context and Problem Problem Traditional state management techniques prevent us from achieving "phoenix deployments."
  126. 126. Context and Problem Forces Early web architectures emphasized server-side state management: Fat Clients to Thin Clients Vertically Scaled Cache Management Stateful Scaffolding on Stateless Protocol (HTTP)
  127. 127. Context and Problem Forces Cloud Infrastructure: Resource Limited Horizontal Scale Limited Load Balancer Support for Sessions Limited (No) Support for Persistent Local Disk
  129. 129. Brick Telemetry
  130. 130. Context and Problem Context Realizing the DevOps Way of Feedback requires that we have visibility into both the business value and technical behavior generated by our services.
  131. 131. Context and Problem Problem Common approaches to service visibility fall short of the architectural qualities that we need.
  132. 132. Context and Problem Forces Visibility is often accomplished via post facto application of agent-based monitoring tools. Agent-based monitoring tools don't understand business value. Determining an application's health often requires complex logic. Traceability of an application is difficult (or impossible) to accomplish with OTS solutions.
  134. 134. Mortar Patterns Service Discovery Edge Gateway Fault Tolerance
  135. 135. Service Discovery
  136. 136. Context and Problem Context Decomposition of architecture into services leads to increasingly more distributed systems.
  137. 137. Context and Problem Problem As systems become distributed, and as service instance lifecycles become more dynamic and independent, location of and communication with dependencies becomes more challenging.
  138. 138. Context and Problem Forces Cloud platforms often assign auto-generated, internal hostnames or private IP's to service instances. As services are scaled and unhealthy instances are replaced, the addresses of a service's instances are constantly changing. Binding a service to anything other than logical names for its dependencies leads to friction in the architectural lifecycle.
  139. 139. Context and Problem Forces Applying Concurrent Execution is made more difficult (or impossible) when binding services to fixed addresses for their dependencies. We may want to remove a service instance from the available pool but keep it running to troubleshoot a problem.
  141. 141. Edge Gateway
  142. 142. Context and Problem Context Decomposed architectures must always be recomposed. This recomposition often happens within the user interface layer of an application.
  143. 143. Context and Problem Problem Recomposing an architecture within the User Interface layer presents significant complexities that can lead to decreased agility and degraded user experience.
  144. 144. Context and Problem Forces Systems often must support multiple user experience options (web/mobile/AVR). Recomposing architectures as the UI layer can require exposing the architecture to the public network. API needs for a mobile device are often quite different from a web UI.
  145. 145. Context and Problem Forces Exposing a network graph to mobile devices can increase latency, increase data usage, and degrade battery life. UI platforms may not support the integration architecture used for all services. Native apps often have longer upgrade cycles. Recomposing the architecture there can lead to friction in the architectural lifecycle.
  147. 147. Fault Tolerance
  148. 148. Context and Problem Context In order to accomplish its assigned tasks, each brick will need to communicate with other bricks, and with external systems, to which we'll collectively refer as dependencies.
  149. 149. Context and Problem Problem When a brick's dependencies become unhealthy, unreachable, or slower than normal to respond, that brick's own performance is degraded, and such degredation can potentially cascade across the entire architecture.
  150. 150. Context and Problem Forces The network is not reliable. Latency is non-zero and unpredictable. Service availability is a product of its dependencies' availabilities.
  151. 151. Context and Problem Forces Failures can be transient. Failures can cascade. An incorrect or stale response is often preferable to no response.
  153. 153. Socratic Q&A
  154. 154. Cloud Native Architecture Katas Setup
  155. 155. What are Architecture Katas? Take me to the rules!
  156. 156. To Cloud Native Add the following to your requirements: Day 1 as a company we're agreeing to guide ourselves by DevOps principles and practice Continuous Delivery. We have no infrastructure; we'll use one or more public cloud providers to deliver our software. Think deeply about your decomposition strategy and what advantages it will bring you. Use the CNA Patterns you know so far in order to enable your architectures to these ends.
  157. 157. Kata Choices