Nov 1, 2017
The Serverless Spectrum
Like so many things in life, serverless is a spectrum with multiple dimensions along which the degree of each can vary
I’ve resisted writing this article for a long time — because everybody and their mother has a think piece about “what is serverless?” Despite the volume of content and best efforts from the community, the confusion continues.
So what finally pushed me over the edge? The primary catalyst for this blog is a response to recent discussions about the role of containers in serverless.
Why serverless?
We all agree “serverless” is a horrible term. Maybe the term “Jeff” would have been better, but it’s not without its downsides.
Instead of spending energy on a meme or particular technological aspects, I think it’s important to focus first on what people who go serverless are aiming to achieve.
- Lower operations burden. This is the fundamental benefit, and it has many facets. Fewer people, leaner teams, lower costs, better security, better resilience…this is all about division of labor.
- Faster time to market. With less to build, feature velocity increases. It’s hard to underscore enough the value that this brings.
- Focus on business value. At its core, what we’re talking about is outsourcing parts of our architecture and implementation that are not core to delivering business value. It’s about embracing division of labor and inverting the dreaded “Not Invented Here Syndrome” — preferring to buy rather than build whenever feasible. It’s possible to use this approach even while using servers — something Joe Emison has written about.
What serverless is NOT
It’s unfortunate that serverless is now the subject of marketing campaigns. Companies are now looking for ways to brand their offerings as serverless — providing an opportunity for the community to weigh-in on their pitch.
#1. Serverless is not FaaS
Many people are speaking about Functions as a Service (FaaS) as if that was the be-all and end-all of serverless. And while FaaS is an integral component of serverless architecture, it’s just the part of a serverless system where your custom code lives.
The more software you put in FaaS that is unrelated to your business logic, the less serverless you’ll be — you’re just building little servers in your functions.
#2. Serverless is not event-driven compute
There are a number of people who have said “serverless is all about the events”, but I think this is misleading. Event-driven computing is a natural fit for serverless architectures, and it dovetails with the idea of pay-per-use. But it’s completely possible and reasonable to build traditional data flows in serverless systems.
#3. FaaS is not always F — containers can be FaaS
Recently, there have been discussions about what kind of contract is “best” between a developer and the platform they are deploying on. The most common model is deploying a function in the form of code to a platform-provided runtime. There is a strong contract between the platform and the developer, but it is highly coupled.
Other people like containers, because the contract is strong but it also highly decouples the developer from the platform. This can still be FaaS! If the container is run only during invocations and is frozen and/or recycled in between — the container is acting as a function just like in a code deployment model. And these two models are not mutually exclusive.
I am a big fan of the “batteries included but swappable” model, and here that looks like platform-provided runtimes to deploy function code onto — with an option to bring your own container for the mature users that have specific needs.
So that’s the F, what about the aaS? That brings me to my next point…
#4. FaaS is not always aaS — and serverless is not just public cloud
On-prem serverless is not an oxymoron. It’s a question of perspective. If you have a large enough organization, the difference for a developer to be using FaaS provided by a third party versus some opaque department elsewhere in the company is probably relatively small.
So the department providing the FaaS application is not using serverless techniques, but it is enabling the rest of the organization to do just that. There’s no “serverless FaaS” and “non-serverless FaaS”. There’s just how serverless is the organization a whole when it’s using FaaS.
Serverless is a spectrum
Like so many things in life, serverless is not an all-or-nothing proposition. It’s a spectrum — and more than that, it has multiple dimensions along which the degree of serverlessness can vary.
For a service to be “more serverless”, it needs to move in one or more of the following directions:
- Service-full + ephemeral compute
- Tighter correspondence between resources used and resources billed
- Smaller and more abstracted control plane
Service-full + ephemeral compute
The term service-full was coined by Patrick Debois, and is a much better and more accurate term than serverless. As a application becomes increasingly serverless, it relies more on external services to provide the building blocks of the system. For example, DynamoDB instead of a Cassandra cluster, and Kinesis instead of Kafka.
Along with service-full is a move towards ephemeral compute. This is a continuation of the ideas in 12 factor apps and immutable infrastructure, that the compute in a system should not be required to be continually-living, custom-tended infrastructure.
We are now extending the notion so that the compute infrastructure should not even exist when it is not handling data. A persistent computing resource is a server no matter what form that resource takes.
Along with this idea comes that the overhead for scaling needs to be low. If the compute infrastructure doesn’t exist when not handling data, it better pop into existence as fast as possible when data is available.
Building a serverless application is like bricklaying: your bricks are SaaS components, and FaaS is the mortar that binds them together.
If we apply the service-full approach to FaaS, we can note that there is a spectrum here, too, involving FaaS applications like kubeless or OpenFaaS that one deploys oneself:
- FaaS application on cluster using on-prem servers
- FaaS application on cluster using public cloud IaaS
- FaaS application on managed cluster (e.g., Google Container Engine)
- Managed FaaS
Again, all of these options are at some point on the serverless spectrum.
Correspondence between resources used and resources billed
A big factor in the attractiveness of serverless is the billing model. It pushes the pay-per-use pricing model further towards paying for exactly what you consume.
The billing moves towards being shrink-wrapped for resources used, rather than resources provisioned. This currently comes largely in terms of time of execution, as computational, memory, and network resources still tend to have fixed provisioning.
The spectrum for this dimension tends to be how these billing models come about. Per-request invocation enables billing only when used. This leads us down the path towards event-driven architectures, which more naturally fit per-request invocations.
I don’t think that “pay nothing at idle (except for data at rest)” is a bar that needs to be cleared before a system can be considered on the serverless spectrum.
For example, AWS Batch is a service that lets to dispatch containers onto an ECS cluster — where the containers define their resource requirements and AWS will manage what kind and how many instances to use for the cluster. These containers control their own lifecycle, and so if they are finite jobs, it’s a fairly serverless-ish system. On the other hand, you can totally have a Batch job that runs a server and never quits — that is not serverless.
Smaller and more abstracted control plane
The final dimension of serverless is a shrinking and more abstract control plane. The more serverless a system is, the fewer knobs need to be tweaked to keep it running well. The knobs that are available on a serverless system are more about what is required (e.g., throughput) than what is provided (e.g., number of shards).
Note that this is about the controls that need to be adjusted to maintain performance of the system. Once again, it’s a batteries-swappable-but-included scenario, where advanced controls may be provided (for example, through the provider’s support team) but are not normally used. Finally, the outputs of the control plane need not be reduced; we still want good visibility into the platform.
Summing up the serverless spectrum
We’ve acknowledged that serverless is a terrible term, and are moving on with our lives. Serverless is, at a functional level, about lower operations burden and faster time to market. Serverless is not FaaS — and FaaS can be a lot of things, but is always some degree of serverless.
Serverless is a spectrum, with serverlessness increasing as the following properties advance:
- Service-full + ephemeral compute
- Tighter correspondence between resources used and resources billed
- Smaller and more abstracted control plane
AWS defines serverless for themselves as “run in response to events, never pay for idle, and fully managed”. While this is simpler and roughly corresponds to my three tenets, I don’t think their framing adequately conveys the shades of gray involved in the concepts.
I’m sure many people out there disagree with me. I’d be interested in hearing your thoughts below, or tweet me some respectful commentary.
