DEV Community

Adekoyejo Akinhanmi
Adekoyejo Akinhanmi

Posted on

What's the best way to manage migrations in a microservice architechure?

I'm thinking of creating a repository that will handle database migrations across the services. Is this efficient?

Discussion (8)

Collapse
sam_ferree profile image
Sam Ferree

I think ideally, a SOLID microservice architecture would imply that a service for model A doesn't care about the schema changes for model B, so migrations could live in the repo for the services they are for.

I could be wrong though, are you running into a specific problem?

Collapse
senornigeria profile image
Adekoyejo Akinhanmi Author

Specifically, I'm using knexjs for migrations and I was unable to run migrations for files that were not present in the current service migration directory. What I mean is, KnexJS would look through its migrations folder and attempt to correlate previous migrations in the migrations table with the files present. If it doesn't find them, it throws an error. So I decided to move all the migrations to a separate service and do version control there.

Collapse
sam_ferree profile image
Sam Ferree

Ah, I'm used to EntityFramework which stores it' "Last Migration" information in a table on the database, so I'm sure if that would be an issue.

Seems like a good enough reason to keep your migrations in their own repo to me.

There is also probably an argument that could be made for a monorepo for all your microservices.

Collapse
ahmgeek profile image
Ahmad Tolba • Edited

Usually, in a microservices architecture, each service should have it's own DB.
I am not sure how your architecture looks like, maybe you can elaborate on this, but, as I said, each service should use it's own DB if necessary.

If you have a shared DB between multiple services, this is an anti-pattern, what you want to do here is: - to have only separate services responsible for specific entities/tables.

  • the migrations should only run from one specific service.

here's some resources:
microservices.io/patterns/data/dat...

Also here's how we do it in my company:
runtastic.com/blog/en/entity-datab...

Collapse
pdeveltere profile image
Pieter Develtere

Actually, you are incorrect here. A shared DB is not an anti pattern. But you definitely want to have separate tables.

From the article on microservices.io that comes after the article you posted:
microservices.io/patterns/data/sha...

Collapse
aroman012 profile image
Alejandro Roman

It's weird because the website says that and at the same time says that it is an anti-pattern that should be avoided.

See the "Decision 3" section microservices.io/articles/applying...

Collapse
rthordonovan profile image
Ryan Thor Donovan

The Grubhub tech blog put up an article about how they did exactly this when they moved both the legacy Seamless and Grubhub data to a new SOA platform while all three were in use: bytes.grubhub.com/a-migration-stor....

The short of it is, yes, you should have a separate service handle the migration, but also consider giving that service direct database access and ensure that all responses are idempotent in case communication fails in the middle of a migration.

Collapse
danielvincenzi profile image
Daniel • Edited

I was looking for about it, and I found the schemahero.io for Kubernetes native.