Container Days: Architecting Modern Apps on AWS

93 views

Published on

Container Days Conference NY 2016 - Architecting Modern Applications on AWS
Co presentation with Mackenzie Kosut

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
93
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Container Days: Architecting Modern Apps on AWS

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Architecting Modern Applications on AWS: VMs, Containers, Microservices, Lambda and More 2016-11-04 Mackenzie Kosut @mkosut AWS Startup Evangelist Tara E. Walker @taraw AWS Technical Evangelist
  2. 2. 15 min Evolution from Monoliths to Microservices 15 min Core Principles of Microservices Approaches to building Microservices on AWS 15 min Other Architectural Principles 5 min Additional Resources Architecting Modern Applications on AWS: VMs, Containers, Microservices, Lambda and More
  3. 3. 2006 EC2 & S3 2016 70+ Managed Services Kinesis Streaming Analytics, Mobile Testing, Redshift Datawarehouse, Code Deploy/Build Tools, Elastic Container Service, Application Load Balancer, Lambda, API Gateway, DynamoDB, Elastic Map Reduce (Hadoop/Spark/Presto/etc), Elastic Beanstalk, Elastic Transcoder, RDS, Elasticsearch, more..
  4. 4. 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
  5. 5. 2009 48 280 722 82 2011 2013 2015 706 September 2016
  6. 6. Migrating from Monolith to Microservice
  7. 7. “The Monolith”
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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/)
  12. 12. Too much software coupling
  13. 13. Too much software coupling Shared libraries
  14. 14. Too much software coupling Shared libraries Shared data
  15. 15. 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/)
  16. 16. “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/)
  17. 17. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  18. 18. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Services communicate with each other over the network Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  19. 19. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” You can update the services independently; updating one service doesn’t require changing any other services. Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  20. 20. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Self-contained; you can update the code without knowing anything about the internals of other microservices Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
  21. 21. “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/)
  22. 22. “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”
  23. 23. Anatomy of a Microservice
  24. 24. Anatomy of a Microservice
  25. 25. Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch) Anatomy of a Microservice
  26. 26. Application/Logic (code, libraries, etc) Anatomy of a Microservice Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch)
  27. 27. Public API POST /restaurants GET /restaurants Application/Logic (code, libraries, etc) Anatomy of a Microservice Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch)
  28. 28. Avoid Software Coupling
  29. 29. Drivers microservices Payments microservice Location microservices Ordering microservices Restaurant microservice Ecosystem of Microservices
  30. 30. = 50 million deployments a year Thousands of teams × Microservice architecture × Continuous delivery × Multiple environments (5708 per hour, or every 0.63 second)
  31. 31. Gilt: Luxury designer brands at members-only prices
  32. 32. ... Sale every day at noon EST
  33. 33. Microservices Architecture on Amazon Web Services
  34. 34. Application Services API Gateway Build, Publish and Manage APIs  Performance at any scale via worldwide edge locations, traffic throttling, and API output caching  Monitor API activity  Integrates with Lambda functions  Run multiple versions of the same API  Fully Managed
  35. 35. Elastic Compute Cloud (EC2) Virtual Servers in the Cloud  Resizable Compute Capacity  Complete control of your computing resources  Reduces time to obtain and boot new server instances to minutes  Choose from 30+ different instance types  Scale as your requirements change  Pay only for what you use Compute
  36. 36. EC2 Container Service Run and Manage Docker Containers  A high performance container management service for running Docker containers on EC2 instances  Use the built in scheduler, write your own, or use a third-party scheduler  Integrates with other services like ELB and EBS  No additional charge  EC2 Container Registry Compute
  37. 37. Lambda Run Code in Response to Events  Runs code in response to triggers such as S3 upload, DynamoDB updates, Kinesis streams, and API Gateway requests  Automatically scales  You only need to provide the code; there is no infrastructure to manage  Pay only for what you use Compute
  38. 38. DynamoDB Predictable and Scalable NoSQL Data Store  Fast, fully-managed NoSQL Database Service  Capable of handling any amount of data  Durable and Highly Available  All SSD storage  Simple and Cost Effective Database
  39. 39. Microservices Architecture Internet Mobile Apps Websites Services AWS Lambda functions AWS API Gateway Cache Endpoints on Amazon EC2 /ECS Amazon Elastic Beanstalk Any other publicly accessible endpoint Amazon CloudWatch Monitoring Amazon API Gateway
  40. 40. 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/)
  41. 41. Microservice A Microservice B public API public API Principle 1: Microservices only rely on each other’s public API
  42. 42. public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
  43. 43. public API public API Nope! Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
  44. 44. public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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/)
  49. 49. public API public API Principle 2: Use the right tool for the job (Embrace polyglot persistence) DynamoDB Microservice A Microservice B
  50. 50. public API public API Principle 2: Use the right tool for the job (Embrace polyglot persistence) DynamoDB Microservice A Microservice B Amazon Elasticsearch Service
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. Today’s Workshop This hands-on workshop will demonstrate the basics of building serverless applications and microservices on AWS using AWS Lambda, Amazon DynamoDB, Amazon API Gateway, and more. Building Serverless Microservices on AWS 1:45PM – 2:45PM
  55. 55. DynamoDB Lambda to retrieve restaurants Restaurant microservice API Gateway POST GET Lambda to store restaurants
  56. 56. 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/)
  57. 57. 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
  58. 58. 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/)
  59. 59. 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
  60. 60. 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
  61. 61. …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)
  62. 62. 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/)
  63. 63. “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
  64. 64. 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
  65. 65. 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
  66. 66. 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
  67. 67. 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
  68. 68. 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)
  69. 69. Full ownership Full accountability Aligned incentives 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)
  70. 70. 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/)
  71. 71. releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  72. 72. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  73. 73. releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  74. 74. releasetestbuild releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  75. 75. releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  76. 76. releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  77. 77. 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 951806
  78. 78. Summary
  79. 79. 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
  80. 80. 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  Polyglot persistence (data layer)  Polyglot frameworks (app layer) 3. Secure your services  Defense-in-depth  Authentication/authorization 6. Automate everything  Adopt an Automation Strategy 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
  81. 81. 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
  82. 82. 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
  83. 83. 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
  84. 84. AWS resources: • Microservices without the Servers https://aws.amazon.com/blogs/compute/ microservices-without-the-servers • 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/ • Serverless Webapp - Reference Architecture: https://github.com/awslabs/lambda-refarch-webapp • Zombie Microservices Workshop: https://github.com/awslabs/aws-lambda-zombie- workshop Popular open-source tools: • Serverless – http://serverless.com • Apex - http://apex.run/ https://aws.amazon.com/devops/ Additional Resources
  85. 85. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you! Mackenzie Kosut @mkosut Tara E. Walker @taraw

×