In Defence of “Serverless” —the term
Serverless is not a good term, yet it is used to describe a powerful and often misunderstood concept.
Being a concept, “an abstract idea”, it is intrinsically nuanced. It’s a feeling, a quality, a spectrum — and overall a space of possible solutions. That space is bounded by the characteristics and qualities of the different “things” it contains. More and more serverless experts are becoming frustrated by using the term serverless for defining this complex space.
This article will address the shortcomings and strengths of the term “serverless” as well as presenting a defence of the benefits of challenging ourselves to change the way we think about building applications — moving further towards serverless architectures.
Some existing definitions:
Serverless allows you to build and run applications and services without thinking about servers — AWS
A Serverless solution is one that costs you nothing to run if nobody is using it. — Paul Johnston
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. — Mike Roberts
These are all masterfully concise and astute definitions, but they lack the practicality of detail, and this detail is the key to understanding the power of a serverless approach.
As a side note, one less elegant definition of mine from earlier in the year was comprised of a tweet chain, conveying the journey I’ve gone through forming a mental model of the space of serverless solutions.
Diving Deeper
From AWS Lambda’s release in 2014 it’s been common for people to use the terms FaaS (Function as a Service) and Serverless synonymously. FaaS is a term for Compute services that allow functions of code to be run in an isolated way. These functions run in response to events (e.g. HTTP calls) and though a system that abstracts the underlying complexity of the Server, it's OS and all the details or provisioning and scale.
FaaS is a key part of many serverless architectures, but you can have a serverless architecture without using FaaS, and a non-serverless architecture that makes use of FaaS. FaaS is very much a Serverless approach to Compute, but Compute (i.e. running code) is not the sole aspect of many application architectures.
There is a wide range of things an application architecture may need. e.g. Compute, Storage, Monitoring…
As mentioned above, FaaS functions are triggered by events, e.g. an HTTP call. The other serverless services in the image above can all be triggered by events and even generate events themselves, which can go on to trigger more services. By moving to architectures that make efficient use of these services, there is a general move to architectures that are more event-driven.
This idea of event-driven architectures has more recently started being used hand in hand with the term a serverless architecture.
This linking of terms is spreading further as cloud providers like AWS release more and more services targeting serverless architectures. And it’s not new, serverless has from an early stage often been characterised as “scale to zero” — such an approach to scaling and billing is obviously tightly coupled to having services that are event-based.
An example of this focus on event-driven architectures is one of the new major serverless services released by AWS — arguably the biggest since Lambda.
EventBridge is AWS’s answer to a serverless fully managed Event Bus. This allows events to flow through different services with less code, better observability and some very forward-thinking additions like the newly launched EventBrige Schema Registry. The Schema Registry can automatically detect and aggregate all the events of huge distributed architectures into one centralised registry — even providing automatic typed SDKs for developers to access the events from the IDE.
The Space of the Possible Solutions Grows
The space of possible solutions includes all the services pictured above.
As well as many other services both in AWS and in other cloud providers.
As well as services to be released over the next decade.
As well as serverless systems self-rolled by creative engineers building new and exciting things by glueing together these component blocks in ways even the cloud providers are not anticipating. EventBridge, after all, was the result of AWS seeing the weird and wonderful ways Cloudwatch Events were being used to trigger Lambdas.
Another example of this phenomenon could be the simple Serverless Event Scheduling System we built by combining of Step Functions and Lambda — covered in detail in another of our articles.
So, why are we not all adopting Serverless
Well first off, it’s hard to see this space of possible solutions from a single, often misused, word — Serverless
Especially when a certain framework chooses to use it as their name — an amazing tool, but not helping to preserve the complex semantics behind the term.
Now, it’s obviously not just a question of lexicon that has slowed the spread of serverless architectures. It’s a paradigm shift, potentially even more impactful than the move to the “Cloud” before it.
Engineers who have grown up building systems composed of servers, self-managed systems and perpetual state have to move to think in event-driven ways with seemingly infinite compute scale and storage — along with new challenges, constraints and a lack of tooling and best practices.
For instance, just one part of moving to a more serverless architecture often involves adopting DynamoDB (or similar) in place of the relational databases of the past. Now NoSQL isn’t new, but the idea of using it for any and all core business requirements is — this is because the whole system now works at a scale and event-driven nature before unknown.
It’s not easy — DynamoDB is complex, doing it well even more so. Throw onto that abandoning the familiar web application frameworks of the past — instead keeping functions lightweight with a low cost of change and offloading typical framework responsibilities to the cloud provider — none of this is trivial!
The benefits outway the costs when you can see the “space of the possible” clearly
People are not going through this pain of migrating their systems and mindsets for the sake of it. Serverless architectures, as discussed in many other articles, allow developers to focus on writing the code that embodies the most business value, while reducing the TCO (Total Cost of Ownership), increasing scalability and reducing the carbon footprint at the same time.
Words Fail
Sometimes, words fail. Sometimes it’s too much to put on one word the responsibility of communicating the boundaries of such a wide and polymorphic space of possible solutions.
But as a word that was created way before many of these newer serverless services — it’s not done a bad job. In fact, it’s a testament to the strength of the word that we are struggling to separate it from this space.
If it had been FunctionFull there is no way we would have kept using it as the space grew, and maybe we would have not grown the space in the way without the Serverless North Star guiding us towards an intangible quality.
For now Serverless, to me at least, manages to do a hard job, defining the borders of a very fluid and complex space of possible solutions in which we can build next-generation architectures. It would help if there was not a framework of the same name, it would help if people didn’t first hear it synonymous with Lambda and it would help if people stopped saying “but you know there are servers…”. That being said, I’ve not heard a better proposal yet!
For now, our job is to do damage control on the current “brand issues” serverless has by sharing more best practices, more content, more architectures, more tooling and also more stories about what can go wrong.
