[torginus]

I disagree - it's often engineering's fault. It's been pretty consistent that a decently specced server, running PHP that was written sometime last century, generating static pages, redis cache in front, and serving static content via nginx, beats the everloving pants off whatever fotm microservice SPA monstrosity modern devs tend to come up with.

The most hilarious if you go to pirate sites (for stuff like comics, manga or movies), and it's 100x faster and works better than the official paid for alternative, even though I'm sure the former runs off some dudes former gamer PC in his bedroom.

[extraisland]

A lot of companies seem to architect their web apps to deal with millions of users. When in reality they may have a couple of hundred hitting the site at once.

This explodes the cost of development and it makes current web development miserable IME.

I am forced to deal with everything being totally overengineered when a Flask app with a PostgresSQL backend could probably do the job on a reasonably priced VPS.

[torginus]

I used to work at a boring mid-sized finance-y company a while ago. Our stack was full Microsoft - IIS,ASP.NET,MS SQL, plus some appliance doing load balancing/API throttling stuff (not sure, not a sysadmin guy). The whole thing fit in a closet, handled 10k+ requests day and night.

All our code was basically - check user auth - do some stuff with the db/perhaps call out to some external service - serve request.

I never saw a single request above 50ms, with most being way less. Nobody ever talked about performance.

Then I moved to a fancy startup. EKS, nodejs servers, microservices of every denomination, GraphQL, every fashionable piece of tech cca 2018. I realized node was shockingly slow, and single threaded to boot, all that overhead added up to requests with a median latency of about 200ms, with the 99% latency measured in seconds.

Performance engineering was front and center, with dashboards, entire sprints dedicated to optimization, potential optimizations constantly considered, adding fake data and suspense to our React frontend, to hide latency etc. It was insane.

[extraisland]

This has been my precisely my experience. There are lots of odd gotchas when working with these fancy stacks and the platform themselves often don't provide much benefit.

[ben_w]

If it's done right, "millions" of users is something you can serve on racks of machines specced from the late 00s with all the commensurate sysadmin tools.

It's just that "done right" means the web pages are actually crafted to be what they need, and there's none of the modern extras like 1850 ad tracking agencies all being copied in, nor an ad server injecting just about anything…

[sgarland]

They cosplay as architecting them that way. IMO, one of the largest negative consequences to EverythingAsAService is that it allows people with little to no experience administering and tuning systems to run complex pieces of software. Sure, you can go spin up a managed Kafka cluster with a few clicks, but that means you can skip reading the docs, which means that you likely have no idea how to use it (or even when you should use it). Case in point for that: the number of people who think Kafka is a message queue.

This is also a huge contributor to the curse of Full Stack Engineering. “Full Stack” should mean that you have significant experience with and knowledge of every system and language you’re interacting with (I’ll give systems administration a pass for the sake of argument). For most web apps, that means frontend and backend, as well as some flavor of RDBMS, some flavor of caching, and likely a message queue. It likely also means you need to understand distributed systems. The number of developers I’ve met who tick all of those boxes is zero. Honestly, as soon as you include an RDBMS, it’s game over for most. Yes, you can get away with horrible things via ORMs, but as soon as you start hitting scaling limits, you’ll discover what people have known for decades: databases are tricky, and chucking everything into JSON columns with UUID PKs isn’t a good idea.