It will be interesting to get your feedback on the later posts. I hope that the main point of disagreement is when - in terms of size application/team - the problems I described become significant obstacles - not if.

They’re not unavoidable for a start but are a bit presented like that. Also, it’s not that you don’t face many of them in a distributed arrangement. The primary difference is in how and at what cost you approach those challenges, I think.

The point I was trying to convey is that if your application *continues* to grow and eventually becomes *huge* (code base + team) it's *very likely* that you will encounter those problems.

And, I should add IF you want to deploy frequently, reliably and sustainably, e.g. many times a day and want to be able to incrementally upgrade your technology stack then these things matter.

Re tech stack: I think you're conflating two things: upgrading the stack for an entire system is even easier in a monolithic arrangement than if you have to hunt down all teams doing that on their own.

The key point is microservices enable you to upgrade/change the technology stack incrementally, one service at a time -> a series of small tasks spread over time. In a monolith, it has to be done everywhere simultaneously => one large coordinated effort => less likely to be done

I think you can argue to err on the less effort for the more common case (frequently upgrading to bugfix releases for security reasons) and accept the overhead in the rarer event of major upgrades. That said, I haven't ever seen this particular aspect tipping the balance.

I agree that keeping multiple services up to date requires work. But security scanning/analysis tools can handle a big part of that. e.g even Github creates PRs for upgrading dependencies to eliminate vulnerabilities.

But I think a bigger issue is that applications live a long time: chrisrichardson.net/post/mic… Today, so many critical enterprise applications are built on ancient tech but there's never enough time to upgrade (as well as being risky) the large monolithic code.

For example, I've had clients who couldn't upgrade framework X (e.g. Spring!) because that required a Y library upgrade that required widespread changes and so was never done. So their monolith was stuck on a very old version of X.