Amazon has had a long-time culture of having smaller teams that are self-contained, fully responsible for an end-to-end execution from planning to operations. These teams are nimble, have different roles (product management, developer, QA engineer, infra/tooling engineers, and so on) to manage all aspects of the software delivery cycle, but the team is big enough to be fed by two pizzas!

The whole concept around the two-pizza team is to keep them independent, fast moving, and better collaborating to avoid any overheads in terms of communication and processes. This is also an ideal setup from a DevOps perspective, where the team is responsible for a complete release life cycle, which also includes deploying to production environments and infrastructure management.

The other benefit that this setup provides is that each team is responsible for a specific piece of business functionality that often integrates with other components in the system using simple APIs that are REST/HTTP-based. This is essentially the core concept around a microservice, which further brings in agility and loosely connected components to bring in greater resilience and scalability to the overall system.

Amazon has multiple different businesses and teams internally that follow these principles and provide everyone with a common scalable software deployment platform, called Apollo. This deployment service has been used by thousands of developers across Amazon over multiple years, so it has been iterated upon and made robust for enterprise grade standards.

Based on this internal experience, Amazon has created many of the AWS capabilities as well. They range from simple APIs, SDKs, and CLI support, to fully-fledged services to enable source code management, continuous integration, and continuous delivery/deployment to software pipeline management. We will explore more of these in the next section.