Reasons for Using Microservices
Microservices offer many benefits, and these are discussed in this chapter. A detailed understanding of the benefits enables a better evaluation of whether microservices represent a sensible approach in a given use case. The chapter continues the discussion from section 1.2 and explains the benefits in more detail.
Section 4.1 explains the technical benefits of microservices. However, microservices also influence the organization. This is described in section 4.2. Finally, section 4.3 addresses the benefits from a business perspective.
Microservices are an effective modularization technique. Calling one microservice from another requires the developer to consciously create code that communicates over the network. This does not happen by accident; a developer has to make that happen within the communication infrastructure. Consequently, dependencies between microservices do not creep in unintentionally; a developer has to generate them explicitly. Without microservices, it is easy for a developer to just use another class and unwittingly create a dependency that was not architecturally intended.
Let us assume, for instance, that in an e-commerce application the product search should be able to call the order process, but not the other way round. This ensures that the product search can be changed without influencing the order process, as the product search does not use the order process. Now a dependency between the product search and the order process is introduced, for example, because developers found a piece of functionality there that was useful for them. Consequently, the product search and order processes now depend on each other and can only be changed together.
Once undesired dependencies have started to creep into the system, additional dependencies rapidly accrue. The application architecture erodes. This erosion can normally only be prevented with the use of architecture management tools. Such tools have a model of the desired architecture and can discover when a developer has introduced an undesired dependency. The developer can then immediately remove the dependency before any harm is done and the architecture suffers. Appropriate tools are presented in section 7.2.
In a microservices-based architecture, the product search and order processes would be separate microservices. To create a dependency, the developer would have to explicitly implement it within the communication mechanisms. This presents a relatively high barrier and consequently does not normally happen unnoticed, even without architecture management tools. This reduces the chances that the architecture erodes because of dependencies between microservices. The microservice boundaries act like firewalls, which prevent architectural erosion. Microservices offer strong modularization because it is difficult to overstep the boundaries between modules.