Rocambys
Serverless
AWS Lambda
Architecture
Cloud

Serverless Architecture: When to Use It and When to Avoid It

Rocambys Team20 March 20263 min read
Serverless Architecture: When to Use It and When to Avoid It

The Serverless Promise

Serverless computing — AWS Lambda, Azure Functions, Google Cloud Functions — eliminates server management entirely. You write functions, deploy them, and pay only for execution time. No patching, no scaling decisions, no idle costs. For the right workloads, it is transformative.

When Serverless Excels

  • Event-driven workloads — Processing uploads, reacting to database changes, handling webhooks. Serverless is purpose-built for this.
  • APIs with variable traffic — REST/GraphQL APIs that see spiky traffic patterns. Lambda + API Gateway scales from 0 to millions of requests seamlessly.
  • Data processing pipelines — ETL jobs, image resizing, PDF generation, email processing. Short-lived, stateless tasks.
  • Scheduled tasks — Cron-like jobs that run periodically. No need to keep a server running 24/7 for a task that executes for 30 seconds daily.
  • Prototyping and MVPs — Get to market faster by eliminating infrastructure decisions early.

When Serverless Falls Short

  • Long-running processes — Lambda has a 15-minute execution limit. Batch processing jobs that run for hours need containers or EC2.
  • Low-latency requirements — Cold starts add 100ms-2s of latency. For real-time applications (gaming, trading), this is unacceptable.
  • Stateful workloads — WebSocket connections, in-memory caches, and session state do not fit the stateless serverless model.
  • High-throughput constant workloads — If your workload runs at consistent high volume 24/7, containers on Fargate or EC2 are more cost-effective than Lambda.
  • Complex debugging scenarios — Distributed traces across dozens of Lambda functions are harder to debug than a monolithic application.

The Decision Framework

Ask these questions about each workload:

  1. Is the workload event-driven or request-based? → Serverless candidate.
  2. Does it complete within 15 minutes? → Serverless viable.
  3. Is traffic highly variable (10x+ between peak and off-peak)? → Serverless cost-effective.
  4. Does it require persistent connections or local state? → Use containers instead.
  5. Is sub-50ms latency required? → Use containers with pre-warmed instances.

Hybrid Architectures

Most modern applications use serverless for some components and containers for others. A typical pattern:

  • API Gateway + Lambda for CRUD APIs.
  • ECS/EKS for real-time processing and WebSocket services.
  • Lambda for event processing (S3 triggers, SQS consumers, scheduled tasks).
  • Step Functions for orchestrating multi-step workflows.

Conclusion

Serverless is a powerful tool, not a universal solution. The most effective architectures use serverless where it excels and containers where it does not. Let the workload characteristics — not industry hype — drive your architectural decisions.