Serverless Architecture
An architectural paradigm where applications run on managed cloud services and event-driven functions without managing server infrastructure.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Unexpected costs from faulty scaling or hot loops.
- Difficulties in distributed tracing and debugging.
- Security risks from misconfigured managed services.
- Keep functions small and single-responsibility.
- Implement idempotency and clear retry strategies.
- Instrument cost metrics and set budget limits.
I/O & resources
- Defined event sources and triggers
- Minimal function code with clear interface contracts
- Managed services for persistence, auth and messaging
- Scalable functions as deployable artifacts
- Metrics for latency, cost and errors
- Integrated observability and alerting pipelines
Description
Serverless architecture is a cloud-native paradigm where applications run on fully managed services and event-driven functions without managing server infrastructure. It reduces operational overhead and enables elastic scaling, but introduces design trade-offs around cold starts, dependency management, cost model and potential vendor lock-in. Compared to traditional architectures, billing and observability approaches change and new operational patterns are required.
✔Benefits
- Reduced operational overhead via managed services.
- Automatic, fine-grained scaling on demand.
- Pay-per-use cost model for irregular workloads.
✖Limitations
- Cold-start latencies for infrequently used functions.
- Limited execution time or resources per invocation.
- Vendor lock-in due to proprietary services and APIs.
Trade-offs
Metrics
- Cold-start latency
Time between function invocation and fully operational execution.
- Cost per request
Average billing cost per function invocation or API call.
- Error rate / retries
Share of failed executions and number of automatic retries.
Examples & implementations
Web API with AWS Lambda
API endpoints served by Lambda functions; API Gateway handles authentication and rate limiting.
Image processing pipeline in functions
Upload triggers a function that transforms images and stores them in object storage; processing scales with input rate.
Scheduled report generation
Scheduled Lambda functions generate reports and deliver results to storage or notification systems.
Implementation steps
Conduct architecture workshop and select use cases.
Implement a proof-of-concept for a critical path.
Integrate observability, cost alerts and security policies.
⚠️ Technical debt & bottlenecks
Technical debt
- Hidden dependencies on provider-specific services.
- Insufficient test coverage for asynchronous processes.
- Monoliths that become hard to split into functions later.
Known bottlenecks
Misuse examples
- Migration without redesign: lift-and-shift of monolithic services into individual functions.
- High-frequency low-latency applications that suffer from cold starts.
- Uncontrolled cost-intensive events resulting from misconfiguration.
Typical traps
- Underestimating total operating costs despite pay-per-use.
- Missing end-to-end traces across multiple managed services.
- Untested provider failure scenarios.
Required skills
Architectural drivers
Constraints
- • Maximum execution time per function (provider limit)
- • Limited native resources (CPU/memory)
- • Network latency to managed services