Microservice architecture divides an enterprise system into small applications, each with a narrow responsibility. Services interact through an API, service bus, or message queue. A strong service has its own data store, execution environment, and release cycle, so it can change without requiring the rest of the system to be released with it. section 8.6
The appeal is lower change risk and the freedom to choose tools suited to each service’s role. Contrast this with a tightly coupled monolith: even a small library upgrade can have unintended effects elsewhere. The choice is not absolute. Enterprises may combine both approaches, and a monolith can still suit a proof of concept. section 8.6 section 8.9
Replacing a legacy language incrementally
If a legacy language needs replacing, look for areas that can be refactored into services. Carving out those areas can avoid a complete rewrite. First weigh the wider technology landscape, including the recruitment market; unfamiliarity with a language alone is not a reason to replace it. section 8.8.1
Table 8.4 Microservices vs. monolithic checklist (view table figure)
Use the checklist to assess how monolithic the current system is. Three or more yes answers point toward a monolithic architecture; the questions test shared code and data, outage scope, server structure, and upgrade downtime. section 8.6













