However, microservices projects require special conditions in order to reach their full potential. This means having two-pizza teams working on them - a term coined at Amazon, when Jeff Bezos instituted the rule that every internal team should be small enough that it can be fed with two pizzas. The goal? Efficiency, productivity, and effective communication.
By allowing two-pizza teams to act autonomously and take ownership over their applications, microservices drive powerful and optimized technical architectures.
Optimized structures & autonomous work
Software development is all about collaboration, communication, and continuous learning, and microservices help create structures that allow teams to thrive. Ultimately, technical success depends on how the team communicates and how it is structured, and all of this leads to teams taking ownership and being in full control of the final product.
In this sense, microservices go hand-in-hand with agile methodologies, and allow teams to organize in smaller “two-pizza” groups where communication is better and relationships are easier to form.
The importance of team communication and cohesiveness shouldn’t be overlooked. In fact, Conway’s Law states that organizations design systems that mirror their own communication structure. If there is not effective communication between team members, there will not be effective communication between components of applications.
By splitting up the application into individual components through containerization, microservices inherently allow cross-functional, agile teams to progress quickly without having to coordinate and synchronize with each team. Teams are able to collectively build product architectures from relatively independent microservices, each being size-appropriate for a two-pizza team to successfully develop, with communication lines naturally supporting the project architecture. Team members can then go on to leverage whatever technology works best for the job - be it cloud native business intelligence, artificial intelligence or others - and ensure communication between components using traditional REST APIs, message brokers or other technologies
This autonomy allows developers to make optimal choices to help the architecture function at its best, without having to worry about coordinating with other teams.
You build it, you own it
Microservices provide development teams with a newfound level of ownership when it comes to the products they build. Developers can work on a functionality from start to finish. They are responsible for the full development path, from building to releasing, allowing them to speed up release cycles. This is something that would be difficult in a monolith architecture, where developers usually work on separate parts of functionalities rather than the entire feature, making individual efforts less visible.
In fact, one of the core tenets of microservices architectures is the principle of “Products not Projects” which states that “a team should own a microservice over its full lifetime.” This ethos of “you build it, you own it” means that developers feel like they are making tangible contributions to the overall business function, giving more meaning and a sense of purpose to the work.
Developers have daily contact with how their software behaves in production, ensuring responsibility and tying them closer to the end user. This level of ownership also leads to developers becoming specialists in a specific business area, resulting in higher-quality products built with expertise.
With this being said, it’s crucial that microservices teams don’t inhibit collaboration by becoming too control-centric and preventing outside input on their “owned” service. Ownership and wider-team collaboration must go hand-in-hand.
Microservices are sweeping the world of software development, which should come as no surprise considering the ways in which they empower development teams. Armed with microservices, developers are able to work more efficiently, autonomously, and with a greater sense of ownership than ever before.