Microservices enable the independence of teams in regard to technical decisions and deployments (section 12.1). This enables the teams to independently implement requirements. In the end this makes it possible for numerous small teams to work together on a large project. This reduces the communication overhead between the teams. Since the teams can deploy independently, the overall risk of the project is reduced.
Ideally the teams should be put together in a way that enables them to work separately on different domain aspects. If this is not possible or requires too much coordination between the teams, collective code ownership can be an alternative (section 12.2). In that case each developer can change all of the code. Still, one team has the responsibility for each microservice. Changes to this microservice have to be coordinated with the responsible team.
Section 12.3 described that microservices have a macro architecture that comprises decisions that concern all microservices. In addition, there is the micro architecture, which can be different for each microservice. In the areas of technology, operations, domain architecture, and testing there are decisions that can either be attributed to micro or macro architecture. Each project has the choice to delegate them to teams (micro architecture) or to centrally define them (macro architecture). Delegating into teams is in line with the objective to achieve a large degree of independence and is therefore often the better option. A separate architecture team can define the macro architecture; alternatively, the responsible team is assembled from members of the different microservice teams.
Responsibility for the macro architecture is closely linked to a concept for technical leadership (section 12.4). Less macro architecture means more responsibility for the microservice teams and less responsibility for the central architecture team.
Though microservices profit from merging operations and development to DevOps (section 12.5), it is not strictly required to introduce DevOps to do microservices. If DevOps is not possible or desired, operations can define guidelines in the context of macro architecture to unify certain aspects in order to ensure a smooth operation of the microservice-based system.
Microservices should always implement their own separate requirements. Therefore, it is best when each microservice can be assigned to a certain department on the business side (section 12.7). If this is not possible, the product owners have to coordinate the requirements coming from different departments in such a way that each microservice has clearly prioritized requirements. When collective code ownership is used, a product owner and his/her team can also change microservices of other teams, which can limit the communication overhead. Instead of coordinating priorities, a team will introduce the changes that are necessary for a new feature by itself—even if they concern different microservices. The team responsible for the modified microservice can review the introduced changes and adjust them if necessary.
Code can be reused in a microservices project if the code is treated like an open source project (section 12.8). An internal project can be handled like an internal open source project—or can in fact be turned into a public open source project. The effort for a real open source project is high, which has to be considered. Therefore, it can be more efficient not to reuse code. Besides, the developers of the open source project have to prioritize domain requirements versus changes to the open source project, which can be a difficult decision at times.
Section 12.9 discussed that an introduction of microservices without changes to the organizational structure at the development level does not work in real life. When there are no domain-focused teams that can develop certain domain aspects independently of other teams, it is practically impossible to develop multiple features in parallel and thus to bring more features to the market within the same time. However, this is just what microservices were meant to achieve. Sustainable development, an easy introduction of continuous delivery, independent scaling of individual microservices, or a simple handling of legacy systems are still possible. Operations and an architecture team can define the macro architecture so that changes to the organizational structure in this area are not strictly required. Ideally, the requirements of the departments are always reflected by one microservice. If that is not possible, the product owners have to coordinate and prioritize the required changes.
- • Microservices have significant effects on the organization. Independent small teams that work together on a large project are an important advantage of microservices.
- • Viewing the organization as part of the architecture is an essential innovation of microservices.
- • A combination of DevOps and microservices is advantageous but not obligatory.
This page intentionally left blank