A distributed system runs an application as separate services that communicate over a network. Microservices are one way to organize those services, not a requirement that every service be tiny. Compared with a monolith, this structure can make a growing application easier to divide across teams and scale, but it takes more work to build and run. section 1.0 section 1.12 section 1.1
The practical gains come from treating services separately. A heavily used service can receive more resources without scaling everything else. Updating one service can limit deployment risk and make a rollback smaller, though a faulty update can still break part of the application. section 1.9
Distribution also introduces new techniques, protocols, and tradeoffs. Do not assume that splitting an application automatically makes it simpler: building, operating, and understanding the whole system are difficult. Weigh the benefits against those costs before choosing how far to split it. section 1.1 section 1.10.2
Stop when the split stops paying off
A conversion from a monolith might leave a smaller monolith alongside several services. Early splits can bring substantial value; continuing toward ever-smaller services may bring diminishing returns until the costs outweigh the gains. section 12.7.2
Figure 12.28 A timeline of conversion to microservices. In the early days, you get a high ROI. As you proceed, however, you’ll get diminishing ROI, and it might not make sense to go all the way to the developer’s utopia of microservices.
The conversion timeline shows why reaching a useful distributed architecture need not mean splitting every component into a microservice. section 12.7.2
