Tradeoffs, Prioritizing Advantages, & Levels
In this lesson, we'll look at some ways we can prioritize advantages of the microservice architecture and some potential trade-offs that should be considered.
We'll cover the following
Which of the discussed reasons for switching to microservices is the most important depends on the individual scenario. The use of microservices in a greenfield system is the one exception.
More often, a deployment monolith is replaced by a microservice system (see chapter 4). In that case, different advantages are relevant.
The easier scaling of development can be an important reason for the introduction of microservices in such a scenario. Often, it is impossible to work quickly enough with a large number of developers on a single deployment monolith.
The easy migration away from the legacy deployment monolith facilitates the introduction of microservices in such a scenario.
Continuous delivery is often an additional goal. The aim is to increase the speed and reliability with which changes can be brought into production.
The scaling of development is not the only scenario for a migration. For example, when a single Scrum team wants to implement a system with microservices, scaling development would not be a sensible reason since the organization of development is not large enough for this. However, other reasons are possible. Continuous delivery, technical reasons like robustness, independent scaling, free technology choice, or sustainable development all play a role in such a scenario.
In the end, it is important to focus on increasing the business value. Depending on the scenario, an advantage in one of the previously mentioned areas might make the company more profitable or competitive, for example, faster time to market or better reliability of the system.