When we have a tightly coupled architecture, small changes can result in large scale failures. As a result, anyone working in one part of the system must constantly coordinate with anyone else working in another part of the system they may affect, including navigating complex and bureaucratic change management processes.
Furthermore, to test that the entire system works together requires integrating changes with the changes from hundreds, or even thousands, of other devel- opers, which may, in turn, have dependencies on tens, hundreds, or thousands of interconnected systems. Testing is done in scarce integration test environ- ments, which often require weeks to obtain and configure. The result is not only long lead times for changes (typically measured in weeks or months) but also low developer productivity and poor deployment outcomes.
In contrast, when we have an architecture that enables small teams of devel- opers to independently implement, test, and deploy code into production safely and quickly, we can increase and maintain developer productivity and improve deployment outcomes. These characteristics can be found in service-oriented architectures (SOAs) first described in the 1990s, in which services are independently testable and deployable. A key feature of SOAs is that they’re composed of loosely coupled services with bounded contexts.‡ Having architecture that is loosely coupled means that services can update in production independently, without having to update other services. Services must be decoupled from other services and, just as important, from shared databases (although they can share a database service, provided they don’t have any common schemas).
Bounded contexts are described in the book Domain Driven Design by Eric J. Evans. The idea is that developers should be able to understand and update the code of a service without knowing anything about the internals of its peer services. Services interact with their peers strictly through APIs and thus don’t share data structures, database schemata, or other internal representations of objects. Bounded contexts ensure that services are compartmentalized and have well-defined interfaces, which also enables easier testing.
‡ These properties are also found in “microservices,” which build upon the principles of SOA. One popular set of patterns for modern web architecture based on these principles is the “12- factor app.”
Promo
- Not
for distribution
90 • Part II
Randy Shoup, former Engineering Director for Google App Engine, observed that “organizations with these types of service-oriented architectures, such as Google and Amazon, have incredible flexibility and scalability. These or- ganizations have tens of thousands of developers where small teams can still be incredibly productive.”
KEEP TEAM SIZES SMALL (THE “TWO-PIZZA TEAM” RULE)
Conway’s Law helps us design our team boundaries in the context of desired communication patterns, but it also encourages us to keep our team sizes small, reducing the amount of inter-team communication and encouraging us to keep the scope of each team’s domain small and bounded.
As part of its transformation initiative away from a monolithic code base in 2002, Amazon used the two-pizza rule to keep team sizes small—a team only as large as can be fed with two pizzas—usually about five to ten people. This limit on size has four important effects:
1. It ensures the team has a clear, shared understanding of the system they are working on. As teams get larger, the amount of commu- nication required for everybody to know what’s going on scales in a combinatorial fashion.
2. It limits the growth rate of the product or service being worked
on. By limiting the size of the team, we limit the rate at which their system can evolve. This also helps to ensure the team main- tains a shared understanding of the system.
3. It decentralizes power and enables autonomy. Each two-pizza team (2PT) is as autonomous as possible. The team’s lead, working with the executive team, decides on the key business metric that the team is responsible for, known as the fitness function, which becomes the overall evaluation criteria for the team’s experiments. The team is then able to act autonomously to maximize that metric.†
4. Leading a 2PT is a way for employees to gain some leadership experience in an environment where failure does not have cata- strophic consequences. An essential element of Amazon’s strategy
† In the Netflix culture, one of the seven key values is “highly aligned, loosely coupled.”
Promo
- Not
for distribution
Chapter 7 • 91 was the link between the organizational structure of a 2PT and the architectural approach of a service-oriented architecture.
Amazon CTO Werner Vogels explained the advantages of this structure to Larry Dignan of Baseline in 2005. Dignan writes:
“Small teams are fast...and don’t get bogged down in so-called administrivia….Each group assigned to a particular business is com- pletely responsible for it….The team scopes the fix, designs it, builds it, implements it and monitors its ongoing use. This way, technology programmers and architects get direct feedback from the business people who use their code or applications—in regular meetings and informal conversations.”
Another example of how architecture can profoundly improve productivity is the API Enablement program at Target, Inc.