Microservices and Teams at Amazon
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:
- Connect only through APIs.
- Connect over HTTPS.
- Largely black boxes to each other.
When comparing microservices with SOA Munns notes some distinctive differences
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.