3 ms·
They are talking about deployment. With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will b
by threeseed 3y ago
They are talking about deployment.
With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down.
With a monolith the whole system is down.
- quickthrower2 3y agoThere are a lot of deployments options to mitigate that risk.
- charcircuit 3y ago>With a monolith the whole system is down. No, you are just at reduced capacity. The moral of the story is not to roll out to 100% right away.
- threeseed 3y agoMonoliths go hand in hand with a centralised database. Bit hard to do schema evolution with a staggered rollout.
- charcircuit 3y agoThe software should be compatible with both the old and new schema until all of your database servers have moved over to the new schema. All rollouts are going to be somewhat staggered even if you go straight to 100%.
- DougBTX 3y agoIf schema migrations take non-zero time and you want zero-downtime deployments, then the both service versions need to be compatible with either the new schema or the old schema, regardless of service size.
- ownagefool 3y agoThe same problem exists in microservoce land, only you now have a load of separate teams managing their own database, perhaps with different solutions.
- hervem 3y agoWait, micro-service and sharing same DB? Did I miss something?
- ownagefool 3y agoI think you misunderstood what I said, which is you still have databases and ergo need to manage migrations and such, only that this now typically falls to the specific teams. That said, loads of folks do microservices with a shared dB.
- gizzlon 3y ago> With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down. In theory, but when the getUser service is down, your app is probably broken as well.