I'm thinking of creating a repository that will handle database migrations across the services. Is this efficient?
Adekoyejo Akinhanmi
Posted on
What's the best way to manage migrations in a microservice architechure?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (7)
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?
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.
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.
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...
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...
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.
I was looking for about it, and I found the schemahero.io for Kubernetes native.