A distributed system runs application components across multiple networked processes or computing environments. Containerizing a monolith lets features move into independently managed containers without requiring an all-at-once rewrite. section 1.1.2
Practical properties emerge as the application is split into components:
- Components communicate over a private container network while remaining isolated from outside access. section 1.1.2
- Features can be tested, scaled, and managed independently, with different technologies selected for different requirements. section 1.1.2
- Production platforms should start available components without enforcing a rigid startup order, then replace components that fail dependency or health checks. section 8.5
Self-healing production
A cluster may run many API and web containers across several servers. If one API container cannot start or runs out of memory, the platform can restart or replace it while the remaining containers continue serving users. section 8.5
Figure 1.3 Decomposing a monolith into a distributed application without rewriting the whole project. All the components run in Docker containers, and a routing component decides whether requests are fulfilled by the monolith or a new microservice.
Trace a monolith’s gradual decomposition into Docker containers, with routing deciding whether requests reach the original monolith or a new microservice. section 1.1.2
