An important aspect is the technological decoupling. Microservices can use different technologies and can have entirely different structures internally. This means that developers have less need to coordinate. Only fundamental decisions have to be made together. All other technical decisions can be made by the teams.
Each microservice can be brought into production independently of the other microservices. There is also no need to coordinate release dates or test phases across teams. Each team can choose its own speed and its own dates. A delayed release date of one team does not influence the other teams.
Separate Requirement Streams
The teams should each implement independent stories and requirements. This enables each team to pursue its own business objectives.
Three Levels of Independence
Microservices enable independence on three levels:
- • Decoupling via independent releases: each team takes care of one or multiple microservices. The team can bring them into production independently of the other teams and the other microservices.
- • Technological decoupling: the technical decisions made by a certain team concern, first of all, their microservices and none of the other microservices.
- • Domain-based decoupling: the distribution of the domain in separate components enables each team to implement their own requirements.
For deployment monoliths, in contrast, the technical coordination and deployment concerns the entire monolith (see Figure 12.1). This necessitates such a close coordination between the developers that in the end all developers working on the monolith have to act like one team.
Figure 12.1 Deployment Monolith
Figure 12.2 Separation into Microservices
A prerequisite for the independence of the microservice teams is that the architecture really offers the necessary independence of the microservices. This requires, first of all, good domain architecture. This architecture also enables independent requirement streams for each team.
There are the following teams in the example from Figure 12.2:
- • The team “user registration” takes care of how users can register in the e-commerce shop. A possible business objective is to achieve a high number of registrations. New features aim at optimizing this number. The components of the team are the processes that are necessary for the registration and the UI elements. The team can change and optimize them at will.
- • The team “order process” addresses how the shopping cart turns into an order. Here, a possible objective is that as many shopping carts as possible turn into orders. The entire process is implemented by this team.
- • The team “product search” improves the search for products. The success of this team depends on how many search processes lead to items being put into a shopping cart.
Of course, there can be additional teams with other goals. Overall this approach distributes the task of developing an e-commerce shop onto multiple teams, which all have their own objectives. The teams can largely independently pursue their objectives because the architecture of the system is distributed into microservices that each team can develop independently—without much need for coordination.
In addition, small projects have many more advantages:
- • Estimations are more accurate since estimates concerning smaller efforts are easier to make.
- • Small projects are easier to plan.
- • The risk decreases because of the more accurate estimates and because of the better forecast reliability.
- • If there still is a problem, its effects are smaller because the project is smaller.
In addition, microservices offer much more flexibility. This makes decisions faster and easier because the risk is smaller, and changes can be implemented more rapidly. This ideally supports agile software development that relies on such flexibility.