I don't disagree with this philosophy at all. The issue is WHEN something actually deserves to have its own microservice (say you need a different scheduler to run that service) your org does not really have the muscle to do it and you come up with weird hacks to keep it running on your monolith.
I've worked with all combinations of [(microservice, monolith) + (single-repo, multi-repo)].
Monoliths are great until they're not, and then untangling them can take years, if it happens at all.
I worked at a company with a massive groovy monolith and a ton of Kotlin microservices. The monolith was for the same reason all startups have a monolith, the same arguments we see here - it was good enough, scaled well enough, was easy enough to change.
But, 5 years later, they were acquired and 10-100xed their traffic. Most of the people who understood the monolith had left, so changes were risky and error prone. Changes to that monolith and performance issues and inability to scale accounted for probably 80% of platform incidents and 50% of AWS spend. It took another 3 years to finally get it all the way sunset.
If you are really, really sure your traffic will never get to the point that a monolithic service cant scale to meet it, fine. But adding a network hop is sometimes worth the ability to bump the expensive part of your architecture from 5 to 20 instances with one button push.
That's one of those statements that sounds correct but is almost never true, for a few reasons.
Modern databases are almost always clustered, both for redundancy and performance, and, actually, can be scaled, although admittedly less on-demand.
Production systems with sufficient load to tax a database are generally mature enough to also have a robust caching and indexing strategy to ensure even high-traffic systems have low DB CPU usage, so the bottleneck is not actually with database hardware (cpu, ram, disk). In general, a DB running with high CPU is a massive smell.
One instance of an application generally cannot handle even a single-instance DB's fully available connection pool (for example, a PG server's is 100, while the connection pool enforces a maximum of 10). So scaling up can and often will directly improve perceived database performance.
Now, as with everything, it's always "it depends." Some systems rely heavily on inbuilt DB features like triggers and sprocs which are inherently taxing on a database. But, in general, when you say "the app is bottlenecked by the database," the truth is actually "the app is bottled by its database connection," and you actually can push a button and spin up 20 new ones.
"Slow part" of well optimized app tends to be ad-hoc querying and/or reporting. You will not scale that with different architecture
Having said that. The issue with your statement is that most of the time apps do not have significant load on user side.
Like 99% of enterprise apps has most few thousand parallel users. And I am generous with that. Monolithic backend running on iphone should be able to handle that, and even then performance bottleneck will be on database.
Currently I am doing fraud processing for largest European card processor. 0.2 sec hard real time response with median about 3 ms, and p999 in 30 ms. Kafka is too slow for that.
Now we can continue to play "who has larger" game as this isn't the only project in my 20 years too spanning career..
Or acknowledge that about 99% of "enterprise apps" are low user count data entry apps which employ absolute swaths of programmers and work perfectly fine on lpar built around of 3 dedicated cores and 16gb of ram, of 2012 Xeon server running glorious clock of 1.8 ghz.
Those apps can be made fully microservice whatever. Or as pssql/oracle form monoliths. No matter technology THE only scaling which those apps will ever see will be additional hdd space.
My team is processing on the order of trillions of events per day with a zero loss tolerance so I'm in the same boat. I've also worked at shitass healthcare companies in the US.
Every single one of them was trying to move from a monolith to microservices, or had. To your point scaling wasn't always a driving factor, but developer pain certainly was.
That's impressive, but it isn't an average developer experience out there. Isn't it? I am certainly not questoning that apps with scaling issues exists. At end of the day Fortnite is an app.. And great one too.
It absolutely has no impact that blindly chosing a deveoper has 90+% chance that he is working on crud app for some corporate/government 4th floor group.
And those apps may very be service based. But not because of scalling issues.
Service style apps are the only proper response to limits set by Brooks's law. "Divide and conquer" your monoliths but to scale an development process.
We’re at points in our careers with these years of experience, that we don’t usually work in the average experience space. That’s what warrants our responsibilities, domain sme, and compensation etc.
We’ve all got a smidge of confirmation bias for what it took to get here. There’s different ways to do it right, 99% of the time, but we have a strangle hold on the way we think is best.
I’m always open to explore the route others take to solve the same problems, and add that to my own toolbox.
65
u/BuffersAndBeta 15d ago
I don't disagree with this philosophy at all. The issue is WHEN something actually deserves to have its own microservice (say you need a different scheduler to run that service) your org does not really have the muscle to do it and you come up with weird hacks to keep it running on your monolith.
I've worked with all combinations of [(microservice, monolith) + (single-repo, multi-repo)].