Scale It Up with Microservices: When and How to Migrate

Sometimes in life, the best things are simple. This philosophy can also ring true when it comes to developing your app, which is why most apps are built using a monolith architecture. Monolith architecture is simple. It’s also uniform, familiar, and easy. So, why would you need to switch architectures?

At some point in the process, your pain points will dictate that something needs to change, and you need to be adaptable. Let’s talk about the alternative: microservices.

What is microservices architecture?

Microservices are loosely coupled services that can be developed, deployed, and maintained independently. Each service is responsible for a discrete task but can communicate with other services through lightweight APIs to solve a complex business problem.

Here is an in-depth guide to get you up to speed, but for the sake of this article, I want to share specifically when to leave the monolith architecture behind in favor of microservices and how to migrate to the new architecture… because it’s essential.

When you break a huge monolith into small pieces, you have the opportunity to ease the communication, development, and release of your app. That is assuming you do it right. If done poorly, you will have to deal with far more conflicts than before. When you choose microservices, you need to do it at the right time and in the right way.

Benefits of a microservices architecture

Here are a few highlights for those considering the switch.

• Each service can be built by one independent team, which makes it easier to scale up development.
• Each service can be scaled independently since they are deployed separately.
• If an error occurs in one service, the whole app doesn’t necessarily stop working.
• There is no need to redeploy the whole app after every tiny bug fix.
• Each service can have the tech stack that is best for the required functionality.

When to switch from a monolith to microservices

If the benefits above are appealing to your current situation, then maybe it’s time to consider switching to microservices.

A traditional app is monolithic. It is built as a single unit that contains all the business logic, and everything is written in the same language and deployed together. Monolithic apps are easy to develop, test, and release, but, as your team and your code grow, they become hard to manage. So, when do you make the switch?

The right time to change your architecture is when you’re facing productivity or resource efficiency issues.

Because it can be difficult to decompose code that is constantly changing, you should start the transition when the app is stable and core functionality is implemented.

To give you some insight into how we do it at OAK’S LAB, we usually start with a monolith and migrate to microservices at a later time. We mostly work with non-technical founders at the very beginning of their startup journey, when only an idea or an outdated MVP exists. For most early-stage projects, monoliths are good enough. However, when the team and codebase become too big to be working effectively, then we make the switch over to microservices for all the benefits listed above.

How to migrate to microservices

1. Start with looking for business logic that can be separated (e.g., user management, notifications, or media). Maybe some parts of the app could benefit from a different configuration (e.g., more GPU for image processing).
2. Bundle services together by implementing an API gateway.
3. Look at popular libraries used by millions of developers. These libraries use semantic versioning and don’t release majorly different versions too often, and you should do the same. The biggest challenge while implementing microservices is to make them work together, so poor design and constant breaking changes are your enemies.
4. Deploy a new version of an API while still keeping the previous one up. This way the dependent services can be upgraded at their own pace to use the new version. It may become difficult to maintain various versions and write fixes for all of them, so make sure to get rid of old versions after the dependent services are upgraded.
5. Every time you call another service, think about what should happen if that service does not respond or fails to process the request. Microservices communicate through a network and rely on it heavily. They are sensitive to any network errors that may occur.
6. And finally, avoid the common mistake of sharing a single database among many services. When this happens, any service can read and write data directly from the database, violating the rules of the service responsible for the data. Moreover, schema changes made within one service may break other services. Having a dedicated database for each service prevents these issues.

Final thoughts (and one small use case)

In order to protect our clients’ data, I can’t go into details about personal projects where we’ve implemented microservices, but here is a great example from Google.

You can see they are building an online boutique consisting of ten services that have different purposes and are written in different languages. For example, RecommendationService is written in Python. This makes perfect sense if you want to utilize one of the many Machine Learning libraries that Python has to offer — but it doesn’t mean the whole app has to be in Python. It’s a small but great example of how beneficial microservices can be in this particular use case.

To sum it up, microservices are a great way to build and manage complex scalable applications. Monoliths are great to get you going, but the right time to think about migrating to microservices is when you face real productivity and efficiency issues. Be patient, follow the guidelines, and remember that microservices are not a quick win. They are a long-term investment.

What are your thoughts about using microservices? Please feel free to reach out to me on LinkedIn.