When you hear about monolithic architecture, your mind immediately switches to legacy architecture.
Many companies have knighted Microservices as the king of modern software development architecture. All of this is because it has widespread adoption by the big players - FAANG.
However, many big tech companies, such as Netflix, Uber, and Amazon, all started with a monolith architecture, and there is a reason why they moved to a microservice architecture.
Many engineers think that monolithic architecture could be improved because it is less reliable and less modular, so it is hard to maintain and scale your system in the long run.
That is not why they are moving to microservice architecture, although there is some truth to this technical problem that led these big companies to adopt the microservice architecture.
First we need to understand why organizations are migrating to microservices in the first place: microservices solve two types of problems: Technical and People problems.
A Technical problem in monolithic architecture is that one component burdens the overall architecture, causing a poor user experience (UX).
For example, image processing requires a lot of CPU. If this CPU load becomes too high, it could starve the rest of the application in processing resources. It could affect system latency. And, if it gets bad enough, it could affect system availability.
On the other hand, a People problem has everything to do with team organization and the software development process. The more people you have working on any given part of the application, the slower development and deployment becomes.
For example, suppose you have 30 engineers competing to "Continuously Deploy" (CD) the same service. In that case, you're going to get a lot of queuing, which means a lot of engineers that could otherwise be shipping products are sitting around waiting for their turn to deploy.
If your system/team/organization doesn't have these problems, then you should use Monolithic architecture instead of Microservices. Here are three reasons why.
🏋️♂️ Monolith Can Also Be Reliable
Engineers often mistakenly think that microservice architecture can help with fault tolerance.
That is only partially the case.
A microservice architecture helps with infrastructure-related faults, such as memory leaks or CPU spikes, which are easier to track down on a specific component rather than a large monolith.
Monolith can be just as fault tolerant and reliable as microservice architecture. You can scale multiple services easily in a cloud environment with proper configurations.
In a monolith, the problem you will need to account for are run-time errors, while for microservice, you will need to handle network errors, which are arguably more complex.
In a Shopify case study on migrating back to monolithic architecture, they said that most of the failure after migrating to monolithic architecture often occur from their code not knowing where to find object definitions, which result in run-time errors.
The engineering team can ensure that nothing was missed by running their tests locally and in CI without failures and running through as much functionality as possible locally and on the string.
Having a new different system means increasing an additional point of failure.
You can call into different components directly rather than over the web app service. You don't have to worry about API version management, backward compatibility, or laggy calls.
Experience engineer often questions when an architecture requires adding a new microservice because adding a new microservice often incurs more latency and failure.
🍰 Monolithic Architecture is Easier to Maintain
One of the biggest downsides of microservice is needing to maintain the infrastructure.
Microservices come with increased operational overhead and problems around code reuse.
Your engineering team will use shared libraries that require services with common functionality.
Then, you realize that changing a field requires a week of work because it requires changing this shared library that hundreds of other engineers use.
That is one of the reasons why Segment switched back to a monolithic architecture.
"Team created shared libraries to provide similar behavior for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. Creating versions of the shared libraries made code changes quicker but reversed the benefit the shared code was intended to provide."
Then, there is the observability aspect of all services.
You will need to have some distributed monitoring tool for ten different services with their CPU, memory profile, and load. It is much more operational work than just monitoring a single service.
Then, you will need to keep writing documentation on your service to make it discoverable. Since members of your team may come and go, if you don't document your service effectively, it can be hard for other people to use.
Maintaining the entire codebase in one place and deploying your application to a single place have many advantages.
You will only need to maintain one repository and be able to easily search and find all functionality in one folder.
You don't have to spin up five different services locally on your computer to test a single feature.
Onboarding new engineers is much faster since everything is in one place.
Load testing will be much easier than load testing three different services.
You can handle consistency in your application.
⚖️ With Cloud Technology Adoption, Monolithic Architecture Can Be Scalable
Most Technology Doesn't Have to "Scale Independently"
A monolith might be straightforward to scale vertically for a long time. For example, regular web apps can go a long way by spinning off the database on a dedicated instance, scaling that vertically, and scaling the rest horizontally with jobs and queues.
Since microservices are faster to spawn than the full monolith, you can be more responsive in acting on spikes. However, microservices spikes also tend to be more brutal than monolith ones.
Let's say you have 10 API endpoints, and two of them at some point get a 5x traffic spike. If each endpoint lives in a separate service, you have to scale the capacity of the two services 5x. That might not be a trivial change, especially if you need to do it fast.
Vice versa, if all the endpoints live in a single monolith, the impact on the overall load is lower and can be more easily absorbed.
Unless a piece of functionality is CPU-bound , IO-bound, or Memory bound , the effort of scalability doesn't warrant maintainability.
Most of the time, your servers are waiting for things to do; adding "more HTTP route handlers" to an application will not suddenly drain it of all of its resources.
💭 When Should You Use Microservices?
Monoliths are preferred if your primary intent is getting a new product to market and iterating quickly.
Usually, you work in a monolith architecture for a couple of years to optimize the development speed because knowing the product's work is more important than using a trendy stack.
You can always pull microservices out of a traditional monolith and re-write in any language that makes the most sense. But you can only get back the time you spent doing that once you find a product market fit and a decent customer base.
According to Martin Fowler, "almost all the cases where I've heard of a system built as a microservice system from scratch, it has ended in serious trouble… you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile".
Engineers deploy all the components of a monolithic architecture in one instance. The service calls are within the same process and no RPCs. The data tables relating to each component are usually deployed in the same database.
In a microservice architecture, each component becomes a self-contained service maintained by a specialized team. The boundaries between services are clearly defined. The user interface talks to multiple services. It is suitable for scaling the business when it has substantial growth to a larger size to make it worth the complexity effort.
Conclusion
Microservice architecture is still the gold standard - almost every tech company adopts microservice architecture. But now, companies are starting to rethink the pros and cons of microservices. Some of the most controversial definitions of microservices are the exclusive use of a database and making 1000+ RPCs within a single client request.
These are the three reasons you probably don't need a microservice architecture for your business:
Monolithic architecture can also have reliability. With the right design, you need to solve run-time errors rather than microservice network errors.
Monolithic architecture is much more maintainable than microservice architecture.
With greater access to technology and more sophisticated hardware, vertical scalability is less expensive than in the early 2000s.
Case Study
These are some case studies about companies that moved from Microservice back to Monolithic architecture:
Istio because of domain separation problem. (link)
Segment in 2017 because of maintainability problem. (link)
Shopify because of issues such as code organization and enforcing boundaries. (link)
💡 Want more actionable advice about Software engineering?
I’m Edward. I started writing as a Software Engineer at Disney Streaming Service, trying to document my learnings as I step into a Senior role. I write about functional programming, Scala, distributed systems, and careers-development.
Subscribe to the FREE newsletter to get actionable advice every week and topics about Scala, Functional Programming, and Distributed Systems: https://pathtosenior.substack.com/
Top comments (0)