Monolith Architecture describes an approach in software design, in which all the components of a software system are deployed together. Together means within a single binary, or within a single installation. Components can refer to whole tiers or logical parts within one.
The advantages are
- Easy deployment: no coordination with other moving parts necessary
- Easy development: all other parts are close by and easily adapted
- Naturally understood: follows from continuously adding functionality
All of the advantages, as Martin Fowler observed, are strong in the early stages of most application lifecycles, but weaken and inverse with growing complexity. This leads to a host of disadvantages, including:
- Tightly coupled: components tend to become strongly dependent on each other; makes them hard to replace / interchange
- Hard to scale: components cannot be scaled individually, the whole must scale (inefficient, costly)
- Leads to vastly Complex Systems: growing functionality in one place, that becomes ever harder to understand
- Hard to maintain, highly fragile: Here be dragons, no one really knows anymore
- Hard to collaborate on: Teams with single responsibilities (of individual components) not possible
- Hides Technical Debt, buried in complexity and historical “reasons”
- Potential for extremely high bus factor
Hence, the later life of growingly complex applications require a different approach: Microservice Architecture. It is entirely possible, actually mostly recommended, to start out monolithic and then use the Strangler Pattern (or akin) to move the architecture.
