Small and Simple
Where software is tending towards complexity, look for opportunities to break it down into smaller and simpler systems.
Rationale
Monolithic applications can be successful, but it has become common for organisations to feel frustrations with them as they grow in complexity and scope over time. Change cycles are tied together – a change made to a small part of the application requires the entire monolith to be rebuilt, retested and deployed.
Over time it is often hard to keep a good modular structure, making it challenging to keep changes that ought to affect only one module contained within that module. Often, a bug in one part of the system can affect other parts of the system in unexpected ways. Scaling requires scaling of the entire application rather than parts of it that require greater resources. Scaling requires uplift of the entire application rather than only the parts that require greater resources.
Software which focuses on doing fewer things well is easier to reason about. This benefits its reliability, understandability and makes it easier to test.
Implications
- It is important to be fully aware of the interconnected nature of the overall system before looking to decompose it - premature abstraction can accidentally lead to an overly complex distributed systems if not well understood.
- Build systems around business capabilities that change independently to others, rather than individual features or technologies.
- Aim to decompose your system into a suite of smaller systems, each of which focus on doing a small number of things well.
- Beware the risks of creating a distributed monolith.
- Services are independently deployable and independently testable.
- Reduce the burden of managing several smaller systems through automation.
- In distributed systems, it is important to design for failure.