Microservices vs Monolith: The Ultimate Comparison 2021

Microservices vs Monolith

Microservices are something new that has hit the software market thread. In the emerging trend of microservices, debates over Microservices vs Monoliths are inevitable. The microservice architecture provides tangible benefits like scalability and flexibility and is a cost-effective way for creating heavy applications. Tech giants like Netflix, Amazon, and Oracle generally implement microservices in one application or the other. On the contrary, the monolithic approach is losing its value as it poses risks to current software delivery methodologies. Before we go into the final comparison of Microservices vs Monoliths, let’s look at both the architectures one-by-one.

1. What Are Microservices?

Microservices are small deployable services that are modeled around complex applications. A microservice is nothing but a newer version of Service-Oriented Architecture (SOA). They communicate with each other using different techniques, and they also have the advantage of being technology agnostic.

From a technical viewpoint, microservices expose one business/technical capability of the applications they encapsulate via multiple small services. Different microservices communicate via API endpoints/HTTP protocols, making it into a distributed system.

The image above shows a distributed architecture, which is enabled by the implementation of microservices. The diagram indicates that small microservices can be deployed on a heterogeneous set of hosts. The hosts can range from Bare Metal instance to the public cloud. This distributed architecture adds to the high reliability, scalability, and portability of the overall application. 

2. What Are Monoliths?

The term monolith comes from an ancient representation of a huge rock. When we talk about software, monoliths are nothing but a large block of codes having multiple modules. These modules are tightly coupled with each other. The application and the business logic are encapsulated in a single deployable binary called a monolith. Usually, a monolith consists of conventional three-tier architecture, namely, a database, a user interface, and a server-side application. The below diagram represents the idea of the monolith in a nutshell.

3. Microservices vs Monoliths: Architectures

Before delving deeper into the other aspects of these two conventions, let’s first understand the Microservices vs Monoliths architectures.

Let’s start with Monoliths. Monoliths are a single build of a unified code. This usually consists of three parts, the UI, the database, and the server-side application. The server-side application usually handles all the HTTP requests and executes the business logic. In monoliths, the server-side logic, the UI logic, the batch jobs, etc., are all bundled in a single EAR (Enterprise Archive), WAR (Web Archive), or a JAR(Java Archive) file. Fig 2.1 shows us a high-level representation of the Monolith Architecture.

Contrary to the above, the word “micro” means small, and Microservices denote a collection of small services to accomplish a business logic. This architectural style is aimed at creating small suites of services that add up to build a larger application. All the microservices run their processes to make this work and have lightweight communication mechanisms, i.e., HTTP resource APIs. These microservices are built independently around the business logic and have a fully independent deployment mechanism. 

4. Microservices vs Monoliths: Pros and Cons

While reading the introduction part of this blog, you must have had a picture in your mind that microservices have an advantage over monolith. This doesn’t just apply to microservices. Monoliths also have a distinct set of benefits that should be considered while deciding the optimal architecture for your application. Let’s talk about Microservices vs Monoliths pros and cons.

Monolithic Architecture Pros

Easy Development and Deployment
Monolith applications have existed since forever. Numerous tools do facilitate easy development and deployment strategies. Developers need to perform a single chunk of deployable code instead of making updates in separate entities.

Performance
Better performance is a crucial advantage of monolith applications over microservices. A microservice-based application may have to make 100 different API calls to 100 other microservices to load one UI screen. Whereas in the monolith, one API call can serve the same purpose because it has a centralized code and memory.

Monolithic Architecture Cons

Tight Coupling
Service modules in monolithic applications are tightly coupled. Business logic is tightly entangled and makes it difficult to isolate the application, and hence scalability becomes a challenge.

Slow Build and Release cycle
Since the code base is enormous, this retards the velocity of the development and testing cycle of the application.

Microservice Architecture Pros

Better Organization

Since the entire code base is broken down into smaller services, it is relatively better organized. The microservices have a particular job and are not dependent on other components.

Increased Agility

With microservices, individuals of a team can work on individual modules. Each individual can build a module and deploy a module independently, thereby reducing the team’s operational friction and increasing the software delivery’s agility.       

The figure above illustrates that every developer in the team will have the liberty to work on independent modules. Code repositories, build, and deployments are separate from one another. Since all the elements are loosely coupled with each other, it increases the agility of the entire Software Development Life Cycle (SDLC). 

5. Microservices: Use Cases

Microservices are widely adopted across multiple tech giants. The implementation of microservices varies from a case-to-case basis. But some of the significant applications which run on microservices and are used on a day-to-day basis include:

Uber Case Study

Like many startups, Uber also started with a monolithic architecture built to run the cab aggregator service in a single city. With time, Uber’s rigorous global expansion opened up many challenges concerning its scalability and continuous integration pipeline. 

The diagram above depicts the old architecture Uber used to follow. There was a REST API that connected the drivers to the passengers. Three different adapters were used within the APIs for billing, payments, emails, and messages. MySQL database was used to store all the data. So, all the functionalities of the application were encapsulated in a single framework. This monolithic framework possessed prominent challenges when it came to upscale the application.

Now, let’s look at the below diagram and understand what changes Uber brought to level up its technical growth strategy. 

✔ An API Gateway was introduced to connect all the drivers to the passengers. The API Gateway internally connects all the microservices such as Passenger Management, Driver Management, Trip management, etc., through REST API calls.

✔ Each microservice performs a singular functionality and has separate deployable binaries. For example, if you change anything in the Driver Management microservice, you just need to build and deploy the Driver Management microservice and not touch the others.

✔ Since all microservices are loosely coupled, their interdependency is greatly reduced. Hence, all the individual microservices can be scaled up to any level. For example, the number of people looking for a cab is anytime higher than the number of people booking a cab or making its payment. In such a case, the processes and the services involved in the trip booking and trip payments can be up-scaled.  

In this way, the world’s largest cab aggregator company, Uber, has benefitted by migrating its architecture from monolith to microservice.

6. Microservices vs Monoliths: Deployment Strategies

While monoliths follow the traditional deployments, microservices have given the system architects a tough time designing the deployment strategy. Since monoliths have a three-tier architecture, they have always been deployed on web servers like Apache Tomcat, Oracle Weblogic, IBM Websphere, etc.

Let’s focus on the microservices deployment strategy. Microservices are known for high scalability; therefore, the supporting IT infrastructure should also be scalable. Here are some of the deployment strategies to choose from for your requirements:

One service-One host

This is a traditional approach for deploying applications. Multiple services can be deployed on one virtual machine. One virtual machine is provisioned and used for the deployment of various services. This ultimately decreases the cost of infrastructure as all the services are running on one host. 

One Service-One Container

In this model, applications running on the ecosystem that supports Docker and Kubernetes play a crucial role. The services are packaged as images and are deployed in containers on the virtual hosts. Containers are incredibly lightweight and easy to build. Containerization enables complete isolation of services. Containerization of microservices also optimizes the infrastructure cost as multiple services are being hosted on a single virtual machine.

Serverless Deployment

Applications developed in programming languages like Node.js, Python, and Java can support stateless and serverless deployments. A Lambda function is created, which runs the microservices and handles all the requests. Again, this strategy is one of the most cost-effective strategies as organizations are billed only for the number of requests in the cloud environment.

7. Microservices vs Monoliths: Operational Impacts

When considering any infrastructure, the first question that comes to our mind is, “What will be the new technology’s operational impacts?” In case you have decided to adopt the microservices, there are undoubtedly some significant impacts that you should consider.

Cost

Several aspects come under the umbrella of “cost.” Cost of getting started, maintenance cost, cost of development, cost of quality, cost of speed and performance, and the cost of ownership. Cost is a significant factor that comes to the executives’ minds while taking the final decision of adopting any software architecture.

Reliability

When it comes to reliability, Microservices has the upper hand here as well. Monoliths are nothing but a big chunk of application binaries. By any chance, if the deployment fails, the entire application goes down. Compared to monoliths, microservices are very reliable. Even in cases when a service fails, the application will not go down as a whole. There are multiple service detection tools like Hashicorp Consul, which checks on every service’s heartbeat. On a high level, reliability is higher in applications running on microservices. 

Scalability

Monoliths can be scaled in multiple ways. One of them is to use numerous VMs and then route the request using a load balancer. Microservice architecture is more fine-grained, and hence scaling each microservice is more fine-grained and flexible.  Scalability is a contrasting factor of any enterprise application. So, there are multiple techniques available in the market, ensuring that microservices are scalable, both horizontally and vertically. Some of the popular tools available in the market are Amazon EKS, Amazon ECS, Docker, and Kubernetes. For precise scaling and better usage of resources, microservices are a clear winner.

If you want to learn more about the tools mentioned before, I recommend you this blog about Amazon ECS vs EKS that describes each of them and helps you understand when to choose one or another.

Time to Market

Due to its bulky size and higher dependencies, build and deploy mechanisms in monoliths are more complicated and time-consuming. Microservices are less resource-sensitive and are built to scale. Since the modules are decoupled from each other, it is easier to build and deploy. This increases the agility of the application running on microservices and significantly reduces the time for microservice applications to reach the market.

8. How To Migrate From Monoliths to Microservices?

Before you migrate from monolith to microservices, there are specific application-level changes that you should adopt. We will discuss several ways on a high level to embrace microservices.

Build Optimization

Monoliths have existed for ages. Monolithic Java projects are built using ANT and Maven. The first step is to streamline your build. You should also remove the dependencies and other external factors affecting your build.

Decouple the Dependencies

Once the build process is streamlined, you should remove the monoliths’ modular dependencies. You may have to refactor your code to achieve this level of decoupling.

Optimize Local Dev

Build, deploy, and test should happen at a faster velocity in the local development environment. Tools like Docker should also be embraced at the local level. This helps in speeding up the operational tasks like setting up a local database, etc.

Parallel Development

Multiple branches should be created in the code repository dedicated to all the different microservices. This setup will promote parallel development of all the monoliths and increase the agility of the software development lifecycle (SDLC).

Adopt Infrastructure as Code (IaC)

Adopting IaC will enable a more uniform and consistent infrastructure. Using a pragmatic approach to build environments will significantly help developers bring the cloud environment closer to their laptops.

9. Microservices vs Monoliths: Which Should You Choose?

Making the right decision of which architecture to choose depends on several factors. Both monoliths and microservices have their pros and cons. However, there are specific considerations you should look into before making the final decision.

Technical Competency

The first thing you should consider is how well you are acquainted with both architectures. If you decide to move towards microservices, are you well versed with all the practices involved in building products on this architecture?

Team

Is your team prepared to imbibe and ingest the principles of microservices? Evaluating the dimensions of the growth of your team and your product is crucial while adopting microservices.

Infrastructure

Infrastructures running on Docker and Kubernetes are best suited to run microservices. In reality, you should have an excellent cloud-based infrastructure if you decide to go with microservices.

Evaluate Business Risks

Microservices may look right in all aspects, but they pose risks to the business. Areas need to be identified which need scaling. Many efforts and human hours can go to waste if you scale those parts that are not required now. The critical business risk is the misplaced effort that can arise due to the vertical/horizontal scaling of microservices.

10. Closing Thoughts

Adopting microservices is a difficult approach. Not all architecture is the same. Similarly, not all applications are the same. Incremental adoption of microservices, associated technologies, and practices is the key. Microservices are more beneficial for complex and evolving applications. However, without proper expertise in these technologies, the adoption of microservice will be a colossal task. This blog gives you an overview of what Microservices vs Monoliths looks like. Ultimately, you’ll need to find the best approach that works well in your context. But don’t worry, that’s why we’re here!