Serverless Is About Accountability

Serverless is the buzzword of our day and everyone has a different take on what it means. Some consider it a philosophy or mindset, others think it is about scaling-to-zero, and some believe it is merely hype around Functions-as-a-Service (FaaS).

I’ve been a serverless user and advocate since before the term as we know it existed. At the risk of sounding like Matthew McConaughey, there is some value in thinking about a concept without the bias of a name attached to it.

When you first hear the word “serverless”, regardless of what definition you may know, there is an inherent tendency to be influenced by the word itself:

  1. That it has something to do with servers (you can’t spell serverless without server.)
  2. That it is probably about a removal/absence of servers (wireless is “without wires”, stainless is without stains, spotless is without spots, and so on.)

The reactions to these interpretations are predictable: “serverless still has servers”, “serverless is SeviceFull”, “serverless is about running containers on a serving layer on a service mesh on Kubernetes on properly tuned server nodes”, and so on. We know there have to be servers, making the word a paradox.

However, I’d like to share a perspective that made me a fanboy and advocate of serverless where we ignore the word itself and instead focus on the problems it is meant to solve.

When everyone is to blame, no one is to blame

Take this example that is top of mind this month: Malware that installs itself on Windows through a browser. Everyone can agree that this is a problem and should never have happened. However, who is responsible for the fix – the browser or the operating system? Should all software ensure it never downloads things onto a computer ever? Or should an operating system never execute downloaded stuff? The answers aren’t easy or obvious.

Consider the Mars Orbiter that spoke metric to an imperial ground station. Both metric and imperial are both equally valid legitimate units. They both represent the same semantic thing. In this case, which unit of measurement was right and which was wrong?

When things go wrong, we frequently face similar dilemmas of choosing who was right and who was wrong:

  1. When a database is overloaded with requests:
    1. “Database teams suck! Make them scale it up. It’s their fault! We need planet-scale databases!” OR
    2. “App devs write shit code. Back in my day we didn’t make a billion DB calls! We wrote efficient code.”
  2. An emergency security patch that bricked machines:
    1. “InfoSec/Compliance made us do it. We did what we were told. They need to back off.”
    2. “Nobody properly tests like we used to back in my day. We need a proper staging environment to thoroughly test everything”
    3. “Users should be thankful that our service is always secure, even if it is down.”

Coupled responsibility doesn’t scale without complete control

Traditionally, we’ve tackled this dilemma through more processes, more coordination, and more shared-state such as common standard documents that everyone reads and adheres to. But the days of a standard-by-committee that everyone adheres to are long gone and never coming back (if they ever existed in the first place.) Especially in a world of multiple clouds, multiple data centers, multiple operating systems, multiple interchange formats, and multiple of everything. This is the complex world we live in.

Fundamentally we must accept that we cannot control other people. We cannot make them do what we want. What we can do is better communicate our expectations. What if the fault with the Mars Orbiter wasn’t the use of anyone “wrong” unit, but rather on both sides for not attaching units to their measurements?

Even the simplest cookbook in the world doesn’t have a recipe that just says “mix 5 flour and 2 sugar”. Technologists, though, grew up sharing recipes that read (5,2,3) and implicitly expand to (5 lb flour, 2 cups sugar, 3 ounces butter). This used to work when everyone worked in large enterprise silos where our magic tuples had inherent meaning.

This model breaks in the cloud, no matter how hard we fight to build some sort of common language for things. Even in a common language, a word may not mean the same thing to different people.

What if there was a better way, a simpler way? Rather than bullying trillion-dollar cloud providers into using uniform terminology, what if we expressed what we wanted instead? 

That might mean, “I want to make sure that only one out of every two VMs I run may ever fail due to the same fault.”

The cloud provider can call it a region, a zone, a sandcastle, or a snow fort. Don’t know. Don’t care. If they meet my contract, I pay them. If they don’t, they pay me.

Serverless is less of using servers as the excuse

Once we reduce our VM contract to a behavioral and functional definition, the corollary applies to our own code/logic too. If the platform is providing the behavior explicitly requested, then the remaining fault if any, is attributable to our code alone. Even if the fault is as simple as not making a sufficient explicit request – we know where it must be fixed and we can fix it.

How many logic bugs, errors, mistakes, and failures have occurred due to the desire to scale to interplanetary levels? Code that handles multiple threads with shared globals because ‘the server can’t handle a thousand processes’ – how do we know this? Did the server/platform communicate its maximum process limit?

These were all excuses for why we couldn’t handle a single request, “Well… it’s all complicated you see – this isn’t built for puny one-request. It’s built for the Moon-Mars-Earth network! For that I needed to do a multi-threaded global state, atomics is inefficient so I optimized it out and wrote code that never has data-races through code reviews and static/dynamic analysis tools.”

By removing the excuse of servers (and making your Cloud/Platform provider responsible and accountable for making them work – somehow), we can hold our own code accountable for doing its job.

Guest Author: Archis Gore is the CTO of Polverse Corporation and he can be reached on Twitter @archis

Share this post

Share your thoughts!!

This site uses Akismet to reduce spam. Learn how your comment data is processed.