Should you choose a microservices architecture over a monolith? What are the pros and cons in reality?
Monoliths
- Single deployment.
- Single runtime single codebase.
- Interaction between classes is most often synchronous.
- Most often every layer is in a separate package.
Microservices
- Many small modules with specific functionality
- More than one codebase
- Every microservice is a separate deployment
- Every microservices has its own DB (or One DB depending on the business)
- Ensures module independence
Monoliths vs Microservices
A monolithic application puts all its functionality into a single process…
… and scales by replicating the monolith on multiple servers
A microservices architecture puts each element of functionality into a separate service..
… and scales by distributing these services across servers, replicating as needed.
Downsides of monoliths
- “spaghetti”, “big ball of mud” (if you write bad code, architecture doesn’t matter)
- You need a full redeploy
- Programmers often violate the layer boundaries
- Classes often “leak” their implementation
- Hard to work with multiple teams
- Hard to manage
Benefits of Microservices
- Deployment automation culture
- Hides implementation details
- Decentralization
- Option to use multiple programming languages
- Separate deployment, separate monitoring
- Continuous deployment
- Highly maintainable and testable
- Agility
Microservices downsides
- Network overhead
- Transaction duplicate (if using one DB, this is not fact)
- Duplicating common data
- Complicated deployment pipeline
- Dependencies
- Development sprawl
- Exponential infrastructure costs
- Added organizational overhead – Teams need to add another level of communication and collaboration to coordinate updates and interfaces.
- Debugging challenges
- Lack of clear ownership
Microservices should we?
“…don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services” Martin Fowler
“the design thinking and decomposition strategy required to create a good microservices architecture are the same as those needed to create a well-structured monolith” Simon Brown
Microservices use cases
- Multiple teams
- Short-lived, spawned workers
- Memory or CPU-intensive parts
- to ease development