4 ms·

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 r

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.

rualca 6y ago
> 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.
- danielheath 6y ago
  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.
  - rualca 6y ago
    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.
humanrebar 6y ago
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?
- danielheath 6y ago
  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.
- nicoburns 6y ago
  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).

rualca 6y ago

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

danielheath 6y ago
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.
- rualca 6y ago
  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.

humanrebar 6y ago

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?

danielheath 6y ago
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.
nicoburns 6y ago
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).