Microservices vs Serverless Architecture

These two words are not on the same axis, and treating them as either/or is the mistake most people make. Microservices is an architectural decision — how you cut a system into independently deployable services. Serverless (specifically FaaS: Functions-as-a-Service like AWS Lambda) is a runtime and billing decision — how one unit of code is hosted, scaled, and charged for. The real trade-off an engineer weighs is how each service runs: as an always-on managed container that you keep warm and scale by adding replicas, versus an on-demand function that the provider spins up per request and bills per millisecond. You can, and people routinely do, implement a microservice on serverless — the checkout service is a set of Lambda functions. So the honest question is never "microservices or serverless"; it is "for this service, do I want warm capacity I manage, or per-invocation capacity the cloud manages?"

The mechanism: warm replicas vs per-invocation instances

Always-on container. Your process boots once, holds a DB connection pool, JIT-warms, and sits behind a load balancer waiting for traffic. Concurrency comes from the request-handling threads/goroutines inside each replica; you scale by running more replicas. Idle replicas still cost money because the CPU/RAM is reserved for you whether or not a request arrives.

FaaS / serverless. There is no long-lived process you own. When a request arrives, the platform finds a warm micro-VM (on AWS, a Firecracker microVM) that already has your code loaded and hands it the event; if none is free, it provisions a fresh one — download code, start the runtime, run your init code — and only then handles the request. That provisioning delay is the cold start. Crucially, one instance handles one request at a time: 500 concurrent requests means 500 concurrent instances. When traffic stops, instances are reaped and you scale to zero — you pay nothing. Billing is GB-seconds of wall-clock execution plus a per-request fee.

That single sentence — you pay only while code runs, but each request may pay a cold-start tax and there is a hard ceiling on how long/big one invocation can be — drives every trade-off below.

Worked example: an image-resize endpoint, both ways

Same service — resize an uploaded image. Each call uses 512 MB of memory and runs for 200 ms. We cost it on AWS Lambda (us-east-1 x86: $0.0000166667 per GB-second + $0.20 per 1M requests) versus a warm container fleet on Fargate (approximately $0.04048 per vCPU-hour + $0.004445 per GB-hour on-demand; a 1 vCPU / 2 GB task ≈ $0.0494/hour ≈ $36/month running 24×7). One warm worker at 200 ms/request handles ~5 req/s.

Per-invocation Lambda cost: 0.5 GB × 0.2 s = 0.1 GB-s × $0.0000166667 = $0.00000166667 compute, plus $0.0000002 request fee = $0.00000186667 per call.

The crossover trace (why): Lambda cost is a straight line through the origin — N calls × $0.00000187. The container line is a step function that starts high (you pay for the first idle task) but the marginal cost of the next request is ~$0 until a worker saturates. The honest comparison is at full utilisation: a 1 vCPU / 2 GB Fargate task costs ≈ $0.0494/hr and at 200 ms/request serves ~5 req/s = 18,000 req/hr, i.e. ≈ $0.00000274 per request — roughly 45–50% above Lambda's $0.00000187. So:

1. At 100 K calls the container fleet is ~99% idle capacity you paid for; Lambda's pay-per-use crushes it (≈ $0.19 vs ≈ $36).
2. On published on-demand rates the two per-request lines never cross — a 100%-busy on-demand task ($0.00000274/req) is still ~47% dearer than Lambda ($0.00000187/req). That is why the 50M and 300M rows are a clear Lambda win at list price; the naive "containers just get cheaper at scale" is false at on-demand pricing.
3. The container's real edge at steady high volume comes from levers Lambda does not give you: reserved capacity / Savings Plans / Spot at a 40–70% discount (dropping a fully-utilized task to ≈ $0.0000008–0.0000016/req), amortising heavyweight startup, and not having to buy provisioned concurrency to tame the cold-start tail. Apply a ~50% Savings-Plan discount and a fully-utilized container falls to ≈ $0.0000014/req — about 25–30% under Lambda; on Spot (~70% off) it is ≈ $0.0000008/req, less than half Lambda's rate. But the discount only wins if the fleet stays busy: the discounted container undercuts Lambda exactly when (1 − discount) ÷ utilization < ≈0.68 (i.e. $0.0494 × (1 − d) ÷ (18,000 × u) < $0.00000187) — a 50%-discounted fleet needs >~73% sustained utilization, a 70%-off Spot fleet needs >~44%. That discounted, well-utilized line, not the on-demand one, is the crossover that matters in practice.

Sensitivity — where does the crossover move? The comparison is really lambda_unit_cost vs container_hourly_rate ÷ (utilization × capacity), and two levers dominate. Duration: Lambda bills wall-clock per invocation with one request per execution environment, so tripling the handler to 600 ms triples the Lambda line (≈ $0.0000052/call vs $0.00000187). What it does to the container line depends on why the handler is slow: if it is waiting on I/O (a downstream API, S3), one container serves many requests concurrently through the wait, its per-request cost barely moves, and long I/O-bound handlers pull the crossover sharply toward containers; if it is CPU-bound, tripling duration also cuts a worker's throughput to a third (5 → ~1.7 req/s), so both lines triple together and the ~47% on-demand gap persists. Utilization: the container's per-request cost is (hourly rate ÷ achieved req/hr) — at 40% fleet utilization it is 2.5× the full-utilization figure (≈ $0.0000069/req vs ≈ $0.0000027 at the verified rates), pulling the crossover back toward Lambda. Idle-heavy fleets and I/O-heavy Lambdas are the two configurations where the folk intuition inverts.

Note the numbers ignore the cold-start tax: at 100 K spiky calls, a meaningful fraction of requests hit a cold instance and see +100 ms to +3 s of extra latency the container fleet never pays.

The hard limits FaaS imposes (and containers don't)

• Cold-start latency. First request to a new instance pays init. A slim Go/Node function is ~100–400 ms; a JVM/.NET function with a fat classpath is often 1–5 s. Lands directly in your p99 tail. Mitigations — provisioned concurrency, SnapStart — cost money and partly defeat scale-to-zero.
• Max execution time. AWS Lambda caps at 15 minutes per invocation; a long ETL, video transcode, or big report will be killed mid-run. A container has no such wall.
• Memory / CPU ceiling. Lambda tops out at 10 GB RAM (CPU scales with memory, ~6 vCPU max). Bigger models or in-memory joins won't fit.
• Payload & ephemeral disk. 6 MB synchronous / 256 KB async event payload; /tmp is 512 MB by default (configurable to 10 GB). Large file work must stream via object storage.
• Enforced statelessness. No sticky in-memory session, no local write-behind cache survives across invocations — every instance is disposable. State must live in Redis / DynamoDB / S3, which adds a network hop and cost.
• Vendor lock-in. Your code binds to the provider's event shapes, IAM, triggers, and limits. Moving Lambda + API Gateway + DynamoDB to another cloud is a rewrite, not a redeploy. Containers (OCI images on Kubernetes) are far more portable.

When to choose which

Signals that point to serverless (FaaS):

• Traffic is spiky or unpredictable and often near zero — you refuse to pay for idle warm capacity.
• Work is event-driven and short: react to an S3 upload, a queue message, a webhook, a cron tick; finishes well under 15 min.
• You want zero ops — no fleet, no autoscaler, no patching — and can tolerate a cold-start tail.
• Glue and integration code where per-request latency isn't user-facing.

Signals that point to always-on containers (microservice on ECS/Kubernetes):

• Steady, high throughput — the fleet stays busy, so pay-per-use is pure overhead and reserved capacity is cheaper.
• Tight, predictable latency requirements — you can't accept cold-start jitter in p99.
• Long-running work, big memory, GPUs, persistent connections (WebSockets, DB pools), or heavyweight startup you want to amortise.
• You need portability across clouds or strict control over the runtime.

Choose FaaS when load is intermittent and latency-tolerant and you value zero idle cost and zero ops above tail-latency and portability. Prefer always-on containers when load is steady and high, latency must be tight, or a job outgrows FaaS's time/memory limits — you trade some ops and always-on cost for control and no cold starts. And remember the framing: a mature system is usually both — steady core services as containers, spiky edges and event handlers as functions, all under one microservices decomposition. A named middle ground is worth knowing: container-on-serverless platforms (Google Cloud Run, AWS App Runner, Fargate with scale-to-zero via KEDA) run your OCI image but scale it per-request and to zero — you keep portability and longer runtimes while regaining pay-for-what-you-use, at the price of a lighter cold start than a fresh VM but heavier than a warm fleet.

Pitfalls

• Treating the choice as system-wide. It's per-service, sometimes per-endpoint. Forcing everything onto Lambda strands your steady, latency-sensitive services on a bad cost/latency curve; forcing everything onto a cluster makes you pay for idle everywhere.
• Ignoring downstream connection storms. A traffic burst to 500 Lambda instances opens 500 DB connections at once and topples a database sized for a small warm pool. Containers naturally cap this; with FaaS you need RDS Proxy / a connection proxy or reserved concurrency.
• Chatty function-to-function calls. Splitting a workflow into many synchronous Lambdas stacks cold starts and network hops, inflating latency and cost. Prefer async event chains or a single function doing the step.
• Forgetting the request fee at volume. At hundreds of millions of calls, the $0.20/1M fee alone becomes real money — and it's exactly where containers pull ahead.
• Assuming "serverless = cheaper" always. It's cheaper for idle-heavy load; for sustained load a discounted, well-utilized container fleet undercuts it — the crossover is real and you must estimate it (with your discount and utilization plugged in), not assume it.

Takeaways

• Microservices is how you decompose; serverless is how a unit runs and is billed — different axes, not competitors. A microservice can run on serverless.
• The real decision is warm managed capacity (containers) vs on-demand per-invocation capacity (FaaS); it's made per service, and mixing both is normal.
• FaaS trades away cold-start latency, a 15-min/10-GB ceiling, enforced statelessness, and portability in exchange for scale-to-zero, zero ops, and pay-per-use.
• Cost curves cross: FaaS wins on spiky/idle load; containers win on steady/high load only via discounted (reserved/Spot), well-utilized capacity — at on-demand list price the lines never cross, so estimate the crossover before committing.

Re-authored and deepened for this guide. Sources: AWS Lambda Developer Guide and pricing (execution limits, cold starts, provisioned concurrency, GB-second billing); AWS Fargate pricing; Sam Newman, Building Microservices, 2nd ed. (decomposition vs deployment); Martin Fowler, "Serverless Architectures" (martinfowler.com); the CNCF Serverless Whitepaper. Cost figures use published us-east-1 rates and are illustrative — verify current pricing for your region and workload (Fargate on-demand vCPU/GB rates re-checked against the AWS Fargate pricing page 2026-08).

Drill ladder: decomposition vs runtime

1. L1: Microservices = decompose; serverless = run/bill unit — orthogonal.
2. L2: 2k Lambdas → DB connections without proxy — what breaks first?
3. L3: Pinning on RDS Proxy — which session features cause it?
4. L4: Cost crossover: steady 24/7 vs spiky — which wins?
5. L5: When WebSocket hub cannot be pure FaaS.