- May 15, 2017
- Author: Vignesh Murugesan
- Category: Technology
Microservice is the process of cutting down large software applications into individually deployable services. These individual services communicate with each other (via API’s) but work independently. Enterprise applications would benefit a lot by implementing microservice architecture as they tend to improve the business considerably. Check out our recent blog to know how increased website speed can promote your business.
Let’s consider that you are working on a banking application. There will be several modules in that application, and every single module will have a separate service and data access layer, unlike a monolithic application. In Monolithic architecture, all modules will be under a single layer which goes to the backend. Here’s a pictorial representation of how a Microservice architecture works.
Why use Microservice?
In Microservice Architecture, each and every module can be altered to meet the requirements, and they can also be deployed independently (including legendary applications) without affecting the core part of the application. This process reduces a substantial amount of time and workload as you could redeploy just that particular service, without making alterations to the entire application.
For Ex: If you get a request to make changes in the Fund Transfer module, the changes can be implemented and deployed separately, without affecting the ACC statement or the Enquiry module. The application will be live, and only the fund transfer module will be down until the changes come into effect.
It offers us the advantage of having smaller codebases simplifying the maintenance process and quick. Also, it saves a lot of development time which improves the overall productivity. Since we’ve made changes only in the Fund Transfer module, any bug or fault could be managed easily within the module. When you work as a team, the others don’t have to wait until the bug is fixed, their work could progress without any hiccups.
Though we’ve specified that Microservices are deployed individually, they could not be deployed within a single EAR/WAR. So let’s see the best way to deploy microservices-based applications.
The best way of deploy microservice-based applications is to use containers. Some of the widely used containers like docker would be a good choice. The reason behind using docker for deployment is that we don’t have to setup our environment and other configurable items every time we use it. Docker allows us to combine all the work into a single image which reduces the overall time.
Unlike Monolithic Architecture where any significant changes could not be made to the flow without knowing the dependency and the impact it would have, you could experiment to our heart’s content in a Microservice environment. Microservice is the ideal solution for improving an application based on the ever changing needs of a customer.
You could experiment to your heart’s content even when you are running a colossal application, which is a key factor. We could implement this in Monolithic Architecture as well. However, it is too time-consuming and would take a lot of effort. There is a huge risk factor involved just a small error to turn the entire application to a total mess.
Difficulties in Monolithic Application
Nowadays, it looks like everyone is switching from Monolithic to Microservices and the reason behind that is very simple. Initially, when we start an application from scratch, there won’t be any problems.
As the application grows day by day, the task of managing it becomes quite tedious in nature.
- You might have ended up packaging all your services under a single WAR/EAR making it a ‘big ball of mud.’ The problem with this is that even a single glitch in some remote part could make the entire application go down. For Ex: If there is a fault in Fund transfer module the entire application will lead to a session regression testing after the bug is fixed. Whereas, Microservices give us relief from all this dilemma.
- You’d not be so enthusiastic to refactor your code to a newer technology stack as that might lead to unexpected consequences. When we try to implement a new stack in ACC statement module, the sudden changes might have a severe impact on other modules, and that’s a huge risk to take.
- Everything in your application comes tightly coupled. Developers can’t imagine working independently as the modules are dependent on each other.
The Switch from Monolithic to Microservice
Now that we know the scope of Microservice Architecture, many of us tend to consider this question, “Is it possible to switch my Monolithic application to Microservice Architecture?” Don’t you worry! It is indeed possible.
Instead of rewriting the entire code base, you can do it in a gradual way to avoid risks. First, split your application into two: Frontend and Backend.
The primary reason behind the downfall of Monolithic application is the desire of separating the presentation layer from the business logic and data access layers.
An application consists of minimum three types of components, and they are:
- Presentation Layer – The layer which could handle all the HTTP requests and implement either an API or web user interface.
- Business logic layer – This layer is the essential part of an application because this is layer is in charge of handling and implementing the business rules.
- Data access layer – This layer consists of access infrastructure components such as databases.
The presentation layer is entirely different from the business logic & the data access layers. So we need to be prudent while splitting the Monolithic application into two smaller ones which could be carried out with the help of API.
One has the presentation layer, whereas the other comprises of the business logic and data access layers.
Once the process of splitting is successful, the presentation layer could make remote calls to the business logic layer. The following diagram explains the architecture.
Splitting a Monolithic application in this specific way has two advantages.
- It allows you to develop, deploy, and scale the two applications independently. It allows the frontend developers to work rapidly on the user interface part and test it.
- Another benefit of this approach is that it exposes a remote API that can be called by the micro services which we develop.
However, this is just a partial solution.
Then you’d have to switch the existing modules in the Monolith to standalone Microservices. Every time you fetch a module and convert into a service, the Monolithic architecture would fade out now.
Once you have converted the necessary modules, the Monolithic Architecture would lose its structure and would resemble an entirely different service.
Strategizing your priority
Normally a Monolithic application will have a tremendous volume of modules. The biggest challenge is to find out which module to convert first. Initially, we have to start with the modules that are small with less dependency, and this attempt would give us an idea about the microservices. Slowly you have to start converting the core modules of your application.
Now the next big move is to pick modules which are modified very often. Once they are converted into a service, you can develop and deploy them independently. Adding automated testing to this process is a crucial step since we will be facing a lot of problems during the transition phase. Maintaining data consistency and integration can be challenging in a Microservice based application.
Benefits of moving to Microservice
- The failure of a single service would not affect the whole application, and the other services will be active. For instance, if there is a fault in the Enquiry Module that would not stop the entire application, the other services will be live and available for use
- It provides us the option of exploring new technologies for a single service. Dependency will not be a huge problem anymore, as rolling back the changes that we made will be a piece of cake as the codebase is minimal. There will be a significant improvement in flexibility when codebase is lighter, unlike the monolithic applications which are inflexible like steel.
- When there is a need to alter a particular service, you’d have to modify and redeploy only that specific service. There would be a substantial improvement in the time taken for deployment and testing. On the other hand, when Monolithic Architecture is considered, even a small change would require testing the entire application taking a toll on the deployment time as well.
- As it is rather easy to understand the functionality of individual services, managing the codebase is practically a breeze.
Drawbacks of Migrating to Microservices
- Each and every service is a separate deployment unit which should be released, tested and monitored individually. This issue raises the demand for automation of the delivery workflow to stay efficient.
- Testing will be quite the tedious process as each service has to be verified before it is deployed. Unlike the Monolithic approach, where you just have to launch your WAR on the application server and make sure it’s connected to the database.
- Since each module is an individual service, handling requests between modules will be challenging. You might face a situation where a service fails to respond and forces you to write additional code to avoid problems.
- The deployment would not be straightforward like deploying WAR. It needs to be in coordination with other services.
Building an application from scratch is a difficult task indeed. While a Monolithic architecture suits simpler applications, it could be a real migraine when your application is complex and ever changing. Microservices offers a better deal in that aspect by being very flexible, but it does come with its own package of complexities and challenges. So, when you are making a choice between these two consider the pros and cons of both architectures before coming to a conclusion.