> Right, but you can also eg run both versions of python on different machines and switch between them at the load balancer layer.
That sounds to me like you are complementing the downsides of running a monolith with the downsides of operating a distributed system, without any noticeable upside.
I should clarify; that technique doesn’t work if there are calls between systems on different versions unless they are tested on both.
I wouldn’t run a system where the two servers call one another.
This is a technique for reducing risk via toggles at the load balancer. The reduction is achieved by making it possible to deploy smaller changes to users, and by reducing the latency of rollback.
These are only useful if you have the ability to introspect the system state in production and confirm whether a new version is working correctly.
It sounds like you're referring to blue/green deployments without using it's name, for some reason, and while failing to present any case of why a monolith provides an advantage. You're just showing downsides without any upside as a tradeoff.
I mean, with microservices you can also do blue/green deployments, and they are not all-in like monoliths. Each deployment only covers a subset of features that can gradually be rolled in and out with the only risk of causing partial failures.
That sounds to me like you are complementing the downsides of running a monolith with the downsides of operating a distributed system, without any noticeable upside.