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

Check out the IT Market Clock report for recommendations on how to consolidate and replace legacy databases. Brought to you in partnership with MariaDB.

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!

Interested in reducing database costs by moving from Oracle Enterprise to open source subscription?  Read the total cost of ownership (TCO) analysis. Brought to you in partnership with MariaDB.

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

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}