Monoliths to Microservices: An API-First Approach

For backend developers, making the decision to migrate from monolith to microservices can be an exciting opportunity to help drive a successful business transformation for the long haul.

But a successful migration is a long process and can burn out even the best of the best. Because of the many layers of abstraction in modern tech stacks, developers are generally inclined to do a data-first migration: to move a mode, or set of models, so it can be called using HTTP instead of the database.

At first glance, this seems like the easiest choice, but this technique can often lead to a distributed monolith that doesn’t generate a particularly easy to use or sensible backend work experience. It will be one with tightly coupled models across many services and only tolerable APIs. That’s why the best option is an API-first approach, which allows developers to create engaging, intuitive interfaces — ones that they’ll want to work with for a long time. So, where to start?

First, Take a Broader Look

Developers need to understand what “done” will actually look like. It’s a grey area, but in a microservice migration scenario that’s OK; and actually, that’s how it should be because APIs are versioned for a reason. New insights on the business problems handled by the new services can change the approach taken or the teams responsible for managing them.

Nevertheless, having a definitive mindset around the type of service and API that will most efficiently drive migration efforts is key. This way, developers can paint the perfect picture of how the process will play out early on, enabling them to make the call on whether or not it’s the right way to look at the change. These confirmations of an API’s usefulness will be continuous.

The net here is that this is a migration, not a transformation. Going against what’s already in place is not the end game, and never should be. It sounds like an investment of huge proportion, and it might be, but regardless developers are able to work faster to rule out (or rule in) an API’s interface amid a journey that better serves the organization in the long run.

The Business Process

Microservices allow software to rapidly communicate with other layers in the tech stack across diverse networks, an attribute that is vital if the business wants to remain competitive in the industry. Therefore, implementing and testing the most efficient business process is mission-critical for a migration that delivers ROI.

Integrating with API-stored data also enables developers to adapt to routinely working with them, and to quickly deal with any issues coming from the migration. Having a concrete understanding of the service and API that’s being created will make executing the migration a lighter lift. Basically, being transparent about how data is being concentrated helps developers to make decisions that ultimately benefit the project (and themselves) during the migration process.

Test the Waters

Again, an API-first approach allows developers to more quickly find out whether the strategy will succeed or fail. Chances are there will be some failures, so be ready and open to it. Design mistakes are common, and retiring a prototype and starting over is fine. Immediate use — and therefore, immediate feedback — of the API really helps cement the benefits of this approach.

The outcomes from implementing and observing these APIs can differ based on the process — developers might be creating datastore APIs in their monoliths, or separate from them. Either way works. What’s essential is the ability to know within days — rather than years — that an API’s interface will (or will not!) serve the migration.

Marching On

It’s important to know from the start that the perfect migration plan is not going to happen in one take. It’s a constant process. API interfaces are unpredictable against an existing monolith (and some more than others), so throughout the migration they’ll need to be prototyped, utilized and changed — in other words, constantly evolving. But by leveraging an API-first approach to microservice migration, this process can be much shorter — being executed over days, rather than months or even years at a time.

This approach also allows developers to grow their skill sets and create APIs they exceed at and enjoy working with; clearing a path for taking action when redundant development work becomes an ongoing issue. Once developers grasp and accustom themselves to these mechanisms, they’ll feel a shift in productivity that will drive them forward in their career as a developer and technical expert.