This would presuppose only a single new version being "in-flight". But a microservice change often bleeds into another microservice having to change. Multiply this by all the agents working on the product, and you get a very complicated release process for those microservices.

The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.

▲

pianopatrick 41 minutes ago | parent | next [-]

Right but if you coordinate those changes in a new version you would still have the old version to fall back to if any of those changes lead to problems.

	▲	kstenerud 23 minutes ago \| parent [-]
		Yes, but then there's a trap lurking nearby: As different versions of the same function proliferate, it muddies the waters, because you now have multiple parts of your system calling a similar-but-not-quite-the-same function. Your refactors are never complete, and you find yourself less able to properly reason about the system as a whole anymore. The payment and subscription systems call different versions of the same function, which works most of the time but they don't always agree. With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.

▲

jatora an hour ago | parent | prev [-]

More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.