Ever since the rise of the AWS Lambda, software engineers have been fascinated by the premise of “just writing code” and not having to worry about the execution or scaling of said code. Since then, the term “serverless” has been coined to describe the new class of solutions. We now have similar implementations from other major providers (Azure functions, Google Cloud Functions, IBM Cloud Functions etc.) as well as an impressive list of open-source solutions (Nuclio, OpenWhisk etc.) all happily referred to as “serverless”.

There is one big problem with all of this, however - the name “serverless” is a big, silly joke. Everybody admits it. Of course there is no such thing as “serverless” and at the end of the day there is somebody who is running the abstraction layer to get you to ‘serverless’. When that ‘somebody’ is a major cloud provider like AWS, Google, Azure or IBM the name is at least marginaly tollerable (ok, you dont have to care about servers), but as soon as we talk about frameworks like Nuclio, OpenWhisk etc. that supposedly you yourself would be running (possibly on a Kubernetes cluster) - the name “serverless” is plain bizarre. Not only you do have to administer your Kubernetes cluster, you also have to administer additional layer on top of it. So what is “serverless”?

Sometimes people use the term “FaaS” (Function-as-a-Service), instead of “serverless”, and it is not a bad name. FaaS pays omage to its predecessor Platform-as-a-Service (PaaS) and acknowledges that a preffered unit of deployment is now a function. However, FaaS is arguably just not “cool enough” and hasn’t taken off too much. So how do we end the silliness behind the term “serverless”?

Here’s an idea, what if we call it Functional, Invocable Runtime Environment or simply: FIRE.

Next time you describe what you have been doing, over the weekend, maybe skip the “serverless” thing and just say “I’ve been playing with FIRE”?

Future generations will thank you.