A distributed system divides functionality among independently operating services that communicate across process or network boundaries. Unlike a monolith, its services can evolve, scale, and be changed by teams more independently, but the architecture introduces coordination and operational complexity. section 1.4.2 section 2.1
Distributed applications trade monolithic simplicity for finer operational and team-level control:
- Teams work against stronger service boundaries instead of coordinating every change in one shared codebase. section 1.4.2
- Services can scale according to their own load rather than requiring the entire application to scale together. section 1.4.2
- Operations must account for networking latency, failures in individual services, and eventual inconsistencies. section 2.1
A controllable cloud-native application
A walking-skeleton application provides a practical distributed-system model that can be configured, experimented with, and deliberately broken. Running it exposes the effects of service failures, network latency, and eventual inconsistencies; Kubernetes supplies the cluster environment. section 2.1
Figure 1.20 In a monolith application, all the logic to implement different use cases are bundled together. This push different teams to work on the same codebase and requires them to have complex coordination practices to avoid conflicting changes.
Compare bundled monolithic logic with independently evolving services and the coordination practices each architecture requires. section 1.4.2
