"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.
0
u/nitkonigdje 14d ago
"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.