The search for better ways to build big systems/apps never stopped for several years until now. We keep learning from the existing systems, open to adopting new technologies and keep observing on how a new wave of technology companies operate in different ways to create IT systems that can make their customers as well as their own developers happier.
Here is a brief article about the monolithic and microservices architecture, their advantages and disadvantages in the present industry and much more essential details that you need to know about it to give you a clear idea.
What Is Monolithic Architecture?
A monolith application is built as a single generated file/directories based on the languages. Let’s consider that we are building an eCommerce application which consists of multiple services such as user, inventory, transaction, shipping, etc.. If we develop this application in JAVA or Golang, it gets generated as a single generated file to deploy in server. But when we develop a Rails application, it consists of a single directory hierarchy deployed using Phusion Passenger on Apache/Nginx.
Advantages Of Using Monolithic Architecture
- Simple to develop
- Simple to deploy
- Simple to scale (run multiple copies behind a load balancer)
Disadvantages Of Using Microservices Architecture
- The monolithic codebase can be difficult to understand and modify. It slows down our development at some point.
- Continuous deployment is difficult – A modification made to a small section of code might be required to redeploy the entire application.
- Scaling specific service(For example, inventory service) of an application is not possible. Every service has different resource requirements – It might be CPU intensive or memory intensive, which means we need to scale the entire application.
- Strict with technologies and their stack.
What Is Microservice Architecture?
A microservice application is built as a collection of loosely coupled services. This corresponds to the Y-axis of the Scale Cube. Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as RabbitMQ. Every service has its own database to be decoupled from other services, which is why data consistency between services is maintained using the Saga pattern.
Advantages Of Using Microservice Architecture
- Highly Maintainable and testable
- Deploy each service independently
- No restriction in the technology stack
- Divide multiple small teams for each service to develop which improves more productivity.
- If there is an issue in one service then only that service will be affected. The other services will continue to handle requests.
Disadvantages Of Using Microservice Architecture
- More engineering is needed i.e., it takes more time to develop and require careful coordination between the teams
- Developers need to understand inter-service communication.
- Testing across multiple services is quite difficult
- Cost of the server is high
Monolithic Vs Microservices Architecture
In a monolithic architecture, a large server is present to take responsibility for handling all the requests. This is going to hit you at scale. Even if we want to scale this, we have to run multiple copies of the application on multiple machines to scale the application request. This approach corresponds to the X-axis of the Scale Cube.
In a Microservices architecture, we build applications by composing a suite of independently deployable, small, modular services. However, one can balance traffic due to your business’ requirements in microservices. For example, if you are receiving a large number of request in inventory service, you can scale up your inventory service and keep the other services using a smaller number of resources. You need to note that the current approach corresponds to the Y-axis of the Scale Cube.
You might need to face and solve many practical challenges when you move from monolithic applications to Microservices architecture. For example, a business transaction may span into several Microservices because we broke up a monolithic system into several autonomous services. Each service has its own database in order to be decoupled from other services where we need to manage data consistency as well. To solve these practical challenges of Microservices with regards to managing distributed transactions and data consistency, an event-driven architecture(Saga pattern) is a highly recommended approach.
Challenges In Microservice Architecture:
There are many challenges that need to be addressed before adopting microservice.
When should we use microservice architecture?
The first challenge is deciding when it makes sense to use microservice architecture. When developing the first beta version of an application, we are rapidly developing business models to enter the world market. This can be a major problem for many startups on how to rapidly evolve the business model and accompanying the application. That time microservice architecture will not be suitable because distributed architecture slows down the development. Most large scale web sites including Netflix, Amazon, and eBay have evolved from a monolithic architecture to a microservice architecture. So the final conclusion is checking the application in the real-world market and decide when we have to migrate to microservice.
How to decompose an application into services?
Next challenge is deciding how to divide the whole application into microservices. There are numerous ways to decompose the application. Below are a few of the strategies:
Ideally, each service should have only a small set of responsibilities or the Single Responsibility Principle (SRP).
How to maintain data consistency in Microservices?
Maintaining data consistency between services is another challenge in microservice development. An application must use the saga pattern i.e a service publishes an event when there is a data change. Other services should consume that event and update their data. For this, we have many message queue options like RabbitMQ, SideKiq, and Kafka.
For more details, please check here
How To Implement Queries?
Another challenge is implementing queries that need to retrieve data from multiple services. For this, we have to use API Composition or Command Query Responsibility Segregation (CQRS) patterns.
We will normally use API composition using third-party tools such as Apigee. We can call two HTTP calls one after another inside Apigee proxy.
Perspective About Microservice
The term “Microservices” was first coined by Netflix referring to their distributed systems architecture, which was based on the idea of “functional decomposition” for scaling applications. For distributed systems, the idea of functional decomposition was nothing new as it has been one of the three scaling patterns. The other two approaches are horizontal scaling and data partitioning. The only new thing was the marketing terminology “Microservices”. As part of evolution, people started to use the containers for running Microservices. Since then, those who have never worked on distributed systems, have been aggressively spreading wrong information that Microservices architecture is all about running applications with Kubernetes using docker which is not the case.
As we have seen the basics of both monolithic and microservices architecture, its own sets of pros and cons, major differences that set them apart and broke the rumored perspective about microservices. So, it is in the hands of the major IT companies to choose the right system architecture that is suitable for the product, simpler for the developer and beneficial for the end-user. Post us thoughts to our experts for more queries
Latest posts by Bharanidharan Arumugam (see all)
- Distributed Transactions Patterns in Microservice Architecture - September 25, 2019
- Monolithic Architecture Vs Microservices Architecture – A Glance - July 25, 2019
- How To Upload Images/Files To AWS S3 Using Node.js - July 1, 2019