Serverless and Edge Functions Are Quietly Eating the Server

I keep having some version of the same conversation with developer friends this year: “we ripped out our Express server and just put it on the edge.” A year ago that sentence would’ve needed a lot more explaining. Now it barely raises an eyebrow.

The pitch for serverless isn’t new — AWS Lambda has been around since 2014. What’s changed in 2021 is where the code actually runs. Cloudflare Workers, Vercel Edge Functions, and AWS’s own Lambda@Edge push your function out to points of presence scattered around the globe instead of a single region. A request from Tokyo doesn’t have to round-trip to us-east-1 anymore; it gets handled a few hundred miles away. For anything latency-sensitive — auth checks, personalization, A/B test routing, redirects — that’s a real, measurable win, not just a marketing bullet point.

There’s also an operational story here that I think matters more to most teams than the latency numbers. Managing servers is work. Patching, autoscaling policies, load balancer configs, capacity planning for traffic spikes — none of that is the reason most companies exist, but it eats real engineering time. Serverless and edge platforms hand that off to the provider. You write a function, you deploy it, and the platform figures out how many instances to run and where. For request-driven workloads — the bulk of what a typical web app does — that tradeoff is looking increasingly obvious.

The catches nobody skips over in the pitch decks

None of this is a free lunch, and anyone who’s actually shipped something on the edge will tell you where it bites. Cold starts are still a thing, even if edge runtimes have gotten better at minimizing them by using lightweight V8 isolates instead of full containers. Debugging is harder — you can’t just SSH in and poke around when something’s misbehaving in a data center you don’t control. And the runtime environments are constrained on purpose: Cloudflare Workers, for instance, don’t give you a full Node.js environment, so libraries that assume access to the filesystem or certain Node APIs just won’t run there without modification.

There’s also a genuine architectural rethink required. Edge functions work great for stateless, short-lived logic. The moment you need a persistent database connection pool, a long-running background job, or heavy compute, you’re back to reaching for traditional servers or specialized backends — durable objects, edge-compatible databases, or just falling back to a regional origin server behind the edge layer.

I don’t think this spells the end of “real” servers anytime soon, despite how some of the more breathless takes frame it. What I do think is happening is a genuine unbundling: the parts of an application that are simple, stateless, and latency-sensitive are migrating outward to the edge, while the stateful, heavyweight parts stay put. That’s a more interesting story than “serverless kills the server,” and it’s also a more accurate one. If you’re starting a greenfield web project right now, it’s worth at least sketching out which routes could live on the edge — you might be surprised how much of a typical app qualifies.