Software Architecture Showdown: Microservices vs. Monolith - Which one should you choose?

August 2, 2023

In recent years microservice architecture has become a trend. Its popularity grew from big tech successfully implementing microservices architecture for their use cases and nowadays almost everyone wants to develop and deliver their applications using microservice architecture. Discussing monolithic software architecture, oftentime people consider it as the “old way” of creating an application. But is that actually a case and should you choose microservice approach vs monolith? Let’s delve into the details.

Monolith Architecture: The Classic Approach 🏛️

Monolith architecture is a software architectural style where application is developed as a single interconnected unit. All the code is located and managed in the single repository and the application is deployed as a single unit.
Monolith was and still is a pretty popular architectural choice because of these benefits:

It is simple to develop and test since almost all of the code and dependencies are located in a single place,
You don’t need to worry about complex communication between many different components that live outside your codebase.
It is performant – all of the computation and business logic is happening in one place so there is almost no need to have external communication which in the end reduces the latency and thus improves performance
Easy to deploy – You only have to worry about deploying one single unite and as such deployments are easy to manage and quick
Low infrastructure overhead – in order to manage a monolith application, its infrastructure can be as simple as one server serving your application. This makes monolith application infrastructure fairly simple and cheap.

Besides all of the benefits of monoliths we have to be aware of its shortcomings as well:

Can become hard to develop – when team size and codebase grows it can be hard to manage and to coordinate development effort. Codebase becomes huge and hard to manage it and oftentimes poor coordination effort can become bottleneck in moving development forward,
Can be hard to scale effectively – In terms of scalability add more computing resources or you could scale horizontally but then you have to scale the whole application. This process can be challenging to do depending on the complexity of the application. Regardless of the scaling strategy, the resource won't be utilized efficiently as you cannot scale a particular component that is a bottleneck in the system.
Maintainability can become hard – as the codebase grows so does the complexity to maintain the system. Developers need to have thorough understanding of the code and quality tests should be written in order to add new features without impacting the other parts of the system.
Limitation in technology stack – in general when you start with one technology stack you are stuck with it for the rest of your development cycle. Since an application is developed as a single unit there is less or no opportunity to use different technology stack for different parts of the application. Changing technology stack down the road can be very costly so it is an imperative to choose wisely at the beginning of the project according to your application needs.
Risks during deployments – Although simple deployment was mentioned as a benefit, such deployment also carries a risk. If one component of the system fails there is a high probability that the whole system will fail. As the system grows so does the number of potential failure points.

Although these challenges are prominent in big, complex and heavy load applications they can certainly be mitigated. StackOverflow, one of the most prominent web services that is helping out developers all across the globe is successfully leveraging simplicity and pragmatism of monolithic architecture using only 9 on-prem servers.

Microservices Architecture: The Modern Approach 🚀

Microservice architecture is a way of developing applications as a collection of relatively small, loosely coupled and independent services. Each service has its own business boundaries and it fulfills its tasks by communicating with other services. Microservice style got popular with advances in cloud computing which allows provisioning of hardware on demand and development of containerization systems such as Docker and orchestration systems such as Kubernetes which allowed teams to be effective and cost efficient in using such style of architecture.
There are multiple advantages of using such architectural style:

Faster and more agile development – Teams should be carefully distributed and work independently on a service. That way one single team has full ownership of a certain service and enables it to develop and act fast.
Scalability – Each service should be independent and have its own database, that means the service can scale its bottlenecks easily with efficient usage of resources, whether you are scaling by adding more resources or adding more instances.
Easier maintenance – since services are independent and much smaller it is easier to maintain and add new features without fear of breaking the whole system. If there is a problem with feature that has been added to the service it will impact only that service and not the whole system
Independently deployable – One of the key features is that each service can be deployed separately which allows teams to move and deliver features fast
Technologically independent - Since services are independent they can be developed using different technology stacks. For example, one service can be developed using Java and another can be developed using Python which offers great flexibility to the team.

All of those good things come with some downsides:

Development environment challenges – In order to develop microservices you might need to have a code of few services simultaneously. Also you will probably have to run multiple services at same time which could be quite heavy on the development machine
Cost – Efficiently running microservices infrastructure is costly. In monoliths you only need one machine for one service, while in microservices you need to deploy and run more things which in the end cost more money. Apart from that, if developers are not experienced in developing using microservice architecture it will slow down the development until they are more proficient
Monitoring and troubleshooting – Monitoring and troubleshooting becomes complex as you need to monitor a lot more components than in monolithic architecture. Besides, it can become tedious to troubleshoot issues that can span across multiple services and be hard to track down
Latency – To fulfill the business needs, one service oftentimes needs to communicate with few other services. Each roundtrip to service increases the latency due to network trip witch in the end impacts overall latency
Data consistency – In distributed systems such as micro services it is impossible to have immediately consistent data. As data spans across multiple databases it is performance costly to have consistent data. Using microservice approach you must settle for eventually consistent data and achieve it through concepts like sagas.

Even though this list can sound scary, many companies are successfully employing microservice architectures. One of the most prominent advocates of microservice architecture is the streaming platform Netflix. Usage of microservices architecture enabled Netflix to gain technology edge in delivering features fast and making the system performant and resilient. Their experience and journey motivated and inspired a lot of other engineers.

Should you use Microservices?

As with every architectural decision, the answer always depends on your use case. Microservice architecture adds a lot of complexity which also increases cost. Two questions that we at SIGIT like to ask yourself is team size is so overly big that it will run into challenges and bottlenecks working on the same codebase? Then a microservice approach is certainly an approach to consider and maybe lean towards.

Another question is, are we developing a software that will be under heavy load and need to scale efficiently? Then again microservices is an approach to consider. Otherwise we would suggest starting with an approach called modular monolith, where monolith system consists of finely grained modules that are formed around business domain. That way you can keep the simplicity and pragmatism of monolithic architecture but be ready to break down the monolith into microservices because of the finely grained modules.