Serverless Continuous Deployment on AWS Lambda: Key Concepts and Trade-offs

This article is based on a workshop session delivered by Mike Roberts, co-founder of Symphonia Cloud, at the Continuous Lifecycle conference in London. The original report was published by The Register.

Why Serverless? The Cloud Evolution Argument

Mike Roberts opened his Continuous Lifecycle workshop with a straightforward justification for cloud computing. Before cloud adoption became mainstream, provisioning a new server in a large financial institution could take nine months — working through procurement, compliance, and infrastructure queues. Today, equivalent compute is available in minutes.

Serverless, Roberts argued, is simply the next step in that evolution — the layer that comes after Platform-as-a-Service (PaaS) and Containers-as-a-Service (CaaS). Organisations move to the cloud primarily for two reasons: cost reduction and faster delivery. Cloud providers offer economies of scale in both operations staffing and raw infrastructure cost that most organisations cannot replicate internally.

What “Serverless” Actually Means

Serverless is an umbrella term that covers two distinct categories of technology:

1. Backend-as-a-Service (BaaS)

BaaS refers to fully managed third-party services that replace components you would otherwise build and operate yourself — things like source control hosting (GitHub), CI pipelines (Travis CI), or CRM platforms (Salesforce). You consume them via API; you do not manage the underlying infrastructure.

2. Functions-as-a-Service (FaaS)

FaaS is what most engineers mean when they talk about serverless compute. Rather than deploying a long-running application process that exposes a set of linked functions, you deploy individual functions that are invoked in response to discrete events. Those events can arrive from several sources:

• HTTP requests (API Gateway)
• Message bus events (e.g., SNS, SQS, Kinesis)
• Storage events (e.g., S3 object creation)
• Time-based triggers (scheduled events)

AWS Lambda, launched in 2014, is the dominant FaaS platform. Comparable offerings exist in Azure Functions and Google Cloud Functions, along with open-source alternatives. Roberts characterised AWS as the “eight-hundred pound gorilla” of cloud infrastructure — a view shared by conference attendees.

Five Defining Characteristics of Serverless Applications

Roberts identified five properties that distinguish a genuinely serverless application from one that merely runs on managed infrastructure:

1. No management of server hosts or server processes. The platform handles OS patching, runtime upgrades, and process supervision entirely.
2. Automatic scaling and provisioning based on load. Capacity adjusts in response to incoming event volume without manual intervention or pre-configured autoscaling rules.
3. Cost based on precise usage. You pay per invocation and per duration of execution, not for idle compute.
4. Performance defined in terms other than host size and count. You configure memory allocation (and, indirectly, CPU) per function rather than selecting instance types and cluster sizes.
5. Implicit high availability. Redundancy and fault tolerance are built into the platform; you do not architect it separately.

Deployment Speed: A Genuine Advantage

One of Roberts’s most striking claims was around development velocity. He argued that serverless applications can be built dramatically faster than equivalent applications on traditional infrastructure. A project that might take three months coordinated across multiple teams — accounting for infrastructure provisioning, environment parity, and deployment pipeline setup — he has seen completed in a week.

He cited comments made by AWS VP Adrian Cockcroft (reportedly in 2017) noting that production Lambda applications were being built and deployed in a single day. The leverage comes from not having to manage or reason about underlying platform components. As Roberts put it: “We don’t have to think about whether our Kafka instance can take the load. It actually changes how we can build products entirely.”

Cost efficiency compounds the velocity argument: Lambda functions only consume billable resources during execution, making them well-suited to workloads with irregular or spiky traffic patterns.

Where Serverless Struggles: Real Limitations

Roberts was direct about the trade-offs. “Serverless is not a land of rainbows and unicorns,” he said. Several workload profiles are poorly served by the model:

• Low-latency, synchronous operations — cold starts introduce non-deterministic latency that is unacceptable in some real-time contexts.
• Large-scale stateful operations — FaaS functions are stateless by design; managing state externally adds complexity and latency.
• Long-running, stateful operations — execution time limits (Lambda’s maximum execution duration, for example) make serverless unsuitable for jobs that need to run continuously or hold state in memory for extended periods.

Beyond workload fit, tooling maturity is a genuine concern. At the time of the workshop, Roberts highlighted two specific gaps:

• Deployment tooling — the ecosystem for packaging, versioning, and deploying Lambda functions was still maturing.
• Distributed monitoring and tracing — observing behaviour across many independently invoked functions is significantly harder than tracing requests through a monolithic service. Tools for correlating logs and traces across microservices were limited.

Additionally, state-based architectural patterns cannot be applied directly. Any state must be externalised to a managed store (DynamoDB, ElastiCache, S3, etc.), which requires rethinking application design from the ground up.

Practical Takeaways for DevOps Teams Evaluating Serverless

For teams considering a move to serverless continuous deployment on AWS Lambda, the core questions to answer before committing are:

1. Does your workload fit the execution model? Event-driven, short-lived, stateless functions benefit most. Long-running or highly stateful processes do not.
2. Can you accept variable latency? Cold starts are a known Lambda characteristic. Provisioned Concurrency (introduced after this workshop) mitigates but does not eliminate the issue.
3. Do you have observability tooling in place? Distributed tracing (AWS X-Ray, or third-party APM tools) is non-negotiable at scale. Plan for it before go-live, not after.
4. Have you modelled the cost curve? Pay-per-invocation is cost-efficient at low-to-moderate volume. Very high-frequency, long-duration functions can become more expensive than equivalent always-on compute.
5. Is your team ready to design for statelessness? Architectural patterns that rely on in-process state or sticky sessions require significant redesign.

Serverless continuous deployment reduces operational overhead and can dramatically accelerate delivery for the right workloads. The trade-off is accepting a more constrained execution model and investing in observability and deployment tooling that the serverless ecosystem was still building out at the time of this workshop — and continues to evolve today.