fbpx

Is it a good idea to convert a Monolithic Application to Microservices

by user

Microservice is a popular term in today’s cloud software development and the agile programming community. Before you make the decision to convert a monolithic application to microservices, read our insights.

What is a Microservice?

Services that are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized, and built and released with automated processes.

Source Wikipedia

Why convert a Monolithic Application to Microservices?

Before we start learning about converting an already working application to microservices, it is important to know why it is needed in the first place.

It might be difficult to extend and improve your existing legacy applications that might be running on older platforms. Scalability becomes an issue and working on top of such huge monoliths might even increase the complexity and makes it even harder to maintain.

Another reason is the need to use modern frameworks for modern problems, that might not be possible in the monolith. For example, if a 10 year old application is running on a legacy Java platform, and you want to integrate Machine Learning capability to the system, it will become difficult. You might want to use a different tech stack Python, for example.

There are several reasons to use microservices. But is it a good idea to migrate an entire monolithic application? Well, maybe not. Sometimes, it’s tempting for technology decision-makers to adopt microservices because that makes you look “cool” in the modern tech community.

Let’s see how you can get out of this dilemma and see if migrating to microservices is a good idea for your organization.

Think about the value that you’ll get from adopting a microservice design.

  1. Do you have a particular component in your application that needs to be scaled and served through a load balancer?
  2. Is there a need to re-write a particular module of your application in a different language/tech stack?
  3. Do you have a distributed team structure where collaboration between teams is difficult due to timezone issues?

These are some of the factors you can consider before adopting a microservice architecture.

But, don’t under estimate the trouble.

decision to convert a monolithic application to microservices should be taken carefully

Migrating from monoliths to microservices should be done incrementally. Trying to do it all at once will result in a big bang. Especially if your monolith is not documented properly, or if you don’t have a clear picture of the implementation.

I’d suggest an approach where you should build new features as microservices instead of building it in the monolith app. And incrementally, migrate the related functions from monolith to your new microservice. And after migrating each function, keep monitoring the logs for increased failures and errors. You should be able to switch it back easily if there is a serious / error.

I did this recently for a huge monolith application (that has high usage). It was written in PHP and we migrated it into Node.js microservices.

But, Microservices make simple things complex.

microservices can be a headache
I just refactored my simple web app into several microservices.

I’d recommend migrating into microservice only if there is a real need. Otherwise, it can cause several other headaches. Distributed applications are very hard to monitor and maintain.

For example, in a monolith application, you know where to look when something fails. You’d probably have a single log file for your entire application. But in you have several microservices, and if one fails, you’d never know the problem, unless you have a sophisticated log aggregation system.

Conclusion

When you write an application, even if it’s monolithic, try to design it as components so that you could simply break a piece from it, and deploy it as a separate microservice.

Simply, ask the question yourself “Do I really need it?”.

If your decision is just because you read about microservices and it looks cool, don’t do it. Because microservices are really hard to maintain and monitor. It would be an overkill for small applications.

If you’re just starting up, I’d recommend adopting component-based design. So when your application grows you can simply separate a component and deploy it as a microservice.