As the evolution of the API continues, a lot of developers are beginning to explore the idea of microservices. Instead of building a single API that includes all the functionality of a monolithic application, smaller applications (referred to as microservices) are being spun up to cover a portion of the application.
In a microservices-nirvana world, each microservice would maintain its own database, isolated from other microservices. So, if you had a Customer microservice, it would tie to a database containing only customer-related information. If you had an Order microservice, the same would hold true for order-related information.
The Microservices Struggle
The struggle comes into play when trying to introduce microservices into an existing application. What further complicates the scenario is when there is legacy application tied to the database which needs to be utilized. This approach causes a break in the philosophy where each microservice has its own database.
Recently, a development team where I work was faced with this very scenario. There was an existing application running on a legacy platform. The original plan was to introduce a single API that covered all the functionality needed for the replacement application. Over time, the development team realized that building a single API introduced more concerns than benefits. The biggest drawback was that we had one huge API, covering every facet of the legacy application.
So, the team started to carve out a microservice approach for each of the aspects of the legacy application. This turned out to be an easy task, at first, since the legacy application utilized tabs that broke out the different aspects of the application. However, the challenge was that each service was going to need to connect to the same legacy database... at least for now.
The challenge in this scenario is to make sure the impact on the database is kept in mind when introducing several microservices that all tie back to the same database. In contrast, the monolithic API design maintained one database connection. Now, the new approach would be introducing 5 to 10 microservices, depending on how deeply the team decided to break down the microservices. This could lead to a new set of problems that did not exist before.
We are still early in this process, but I plan to include a follow-up article in the future, which will provide an update on our progress.
Hope you have a really great day!
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}