Serverless: FaaS Is Just the Beginning
Discover how far serverless can go: Functions-as-a-Service is just the beginning. We reveal the next step in cloud architecture.
Key Takeaways
- Serverless goes beyond Lambda/Functions: databases, queues, storage, ML inference – all available as serverless
- Pay-per-Execution saves 60-80 percent for sporadic workloads but can be more expensive than compute instances for continuous loads
- Cold starts remain a problem for latency-critical applications – provisioned concurrency as a workaround
- Vendor lock-in through proprietary event models (EventBridge, Cloud Events) – portability requires abstraction layers
- Serverless-first as an architectural principle: only deploy on compute what can’t be done serverless
Serverless has found its place – but differently than expected. AWS Lambda, Azure Functions, and Google Cloud Functions were the starting point. By 2026, serverless will be an architectural principle, not just a single service: serverless databases, serverless containers, serverless ML inference. The question is no longer whether to use serverless, but how much.
Beyond Functions: The Serverless Ecosystem in 2026
The first wave of serverless (2015-2020) focused on functions: small code fragments, event-triggered, pay-per-invocation. The 2026 ecosystem is dramatically broader: DynamoDB and Aurora Serverless (databases), SQS and EventBridge (messaging), S3 and EFS (storage), SageMaker Serverless Inference (ML) – all without capacity planning.
The paradigm shift: Instead of asking, “Which server do I need?”, the question becomes, “Which service does the cloud offer for my use case?” Increasingly, the answer is one where you don’t worry about infrastructure.
When Serverless is Cheaper – and When It’s Not
The cost math is clear for sporadic workloads: A Lambda function running 10,000 times a day for 200ms each costs less than 1 EUR/month. A small EC2 server for the same workload: 30-50 EUR/month. Savings: 97 percent.
For continuous loads, the equation reverses: A Lambda function running 24/7 with high concurrency becomes more expensive than a dedicated EC2 instance. The break-even analysis depends on invocation frequency, execution duration, and memory requirements. Rule of thumb: Below 50 percent utilization, serverless is cheaper.
Cold Starts: The Persistent Problem
When a serverless function is invoked for the first time after inactivity, the runtime environment must be initialized – this is the cold start. Python/Node.js: 100-500ms. Java/.NET: 1-5 seconds. For APIs with latency requirements under 200ms, this is problematic.
Solutions: Provisioned Concurrency (AWS) keeps functions warm – eliminating cold starts but also the cost advantage. SnapStart (Java) and Tiered Compilation reduce initialization time. The trend: Runtimes are getting faster, cold starts are getting shorter – but not eliminated.
Serverless-First as an Architectural Principle
Forward-thinking architects start with the question: “Can this be done serverless?” Only what cannot be realized serverless (long-running processes, GPU workloads, special network requirements) is deployed on compute instances or Kubernetes.
This principle maximizes the portion of infrastructure that is fully managed. Less operational effort, automatic scaling, pay-per-use – the operational advantages usually outweigh the limitations. The architecture must adapt (event-driven, stateless, idempotent), but these are best practices for scalable systems anyway.
Frequently Asked Questions
Is serverless only suitable for small workloads?
No. Netflix, Coca-Cola, and LEGO run massive serverless architectures. Serverless is designed to scale to millions of concurrent executions. The limitation isn’t scaling—it’s architecture: stateless, event-driven, and short-lived processes.
How do I handle state in serverless?
State must be externalized: DynamoDB or Redis for session state, S3 for files, Step Functions for workflow state. This requires architectural discipline—but enforces best practices that are also valuable in non-serverless systems.
What about vendor lock-in?
It’s real, but manageable. Event models and trigger configurations are proprietary. However, the function logic itself (Python, Node.js, Go) remains portable. Frameworks like Serverless Framework and SST partially abstract provider-specific details.
Can I migrate existing applications to serverless?
Monoliths: difficult to impossible without re-architecting. Microservices: yes, incrementally. Recommendation: build new features serverless, gradually migrate existing services. Use the Strangler Fig pattern as a migration strategy.
What are serverless containers (Fargate, Cloud Run)?
Containers that run without cluster management. They combine container flexibility (custom runtime, larger payloads) with the serverless operational model (no server management, pay-per-use). For many workloads, they represent the sweet spot between Lambda and Kubernetes.
Header image source: Pexels / Steve Johnson
Translated from the German original using artificial intelligence. The German version is authoritative.
Editor's Picks
cloudmagazinLenovo ThinkCentre M75q Tiny Gen 5: Enterprise mini PC with AMD PRO and 5-watt idle power for edge and kiosk usecloudmagazinServerless AI is overhyped—here’s what actually matters insteadcloudmagazinQNAP TS-464: 4-bay NAS with Docker, HDMI, and PCIe slot—features Synology doesn’t offer in this class
