Microservices and Monolith are two popular application architectures. In this article, we will take a look at each, their advantages and disadvantages.
Monolithic Architecture is a traditional way of developing server-side or client-side applications. These applications have a single large codebase in which the application is developed. For example, a Java application can be deployed from a single WAR file onto the application server. To update the code, add features or make any changes, you have to re-build and re-deploy the entire application. This may break the entire application if something goes wrong.
The application stack can be broken into three logical and physical computing tiers:
- Presentation Layer
- Application Layer
- Data Layer
This is the core of the application. In this tire, data collected from the presentation layer are processed against other information in the data tier – using business logic, a specific set of business rules. This layer is typically developed using Python, Java, Perl, PHP, or Ruby, and communicates with the Data Layer using APIs.
Data Layer is also called a database layer. The information processed by the Application Layer is stored and retrieved from here. This can be any type of databases such as a relational database like MySQL, Postgresql, etc., or a NoSQL database like MongoDB, Cassandra, etc.,
There are a few benefits of a three-tier architecture, such as,
- Each tier can run on a separate operating system and server platform.
- Faster development.
- Improved scalability.
- Improved security.
- Improved reliability.
There are quite a few advantages and many disadvantages to this type of architecture.
- Since it is a single application, it is easy to develop, test and deploy.
- Since this method of application development is used for a long time, there are so many tools available and well tested for production use.
- The application can be scaled horizontally, running multiple copies and routing incoming traffic using a load balancer.
- The large, monolithic codebase scares developers, especially ones who are new to the team.
- The application can be difficult to understand and modify.
- You must rebuild and redeploy the entire application for minor bug fixes, to add a feature or changes made to the code. This can break the entire application if something goes wrong.
- Continuous Deployment is difficult.
- For a big project, the size of the application can slow down the start-up time.
- The larger the codebase, the slower the IDE. This makes the developers less productive and difficult to make changes.
- Requires a long-term commitment to a technology stack. You cannot change the programming language used to build the application, to do so you have to rewrite the entire application. This makes it difficult when a long-term development of the project decides to quit.
Rather than building your application as a Monolith, you break the application into independent chunks of individual services, these services have their functions and database with a specific goal. These services are interconnected and would expose a REST, RPC, or message-based API and most services consume APIs provided by other services. When a client wants to access the application, they talk to the API Gateway rather than directly to the services. Changes to a service like updating, bug fixes, and any other changes occur within each service. Microservices do not reduce the complexity of an application but make it visible so that it is more manageable. Adopting microservices often goes hand in hand with DevOps.
- Breaking an application into fragments of manageable services allows you to develop the application and much easier to understand and maintain.
- Microservices allow you to continuously test, deploy and update services independently, which leads to faster deployment and troubleshooting.
- Rather than being committed to a single technology stack, you can use multiple or adopt new technologies based on the requirement, performance, and complexity of the service.
- You can easily upscale or downscale a service individually based on the incoming traffic or application load. This frees up memory and CPU for other services.
- It is easy to make changes, add features, or fix bugs compared to Monolithic Architecture. This reduces the risk of downtime, and developers can roll back an update or introduce changes to a service without needing to redeploy the entire application.
- It is easy to monitor individual services to identify and resolve any cause of performance issues.
- You can use an orchestration framework to manage individual services. Probably the best known of these orchestration frameworks is Kubernetes.
- Microservices come with all the disadvantages of a distributed system.
- Architecting a microservice can be complex and challenging. There's a lot more planning involved.
- There is a higher chance of communication failure between different services. The communication mechanism between services should be based on either messaging or RPC, and write code to handle partial failure.
- Microservices require extra resources, as each microservice comes with its own runtime environment and data storage.
- Deploying a microservice-based application can be complex. In a Monolithic architecture, the application is simply deployed into multiple servers behind a load balancer, whereas a microservice application typically consists of numerous services.
Which one is better?
Choosing the right architecture for your next project is important, and it's inherently difficult to develop complex applications. Monolithic architecture is best suited for a small team or small applications. This reduces the unnecessary complexity of designing microservices. The Microservice architecture is a better option for more complex and evolving applications. Getting multiple microservices to reliably function together as a microservices-oriented program is a difficult task. The trade-offs can be substantial, but so can the benefits.
Thanks for reading, I will cover topics like moving from Monolith to Microservices and Securing Microservices in a future blog post. Subscribe to receive weekly newsletters of my latest blog posts.