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.
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 the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.