Successfully reported this slideshow.

Introduction to Microservices

377

Share

1 of 124
1 of 124

More Related Content

More from Amazon Web Services

Related Books

Free with a 30 day trial from Scribd

See all

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

Editor's Notes

  • Remind audience that this is a 200-level session
    Cover a lot of ground – we can fill a multi-day workshop

    Ask “by show of hands”, how many are familiar with the idea of microservices.
    How many have built out microservices?
  • And we continue to innovate on behalf of our customers. 90-95% of roadmap is based on what customers ask for.

    And one of the reasons why customers choose the AWS platform is the speed of innovation, as we build more features that customers want.

    But it wasn’t always this way.
  • But it wasn’t always this way. Amazon used to be built using a monolith architecture.

    I don’t know about you, but around the year 2001, we found our own biggest bottleneck at Amazon.
    At that time, it became increasingly difficult for our software developers to integrate new features into the Amazon.com page, understand the data that came in through our eCommerce operations and react quickly to customer feedback.
    The reason was that the Amazon.com homepage had turned into this large, complex and difficult to maintain thing:
    The Monolith.
    Obidos, $3.2B in revenue, C++

    Over time, the set of features on the Amazon website grew and the Obidos codebase began to sprawl.  The binary was multiple gigabytes and took a very long time to compile.  So, in the early-mid 2000s, the company began to switch over to Gurupa. Gurupa was a webserver that could only talk to databases and filesystems through BSF (Amazon in-house equivalent of Thrift), and then when these services gave the data to the server, it would assemble them into a webpage using Mason templates, which is basically Perl interspersed with HTML (feels similar to PHP). Over the period of about 2 1/2 years (I think) around 2004-2005, the company migrated from Obidos to Gurupa completely.
  • So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
    And we identified a few root causes.

    And at Amazon, where it’s all about the customer, that just is not acceptable.
  • So at Amazon, one of our leadership principle is Dive Deep. practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
    And we identified a few root causes.

    And what we started to understand as the root cause were two key ones:

  • - when you're working with a monolithic app, you have many developers all pushing changes through a shared release pipeline
    - this causes frictions at many points of the lifecycle
    - upfront during development, engineers need to coordinate their changes to make sure they're not making changes that will break someone else's code
    - if you want to upgrade a shared library to take advantage of a new feature, you need to convince everyone else to upgrade at the same time – good luck with that
    - and if you want to quickly push an important fix for your feature, you still need to merge it in with everyone else's in process changes
    - this leads to "merge Fridays", or worse yet "merge weeks", where all the developers have to compile their changes and resolve any conflicts for the next release
    - even after development, you also face overhead when you're pushing the changes through the delivery pipeline
    - you need to re-build the entire app, run all of the test suites to make sure there are no regressions, and re-deploy the entire app
    - to give you an idea of this overhead, Amazon had a central team whose sole job it was to deploy this monolithic app into production
    - even if you're just making a one-line change in a tiny piece of code you own, you still need to go through this heavyweight process and wait to catch the next train leaving the station
    - for a fast growth company trying to innovate and compete, this overhead and sluggishness was unacceptable
    - the monolith became too big to scale efficiently so we made a couple of big changes
    - one was architectural, and the other was organizational
    Building complex applications is inherently difficult
  • Teams depend on each other’s libraries + other common libraries
    “We’re blocked as we cannot build our software until you hand us the latest version of your library”
    Teams depend on each other’s database schema
    “We’re afraid the changes we’re making to our database schema will break your code”
  • Teams depend on each other’s libraries + other common libraries
    “We’re blocked as we cannot build our software until you hand us the latest version of your library”
    Teams depend on each other’s database schema
    “We’re afraid the changes we’re making to our database schema will break your code”
  • Teams depend on each other’s libraries + other common libraries
    “We’re blocked as we cannot build our software until you hand us the latest version of your library”
    Teams depend on each other’s database schema
    “We’re afraid the changes we’re making to our database schema will break your code”
  • We knew there had to be a better way.
    So around this time, we implemented a company-wide mandate to decompose our monolith and EVOLVE towards microservices.
  • We knew there had to be a better way.
    So around this time, we implemented a company-wide mandate to decompose our monolith and EVOLVE towards microservices.
  • So what defines a microservice?
    You can certainly look it up on Wikipedia, but the succinct definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
  • So what defines a microservice?
    You can certainly look it up on Wikipedia, but the succinct definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
  • So what defines a microservice?
    You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
  • So what defines a microservice?
    You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
  • So what defines a microservice?
    You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
  • So what defines a microservice?
    You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
  • We knew there had to be a better way.
    So around this time, we implemented a company-wide mandate to move towards microservices.
  • We knew there had to be a better way.
    So around this time, we implemented a company-wide mandate to move towards microservices.
  • Anatomy of a microservice

    TODO: Change to restaurantAPI
  • Anatomy of a microservice

    TODO: Change to restaurantAPI
  • Anatomy of a microservice

    TODO: Change to restaurantAPI
  • Anatomy of a microservice

    TODO: Change to restaurantAPI
  • Allows you to avoid software coupling, because you know longer have shared libraries or shared datastores. Microservices just talk to one another via their public APIs.
  • Web of Microservices
  • 2009
  • - what does success look like
    - there are a lot of ways that you can measure the process, and no one way is perfect
    - but here's one data point
    - when you have thousands of independent teams
    - producing highly-factored microservices
    - that are deployed across multiple dev, test, and production environments
    - in a continuous delivery process
    - you get a lot of deployments
    - at Amazon in 2014, we ran over 50M deployments
    - that's an average of 1.5 deployments every second
  • TODO: Summarize the benefits that Nike was able to see
  • Or to put more simply….

    Use the right tool for the job.
  • Or to put more simply….

    Use the right tool for the job.
  • So with those two core principles as foundation, let’s build a microservice
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Coursera
    13 million users from 190 countries
    1,000 courses from 119 institutions, everything from Programming in Python to Songwriting.

    Coursera uses Amazon EC2 Container Service to manage a microservices -based architecture for its applications.
    Now deploy software changes in minutes instead of hours in a resource-isolated environment.

    Large monolithic application for processing batch jobs that was difficult to run, deploy, and scale.
    A new thread was created whenever a new job needed to be completed, and each job took up different amounts of memory and CPU, continually creating inefficiencies.
    A lack of resource isolation allowed memory-limit errors to bring down the entire application.

    Each job is created as a container and Amazon ECS schedules the container across the cluster of EC2 instances. ECS handles all the cluster management and container orchestration, and containers provide the necessary resource isolation.

    Prototype up and running in <2 months
    Speed and agility: Software deployment time went from hours to minutes
    Each team can now develop and update its respective applications independently
    Operational efficiency: No extra infrastructure engineering time is spent installing software and maintaining a cluster—Amazon ECS handles everything from cluster management to container orchestration.
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • “Simplest way to build powerful, dynamic apps in the cloud”
  • “Simplest way to build powerful, dynamic apps in the cloud”
  • “Simplest way to build powerful, dynamic apps in the cloud”
  • “Simplest way to build powerful, dynamic apps in the cloud”
  • “Simplest way to build powerful, dynamic apps in the cloud”
  • “Simplest way to build powerful, dynamic apps in the cloud”
  • Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
    Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
    Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
  • Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
    Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
    Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
  • Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
    Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
    Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
  • Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
    Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
    Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
  • Demo: Build a microservice using Lambda and API gateway
    Emphasize the versioning aspect of microservices
    Test the service using Postman
    Export out the Swagger definition
    Use Swagger tool to generate documentation
    Show that you can generate client libraries
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Go Serverless
  • Demo: Build a microservice using Lambda and API gateway
    Emphasize the versioning aspect of microservices
    Test the service using Postman
    Export out the Swagger definition
    Use Swagger tool to generate documentation
    Show that you can generate client libraries
  • Go Serverless
  • All this promotes agile experimentation
  • Web of Microservices
  • Or to put more simply….

    Use the right tool for the job.
  • Or to put more simply….

    Use the right tool for the job.
  • This goes both ways:

    Service registry

    Service owners have a responsibility – publish your health, monitor Clients have a responsibility to do exponential backoff – in case there are errors
  • This goes both ways:
    Service owners have a responsibility – publish your health, monitor Clients have a responsibility to do exponential backoff – in case there are errors
  • If it moves, it should be tracked and logged


    Spend more time working on code that analyses the meaning of metrics than code that collects, moves, stores and displays metrics
    Reduce key business metric latency to less than the human attention span (~10s)
    Validate your measurement system has enough accuracy and precision. Collect histograms of response time
    Monitoring systems need to be more available and scalable than the systems (and services) being monitored
    Optimise for monitoring distributed, ephemeral, 'cloud-native', containerised microservices
    Fit metrics to models in order to understand relationships (this is a new rule)

  • Or to put more simply….

    Use the right tool for the job.
  • It’s about communication between teams.

    So, it’s not only about changing
    the software architecture,
    but also changing the way
    software teams are organized.
  • - in conjunction with breaking apart the architecture, we also broke apart the organization
    - we split up the hierarchical org into small teams
    - we called them 2-pizza teams, because if they got larger than you could feed with 2 pizzas, we'd break them up
    - in reality, the target number is about 8 people per team, so I personally think the 2 pizza goal is maybe a little too frugal
    - another important change that went along with this is cultural
    - when we split up the org, we gave the teams full autonomy
    - they became small startups that owned every aspect of their service
    - they worked directly with their customers (internal or external), set their roadmap, designed their features, wrote the code, ran the tests, deployed to production, and operated it
    - if there was pain anywhere in the process they felt it
    - operational issue in the middle of the night, the team was paged
    - lack of tests breaking customers, the team got a bunch of support tickets
    - that motivation ensured the team focused on all aspects of the software lifecycle, broke down any barriers between the phases, and made the process flow as efficiently as possible
    - we didn't have this term at the time, but this was the start of our "DevOps" culture

  • - in conjunction with breaking apart the architecture, we also broke apart the organization
    - we split up the hierarchical org into small teams
    - we called them 2-pizza teams, because if they got larger than you could feed with 2 pizzas, we'd break them up
    - in reality, the target number is about 8 people per team, so I personally think the 2 pizza goal is maybe a little too frugal
    - another important change that went along with this is cultural
    - when we split up the org, we gave the teams full autonomy
    - they became small startups that owned every aspect of their service
    - they worked directly with their customers (internal or external), set their roadmap, designed their features, wrote the code, ran the tests, deployed to production, and operated it
    - if there was pain anywhere in the process they felt it
    - operational issue in the middle of the night, the team was paged
    - lack of tests breaking customers, the team got a bunch of support tickets
    - that motivation ensured the team focused on all aspects of the software lifecycle, broke down any barriers between the phases, and made the process flow as efficiently as possible
    - we didn't have this term at the time, but this was the start of our "DevOps" culture

  • Or to put more simply….

    Use the right tool for the job.
  • - with these new tools, we completed the puzzle
    - the teams were decoupled and they had the tools necessary to efficiently release on their own
  • - with these new tools, we completed the puzzle
    - the teams were decoupled and they had the tools necessary to efficiently release on their own
  • - with these new tools, we completed the puzzle
    - the teams were decoupled and they had the tools necessary to efficiently release on their own
  • - with these new tools, we completed the puzzle
    - the teams were decoupled and they had the tools necessary to efficiently release on their own
  • - with these new tools, we completed the puzzle
    - the teams were decoupled and they had the tools necessary to efficiently release on their own
  • - with these new tools, we completed the puzzle
    - the teams were decoupled and they had the tools necessary to efficiently release on their own
  • But more important than the technologies are the principles we talked about.
  • Put this perspective
    - Operating a monolith may be easier
    - When you can’t innovate quickly
    - Understand your domain
  • So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
    And we identified a few root causes.
  • So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
    And we identified a few root causes.
  • So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
    And we identified a few root causes.
  • There’s no shortage of resources
  • So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
    And we identified a few root causes.
  • ×