As a developer, it’s just not about developing the features, it’s also about architecting the application in the right way so that it would be flexible even if it scales on. Likewise, most of the application currently follows Monolithic Architecture. It’s one of the right ways of architecting your application. But in this technology paradigm, we are finding out new ways and trying out new things. Microservice Architecture, a new way of architecting your application. It has become increasingly popular over the past few years. And also most of the enterprise applications started to adopt this architecture.
In this blog, we will explore what is Monolithic Architecture? What is a Microservice Architecture? And finally, we will see a detailed difference between these two architectures. And also, we will discuss about how we can communicate between microservices.
Monolithic Architecture
It is one of the traditional ways of building your applications. The architecture consists of different components that will be combined into a single application. So basically, all the components would be tightly bounded which will be dependent on each other. No matter how much you try to decouple them, it stays as a single application. Despite having different components, it can be deployed only as a single application that is applicable to all platforms (Web/Mobile).
And also, if you want to do some changes to one feature, it may influence the work of the entire process or other features which has been already deployed.
As you see in the above diagram, all the layers such as the presentation layer, database layer, etc will be tightly bound and it will be communicated to a single database. It might be a cool way of developing the application, but each architecture has its own pros and cons.
Pros of Monolithic Architecture
The following are some of the pros of Monolithic Architecture,
- Easy to develop – As you know it’s being followed by most of the developers around the world, it’s very easy to get started off with and also it’s simple
- Test Application Easily – You can do some automation testing using various tools which is an added value to this architecture.
- Deployment is Simple – You can deploy the application in a single go
- Blogs & Article – You can find more relevant articles and blogs regarding this architecture and also it helps you to solve your problems quicker if you face any issues in this architecture
Cons of Monolithic Architecture
The following are some of the cons of Monolithic Architecture,
- Code Maintainability – If your application gets bigger, the number of files and projects gets increased, and sometimes developing a feature will break other features.
- Dependent on each other – All the components are tightly coupled to each other and a single change in a component may affect other components
- Startup Time – The size of the application may slow down the startup of your application
- Deployment – A small change in a single component may lead to redeployment of the entire application
- Framework / Technology change – If you want to change the framework of a single component it may affect all the components. And so you have to do it for all projects.
The main point which I want to highlight is Code Maintainability. When your application gets bigger, you would face a difficult time in maintaining your code. And also let’s say there are two modules, Login Module, and Product Module, in a monolithic architecture both are dependent on each other and cannot be tested until and otherwise both are deployed.
Microservice Architecture
It is a modern way of building your applications. In this architecture, all the components are divided into small components independent of each other. So each component is called a Microservice. Each service will have its own presentation layer, data layer, etc. And also, it has its own database. Likewise, you can split it into various microservice such that it will be independent of each other
As you see in the above image, each microservice can be developed in different frameworks/languages that can be communicated to each other. And as I said earlier each microservice has its own database. Let us see the pros and cons of Microservice Architecture.
Pros of Microservice Architecture
The following are the pros of Microservice Architecture,
- Independent Components – Test, deploy and ship into production very easily since the modules are independent to each other.
- Code Maintainability – Even if the application scales up, the code can be easily maintainable and also the code readability increases
- Scalability – Since each service is independent of each other, we can easily scale up our application.
- Flexibility – Each microservices can be developed with different languages/framework which can be communicated together
- Fault Tolerance – Isolation of microservices makes fault tolerance better.
Cons of Microservice Architecture
The following are the cons of the Microservice Architecture,
- Communication – If you do synchronous communication between microservices, then it leads to a monolithic way to communicate between client and server.
- Services & Resources – If you have a lot of microservices, each service will have its own resources (API’s, database etc) which will be hard to maintain.
- Development Challenges – Microservices are great for large product companies, but it can be slower, and it would be very challenging for small companies.
So as you see there are a lot of advantages when you use Microservice Architecture. Earlier I said that each service is independent of each other but when you develop microservices there might be a situation where you want to communicate between microservices. So, is that possible? If that’s possible what’s the best way to communicate between microservices?
Communication in Microservices
In a monolithic application, a client sends a request to the server and it makes a function call to the respective layers and it gives us the data. But according to the Microservice application, we need to split them into two aspects of communication such as,
- Communication Protocols
- Communication from a single client to a single receiver and multiple receivers
Let’s explore about these communication aspects.
Communication Protocols
Client and services may communicate between each by various protocols but in this web paradigm, most of us use HTTP/HTTPS protocol or AMQP protocol.
- Synchronous Communication – If you want to communicate between the client and service in a synchronous way, we use the HTTP/HTTPS protocol.
- Asynchronous Communication – As the communication type mentioned as asynchronous, the client doesn’t wait for the response from the service. And you can use the AMQP protocol for asynchronous communication.
Communication from a single client to a single receive and multiple receivers
A single microservice or multiple microservices process the requests from the client. So they have split into,
- Single Receiver -Exactly one microservice process each request.
- Multiple Receiver – Multiple microservices processes each request. So, the communication between these microservices should be asynchronous such that it doesn’t affect the performance of your application.
As you see we have two types of communication aspects in microservices. Most of the time whenever you build a microservice application, you would go with single receiver communication with synchronous protocols HTTP/HTTPS. But you don’t have to worry about this whenever you build a microservice, the problem arises when you integrate those microservices. From the definition of microservices, each service should be independent of each other likewise you should reduce the communication between them. But if you want to communicate between the services you should go for asynchronous communication.
If possible, avoid the synchronous communication between services and also avoid chaining of requests which will break you entire microservice Architecture.
As you see in the above image, the first communication seems to be antipattern as the client sends a request to microservice M1 which is dependent on other microservices. You should avoid this completely. On the other hand, a client sends a request to microservice M2 which is also dependent on other microservices but the communication between them is asynchronous. So this is the right way of handling communication between microservices.
So the main important thing we learned in communication between microservices is never to do asynchronous communication between microservices.
Conclusion
When you learn about this architecture, everything seems to be awesome. But the real challenge occurs when you develop an enterprise application with this architecture. There will be a lot of challenges like communication, removing dependency between services, etc. But most of the large enterprise applications already follow this architecture. And they are facing a lot of advantages over using Monolithic or Service-Oriented Architectures.
In our next blog, we will explore how we can build an ASP.NET Core Web Application using Microservice Architecture.
Happy Coding!
Cheers!
