Microservices at Amazon
As popularized by Yegge’s Google platform rant, Amazon is regarded as the first company that got microservices and APIs right. Chris Munns, business development manager of DevOps at AWS, provided an excellent talk at I Love APIs 2015 about how enterprise microservices are really built at Amazon, and what makes them work at enterprise scale.
Chris wasn’t the only one to discuss microservices; people from several businesses presented at I Love APIs 2015 on how to build microservices including Verizon, Magazine Luiza, Netflix, Burberry, Belly, and Zoosk.
Chris started his discussion with an architectural overview, the main points of which were:
- Lots of microservices talking to lots of services
- Fifty million deployments per year
- Connect only through APIs over HTTP
- Mostly black box between services
Amazon internal services architecture circa 2009
He gave us an overview of how Amazon organizes to deliver enterprise microservices:
- Run by two-pizza teams (team size limited to two pizzas for a team meal)
- A team owns one or more microservices; no microservice should be bigger than what a two-pizza team can run
- Teams control their own destiny (product planning, Dev, Ops, and QA)
- Teams exist as part of larger orgs, such as Amazon.com (retail) or Prime, for example
On the tooling front, Chris said that Amazon:
- Had to build lots of tooling itself because no company deployed microservices at Amazon’s scale
- Built tooling as a set of microservices
- Created Apollo, a custom deployment tool that enables integrated health checks to ensure new software functions as expected and one-click deployment and rollbacks
- Created Pipelines, a continuous delivery tool supporting Amazon development workflows that enables automated action taking and alerting
Chris also described a host of Amazon best practices:
- Mostly no coordination between teams when deploying services
- Each team releases on its own schedule resulting in 50 million deployments annually
- Lots and lots of monitoring
- Host metrics (is the infrastructure I’m running on sound?)
- Service metrics (am I meeting my performance SLAs?)
- Log analytics (is something erroring out?)
- Build metrics (did someone check in crappy code?)
Building all services, all the time, in parallel
Finally, Chris described how AWS released developer tools that were battle-proven for building microservices at Amazon, including CodePipeline (the AWS version of Pipelines), CodeDeploy (the AWS version of Apollo), and API Gateway (hundreds to teams all talking to each other requires properly protecting services and revoking keys to keep running).
If you want to learn more, please let us know in the Apigee Community. Stay tuned for more on this topic from us; we’re also planning webinars with Amazon on enterprise microservices, so let us know if there’s anything you’d like us to cover.