I am working on creating a set of microservices in Docker (using .net core and AWS RDS as the backbone, but that is not relevant).
As part of the deployment, the old container and new container co-exist for a short period of time (under 30 seconds usually) to ensure there is no downtime.
However, this means that if my schema is incompatible with the previous version of the microservice (or the old schema is incompatible with the new version), one set of containers will not function correctly.
My thoughts are:
Do backwards-compatible migrations only. Meaning, there is no
delete columnmigrations. I am not impressed with this approach as it would result in some clutter accumulating (granted, with the size of the microservice it won't be too bad, but it will be an unsightly schema in a couple of years time)
Obsolete-remove two step deployments. Meaning in v2 we remove code consuming the schema, but not the schema itself and in v3 we remove the schema. The issue here is that either we need to do two consecutive deployments in a row, which seems stupid, or make sure developers remember to checkin those removals into the next version, which is potentially human error prone and will result in clutter accumulating again
- Have two types of deployments - breaking and non-breaking; with breaking deployment doing the old school stop service, migrate, bring up new service. The issue here is that there is downtime for the end users.
What would you go with, and why? (or, if you already have something else, please do tell).