> And if the set up is like most apps, you will likely need both running to debug most issues because most issues happen at the system to system interface
wrong. well architected services would have a good interface and problems rarely span multiple services.
>- has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years -> you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun!
this is no un-nuanced. the point is if you have decomposed the codebase into smaller ones - migrations are easier.
Surely if your monolith codebase is good enough, migrations will be easy too. And a well architected system can be run on a single machine. If you don't believe me, try running windows 95 on your machine. These are True Scotsman fallacies that devs often use to justify whatever paradigm/philosophy they believe in. Most code in the wild is not perfectly designed or if it is, it doesn't stay so for long. Paradigms that rely on optimal conditions to work decently aren't universally useful imo.
If your car only works on pristine, smooth roads, it's not a good car, no matter how many cool features it has or how fast you can ride it.
wrong. well architected services would have a good interface and problems rarely span multiple services.
>- has an old bespoke Ant + Maven + Jenkins + Bash + Perl build and deploy system that has been built up over the last 30 years -> you can have the same problem on a micro service architecture, you can actually have that problem multiplied by 10 and now you can spend a whole sprint updating dependencies. Fun!
this is no un-nuanced. the point is if you have decomposed the codebase into smaller ones - migrations are easier.