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.

Introduction to Microservices

29,435 views

Published on

Learn about microservices, evaluate whether your organization is ready for microservices, and discuss methods for implementing these architectures.

Published in: Technology

Introduction to Microservices

  1. 1. Introduction to Microservices Peter Dalbhanjan, Solutions Architect, AWS
  2. 2. 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
  3. 3. * As of 1 Feb 2016 2009 48 280 722 82 2011 2013 2015
  4. 4. “The Monolith”
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. “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/)
  9. 9. 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/)
  10. 10. Too much software coupling
  11. 11. Too much software coupling Shared libraries
  12. 12. Too much software coupling Shared libraries Shared data
  13. 13. 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/)
  14. 14. “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/)
  15. 15. “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)
  16. 16. Services communicate with each other over the network “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)
  17. 17. “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.
  18. 18. “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
  19. 19. “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/)
  20. 20. “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”
  21. 21. Anatomy of a Micro-service
  22. 22. Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch) Anatomy of a Micro-service
  23. 23. Application/Logic (code, libraries, etc) Anatomy of a Micro-service Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch)
  24. 24. Application/Logic (code, libraries, etc) Anatomy of a Micro-service Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch) Public API POST /restaurants GET /restaurants
  25. 25. Avoid Software Coupling
  26. 26. Drivers micro-services Payments micro-service Location micro-services Ordering micro-services Restaurant micro-service Ecosystem of micro-services
  27. 27. = 50 million deployments a year Thousands of teams × Microservice architecture × Continuous delivery × Multiple environments (5708 per hour, or every 0.63 second)
  28. 28. Gilt: Luxury designer brands at members-only prices
  29. 29. ... Sale every day at noon EST
  30. 30. Principle 1 Micro-services 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/)
  31. 31. Micro-service A Micro-service B public API public API Principle 1: Microservices only rely on each other’s public API DynamoDB
  32. 32. Micro-service A Micro-service B public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) DynamoDB
  33. 33. Micro-service A Micro-service B public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Nope! DynamoDB
  34. 34. Micro-service A Micro-service B public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) DynamoDB
  35. 35. Micro-service A public API 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
  36. 36. Micro-service A public API 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 storeRestaurant (id, name, cuisine) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) Version 1.1.0
  37. 37. Micro-service A public API 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 storeRestaurant (id, name, cuisine) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) Version 1.1.0 storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) Version 2.0.0
  38. 38. 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/)
  39. 39. Principle 2: Use the right tool for the job (Embrace polyglot persistence) Micro-service A Micro-service B public API public API DynamoDB
  40. 40. Principle 2: Use the right tool for the job (Embrace polyglot persistence) Micro-service A Micro-service B public API public API DynamoDB Amazon Elasticsearch Service
  41. 41. Principle 2: Use the right tool for the job (Embrace polyglot persistence) Micro-service A Micro-service B public API public API Amazon Elasticsearch Service RDS Aurora
  42. 42. Principle 2: Use the right tool for the job (Embrace polyglot programming frameworks) Micro-service A Micro-service B public API public API Amazon Elasticsearch Service RDS Aurora
  43. 43. Principle 2: Use the right tool for the job (Embrace polyglot programming frameworks) Micro-service A Micro-service B public API public API Amazon Elasticsearch Service RDS Aurora
  44. 44. Let’s build a microservice!
  45. 45. Restaurant Micro-service GET /restaurants POST /restaurants
  46. 46. Restaurant Micro-service Approach #1 EC2
  47. 47. Restaurant Micro-service EC2
  48. 48. Restaurant Micro-service EC2
  49. 49. Restaurant Micro-service EC2EC2 EC2 EC2
  50. 50. Restaurant Micro-service EC2EC2 EC2 EC2 Elastic Load Balancer
  51. 51. Restaurant Micro-service Approach #2 Containers Using ECS
  52. 52. Restaurant Micro-service EC2EC2 EC2 EC2 Elastic Load Balancer
  53. 53. Restaurant Micro-service EC2EC2 EC2 EC2 Elastic Load Balancer
  54. 54. Restaurant Micro-service EC2EC2 EC2 EC2 Elastic Load Balancer Amazon EC2 Container Service (ECS) to manage containers
  55. 55. • 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
  56. 56. Restaurant Micro-service Approach #3 API Gateway + Lambda
  57. 57. DynamoDB Restaurant Micro-service
  58. 58. DynamoDB Lambda Restaurant Micro-service
  59. 59. DynamoDB Lambda Restaurant Micro-service API Gateway
  60. 60. AWS Lambda lets you run code without managing servers
  61. 61. Upload your code (Java, JavaScript, Python)
  62. 62. Upload your code (Java, JavaScript, Python) Set up your code to trigger from other AWS services, webservice calls, or app activity
  63. 63. Lambda automatically scales Upload your code (Java, JavaScript, Python) Set up your code to trigger from other AWS services, webservice calls, or app activity
  64. 64. 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
  65. 65. AWS API Gateway is the easiest way to deploy micro-services
  66. 66. Create a unified API frontend for multiple micro-services
  67. 67. Create a unified API frontend for multiple micro-services Authenticate and authorize requests
  68. 68. Create a unified API frontend for multiple micro-services Authenticate and authorize requests Handles DDoS protection and API throttling
  69. 69. Create a unified API frontend for multiple micro-services …as well as monitoring, logging, rollbacks, client SDK generation… Authenticate and authorize requests Handles DDoS protection and API throttling
  70. 70. Restaurant Microservice
  71. 71. DynamoDB Restaurant Microservice
  72. 72. DynamoDB Lambda to retrieve restaurants Restaurant Microservice Lambda to store restaurants
  73. 73. DynamoDB Lambda to retrieve restaurants Restaurant Microservice API Gateway POST GET Lambda to store restaurants
  74. 74. DynamoDB Lambda to retrieve restaurants Restaurant Microservice API Gateway POST GET Web UI Lambda to store restaurants
  75. 75. DynamoDB Lambda to retrieve restaurants Restaurant Microservice API Gateway POST GET Web UI Lambda to store restaurants
  76. 76. 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
  77. 77. Micro-service A Micro-service B public API public API DynamoDB From a few…
  78. 78. Drivers micro-services Payments micro-service Location micro-services Ordering micro-services Restaurant micro-service …to an ecosystem
  79. 79. 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/)
  80. 80. 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
  81. 81. 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/)
  82. 82. Hey Sally, we need to call your micro- service 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. Micro-service A Micro-service B public API public API Principle 4: Be a good citizen within the ecosystem
  83. 83. Principle 4: Be a good citizen within the ecosystem (Have clear SLAs) Restaurant Micro-service 15 TPS100 TPS5 TPS20 TPS Before we let you call our micro-service we need to understand your use case, expected load (TPS) and accepted latency
  84. 84. …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)
  85. 85. 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/)
  86. 86. “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
  87. 87. 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
  88. 88. 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
  89. 89. 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
  90. 90. 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
  91. 91. 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
  92. 92. 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)
  93. 93. 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)
  94. 94. 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/)
  95. 95. releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  96. 96. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service
  97. 97. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service releasetestbuild
  98. 98. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service releasetestbuild releasetestbuild
  99. 99. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service releasetestbuild releasetestbuild releasetestbuild
  100. 100. releasetestbuild releasetestbuild Focused agile teams 2-pizza team delivery pipeline service releasetestbuild releasetestbuild releasetestbuild releasetestbuild
  101. 101. 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
  102. 102. 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
  103. 103. 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
  104. 104. Benefits of microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual micro-service
  105. 105. Benefits of microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual micro-service New releases take minutes Short time to add new features Easier to maintain and evolve system
  106. 106. Benefits of microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual micro-service New releases take minutes Short time to add new features Easier to maintain and evolve system Faster innovation Delighted customers Increased agility
  107. 107. 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
  108. 108. Thank you! Peter Dalbhanjan dalbhanj@amazon.com

×