Digital Transformation - ARC219 - re:Invent 2017
•
6 likes•1,117 views
Many industries are going through a digital transformation as their existing business models are being disrupted and new competitors emerge. The key driver is a need for faster time-to-value as a direct relationship with customers provides analytics that drive personalization and rapid product development. There’s a cultural aspect to the change, as well as new organizational patterns that go along with a migration to cloud native services. Application architectures are evolving from monoliths to microservices and serverless deployments, and they becoming more distributed, highly available, and resilient. The highly automated practices that have built up around DevOps are moving to the mainstream, and some new techniques are emerging around security red teams and chaos engineering.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Digital Transformation - ARC219 - re:Invent 2017
Similar to Digital Transformation - ARC219 - re:Invent 2017 (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Digital Transformation - ARC219 - re:Invent 2017
- 1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Digital Transformation Adrian Cockcroft A W S V P C l o u d A r c h i t e c t u r e S t r a t e g y @ a d r i a n c o N o v e m b e r 2 8 , 2 0 1 7 AWS re:INVENT
- 3. OLD WORLD IT Employees at work Factories + supply chainSales channels Marketing analytics
- 4. Employees at work Factories + supply chainSales channels Marketing analytics OLD WORLD IT NEW WORLD IT
- 5. NEW WORLD IT Employees at work Factories + supply chain IoT connected things Online marketing Continuous supply tracking Just-in-time production Online sales + delivery Social media
- 6. Personalization Customer tracking New channels direct to customer New Needs
- 7. Evolution of Business Logic Monolith Microservices Functions
- 9. Splitting Monoliths Ten Years Ago XML & SOAP
- 11. REST JSON Fast binary encodingsSplitting Monoliths Five Years Ago
- 18. Microservices Five Years Agoto Functions Amazon Kinesis Amazon API Gateway Amazon SNS Amazon S3 Amazon DynamoDB Amazon SQS Standard building brick services provide standardized platform capabilities
- 19. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to Functions Business Logic Glue between the bricks Standard building brick services provide standardized platform capabilities
- 20. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to Functions
- 21. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to Functions
- 22. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to FunctionsEphemeral
- 26. Microservices to Amazon API Gateway Amazon SNS Amazon S3 Functions Ephemeral
- 27. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to Functions Ephemeral When the system is idle, it shuts down and costs nothing to run
- 28. Evolution of Business Logic Monolith Microservices Functions
- 29. The New De-Normal Monolithic databases Kitchen sink analogy De-normalized
- 30. Expensive, Hard to Create and Run Monolith
- 31. Expensive, Hard to Create and Run ic DatabaseMonolith
- 43. Consistency Problem How many complete sets are there?
- 44. Consistency Problem How many complete sets are there?
- 45. Consistency Problem How many complete sets are there? GLASSES
- 46. Adding a New Use Case GLASSES
- 47. Adding a New Use Case SAKE SET GLASSES BOWLS
- 48. Cloud Makes It Easy to Add New Databases
- 49. Untangle and Migrate Existing ‘Kitchen Sink’ Schemas
- 50. Untangle and Migrate Existing ‘Kitchen Sink’ Schemas
- 51. The New De-Normal Monolithic databases Kitchen sink analogy De-normalized
- 52. Cloud Native Architecture Principles and practices
- 54. Infrastructure Datacenter Native Architecture Lives for years DATACENTER
- 55. Cloud Migration Pay as you go DATACENTER Pay up front and depreciate over 3 years Pay a month later for the number of seconds used
- 56. Cloud Native Principle Pay for what you used last month… …not what you guess you will need next year.
- 57. File tickets and wait for every step Self-service, on-demand, no delays ! VS !
- 58. File tickets and wait for every step Self-service, on-demand, no delays ! VS !!
- 59. File tickets and wait for every step Self service, on-demand, no delays ! VS !! Deploy by filing a ticket and waiting weeks or months Deploy by making an API call self-service within minutes
- 60. Cloud Native Principle Self-service, API-driven, automated Move from request tickets at every step to a tracking ticket that records what happened
- 62. Cloud Native Principle Instant globally distributed deployments and data by default
- 64. Chicago New York Ohio U.S.-East-2 Virginia U.S.-East-1 a b c a b c Typical datacenter architecture Typical cloud architecture Zones a, b, and c are 10–100km apart Regions and Zones
- 66. Regions and Zones Datacenter native migration to cloudKeep the same configuration and run MySQL on a cloud instance yourself MySQL Primary MySQL Secondary
- 67. Regions and Zones Cloud native data migration MySQL Primary MySQL Secondary Amazon Aurora Distribute over all three zones
- 68. Regions and Zones Cloud native data migration MySQL Primary MySQL Secondary More resilient within each region
- 69. Cloud Native Principle Distribute over zones within a region by default
- 70. Elasticity DATACENTER Hard to get over 10 percent utilization—need extra capacity in case of peak CLOUD Target over 40 percent utilization—no capacity overload issues
- 71. Automatic scaling for predictable heavy workloads Serverless for spiky workloads with idle periods
- 72. Cloud Native Principle Turn it off when it’s idle Many times higher utilization Huge cost savings Avoids capacity overloads
- 77. Cloud Native Principle Immutable code Automated builds Ephemeral instances, containers, and functions Blue–Green deployments Versioned services
- 78. Pay as you go, afterward Self-service—no waiting Globally distributed by default Cross-zone/region availability models High utilization—turn idle resources off Immutable code deployments Cloud Native Principles
- 79. Cloud Native Principles Remain constant as practices evolve
- 80. Cloud Native Architecture Principles and practices
- 83. Leverage Wardley Maps Move up the value chain
- 84. With Leverage Comes Dependencies…
- 85. Lock-in and the Lifecycle of Dependencies Choosing, using, and losing
- 86. What is the return on investment (ROI) for each phase? Choosing Using Losing
- 87. What is the ROI for each phase? How has ROI changed with advances in technology and practices? Choosing Using Losing
- 89. Choosing
- 90. Choosing
- 91. Choosing
- 92. Choosing
- 95. Using
- 96. Using
- 99. Losing
- 100. Losing
- 101. Losing—What Changed?
- 102. Years Millions of dollars Hundreds of dev years Lock-in Lawyers and contracts Old World Monolithic on-prem waterfall lock-in Weeks Hundreds of dollars A few dev weeks Refactoring Self-service New World Agile cloud-native micro-dependencies
- 103. Bottom Line ROI for choosing, using, losing has changed radically. Stop talking about lock-in, it’s just refactoring dependencies The cost of each dependency is far lower Frequency of refactoring is far higher Investment and return are much more incremental
- 104. Chaos Architecture A Cloud Native Availability Model Adrian Cockcroft
- 105. Four layers Two teams An attitude Chaos Architecture
- 107. No single point of failure Infrastructure and Services
- 108. No single point of failure
- 109. No single point of failure Distributed
- 110. No single point of failure Replicated
- 111. No single point of failure ReplicatedDistributed
- 112. No single point of failure ReplicatedDistributed Automated
- 113. No single point of failure ReplicatedDistributed Automated Cloud
- 114. Infrastructure
- 116. Data replication Traffic routing Avoiding issues Anti-entropy recovery Switching and Interconnecting
- 117. Data replication Traffic routing Avoiding issues Anti-entropy recovery Switching and Interconnecting
- 118. Data replication Traffic routing Avoiding issues Anti-entropy recovery Switching and Interconnecting
- 119. Who has a backup datacenter? What’s the best description of it? 1. Availability theater—never tried to use it 2. Infrequent partial testing 3. Regular tests during maintenance 4. Frequent failovers during production to prove that no-one can tell it’s happening
- 120. Route updates and customer requests to specific regions and services Replicate data and re-route requests during incidents Switching mechanism must be far more reliable than redundant elements you are switching between
- 123. App ! Error returns Slow response Network partition Application Failures
- 124. Microservices limit ‘blast radius’ for software incidents Circuit breakers limit damage Bulkheads prevent it from spreading DITTO—Do Idempotent Things To Others Avoid update and delete semantics
- 127. I wonder why it did that? Let’s reboot it. Whoops! Now it’s really hosedUnexpected application behavior often causes people to intervene and make the situation worse People
- 128. A fire drill is a boring routine where we make everyone take the stairs and assemble in the parking lot People Training !
- 129. Fire drills save lives in the event of a real fire, because people are trained for how to react People Training
- 130. Infrastructure Switching Application People Who runs the ‘fire drill’ for IT?
- 135. Infrastructure Switching Application People Tools Tools Chaos Engineering Team Security Red Team
- 137. Infrastructure Switching Application People Chaos Engineering Team Tools Security Red Team Tools Four layers Two teams An attitude— Break it to make it better Chaos Architecture
- 138. Risk Tolerance Who is at risk for what? Is downtime a bigger risk? You Choose Availability Higher risk Permissive Consistency Secure Downtime
- 141. Break It to Make It Safer The “new view” of safety based on: Todd Conklin’s pre-accident podcast John Allspaw’s stella.report Sydney Dekker—Drift into Failure
- 142. Failures are a System Problem— Lack of Safety Margin Not something with a root cause of component or human error
- 143. Blindfolded on a cliff edge, what would you do?
- 144. Hypothesis Testing • We think we have safety margin in this dimension, let’s carefully test to be sure • In production • Without causing an issue
- 145. How to Select a Test? LDFI—Lineage-driven Fault Injection Dependency graphs for important flows
- 146. Experienced staff Robust applications Dependable switching fabric Redundant service foundation
- 147. Chaos Architecture A cloud native availability model
- 149. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you! C L I C K T O A D D T E X T