Solving the problem of needing to run two different technology stacks by running two different technology stacks is decades older than the concept of micro services.

I'm a huge monolith proponent. But that doesn't mean I think every application should be one service. I just believe you shouldn't create a second service until you have a good reason to like "we need to run on two different tech stacks", or "our team is getting hard to manage let's split it into two teams that work on 2 services".

Problems are typically older than solutions, yes.

And it's simple to concede that monoliths need to be split sometimes. It's much harder in practice to do so. Most monoliths do not have standards, let alone enforcement mechanisms, to ensure that the design of the monoliths leave open splitting later. The things that can make that process difficult (or impossible) are many and subtle, such as global state, in process locks, interpreter protected consistency guarantees, disregard for ABI implications, etc. Having different processes (in production!) does guarantee that a snarl of those problems will not prevent splitting things up later.

> such as global state, in process locks, interpreter protected consistency guarantees,

If you need to share state or you need consistency/locking/transactions across bounded contexts on one service it's trivial to implement. But this can be incredibly difficult to do correctly across multiple servers. No one has implemented a multi-phase commit over multiple services and said "dang that was easy" afterwards.

They're the cure and the disease.

Without a way to keep the system heterogeneous, people have to accept that they are on the same upgrade treadmill as the rest of the people in the organization, which means they have to constantly invest time and energy into keeping up with things.

Containers or microservices mean that the upgrade happens fifteen times, not once, and each group has their own little passion play about why they should do it later instead of now. And in the time it takes to argue about 15 upgrades, 2 more versions have come out.

This is the same issue as with static linking. This debate is quite old and was once "decided" already in favor of dynamic linking...

Using dynamically linked libraries enforces to upgrade all dependencies in lock-step. But you need to fix bugs or security issues only once for your whole software distribution.

Right, but you can also eg run both versions of python on different machines and switch between them at the load balancer layer. That also lets you eg quickly roll back the upgrade from a single area.

You can do all these things either way. The question is which way suits your tools and organisational structure.

But if you have a lot of migration to do, you're keeping compatibility across the whole stack that entire time. If you have more atomic processes, the trivial ones get migrated trivially and aren't forced to carry technical debt for extended periods of time.

And there are worse scenarios than python upgrades. What happens if your processor or your OS reaches end of life? Do you keep running the whole stack on Windows XP without security patches until the last bit is ready?

Hopefully you fix compatibility with newer versions of windows years before XP goes end of life. A lot of people seem to have created these problems for themselves by buying into proprietary platforms that then get yanked from underneath them. You can generally choose stacks that don't have this problem (or not to nearly the same degree).

If some parts are running xp exposed and unpatched, your organisation needs to fix that before tackling application architecture. The question doesn’t make sense; I might as well ask which galaxy I should colonise.

No technique or tool will fix your organisation.

> 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.

I still fail to see the point of your approach.

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.

It is possible, and easy, to have two virtual environments with a different python version in the same project. I am doing this right now with a long-lived project, where a deploy script uses python 2 and everything else python 3.

Only in different processes.

That's not a big problem in a small org/app