Enterprise summit – architecting microservices on aws final v2
•
9 likes•4,277 views
To tackle complexity and change, AWS customers are increasingly evolving their architectures from monoliths towards microservices, and benefiting from increased agility, simplified scalability, resiliency, and faster deployments. However, microservices also introduce new technical challenges. In this session, we'll provide an introduction and overview of the benefits and challenges of micrososervices, and share best practices for architecting and deploying microservices on AWS.
Enterprise summit – architecting microservices on aws final v2
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Level 200 (Introductory) Pierre Steckmeyer, AWS Solutions Architect September 28th, 2016 Architecting Microservices on AWS Divide and conquer for agility and scalability:
- 8. ENTERPRISE APPS DEVELOPMENT & OPERATIONSMOBILE SERVICESAPP SERVICESANALYTICS Data Warehousing Hadoop/ Spark Streaming Data Collection Machine Learning Elastic Search Virtual Desktops Sharing & Collaboration Corporate Email Backup Queuing & Notifications Workflow Search Email Transcoding One-click App Deployment Identity Sync Single Integrated Console Push Notifications DevOps Resource Management Application Lifecycle Management Containers Triggers Resource Templates TECHNICAL & BUSINESS SUPPORT Account Management Support Professional Services Training & Certification Security & Pricing Reports Partner Ecosystem Solutions Architects MARKETPLACE Business Apps Business Intelligence Databases DevOps Tools NetworkingSecurity Storage Regions Availability Zones Points of Presence INFRASTRUCTURE CORE SERVICES Compute VMs, Auto-scaling, & Load Balancing Storage Object, Blocks, Archival, Import/Export Databases Relational, NoSQL, Caching, Migration Networking VPC, DX, DNS CDN Access Control Identity Management Key Management & Storage Monitoring & Logs Assessment and reporting Resource & Usage Auditing SECURITY & COMPLIANCE Configuration Compliance Web application firewall HYBRID ARCHITECTURE Data Backups Integrated App Deployments Direct Connect Identity Federation Integrated Resource Management Integrated Networking API Gateway IoT Rules Engine Device Shadows Device SDKs Registry Device Gateway Streaming Data Analysis Business Intelligence Mobile Analytics
- 9. * As of 1 Feb 2016 2009 48 280 722 82 2011 2013 2015
- 10. “The Monolith”
- 11. Challenges with monolithic software Long Build/Test/Release Cycles (who broke the build?) Operations is a nightmare (module X is failing, who’s the owner?) Difficult to scale New releases take months Long time to add new features Architecture is hard to maintain and evolve Lack of innovation Frustrated customers Lack of agility
- 12. Challenges with monolithic software Long Build/Test/Release Cycles (who broke the build?) Operations is a nightmare (module X is failing, who’s the owner?) Difficult to scale New releases take months Long time to add new features Architecture is hard to maintain and evolve Lack of innovation Frustrated customers Lack of agility
- 13. Challenges with monolithic software Long Build/Test/Release Cycles (who broke the build?) Operations is a nightmare (module X is failing, who’s the owner?) Difficult to scale New releases take months Long time to add new features Architecture is hard to maintain and evolve Lack of innovation Frustrated customers Lack of agility
- 14. “20080219BonMorningDSC_0022B” by Sunphol Sorakul . No alterations other than cropping. https://www.flickr.com/photos/83424882@N00/3483881705/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 15. Monolith development lifecycle releasetestbuild delivery pipeline app (aka the“monolith”)developers Photo by Sage Ross. No alterations other than cropping. https://www.flickr.com/photos/ragesoss/2931770125/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 16. Too much software coupling
- 17. Too much software coupling Shared libraries
- 18. Too much software coupling Shared libraries Shared data
- 19. Evolving towards microservices “IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 20. “IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 23. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Adrian Cockcroft (former Cloud Architect at Netflix, now Technology Fellow at Battery Ventures)
- 24. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Adrian Cockcroft (former Cloud Architect at Netflix, now Technology Fellow at Battery Ventures) Services communicate with each other over the network
- 25. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Adrian Cockcroft (former Cloud Architect at Netflix, now Technology Fellow at Battery Ventures) You can update the services independently; updating one service doesn’t require changing any other services.
- 26. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Adrian Cockcroft (former Cloud Architect at Netflix, now Technology Fellow at Battery Ventures) Self-contained; you can update the code without knowing anything about the internals of other microservices
- 27. “Do one thing, and do it well” “Swiss Army” by by Jim Pennucci. No alterations other than cropping. https://www.flickr.com/photos/pennuja/5363518281/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 28. “Tools” by Tony Walmsley: No alterations other than cropping. https://www.flickr.com/photos/twalmsley/6825340663/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/) “Do one thing, and do it well”
- 29. Anatomy of a Microservice
- 30. Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch) Anatomy of a Microservice
- 31. Application/Logic (code, libraries, etc) Anatomy of a Microservice Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch)
- 32. Public API POST /restaurants GET /restaurants Application/Logic (code, libraries, etc) Anatomy of a Microservice Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch)
- 34. Drivers microservices Payments microservice Location microservices Ordering microservices Restaurant microservice Ecosystem of microservices
- 38. = 50 million deployments a year Thousands of teams × Microservice architecture × Continuous delivery × Multiple environments (5708 per hour, or every 0.63 second)
- 39. Gilt: Luxury designer brands at members-only prices
- 40. ... Sale every day at noon EST
- 43. Principle 1 Microservices only rely on each other’s public API “Contracts” by NobMouse. No alterations other than cropping. https://www.flickr.com/photos/nobmouse/4052848608/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 44. Microservice A Microservice B public API public API Principle 1: Microservices only rely on each other’s public API
- 45. public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
- 46. public API public API Nope! Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
- 47. public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
- 48. Principle 1: Microservices only rely on each other’s public API (Evolve API in backward-compatible way…and document!) storeRestaurant (id, name, cuisine) Version 1.0.0 public API Microservice A
- 49. Principle 1: Microservices only rely on each other’s public API (Evolve API in backward-compatible way…and document!) storeRestaurant (id, name, cuisine) storeRestaurant (id, name, cuisine) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) Version 1.0.0 Version 1.1.0 public API Microservice A
- 50. Principle 1: Microservices only rely on each other’s public API (Evolve API in backward-compatible way…and document!) storeRestaurant (id, name, cuisine) storeRestaurant (id, name, cuisine) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) Version 1.0.0 Version 1.1.0 Version 2.0.0 public API Microservice A
- 51. Principle 2 Use the right tool for the job “Tools #2” by Juan Pablo Olmo. No alterations other than cropping. https://www.flickr.com/photos/juanpol/1562101472/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 52. public API public API Principle 2: Use the right tool for the job (Embrace polyglot persistence) DynamoDB Microservice A Microservice B
- 53. public API public API Principle 2: Use the right tool for the job (Embrace polyglot persistence) DynamoDB Microservice A Microservice B Amazon Elasticsearch Service
- 54. public API public API Principle 2: Use the right tool for the job (Embrace polyglot persistence) RDS Aurora Microservice A Microservice B Amazon Elasticsearch Service
- 55. public API public API Principle 2: Use the right tool for the job (Embrace polyglot programming frameworks) RDS Aurora Microservice A Microservice B Amazon Elasticsearch Service
- 56. public API public API Principle 2: Use the right tool for the job (Embrace polyglot programming frameworks) RDS Aurora Microservice A Microservice B Amazon Elasticsearch Service
- 59. Restaurant Microservice GET /restaurants POST /restaurants
- 64. Restaurant Microservice EC2EC2 EC2 EC2 Elastic Load Balancer
- 66. Restaurant Microservice EC2EC2 EC2 EC2 Elastic Load Balancer
- 67. Restaurant Microservice EC2EC2 EC2 EC2 Elastic Load Balancer
- 68. Restaurant Microservice EC2EC2 EC2 EC2 Elastic Load Balancer Amazon EC2 Container Service (ECS) to manage containers
- 69. • Prototype in less than 2 months • Deployment time: hours minutes • Each team can now develop its respective applications independently Coursera 13 million users from 190 countries 1,000 courses from 119 institutions
- 70. Restaurant Microservice Approach #3 API Gateway + Lambda
- 74. AWS Lambda lets you run code without managing servers
- 75. Upload your code (Java, JavaScript, Python)
- 76. Upload your code (Java, JavaScript, Python) Set up your code to trigger from other AWS services, webservice calls, or app activity
- 77. Lambda automatically scales Upload your code (Java, JavaScript, Python) Set up your code to trigger from other AWS services, webservice calls, or app activity
- 78. Lambda automatically scales Upload your code (Java, JavaScript, Python) Pay for only the compute time you use (sub-second metering) Set up your code to trigger from other AWS services, webservice calls, or app activity
- 79. AWS API Gateway is the easiest way to deploy microservices
- 80. Create a unified API frontend for multiple microservices
- 81. Create a unified API frontend for multiple microservices Authenticate and authorize requests
- 82. Create a unified API frontend for multiple microservices Authenticate and authorize requests Handles DDoS protection and API throttling
- 83. Create a unified API frontend for multiple microservices …as well as monitoring, logging, rollbacks, client SDK generation… Authenticate and authorize requests Handles DDoS protection and API throttling
- 87. DynamoDB Lambda to retrieve restaurants Restaurant Microservice Lambda to store restaurants
- 88. DynamoDB Lambda to retrieve restaurants Restaurant Microservice API Gateway POST GET Lambda to store restaurants
- 89. DynamoDB Lambda to retrieve restaurants Restaurant Microservice API Gateway POST GET Web UI Lambda to store restaurants
- 91. DynamoDB Lambda to retrieve restaurants Restaurant Microservice API Gateway POST GET Web UI Lambda to store restaurants
- 92. Highly Scalable • Inherently scalable Secure • API Gateway acts as “front door” • Can add authN/authZ; or throttle API if needed • S3 bucket policies • IAM Roles for Lambda invocations Cost-efficient • Only pay for actual microservice usage
- 93. Microservice A Microservice B public API public API From a few…
- 94. Drivers microservices Payments microservice Location microservices Ordering microservices Restaurant microservice …to an ecosystem
- 95. Principle 3 Secure Your Services “security” by Dave Bleasdale. No alterations other than cropping. https://www.flickr.com/photos/sidelong/3878741556/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 96. Principle 3: Secure Your Services • Defense-in-depth • Network level (e.g. VPC, Security Groups, TLS) • Server/container-level • App-level • IAM policies • Gateway (“Front door”) • API Throttling • Authentication & Authorization • Client-to-service, as well as service-to-service • API Gateway: custom Lambda authorizers • IAM-based Authentication • Token-based auth (JWT tokens, OAuth 2.0) • Secrets management • S3 bucket policies + KMS + IAM • Open-source tools (e.g. Vault, Keywhiz) API Gateway
- 97. Principle 4 Be a good citizen within the ecosystem “Lamington National Park, rainforest” by Jussarian. No alterations other than cropping. https://www.flickr.com/photos/kerr_at_large/87771074/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 98. Hey Sally, we need to call your microservice to fetch restaurants details. Sure Paul. Which APIs you need to call? Once I know better your use cases I’ll give you permission to register your service as a client on our service’s directory entry. Microservice A Microservice B public API public API Principle 4: Be a good citizen within the ecosystem
- 99. Principle 4: Be a good citizen within the ecosystem (Have clear SLAs) Restaurant Microservice 15 TPS100 TPS5 TPS20 TPS Before we let you call our microservice we need to understand your use case, expected load (TPS) and accepted latency
- 100. …and many, many others! Distributed monitoring and tracing • “Is the service meeting its SLA?” • “Which services were involved in a request?” • “How did downstream dependencies perform?” Shared metrics • e.g. request time, time to first byte Distributed tracing • e.g. Zipkin, OpenTracing User-experience metrics Principle 4: Be a good citizen within the ecosystem (Distributed monitoring, logging and tracing)
- 101. Principle 5 More than just technology transformation “rowing on the river in Bedford” by Matthew Hunt. No alterations other than cropping. https://www.flickr.com/photos/mattphotos/19189529/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 102. “Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.” Melvin E. Conway, 1967 Conway’s Law
- 103. Decentralize governance and data management Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 104. Decentralize governance and data management Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 105. Silo’d functional teams silo’d application architectures Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 106. Silo’d functional teams silo’d application architectures Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 107. Cross functional teams self-contained services Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 108. Cross functional teams self-contained services Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 109. Non-pizza image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html Cross functional teams self-contained services (“Two-pizza teams” at Amazon)
- 110. Full ownership Full accountability Aligned incentives “DevOps” Non-pizza image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html Cross functional teams self-contained services (“Two-pizza teams” at Amazon)
- 111. Principle 6 Automate Everything “Robot” by Robin Zebrowski. No alterations other than cropping. https://www.flickr.com/photos/firepile/438134733/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 112. releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
- 113. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
- 114. releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
- 115. releasetestbuild releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
- 116. releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
- 117. releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
- 118. Principle 6: Automate everything AWS CodeCommit AWS CodePipeline AWS CodeDeploy EC2 ELB Auto ScalingLambdaECS DynamoDBRDS ElastiCache SQS SWF SES SNS API GatewayCloudWatch Cloud Trail KinesisElastic Beanstalk
- 119. It’s a journey… Expect challenges along the way… • Understanding of business domains • Coordinating txns across multiple services • Eventual Consistency • Service discovery • Lots of moving parts requires increased coordination • Complexity of testing / deploying / operating a distributed system • Cultural transformation
- 120. Principles of Microservices 1. Rely only on the public API Hide your data Document your APIs Define a versioning strategy 2. Use the right tool for the job Polygot persistence (data layer) Polyglot frameworks (app layer) 3. Secure your services Defense-in-depth Authentication/authorization 6. Automate everything Adopt DevOps 4. Be a good citizen within the ecosystem Have SLAs Distributed monitoring, logging, tracing 5. More than just technology transformation Embrace organizational change Favor small focused dev teams
- 121. Benefits of microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual microservice New releases take minutes Short time to add new features Easier to maintain and evolve Increase innovation Delighted customers Increased agility
- 122. Benefits of microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual microservice New releases take minutes Short time to add new features Easier to maintain and evolve system Faster innovation Delighted customers Increased agility
- 123. Benefits of microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual microservice New releases take minutes Short time to add new features Easier to maintain and evolve system Faster innovation Delighted customers Increased agility
- 124. Additional AWS resources: • Zombie Microservices Workshop: https://github.com/awslabs/aws-lambda-zombie-workshop • Serverless Webapp - Reference Architecture: https://github.com/awslabs/lambda-refarch-webapp • Microservices with ECS: https://aws.amazon.com/blogs/compute/using-amazon- api-gateway-with-microservices-deployed-on-amazon-ecs/ • Serverless Service Discovery: https://aws.amazon.com/blogs/developer/ serverless-service-discovery-part-1-get-started/ • ECS Service Discovery: https://aws.amazon.com/blogs/compute/ service-discovery-an-amazon-ecs-reference-architecture/ • Microservices without the Servers https://aws.amazon.com/blogs/compute/ microservices-without-the-servers Popular open-source tools: • Serverless – http://serverless.com • Apex - http://apex.run/ https://aws.amazon.com/devops/ Additional resources
- 125. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Pierre Steckmeyer steckmey@amazon.com Thank you!