I feel like this article conflates monoliths with monorepos. You can have a more flexible (though not as "flexible" as microservices, perhaps for the better) en

I feel like this article conflates monoliths with monorepos. You can have a more flexible (though not as "flexible" as microservices, perhaps for the better) engineering by just following the "libraries" pattern mentioned in the article and splitting each of the libraries into their own repos, and then having version bumps of these libraries as part of the release process for the main application server. Doing it this way gets you codebase simplicity, release schedule predictability, and makes boundaries a bit more sane. This should get you a lot farther than the strawmanned "one giant repo with a spaghetti mess of code" model that the author posits.