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.

Digital Transformation | AWS Webinar

1,441 views

Published on

Webinar slides for the Digital Transformation Webinar - March 28, 2018

  • Very Nice: See Latest Blogs @ https://www.thesisscientist.com/Blog
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Digital Transformation | AWS Webinar

  1. 1. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Digital Transformation Gl auber Gal l ego S o l u t i o n s A r c h i t e c t u r e M a n a g e r G o v e r n m e n t , E d u c a t i o n & N o n - P r o f i t B u s i n e s s A W S L a t i n A m e r i c a M a r c h 2 8 , 2 0 1 8
  2. 2. Digital Transformation Disruption and opportunities Microservices evolution Cloud native Dependency management Chaos architecture
  3. 3. OLD WORLD IT Employees at work Factories + supply chainSales channels Marketing analytics
  4. 4. Employees at work Factories + supply chainSales channels Marketing analytics OLD WORLD IT NEW WORLD IT
  5. 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. 6. Personalization Customer tracking New channels direct to customer New Needs
  7. 7. Evolution of Business Logic Monolith Microservices Functions
  8. 8. Splitting Monoliths Ten Years Ago
  9. 9. Splitting Monoliths Ten Years Ago XML & SOAP
  10. 10. Splitting Monoliths TenFiveYears Ago
  11. 11. REST JSON Fast binary encodingsSplitting Monoliths Five Years Ago
  12. 12. Splitting Monoliths TenFive Years Ago
  13. 13. Microservices Five Years Ago
  14. 14. 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
  15. 15. 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
  16. 16. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to Functions
  17. 17. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to Functions
  18. 18. Amazon SNS Amazon S3 Amazon API Gateway Amazon SQS Amazon Kinesis Amazon DynamoDB Microservices to FunctionsEphemeral
  19. 19. Microservices to Functions Ephemeral
  20. 20. Microservices to Amazon API Gateway Amazon SQS Functions Ephemeral
  21. 21. Microservices to Amazon API Gateway Amazon Kinesis Amazon DynamoDB Functions Ephemeral
  22. 22. Microservices to Amazon API Gateway Amazon SNS Amazon S3 Functions Ephemeral
  23. 23. 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
  24. 24. Evolution of Business Logic Monolith Microservices Functions
  25. 25. The New De-Normal Monolithic databases Kitchen sink analogy De-normalized
  26. 26. Expensive, Hard to Create and Run Monolith
  27. 27. Expensive, Hard to Create and Run ic DatabaseMonolith
  28. 28. Database Schema Entity Relationship
  29. 29. Database Schema Entity Relationship
  30. 30. Database Schema Entity Relationship
  31. 31. Kitchen Sink Analogy
  32. 32. Kitchen Sink AnalogyCleanup GLASSES
  33. 33. GLASSES Kitchen Sink Cleanup
  34. 34. GLASSES Kitchen Sink Cleanup
  35. 35. Kitchen Sink Cleanup GLASSES
  36. 36. Kitchen Sink Cleanup GLASSES
  37. 37. Kitchen Sink Cleanup GLASSES
  38. 38. Kitchen Sink Cleanup GLASSES
  39. 39. Consistency Problem How many complete sets are there?
  40. 40. Consistency Problem How many complete sets are there?
  41. 41. Consistency Problem How many complete sets are there? GLASSES
  42. 42. Adding a New Use Case GLASSES
  43. 43. Adding a New Use Case SAKE SET GLASSES BOWLS
  44. 44. Cloud Makes It Easy to Add New Databases
  45. 45. Untangle and Migrate Existing ‘Kitchen Sink’ Schemas
  46. 46. Untangle and Migrate Existing ‘Kitchen Sink’ Schemas
  47. 47. The New De-Normal Monolithic databases Kitchen sink analogy De-normalized
  48. 48. Cloud Native Architecture Principles and practices
  49. 49. Datacenter Native DATACENTER Architecture
  50. 50. Infrastructure Datacenter Native Architecture Lives for years DATACENTER
  51. 51. Cloud Migration Pay as you go DATACENTER Applications and data Pay up front and depreciate over 3 years Pay a month later for the number of seconds used
  52. 52. Cloud Native Principle Pay for what you used last month… …not what you guess you will need next year.
  53. 53. File tickets and wait for every step Self-service, on-demand, no delays ! VS !
  54. 54. File tickets and wait for every step Self-service, on-demand, no delays ! VS !!
  55. 55. 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
  56. 56. Cloud Native Principle Self-service, API-driven, automated Move from request tickets at every step to a tracking ticket that records what happened
  57. 57. Cloud Native Principle Instant globally distributed deployments and data by default
  58. 58. 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
  59. 59. Chicago New York Ohio U.S.-East-2 Virginia U.S.-East-1 a b c a b c Regions and Zones Failover Hurricane Sandy
  60. 60. Regions and Zones Datacenter native migration to cloudKeep the same configuration and run MySQL on a cloud instance yourself MySQL Primary MySQL Secondary
  61. 61. Regions and Zones Cloud native data migration MySQL Primary MySQL Secondary Amazon Aurora Distribute over all three zones
  62. 62. Regions and Zones Cloud native data migration MySQL Primary MySQL Secondary More resilient within each region
  63. 63. Cloud Native Principle Distribute over zones within a region by default
  64. 64. 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
  65. 65. Automatic scaling for predictable heavy workloads Serverless for spiky workloads with idle periods
  66. 66. Cloud Native Principle Turn it off when it’s idle Many times higher utilization Huge cost savings Avoids capacity overloads
  67. 67. Versioned Delivery Pipeline Developer Build system
  68. 68. Versioned Delivery Pipeline Developer 0 1 2 3 4 56 7 8 9Build system Canary test
  69. 69. Green version Blue version Versioned Delivery Pipeline Developer 0 1 2 3 4 56 7 8 9Build system Canary test
  70. 70. Green version Blue version Versioned Delivery Pipeline Developer 0 1 2 3 4 56 7 8 9Build system Canary test Old versions
  71. 71. Cloud Native Principle Immutable code Automated builds Ephemeral instances, containers, and functions Blue–Green deployments Versioned services
  72. 72. 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
  73. 73. Cloud Native Principles Remain constant as practices evolve
  74. 74. Cloud Native Architecture Principles and practices
  75. 75. Building on Cloud Chaos architecture Dependency management Opportunities
  76. 76. Startup Spaces Incremental Gap fillers Leverage Category creator
  77. 77. Leverage Wardley Maps Move up the value chain
  78. 78. With Leverage Comes Dependencies…
  79. 79. Lock-in and the Lifecycle of Dependencies Choosing, using, and losing
  80. 80. What is the return on investment (ROI) for each phase? Choosing Using Losing
  81. 81. What is the ROI for each phase? How has ROI changed with advances in technology and practices? Choosing Using Losing
  82. 82. Using Losing Choosing
  83. 83. Choosing
  84. 84. Choosing
  85. 85. Choosing
  86. 86. Choosing
  87. 87. Choosing—What Changed?
  88. 88. Choosing Using Losing
  89. 89. Using
  90. 90. Using
  91. 91. Using—What Changed?
  92. 92. Choosing Using Losing
  93. 93. Losing
  94. 94. Losing
  95. 95. Losing—What Changed?
  96. 96. 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
  97. 97. 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
  98. 98. Chaos Architecture A Cloud Native Availability Model
  99. 99. Four layers Two teams An attitude Chaos Architecture
  100. 100. No single point of failure Infrastructure and Services
  101. 101. No single point of failure
  102. 102. No single point of failure Distributed
  103. 103. No single point of failure Replicated
  104. 104. No single point of failure ReplicatedDistributed
  105. 105. No single point of failure ReplicatedDistributed Automated
  106. 106. No single point of failure ReplicatedDistributed Automated Cloud
  107. 107. Infrastructure
  108. 108. Data replication Traffic routing Avoiding issues Anti-entropy recovery Switching and Interconnecting
  109. 109. Data replication Traffic routing Avoiding issues Anti-entropy recovery Switching and Interconnecting
  110. 110. Data replication Traffic routing Avoiding issues Anti-entropy recovery Switching and Interconnecting
  111. 111. 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
  112. 112. 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
  113. 113. Infrastructure Switching
  114. 114. App ! Error returns Slow response Network partition Application Failures
  115. 115. 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
  116. 116. Infrastructure Switching Application
  117. 117. 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
  118. 118. A fire drill is a boring routine where we make everyone take the stairs and assemble in the parking lot People Training !
  119. 119. Fire drills save lives in the event of a real fire, because people are trained for how to react People Training
  120. 120. Infrastructure Switching Application People Who runs the ‘fire drill’ for IT?
  121. 121. Infrastructure Switching Application People Chaos Engineering Team
  122. 122. Infrastructure Switching Application People Tools Chaos Engineering Team
  123. 123. Infrastructure Switching Application People Chaos Engineering Team Game days Tools Simian Army chaostoolkit.org ChAP Gremlin
  124. 124. Infrastructure Switching Application People Tools Chaos Engineering Team Security Red Team
  125. 125. Infrastructure Switching Application People Tools Tools Chaos Engineering Team Security Red Team
  126. 126. Infrastructure Switching Application People Chaos Engineering Team Tools Security Red Team Safestack AVA Metasploit Nmap AttackIQ Tools SafeBreach
  127. 127. 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
  128. 128. Digital Transformation Disruption and opportunities Microservices evolution Cloud native Dependency management Chaos architecture
  129. 129. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you!

×