I agree w/ the sentiment, but the author doesn't seem to understand why people tend to like touching the customer at the edge. Since everyone is doing TLS these days, you have to do a TCP connect round-trip and a TLS round-trip before you can start yammering over a connection securely. So that's at least three round-trips. If you're one-way latency is 200ms, that's about a second of delay before things start happening. The benefit of the edge is you can establish a connection with an endpoint that's "nearby" with less latency for the TCP & TLS round-trips and then use a previously established connection (that does not require you to do the TCP & TLS roundtrips.)

There's still latency, but the impact of the round-trips at connection time is reduced.

Also, web-apps use horizontal scaling largely to reduce the impact of head of line blocking (where requests are queued up at the client waiting for the current request to complete.) Browsers will sometimes (often?) open multiple connections to the same endpoint to reduce HoL blocking impact. But, sometimes apps are inherently serial (you don't know what the next request is until you get the response back from the current request) so YMMV. Also... HTTP/2 and QUIC are cool, and I think most major browsers support either or both.

Amazon is also sort of (in)famous for triple-redundancy. Their apps run in at least three different availability zones (think different data centers) to avoid the impact of one data-center going down. Sure, it doesn't happen very often, but Amazon REALLY doesn't want their site to be down at all.

So sure... you COULD run the overwhelming majority of web apps on a single container in a small VM on a single machine somewhere, but it's more than just resource utilization. It's also responsiveness and resistance to single data-center failures.

But don't confuse my comments with a callous disregard for the OP's concerns. Dude has a point. I think anyone who tries to deploy a web app to AWS (or Azure or GCP or ...) is barraged with messages about how you have to deploy things in multiple data-centers and you're not a REAL developer until you've crafted your own customized templating engine for spitting out TerraForm or CloudFormation scripts that automagically deploy to N+1 unique datacenters.

There's probably a market out there for a simplified system that's "here's a simple {Node|Python|Ruby} app. Automagically distribute the backend to N different data-centers, maybe only one is up at a given time and the other N-1 are hot spares. And make the persistence tier indistinguishable from a local DB like Mongo or PostgreSQL (or some weird Prevayler-like thing.) Don't make me craft custom TF or CF to manage redundancy.)"

Please note. I'm not talking about using SAM.

To recap... I think the OP has a very valid point, but may not be familiar with all the current triple-redundancy dogma.