> You need to be able to gradually roll out a change to prevent problems from escalating and causing downtime. From my perspective I prefer it to rolling updat

> You need to be able to gradually roll out a change to prevent problems from escalating and causing downtime. From my perspective I prefer it to rolling updates, it just costs a lot of resources. It gives you a chance to verify all the parts of your system together during release. You deploy an entire new parallel copy of your system and test it. This can be manual or automated. Once you have confidence, you can flip traffic. Alternatively you can siphon off a slice of production traffic and monitor metrics as you gradually shift traffic over to the new release. Note that you can also nearly "instantly" roll back at any point, unlike with a rolling update. Again, this is only "sort of" a mixed fleet situation because you can maintain the invariant that service A at v1.23 only talks to service B at v1.23. This means you can atomically refactor the interface between two services and deploy them without thinking too hard about what happens when versions are mixed. Distributed transactions I'm not so sure about, we would have to talk specific situations. > And this is being done just because someone thinks it's a good idea to keep all code in a single repo? It's more like, if you have a monorepo this is one option that becomes simpler for you to do, should you happen to want to do it.