Skip to main content

Lesson 7: When NOT to Use Serverless

Understanding Serverless Trade-offs and Limitations​

Serverless is powerful, but not universal. Avoid it when:

  • You need consistently low latency and warm state
  • Workloads run continuously with predictable load
  • Execution exceeds platform time limits
  • You require specialized hardware or custom runtimes

Simple Explanation​

What it is​

This lesson highlights the situations where serverless is a poor fit so you can choose a better model upfront.

Why we need it​

Serverless is powerful, but forcing every workload into it can create slow performance or unexpected costs. Knowing the limits saves real money and time.

Benefits​

  • Avoids bad architecture before you build too much.
  • Helps budget planning by steering always-on workloads elsewhere.

Tradeoffs​

  • More operations work when you choose containers or VMs instead.
  • Less convenience because you manage scaling and patching yourself.

Real-world examples (architecture only)​

  • Always-on video processing → Containers.
  • Sub-10ms API latency → Dedicated servers.
  • Long-running batch jobs → Managed batch or data pipelines.

Key Topics (Outline)​

  • Always-on workloads and cost analysis
  • Sub-100ms latency requirements
  • Long-running jobs (> 15 minutes)
  • Stateful protocols (WebSockets, persistent connections)
  • High-bandwidth workloads
  • GPU/ML training workloads
  • Complex networking requirements
  • Licensing and vendor lock-in concerns
  • Operational maturity and debugging complexity

Project (Cloud-Agnostic)​

Describe a workload that should NOT use serverless and propose a better alternative.

Deliverables:

  1. Describe the workload and its constraints.
  2. Explain why serverless is a poor fit.
  3. Propose a better architecture and map it to AWS or GCP services.

If you want feedback, email your write-up to [email protected].

References​