Keep the monolith, but split the workloads

One critique I have is that this presents a binary option of either full monolith and microservices.

The truth is somewhere in between where you have dependent services large enough to warrant being their own monolith being split off. Breaking up of a monolith is almost never (anecdotal observation after 15 years of seeing this argument surface in every company I've been in) a technical need, but a combination of organizational and business requirements. This is not to say it's never technical, just that it's rare for it to be a reason.

Organizational: The teams are so huge that they prefer their own development cycle, deployment, and rollout safeguards.

Business: Partitioning of products for different SLAs, which is difficult to guarantee when you have a different team introducing some bug every other week that takes down the servers.

Also affectionately called macroservices.

No idea if I stole it some where or came up with the idea when I was falling into slumber after losing a few days to a P0 incident, but I think it describes the N-tier architecture and what I adopt at work quite well.

One often finds derogatory remarks about PHP, or that the popularity of the language is declining. Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. The failure that the Rails app experienced in the post simply wouldn't have happened with PHP. Especially for web applications, PHP's concept of "One Request = One freshly started process" is absolutely brilliant.

So, OP is right, write more monoliths, and I would add: write them in languages that fit the stateless nature of http requests.

You’re right, that’s a very fair point. I should’ve made it clear that the middle ground of moderately-sized but logically separate services is very much a good world to be in.

I’d actively encourage splitting a monolith into services when the candidate split would be:

1. A service that has a clear purpose that can be explained either separately from the monolithic whole or as a complementary piece

2. It will receive enough active development that the cost of upgrading/on-going investment is an acceptable percent of total work time

3. It can improve the organisations state of ‘ownership’ and better align the codebase with the team structure that own it

There is always a middle ground, and I should’ve done better to explain that.

PHP is amazing, yes the syntax is a little awkward. I love working with it.

Especially with libraries/ framework that are 10+ years old Their documentation is extremely detailed.

So you have more confidence that you'll deliver a working product. Instead of reading github issues to fix an obscure error message.

Old does not always mean outdated.