Every few years the industry anoints a new hosting paradigm as the thing that renders everything before it obsolete. Serverless is the current favorite, and if you took the marketing at face value you’d assume we should have shredded our VPS fleets years ago. Reality is messier. I’ve moved workloads onto Lambda that cut a client’s bill by 80%, and I’ve also watched teams pour money into serverless setups that would have hummed along quite happily on a $20 VPS.<\/p>\n
The honest framing is that serverless versus traditional hosting isn’t a fight with a champion. They’re different tools that solve overlapping problems with wildly different tradeoffs across cost, latency, control, and operational effort. Choose wrong and you’ll either overpay, slam into an execution ceiling at the worst possible moment, or spend your weekends patching kernels you never wanted to think about in the first place.<\/p>\n
What follows is a walk through the architectural differences that actually show up in production, complete with the numbers and gotchas I wish somebody had handed me before my first serverless migration.<\/p>\n
Before we get into costs and latency, it pays to be precise about what each model hands you and what it takes away. The vocabulary gets muddy fast, so let’s anchor it.<\/p>\n
Traditional hosting means you rent a machine\u2014virtual or physical\u2014and it runs around the clock. A VPS carves out a slice of a hypervisor’s CPU, RAM, and disk; a dedicated server hands you the entire box. Either way you get a full Linux userland: a kernel you can tune, a package manager, systemd, cron, persistent block storage, and root.<\/p>\n
Everything above the hypervisor is yours to run. OS updates, firewall rules, service hardening, log rotation, backups, process supervision\u2014all your problem. The machine belongs to you until you power it off, and it bills the same whether it’s serving ten requests a second or sitting idle at 3 a.m.<\/p>\n
“Serverless” is a misnomer\u2014there are still servers, you just never lay eyes on them. You upload a unit of code (a function), attach a trigger (an HTTP request, a queue message, a scheduled event), and the platform runs it on demand. When nothing calls it, nothing runs and nothing bills.<\/p>\n
The constraint that defines everything else is that functions are stateless<\/em> and ephemeral<\/em>. Each invocation may land on a fresh execution environment with a scratch filesystem that evaporates when it’s done. There’s no persistent local disk to lean on, no long-lived daemon guaranteed to hold an in-memory cache across requests, and a hard wall on how long any single invocation can run. Durable state of any kind\u2014sessions, uploads, application data\u2014has to live in an external managed service.<\/p>\n The major players share the model but diverge on the details that shape your latency and portability:<\/p>\n Cost is where the two models split most sharply, and where the priciest mistakes get made. The core distinction is simple: serverless bills for work performed<\/em>, traditional hosting bills for capacity reserved<\/em>.<\/p>\n Serverless pricing has two parts: a charge per request and a charge for compute time measured in gigabyte-seconds (memory allocated \u00d7 execution duration). Lambda bills duration in 1-millisecond increments. A function allocated 512 MB that runs for 120 ms costs you for exactly that sliver of resource and nothing more.<\/p>\n Roughly, Lambda charges around $0.20 per million requests plus about $0.0000166667 per GB-second. Run those numbers on a low-traffic API and they look almost comical: a function handling 100,000 requests a month, each running 100 ms at 256 MB, comes out to a few cents. The generous free tier covers many hobby and internal-tool workloads outright.<\/p>\n Traditional hosting inverts this. You pay a flat monthly rate for a fixed allotment of CPU, RAM, and storage. A 2 vCPU \/ 4 GB VPS might run $20\u201340\/month regardless of load. That predictability is a genuine feature\u2014you know your bill before the month begins\u2014but you’re paying for the peak capacity you provisioned even during the 80% of the day when utilization sits below 10%.<\/p>\n The mental model is what matters here: with a VPS, idle time is sunk cost. With serverless, idle time is free. Which one wins comes down entirely to the shape of your traffic.<\/p>\n Serverless shines on work that’s bursty, unpredictable, or mostly idle:<\/p>\n I once moved a client’s image-thumbnail pipeline off an always-on worker fleet and onto Lambda triggered by S3 uploads. Their traffic was brutally spiky\u2014dead quiet all week, then a flood on campaign launch days. The old fleet was sized for the spike and idle the rest of the time. Serverless cut the compute bill by more than 70% and, just as valuable, killed the on-call anxiety about the fleet buckling during a launch.<\/p>\n The economics flip the moment traffic turns steady and high-volume. If your function is running essentially all the time at high concurrency, you’re paying serverless’s per-GB-second premium continuously\u2014and that premium is real. Sustained compute on a dedicated box is far cheaper per unit than the equivalent on Lambda.<\/p>\n There’s a crossover point, and it’s worth doing the arithmetic. As a rough heuristic: if a function is busy more than roughly 40\u201350% of the day at meaningful concurrency, price out the equivalent VPS or reserved instances. I’ve seen teams whose “cheap serverless” API was quietly running five figures a month because it never stopped executing\u2014a Kubernetes deployment or an autoscaling group of VPS instances would have cost a fraction of that.<\/p>\n Cost isn’t the only axis. The biggest serverless surprise for teams coming from traditional hosting is cold start latency.<\/p>\n When a request arrives and no warm execution environment is sitting ready, the platform has to build one: allocate a micro-VM or container, load your runtime, initialize your code, and only then handle the request. That provisioning step is the cold start<\/strong>, and it tacks on latency ranging from tens of milliseconds to several seconds.<\/p>\n Warm invocations\u2014where the environment still exists from a recent request\u2014skip all of that and respond in single-digit milliseconds. The catch is that you don’t control when environments get recycled. A function that goes quiet for a while goes cold, and the next unlucky user eats the full startup penalty.<\/p>\n Cold start duration is anything but uniform. The runtime you pick matters enormously:<\/p>\n Memory allocation plays a role too. On Lambda, CPU scales in proportion to configured memory, so a function with more memory initializes faster because it gets more CPU during startup. Counterintuitively, bumping memory from 256 MB to 1 GB can lower your total cost by shortening duration, even though the per-second rate is higher. Benchmark before assuming the smallest memory tier is the cheapest.<\/p>\n Several techniques cut down or eliminate cold starts:<\/p>\n Cloudflare Workers sidesteps the whole problem with a different architecture. Instead of booting a container per function, it runs code inside V8 isolates\u2014the same lightweight sandboxing mechanism Chrome uses for browser tabs. Isolates start in well under a millisecond, so cold starts effectively vanish.<\/p>\n The tradeoff is a tighter environment: you’re limited to JavaScript and WebAssembly, CPU time per request is strictly bounded, and you don’t get the full Node.js API surface. For latency-sensitive edge logic\u2014auth, redirects, A\/B routing, API aggregation\u2014it’s superb. For heavy compute or arbitrary runtimes, it’s the wrong tool.<\/p>\n Everything serverless abstracts away is something traditional hosting hands you full control over. Whether that reads as freedom or burden depends on your workload.<\/p>\n On a VPS or dedicated box you own the environment top to bottom. Need a specific kernel version for a networking feature? Want to set None of this is possible inside a function environment. That’s the point\u2014and the tradeoff.<\/p>\n Traditional hosting handles long-lived and scheduled work natively. A Serverless can approximate some of these (scheduled triggers stand in for cron, queue triggers for poll loops), but the stateless, short-lived model fights anything that needs to hold state in memory or maintain long connections. A WebSocket gateway on serverless is possible but architecturally awkward next to a plain daemon on a box.<\/p>\n In serverless the OS is the provider’s problem. You never SSH in, never patch a kernel, never configure a host-level firewall. Under the shared responsibility model, the provider secures the infrastructure and platform; you stay on the hook for your application code, your dependencies (that vulnerable npm package is still yours to fix), and your IAM configuration.<\/p>\n That last point deserves emphasis: least-privilege function roles are the single most important serverless security control. Every function should carry an IAM role granting exactly the permissions it needs and nothing more. An over-permissioned function is the serverless equivalent of running everything as root.<\/p>\n Serverless imposes hard limits that traditional hosting simply doesn’t:<\/p>\n Hit one of these mid-project and you’re refactoring. Know them cold before you commit an architecture to serverless.<\/p>\n Scaling is where serverless earns its keep, and where state becomes the recurring headache.<\/p>\n Auto-scaling serverless is genuinely hands-off. When a thousand requests land at once, the platform spins up a thousand concurrent execution environments (within account limits) with zero capacity planning on your part. When traffic drops, it scales back to zero. No load balancers to configure, no autoscaling groups to tune, no scaling policies to babysit.<\/p>\n Traditional hosting makes you build that elasticity yourself: a load balancer in front of multiple instances, an autoscaling group or Kubernetes horizontal pod autoscaler, health checks, and scaling thresholds. It’s more work and it reacts more slowly\u2014spinning up a new VM takes minutes, not milliseconds\u2014so you typically over-provision headroom to absorb spikes while fresh capacity boots.<\/p>\n The flip side of serverless auto-scaling is that it happily scales your problems<\/em> too. A function that opens a database connection per invocation will cheerfully open ten thousand connections and take your database down with it. Serverless scaling is only as elastic as its weakest downstream dependency\u2014which brings us to state.<\/p>\n Because functions are stateless and ephemeral, every piece of durable state has to live outside the function:<\/p>\n This externalization is cleaner architecturally in a lot of ways, but it drags in a connection-management problem. Traditional relational databases assume a modest pool of long-lived connections; serverless can overwhelm them in a heartbeat. Reach for connection proxies (RDS Proxy), connectionless data stores (DynamoDB), or HTTP-based database APIs to survive high concurrency. On a traditional server, state can live locally\u2014a Redis instance on the same box, a local SQLite file\u2014simplifying the topology at the cost of the elasticity serverless gives you.<\/p>\n The failure modes of each model are distinct. Here are the ones I hit most often, with their usual causes and fixes.<\/p>\nKey Serverless Platforms and Their Runtimes<\/h3>\n
\n
\/tmp<\/code> up to 10 GB.<\/li>\nCost Models Compared<\/h2>\n
Per-Invocation and Execution-Duration Billing<\/h3>\n
Provisioned Capacity Billing<\/h3>\n
When Serverless Is Cheaper: Spiky and Low-Traffic Workloads<\/h3>\n
\n
When Traditional Hosting Wins: Steady High-Volume Traffic<\/h3>\n
Performance and Latency Considerations<\/h2>\n
The Cold Start Problem<\/h3>\n
Runtime and Memory Impact on Startup Latency<\/h3>\n
\n
Cold Start Mitigations: Provisioned Concurrency and Warming<\/h3>\n
\n
Edge Platforms and V8 Isolates (Cloudflare Workers)<\/h3>\n
Control and Environment Flexibility<\/h2>\n
Full OS, Kernel, and Package Control in Traditional Hosting<\/h3>\n
sysctl<\/code> tunables for a high-connection web server? Have to install an obscure system library your application links against, or compile something from source? All trivial. You control iptables<\/code>\/nftables<\/code>, you install and configure your own intrusion detection, and you decide exactly what runs.<\/p>\n# Tuning a traditional server for high connection counts\nsysctl -w net.core.somaxconn=65535\nsysctl -w net.ipv4.tcp_tw_reuse=1\n# Persistent daemon under systemd\nsystemctl enable --now myapp.service<\/code><\/pre>\nCron Jobs, Daemons, and Long-Running Processes<\/h3>\n
cron<\/code> entry, a systemd timer, a persistent worker draining a queue, a WebSocket server holding thousands of open connections for hours\u2014all standard fare.<\/p>\nThe Abstracted OS in Serverless<\/h3>\n
Execution Time, Payload, and Memory Limits<\/h3>\n
\n
\/tmp<\/code> exists but is scratch space, wiped between environments.<\/li>\n<\/ul>\nScaling and State Management<\/h2>\n
Auto-Scaling Serverless vs Manual Scaling<\/h3>\n
Externalizing State in Serverless<\/h3>\n
\n
Best Practices<\/h2>\n
\n
Troubleshooting<\/h2>\n