Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Microservices and the Impact on the Database

DZone's Guide to

Microservices and the Impact on the Database

So you are ready to start building a bunch of microservices, have you considered the impact on your database?

· Database Zone
Free Resource

Find out how Database DevOps helps your team deliver value quicker while keeping your data safe and your organization compliant. Align DevOps for your applications with DevOps for your SQL Server databases to discover the advantages of true Database DevOps, brought to you in partnership with Redgate

Image title

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

Image title

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!

Align DevOps for your applications with DevOps for your SQL Server databases to increase speed of delivery and keep data safe. Discover true Database DevOps, brought to you in partnership with Redgate

Topics:
micro services ,microservice architecture ,database ,performance and monitoring ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}