Alex Hudson

Thoughts on Technology, Product, & Strategy

A FaaS by any other name would smell as sweet

This evening’s RedMonk article on linguistic prescriptivism is, as usual, excellent reading. Does it matter what people call things? Is the intent behind the name something significant, which should be respected?

In computer science we “have form” on this subject. The names or symbols we assign to things are very clearly different from the values involved. We might write 2.0 or 1.999..., and these symbols are distinctively different from the concept of two-ness, and indeed in another language we might write a two using very different symbols, like(() ()). Often this logic gets carried forward into other areas – somewhere else on Twitter, a discussion about Serverless was happening.

This set of Tweets got me thinking:

Is this really what Serverless is all about? Is it worth trying to define this word tightly? Is anyone else going to care?

It’s clear already that different people mean different things by “Serverless”. To the extent that we argue what this means, we already fall into the trap that James has written about: is there really only a single specific concept here?

For what it’s worth, I disagree with Ben’s definition for one simple reason: if “serverless” is to have prima facie meaning, I shouldn’t care what a server is doing. If my container is sat there active, but this has no impact on me, then why is that not serverless? In fact, if I’ve uploaded something into Lambda and keep it warm with polling functions, am I automatically no longer serverless? I would argue obviously not.

But there are a bunch of things here that serverless could be, lots of different things people mean, and all of them have value. Off the top of my head:

  • where I’m paying by request rather than a flat rate
  • where my code can potentially hibernate when “not needed”
  • when I can ignore the server piece and just upload the code into something
  • when I don’t have to worry about how my code scales
  • where my code is event-driven from some external system
  • when my software is small and designed around functions / otherwise microservice-y

All of these definitions are deeply problematic. For example, I’ve been able to upload code into Salesforce without worrying about servers and scaling for a while now; generally I don’t pay (either by request or at an additional flat rate) to be able to do that – is that serverless?

Having software which could be “hibernated” at some point definitely feels like it should be part of the definition, and for that to work broadly it implies the ability to start up very quickly. But, that’s true of most dynamic languages.

I’ve said it before and probably will say it again: one of the reasons that people liked PHP, and the reason it got insanely popular, was because it was so super-simple. You didn’t worry about servers; you just got some hosting, uploaded your code, and that code was only executed per-request as needed. For the most part, people don’t pay per request in this model, but that seems to me to be a business model decision.

Is any of this a problem?

I absolutely agree with James that being broadly accepting in discussion is crucial for diversity. It’s clear when you consider the opposite; to be able to point at something and say “That’s not <X>!” is an exclusionary statement.

Sometimes, that’s ok. “Your on-premise SQL database is not serverless!” is a relatively uncontroversial statement: serverless should be a broad church, but I doubt anyone would be offended if that concept wasn’t included.

I worry that attempting to be prescriptive about this encourages tribalism. However; if someone asks me to explain “serverless”, what do I say? Give my view, with the caveat that few agree? Attempt to give all views? What do we say the defining benefit here actually is?

I tend to describe it a little bit like a cloud operating system; taking the developer even further away from the underlying hardware. The network is no longer really that relevant, we’re not sure where the storage actually is, we have many fewer guarantees about performance, but all of this is ok because it’s much simpler and more flexible.

However, besides platitudes about being able to build things more quickly, reducing complexity, decreasing maintenance – it’s difficult to pin-point specific benefits even with a specific definition.

Inevitably, no matter how we talk about it, someone will pop up with “But there are still servers!”. Fundamentally, the problem here is that arguing about semantics prevents discussion about the concepts themselves, and that is a bigger problem than lack of agreement about the labels to use about the concepts.

Maybe we need a new formulation of Postel’s Law:

Be liberal accepting the labels people use for concepts. Be specific and transparent in the the labels you apply.

Previous

Responses to “Software architecture is failing”

Next

The CTO’s guide to containers/serverless changes – re:Invent 2017

1 Comment

  1. Richard Stanford

    How about the point that “Serverless” is meaningless without more words?

    You can write “serverless code” if it can be deployed to something like Lambda and doesn’t rely on a persistent service to host it. You can have a “serverless deployment” if you are able to accept a request and respond to it in an isolated environment in a reasonable amount of time – if you’re magically respawning Jetty for each request in a microsecond that would still count.

Leave a Reply