Serverless or Containers? A Decision, Not a Religion

Few architecture questions attract as much dogma as serverless versus containers. The honest answer is that both are excellent, both are sometimes wrong, and the right choice depends on details that no blog post can know about your system. What a blog post can do is give you the questions to ask.

Start with the traffic shape

Serverless functions shine for spiky, event-driven, or low-and-irregular traffic — you pay only when they run, and they scale to zero. Containers tend to win for steady, high-throughput workloads where always-on capacity is cheaper than per-invocation pricing and cold starts would hurt.

• Spiky or unpredictable load, glue code, scheduled jobs → lean serverless.
• Steady high throughput, long-running connections, latency-sensitive paths → lean containers.
• Genuinely mixed? Use both — serverless at the edges, containers at the core.

Count the operational cost, not just the bill

Serverless trades infrastructure ownership for platform constraints: execution time limits, cold starts, and a programming model that fights some workloads. Containers give you control and portability at the price of running the platform — clusters, scaling policies, patching. Pick the constraint set your team can live with.

Choose the option whose failure modes you'd rather debug at 2am — that tells you more than any benchmark.

Keep the seams clean either way

The most expensive mistake isn't picking the 'wrong' one — it's coupling your business logic so tightly to the runtime that switching later means a rewrite. Keep your domain logic in plain, portable code and treat the runtime as a thin adapter. Then the decision stays reversible, which is the most pragmatic property an architecture can have.