Serverless is sold as the simplest path to production. No servers to manage. Pay only for what you use. Scale automatically. What could go wrong? Quite a lot, actually. Here are seven pitfalls we've seen trip up DACH enterprises—often after serverless is already in production.
1. Cold Start Latency Surprises
Your function works perfectly in testing. Then a real user waits 3-5 seconds for a response because the function hadn't run recently. Cold starts are serverless's dirty secret.
The issue compounds with VPC-attached functions (common for database access), larger deployment packages, and languages like Java or .NET. One financial services client saw cold starts exceeding 10 seconds for their Java functions.
Mitigation strategies:
- Provisioned concurrency: Pay to keep functions warm (defeats pay-per-use benefit)
- Smaller packages: Strip dependencies ruthlessly
- Language choice: Python and Node.js start faster than Java
- Architecture redesign: Keep latency-sensitive paths off cold-startable functions
If sub-second response time matters to your users, cold starts will eventually matter to your architecture.
2. The Observability Black Hole
Traditional monitoring assumes long-running processes. Serverless functions are ephemeral—they exist only during execution. Your existing monitoring tools probably don't work.
Distributed tracing becomes essential but harder. A single user request might trigger dozens of function invocations across multiple services. Correlating logs and understanding latency requires purpose-built tooling.
What you need:
- Structured logging: JSON logs with correlation IDs from the start
- Distributed tracing: X-Ray, Jaeger, or similar—baked in, not bolted on
- Metrics aggregation: CloudWatch isn't enough for complex applications
- Cost correlation: Tie invocations to business transactions
3. Timeout Cascades
Function A calls Function B, which calls Function C. Function C is slow. Function B times out waiting for C. Function A times out waiting for B. The user sees an error—but which function failed? And did any of them complete partial work?
Timeout management in serverless chains is genuinely difficult. Each function has its own timeout, and they don't coordinate. Retry logic compounds the problem—you might retry a function that actually succeeded but responded too slowly.
Design principles:
- Async where possible: Don't chain synchronous function calls
- Timeout budgets: Outer function timeouts must exceed inner function timeouts plus overhead
- Idempotency: Every function must handle being called twice safely
- Circuit breakers: Fail fast rather than cascade timeouts
4. The Vendor Lock-in Trap
AWS Lambda isn't Azure Functions isn't Google Cloud Functions. Each has proprietary triggers, event formats, runtime behaviors, and deployment models. Your "portable" code isn't.
Even within a provider, serverless services create tight coupling. Lambda + API Gateway + DynamoDB + Step Functions forms an ecosystem that's practically impossible to migrate. You're not just using services—you're adopting an architecture that exists only on one platform.
Realistic approaches:
- Accept the lock-in: Sometimes the benefits outweigh portability concerns
- Abstract the boundaries: Keep business logic separate from trigger handling
- Kubernetes alternatives: Knative or OpenFaaS offer more portability (with more complexity)
- Multi-cloud strategy: Keep some workloads on containers for flexibility
5. Cost Model Inversions
Serverless is cheap at low scale and expensive at high scale. The pricing model that made your prototype affordable can make your production system unsustainable.
We've seen workloads where serverless cost 3-4x more than equivalent container deployments at scale. The break-even point varies, but high-throughput, steady-state workloads almost always favor containers or VMs.
Cost danger zones:
- High-frequency invocations: Millions of daily invocations add up fast
- Long-running functions: You pay per millisecond—inefficient code is expensive
- Data transfer: Moving data between services incurs egress charges
- Provisioned concurrency: The warm function tax can exceed container costs
6. State Management Complexity
Functions are stateless. Your application probably isn't. Where does state live? How do functions coordinate? These questions lead to architectural complexity that doesn't appear in serverless tutorials.
Common state stores—DynamoDB, Redis, databases—each add latency, cost, and failure modes. State management patterns that work in monoliths or microservices don't translate directly to serverless.
State strategies:
- External state stores: Accept the latency and cost of DynamoDB, Redis, etc.
- Step Functions: Use orchestration services for workflow state
- Event sourcing: Store events, derive state when needed
- Stateful containers: Keep stateful components off serverless
7. Testing Reality Gaps
Local testing environments for serverless are approximations at best. SAM Local, serverless-offline, and similar tools simulate—they don't replicate. Production behavior differs.
Integration testing requires deploying to actual cloud environments, which is slow and expensive. The feedback loop that makes development productive with containers or VMs is much longer with serverless.
Testing approaches:
- Unit test heavily: Test business logic without cloud dependencies
- Contract testing: Verify interfaces between functions
- Ephemeral environments: Deploy to real cloud for integration tests, tear down after
- Production testing: Canary deployments with real traffic
When Serverless Makes Sense (And When It Doesn't)
Serverless excels for event-driven, unpredictable workloads with variable demand. It struggles with latency-sensitive, high-throughput, stateful applications.
The best serverless architectures combine serverless functions for appropriate workloads with containers or managed services where serverless doesn't fit. Dogmatic "serverless everything" approaches usually fail.
Evaluating serverless for your workloads? Our team has designed and operated serverless architectures for DACH enterprises. We can help you identify where serverless adds value—and where it creates problems you don't need.