Serverless isn’t the Evolution of Compute

I’ve been banging on for ages about how Serverless is the evolution of compute, and after a Twitter conversation with Adam Jacob and xnoɹǝʃ uɐıɹq about how Serverless is the future of software design, following a Kelsey Hightower tweet, I’ve realised I’m completely wrong.

Serverless, and more specifically, Functions as a Service (FaaS), is an evolution of how we consume compute, not the underlying compute itself. For the majority of users, the evolution of the method of consumption is indistinguishable from the evolution of the underlying resource. From a developer or user perspective, there is always an abstraction of some sort between the application and the underlying physical resources, even if it is just a very thin operating system.

So when we see that abstraction and our method of consuming that underlying resource, it’s easy to think that the evolution of that abstraction is the evolution of the underlying resource.

The two are linked. The evolution of the underlying compute resources drives the evolution of the abstractions on top that, which in turn define how we consume the resource.

Companies like Intel, AMD, ARM and NVIDIA evolve compute, they create faster device busses and make more efficient processors. Moore’s Law has been a great way to represent this evolution for many years. These evolutionary steps drive evolution of the abstractions above. Virtualisation is possible because the overhead of a hypervisor is negligible due to advances in performance in CPU, memory and device busses. This same pattern is true with every abstraction. The latency introduced by the abstraction is made negligible by advances in performance of the underlying compute.

Virtualisation also made it easier to manage compute resources through the abstraction of the hypervisor, as it provided better isolation, and encapsulation of an operating system. Containers then took this to the next step by providing isolation and encapsulation of an application on top of an operating system. FaaS platforms do the same thing, leveraging containers for encapsulation and isolation, but allowing functions within an application to be decomposed through the introduction of a low latency message bus.

With the continual evolution of consumption through abstraction we can see that the form factor in which we consume compute and the corresponding unit of deployment of applications that consume that compute have reduced. Correlating to this, is the reduced time to provision and reduced lifespan. Less to provision, so it takes less time. Less to decommission and the lifespan reduces.

The latter stages of the evolution of consumption has seen the distribution of the compute move to the ‘as a service’ paradigm. Initially localised to a single zone, but later stretched across a cloud provider region comprising multiple data centers.

Another important aspect about the evolution of consumption of compute, is how the interface of that compute has changed. We’ve moved from punchcards, through terminals with keyboards and mouse, direct console access, to remote console access with via SSH or RDP protocols. With the introduction of FaaS as the latest step in this evolution, compute resources are now exclusively accessed via an HTTPS interface.

This mimics the evolution of consumption of storage that has seen object based storage come to the fore, with access through an HTTPS interface.

In the Linux world everything is file, in the Serverless world everything is an HTTPS interface.

This normalises access to the resources required by an application to a single secure protocol. Those resources have also become distributed within a cloud region, or across multiple clouds or services.

This shift to put all resources behind an HTTPS interface and make them inherently distributed changes the way applications are written.

There is no filesystem you can just read and write from, it’s an HTTPS call to an object store. There is no global memory space across clouds that functions can magically access, you need to pass state between functions via an event bus or read/write state to a service behind an HTTPS interface.

Importantly, in the same way that the evolution of underlying physical components negated the overhead of previous abstractions, that restricted adoption, so will the evolution of physical components do the same with FaaS platforms.

In conjunction with all these changes in how we consume resources there has been a shift in how we write software. The rise of microservices, the 12 factor app and cloud native applications have been driving the trend to build our applications in smaller parts that can scale and fail independently of each other.

The reality is that FaaS platforms are not changing the way applications are written, they are simply platforms that are more suited to the way applications will be written.