Breaking a Monolith Into Microservices: Best Practices and Challenges

You Will Learn

• What are the important features of microservices architectures?
• What are the important challenges?
• How do you breakdown a monolith into microservices?

Let’s start with the basics of a monolithic architecture, understand microservices architecture, and figure out what you should do to migrate from the former to the latter.

Monolithic Architecture

The salient features of monolith applications are:

• Released, or taken to production, once every few weeks, months, years.
• Generally, have a wide range of features and functionality.
• Have a development team of over 50 people working on them.
• Debugging problems that arise is a huge challenge.
• It is almost impossible to bring in new technologies and technical processes, midway through the lifetime of such an application.

Monolith applications are typically huge and have millions of lines of code.

A monolithic application would look something like the following:

You have a large application talking to a large database.

Microservices Architecture

In a microservices architecture, instead of building a large application, we build a number of smaller applications, known as microservices.

Here is how you would split up the monolith MovieApplication:

As you can see here, the databases are also separated out.

Microservices architecture involves a number of small, well-designed microservices that exchange messages among themselves:

Microservices Architecture Is Tough

While a microservices architecture looks very easy at a high level, implementing it is no trivial process.

There are a number of important decisions to make for moving to microservices architecture, such as:

• What are the boundaries of the individual microservices?
• How small should a microservice be, and what functionality should go into it?
• What data needs to go into the database to which a particular microservice talks extensively?
• How should the microservices communicate with each other?

Challenges With Microservices Architecture

The challenges that need to be tackled when setting up a microservices architecture are described below.

Quick Set Up Needed

You cannot spend a month setting up each microservice. You should be able to set up a microservice quickly.

Automation

Because there are a number of smaller components instead of a monolith, there needs to be automation in every activity, such as builds, deployment, monitoring, etc.

Visibility

You have a potentially large number of smaller components to deploy and maintain. This number could be 100 today and 1000 tomorrow. You should be able to monitor and identify problems automatically. You need great visibility around all the components.

Bounded Context

Deciding the boundaries of a microservice is not an easy task. Applying Bounded Context principles from Domain Driven Design is usually a good starting point.

Your understanding of the domain evolves over a period of time. You need to ensure that the microservice boundaries evolve with time.

Configuration Management

You need to maintain configurations for hundreds of components across environments. It would be best to have a configuration management solution.

Dynamic Scale Up and Scale Down

The advantages of a microservices architecture can be realized only if the application can scale up and scale down easily in the cloud.

Pack of Cards

If the microservice at the bottom of a call chain fails, it can have knock-on effects on all the other microservices. Microservices should be fault tolerant by design.

Debugging

When there is a problem that needs investigation, you might need to look into multiple services across different components. Centralized logging and dashboards are essential to make it easy to debug problems.

Consistency

You cannot have a wide range of tools solving the same problem. While it is important to encourage innovation, it is also essential to have decentralized governance around the languages, platforms, technologies, and tools used for implementing, deploying, and monitoring microservices.

Going From Monolith to Microservices Is Not an Easy Switch

You may have noticed that after describing monolithic applications, we directly jumped into the challenges of microservices.

The reason we did not talk about the advantages of microservices first is that you need a reality check when you migrate from one architecture to another. You need to realize this is not something you can do in a few weeks or months.

Getting a microservices architecture right involves a few years of work. It’s not a switch, but a journey.

During that journey, both architectures live side by side.

You would hope that the number of applications using a microservices architecture grows over time.

Ask Why You Are Migrating From Monolith to Microservices

This is the most important question to ask! Don’t use microservices because it is a buzzword. Use it because your business needs it.

Why Are You Migrating from Monolith to Microservices? What Do You Want to Achieve?

• Do you want to be able to adopt new technologies and processes faster?
• Do you want faster release cycles for your application?
• Do you want to scale more easily in the cloud?

You need to be very aware of which of these reasons is the biggest one for your migration.

The approach you use to actually migrate would differ, based on the exact reason for migration.

Let’s look at these approaches in a little more detail.

If Your Reason Is to Adopt New Technologies

Let’s say the reason you're switching to microservices is the ability they provide to adopt newer technologies. In that case, you can start off with designing microservices for the next set of features you intend to implement. In other words, all the requirements for new feature implementation in the monolithic application are the best candidates to become microservices.

You need to answer questions such as:

• How do you design the database?
• How do make sure the communication between the old monolith and the new components is working?

If Your Reason Is to have Faster Release Cycles

Your business may not be happy with the pace at which new features are being released to production. In that scenario, you first need to identify those parts of the application, where there are frequent changes.

Once you do this, you can extract the fast moving parts and create microservices around them.

The idea behind this is that when there is a change, only release the related microservice.

If Your Reason Is to Scale With the Cloud

If the driving force behind the migration is scaling with the cloud, then you need to analyze what needs to be done to put your application in the cloud.

Start with research and proof-of-concept prototypes to understand the dependencies involved. You need to find out which dependencies are important to break and anticipate the problems you may face on making the application cloud-native.

More Than One

Your business might need microservices for more that one of the above reasons. Prioritize them and get started with the most important ones.

Clearly, the path to migration will not be the same for all. However, with whatever microservices that you design in your journey, make sure they address the challenges that we saw earlier, in an effective manner.

Do check out our video on this:

Or you can check it out on YouTube here.

Summary

In this article, we had a good look at the activities involved in moving from a monolith to a microservices architecture. We observed that it is not an easy journey, as the process involved in designing the two kinds of systems is radically different.

The actual journey of your migration will heavily depend upon the exact reason you want to do it. Ultimately, with whatever microservices you come up with, make sure they effectively address the challenges that exist in such a system.