Chapter 2. Multiple Rates of Change

Do parts of your system need to evolve at different speeds, or in different directions? In any system, some modules are hardly touched while others seem to change every iteration. Separating them into microservices can be useful, allowing each component to have independent life cycles.

Parts of Your System Evolve at Different Rates

It should be obvious to anyone involved in a software project that not every part of your system evolves at the same rate. Some components are changed constantly while others haven’t been modified in weeks or months, even years. If aspects of your system evolve at different speeds, you might need microservices. To illustrate, let’s pick an example—say, a monolithic online retail app, as described in Figure 2-1.

The Monolith
Figure 2-1. For your consideration…the Monolith!

Odds are, the cart module probably hasn’t changed much and the inventory system is really stable.1 Meanwhile, your product owner constantly wants changes to the recommendation engine, and no one has ever said “Our search is too good.” In the monolith, everything has to move at the same rate, which is part of the rationale behind quarterly release cycles.

Today we have options. Splitting those two modules—recommendation engine and search—into microservices would allow the respective pieces to iterate at a faster pace. This approach will help you quickly ...

Get Responsible Microservices now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.