Microservices and Teams at Amazon

by Jan Stenberg on Dec 31, 2015 |

The microservices pattern are changing how we build applications and team structure is extremely important to be successful in building and running these microservices Chris Munns stated in a talk about how microservices at enterprise scale are built at Amazon at the earlier I Love APIs 2015 conference.

Munns, Business Development Manager for DevOps at Amazon, refers to Wikipedia for a definition of microservices but also states four constraints:

  • Single-purpose.
  • Connect only through APIs.
  • Connect over HTTPS.
  • Largely black boxes to each other.

When comparing microservices with SOA Munns notes some distinctive differences

Microservices SOA
  • Many very small components
  • Business logic lives inside a single service domain
  • Simple wire protocols, e.g. HTTP with XML or JSON
  • API driven with SDKs/Clients
  • Fewer more sophisticated components
  • Business logic can live across multiple domains
  • Enterprise Service BUS (ESB) like layers between services
  • Middleware

The well-known term two pizza teams for describing size of teams at Amazon are actually called Service teams and own the “primitives” they build, which includes product planning, development work and operational and client support work. They have full ownership and accountability and are also responsible for the day-to-day operations and maintenance, known as you build it, you run it. This means that quality assurance (QA), being on call and operations all exists within a service team, but Munns notes that some of the people in these roles may be shared across the organisation.

For the teams this means a lot of freedom but they are empowered and held to high standards through:

  • Thorough training.
  • Patterns & practices defined at scale from 20+ years of experience.
  • Regular metric reviews both from a business and a technical perspective.
  • Sharing of new tools, services and technologies by internal experts.

Looking at what is important for Amazon working with small teams and microservices Munns’ advice to other organisations heading the same way includes:

  • Culture; emphasizing that ownership and accountability go hand in hand, and that larger teams typically move slower that smaller teams. Insist on standards of excellence but not how it’s done.
  • Practices; noting the importance of continuous integration (CI) and delivery (CD) as well as simplifying operational tasks.
  • Tools; for the mentioned practices, for infrastructure management, for metrics and monitoring and for communication and collaboration.

Munns lastly emphasizes the importance of establishing a pattern for services and clients, thus preventing an organization from reinventing the same basic parts for things like communication, authorization, abuse prevention and service discovery. He also notes how important metrics of builds, hosts, services, etc. are to find out if the infrastructure is running as expected, if SLAs are met and so on.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.