Serverless isn’t about servers, it’s about apps

There’s a lot of confusion surrounding the concept of “serverless computing.” That could be because it’s quite erroneously named. It’s neither about servers or computing. At least not in the traditional sense of the word in which most IT professionals use it.

Serverless is much better referred to as Functions as a Service (FaaS) because that’s what it offers. In the same sense that FaaS is serverless, so is SaaS and, one might correctly conclude, PaaS. That’s because the server – the compute – is taken out of the equation from the perspective of its consumer, who is usually a developer. Compute (server, network) resources are hidden under the covers, automatically provisioned, managed, and scaled through a web of automation and orchestration ultimately governed by the provider of the service. You pay for it, but you never have to see it.

Serverless FaaS is not a replacement for SaaS, or for PaaS, or for cloud, in general. It is yet another option layered atop existing models that providers developers with the exciting ability to invoke functions on demand. It is event-driven, which means the function is triggered by an event. That event is often the invocation of an API call, which takes the form of an HTTP request with a very specific URI. Yes, an API call.

The most often cited use case for FaaS is image or video processing. This is because the resources required are often unpredictable, but in frequency and capacity. FaaS provides an affordable and efficient means to process said media on a per-call basis. Another example might be related to the IoT space, where actions are triggered by events that occur either through a controller app or from the thing itself. And there’s always the API backend use case, which often makes more sense to most folks than any other use case because APIs are often described as URIs invoking functions.  Regardless of what the function is doing, it executes only when triggered by a specific event, and is expected to be a single, isolated function.

This is not cloud as we are used to seeing or discussing it. That’s because cloud (IaaS) is about infrastructure and operations, while FaaS (and PaaS and SaaS) are about applications. They are intended as a development environment, in which developers are able to implement code to perform some tasks as part of a larger, application initiative. Can you build an app out of multiple FaaS implementations? Absolutely. Indeed in this respect, FaaS is to SaaS as microservices are to monoliths.

But that is exactly the point. FaaS is about applications, not servers. You can’t implement a cloud with FaaS, but you can develop an application. You can’t lift and shift an app into a “serverless” environment. It must be deconstructed and then rebuilt, nay, re-architected as a collection of FaaS.

The combinations (or are they permutations?) are extensive. One might incorporate FaaS along with PaaS from an app deployed in IaaS. The IaaS and PaaS might be on-premises, while the FaaS is public.

The thing is with SaaS, PaaS, and FaaS is that you never see the ‘servers’. That’s not true in IaaS, where we call servers “instances” and are required to manage and maintain them. That’s because IaaS – whether on-premises or public – is about delivery of infrastructure and operations, not applications. That’s always been true, but we’ve been able to ignore it for the past decade because “server == application” has been the norm for so long.

But with the rise of microservices and APIs, and now FaaS, we can no longer operate in a mode where “server == application” because it’s simply not true any more.

At the end of the day, FaaS isn’t about servers, or even really cloud (in the sense we’ve come to understand it). But it is a significant shift in how we might architect and build out applications.