By the end of the lesson, you can define the monolith, list its advantages and costs along the seven aspects, and say when it is worth keeping.
Why start with the monolith?
The monolith is the base case to which the other architectures are compared. Without understanding what it gives and what it takes away, the advantages and costs of splitting cannot be weighed. The monolith is also often a good choice, not just a starting point.
What is the monolith?
A monolith is an application whose main functions are parts of a single deployment unit. This refers to the boundary of release and execution, not to the quality of the code: the internal structure of a monolith can be layered, component-based or modular, but it can also be untidy. According to microservices.io, the monolithic architecture builds the application as a single deployable and executable component with a single database.
A monolith does not necessarily run on one machine: several identical instances can run behind a load balancer. Even then, several copies of one application run, not several services.
flowchart LR
U["Client"] --> H["HTTP entry"]
subgraph M["Monolith: one deployment unit"]
H --> A["Business functions"]
A --> R["Data access"]
end
R --> DB[("Database")]
Internal calls are function calls within a process. Control flow, exceptions and the transaction can be followed in one place.
By aspect
Aspect
The monolith typically
Coupling
The boundary between parts is held only by discipline; it easily disappears
Deployability
One release, simple, but every change affects the same package
Scaling
The whole application can be scaled; individual parts cannot separately
Data management
Shared database, local transactions
Consistency
The data of several functions can be modified in one transaction
Failure handling
One call stack, one log source; but one fault can affect the whole process
Team and operations cost
Few moving parts; in a large team the shared code requires coordination
As advantages of the monolith, microservices.io mentions simpler, more efficient local communication and local database transactions (in detail in lesson 5.1); as drawbacks, the large shared codebase, the slower release process, the single technology set, and the fact that the scaling, availability or security properties of the parts cannot be separated.
Where does the cost appear?
A significant part of the costs stems from shared resources and the shared release. A memory leak affects the whole process. If only one function needs a lot of processor time, more instances of the whole application must be started, unless the load is taken out into a separate running unit. In a large organisation the shared code and the shared release process can become a point of coordination.
Important: some of these difficulties come not from the existence of the monolith, but from bad internal boundaries or neglected tests. Splitting does not fix them by itself.
When is it worth keeping?
If the main parts of the application change together, need shared transactions, and the team handles a single release efficiently, the monolith is a good choice. Martin Fowler justifies the "monolith first" strategy by saying that service boundaries are hard to set correctly in advance, and moving functions between services is much harder than within a monolith. He adds that this is not automatic: only a well-modular monolith can be split later.
Common misconceptions
Statement
Clarification
"A monolith runs on one server."
It can run in several instances; the point is the shared deployment unit.
"A monolith is untidy code."
Its internal structure can be tidy and checked.
"A monolith cannot be scaled."
It can be scaled horizontally; only the individual parts cannot separately.
"A modern system cannot be a monolith."
The choice depends on the requirements, not fashion.
In short
A monolith is a single deployment unit with a shared execution and release boundary.
Its advantage is simplicity, the local call and the local transaction.
Its price is the shared release, shared resources and the lack of selective scaling.
Bad structure is not a property of the monolith and is not fixed by splitting.
Review questions
Why does a monolith not become a microservice just because it runs in six instances?
In which aspect is the monolith advantageous, and in which is it disadvantageous?
When is keeping the monolith justified instead of splitting?
The Monolith: One Deployment Unit
Objectives
By the end of the lesson, you can define the monolith, list its advantages and costs along the seven aspects, and say when it is worth keeping.
Why start with the monolith?
The monolith is the base case to which the other architectures are compared. Without understanding what it gives and what it takes away, the advantages and costs of splitting cannot be weighed. The monolith is also often a good choice, not just a starting point.
What is the monolith?
A monolith is an application whose main functions are parts of a single deployment unit. This refers to the boundary of release and execution, not to the quality of the code: the internal structure of a monolith can be layered, component-based or modular, but it can also be untidy. According to microservices.io, the monolithic architecture builds the application as a single deployable and executable component with a single database.
A monolith does not necessarily run on one machine: several identical instances can run behind a load balancer. Even then, several copies of one application run, not several services.
flowchart LR U["Client"] --> H["HTTP entry"] subgraph M["Monolith: one deployment unit"] H --> A["Business functions"] A --> R["Data access"] end R --> DB[("Database")]Internal calls are function calls within a process. Control flow, exceptions and the transaction can be followed in one place.
By aspect
As advantages of the monolith, microservices.io mentions simpler, more efficient local communication and local database transactions (in detail in lesson 5.1); as drawbacks, the large shared codebase, the slower release process, the single technology set, and the fact that the scaling, availability or security properties of the parts cannot be separated.
Where does the cost appear?
A significant part of the costs stems from shared resources and the shared release. A memory leak affects the whole process. If only one function needs a lot of processor time, more instances of the whole application must be started, unless the load is taken out into a separate running unit. In a large organisation the shared code and the shared release process can become a point of coordination.
Important: some of these difficulties come not from the existence of the monolith, but from bad internal boundaries or neglected tests. Splitting does not fix them by itself.
When is it worth keeping?
If the main parts of the application change together, need shared transactions, and the team handles a single release efficiently, the monolith is a good choice. Martin Fowler justifies the "monolith first" strategy by saying that service boundaries are hard to set correctly in advance, and moving functions between services is much harder than within a monolith. He adds that this is not automatic: only a well-modular monolith can be split later.
Common misconceptions
In short
Review questions
Learning resources