Coding for a serverless future

Looking down the road at zero-infrastructure development

I consider myself really lucky that for all the progress we’ve made in the last few decades, we’re still in the nascent stages of our industry. There’s no other line of work I know of where the landscape changes so rapidly, and so dramatically, as in technology.

We’ve seen shifts like these throughout our young history. We moved from connecting to mainframes to networking our own servers; from our own servers to renting them from dedicated facilities with exceptional connectivity. From there we virtualised our hardware away to share resources and save on costs, and then on to the amorphous cloud — where we could acquire and release these shared resources ephemerally.

These shifts have not taken long. We move so quickly, and with so much at stake, that we strive to optimise away anything that distracts our focus.

Consider that each of these innovations is a revision of its’ predecessor. A sequence of culling our distractions and excising repetition that has brought us to the notion that we could mostly get by without considering our infrastructure at all.

What does that look like now? What will it look like next year (and how far ahead can we predict that)?

Just tell me what you want me to do

Serverless is a concept built on FaaS (functions-as-a-service). The core tenet of this architecture is that the responsibility for the infrastructure that runs your logic should rest with the service provider entirely.

This is a step beyond deploying applications to a cloud provider, where you tell the provider what you think you need, and they provide what’s requested and bill you in return.

In a serverless scenario, you tell the provider what you need to run (e.g. your code), and let them decide what hardware they need to use to get the work done. Rather than being billed for a machine (that may sit idle for much of the time), you pay per event (i.e. a total amount based on just the resources used in running your code). The rest is the responsibility of the provider to get right.

Oh yeah, I know this! It’s… [something we’ve had for years].

At first glance, this does seem like an idea that’s been around for quite some time in various guises — and in many ways it has. The notion of paying per event for infrastructure costs is not new.

The difference between what we now consider to be serverless development and (for example) a platform like Google AppEngine is that the latter is specifically targeted to building a public web application; events there are public web requests, and when producing a response you are given access to a handful of other related Google services to build an application around.

In serverless scenarios, the target workload shifts to effectively any action that has a known input, action and output ahead of time (these can be thought of as event triggers in the cloud). Yes, these can be public web requests, but they can as easily be a trigger from a database event source, a queue system or a scheduled job, among many others.

It’s this wide scope of use cases that I believe makes serverless significant, as it has the potential to bring a critical mass of developer workloads to a point where the time and effort spent on managing the physical infrastructure behind our code could be negated entirely.