What is Serverless? The “2020” edition
I’ve spent most of this year avoiding talking about serverless as can be seen from previous blog posts such as Serverless is Doctrine, not a Technology and Cloud 2.0 is no longer King — Serverless has dethroned it. Discussions on various networks have tended to descend into discussions around the compute aspects of FaaS.
Not only that, but I’ve tried to stay out of discussions, because it feels like too many big companies and marketing budgets are trying to “own” the word, to ensure that their technology is part of the movement. The word “serverless” has definitely been co-opted by a range of companies to fit their preferred technology that in my mind it doesn’t fit.
Serverless (in some people’s minds) currently encompasses:
- Anything that looks like “Function as a Service” like AWS Lambda, Google Cloud Functions, and Azure Functions
- Anything that can run a Function as a Service system, like OpenFaaS and similar
- Ok… lots of people think it’s a synonym for Function as a Service (spoiler: it’s not)
- Any solution that runs “on demand compute” such as Google App Engine (spoiler: it’s not)
- Anything that runs a container on demand like Google Cloud Run or Fargate (note: I like Cloud Run)
- Basically “on demand compute” of some description, some of which “scales to zero”
And you’ll often find fans of technologies such as kNative and Kubernetes talking about how their technologies are “serverless” or “enable serverless” architectures.
PSA: These technologies have their place and the people who work on them are probably really nice people (I haven’t met them all, so I just don’t know). If they fill a business need for you, then fantastic, please use them. I am simply questioning whether they should be called “serverless” not whether they have intrinsic value or not.
I also know that AWS has softened the use of the word serverless over the last year or so, because the slides and website it uses to explain serverless have changed since I worked there as Senior Developer Advocate for Serverless, for example encompassing Fargate when previously it didn’t. See the July 28th 2018 version against the current version of the AWS Serverless page and you can see the differences.
Just to clarify, what most people mean when they talk about serverless, is FaaS or a technology that enables FaaS.
And that’s ok, because the the word “serverless” is actually the problem here.
The implication of the word is that we remove the need to worry about the “server” as in “server”-less.
But that’s not what I talk about, when I talk about serverless, at least, it isn’t any more.
And I can’t stand the word “serverless” any more. It’s just the wrong word. I wish we’d picked something more like “cloud” because it would have made more sense.
Serverless is an approach not a technology
When I set out to build the technology for a startup in 2015, I picked AWS Lambda as the base not because I wanted to use something new and cool (it was less than a year old at that point) but because I had a different set of priorities.
I wanted to limit my exposure to managing servers as much as possible.
Notice that I’m not worried about managing servers. It’s my exposure to the risk that matters here.
I literally didn’t want to have to think about ssh-ing into any instances, and upgrading them regularly, monitoring them for hack attempts, maintaining any libraries on a long running system etc. unless I had no other choice due to workload constraints.
Managing servers becomes onerous over time, and in a startup, saving yourself time over your runway is pretty much the best thing you can do.
My choice was not to “avoid having to think about servers” but simply a pragmatic attempt to avoid as much of the long term work of maintaining them as I could.
It’s like saying “I can make most of this runway pretty smooth all the way along instead of really smooth to halfway, and hope that by the time we get there we’ll have the resources to make the rest really smooth too”.
Startups are hard. They require focus and things can change in an instant. You get a call and your CEO says “we’re now doing this — change everything” and you have to move quickly.
I built the startup around an API, and each route was built around a single Lambda function so following something like the Single Responsibility Principle or as I like to say “each function should only do one thing”.
I built in this style because it allowed me on a number of occasions to change the API rapidly so that I could avoid impacting other parts of the system.
That’s not to say you can’t do that in other ways, because you can. And in some ways, building it using a web framework with an API module e.g. django or rails, is easier if you know it (did… did I just say that it might be easier to build it another way… I did)…
…but managing it, and adjusting it and changing it over time is a different beast. I’ve been there and done that many times before and knew what that was like. The most costly part of a startup that I’ve seen is usually the second build, not the first. The first one is trivial and can be done in a whole lot of different ways.
The second build is where you do one of two things: you either rewrite the entire stack in a “better way” (and often make all the same mistakes again), or you try to refactor your code to make it “better”, and both take time out from feature releases to do so. Neither is generally productive. Trying to avoid this is good sense.
So what if there was a way you could do it differently? Build systems in a way that allows you to do two things:
- easily add to your systems and have low ongoing maintenance requirements?
- easily change your systems over time without having to do a big bang rewrite/refactor?
I didn’t pick Lambda and subsequently API Gateway, DynamoDB, S3 and Cognito, because they were cool or new, or even because Lambda scaled to zero, although the scaling to zero was an advantage.
I picked these technologies, what I call “serverless” because they provided me with a pragmatic way to achieve (what are ultimately) the business goals I had set for myself.
Serverless is and always has been about understanding your business
One of the key frustrations I have when talking to developers about this (and several of the product owners and advocates at big cloud vendors are at fault for this as well) is that they think they’re talking about the business, when they are really talking about technology.
I have been a CTO, an Interim CTO, and am an Advisor to startups now. If a developer is so detached from the business that they don’t understand why they are doing something from a business point of view, then they are basically wasting money.
If you are a developer and your first thought is that serverless is about technology then you’ve got it mixed up.
Serverless is first, foremost and always will be about the business.
It’s a relatively simple thing to understand.
It’s also why serverless isn’t about technology choices.
Because while I have never come across this, it is possible to argue that a “serverless startup” may have containers and servers within it.
Why?
Because running servers or instances may be the most efficient way of achieving the business value you are trying to achieve.
Which is why a “serverless architecture” based upon the criteria that many put onto it — FaaS or “on demand” — is incorrect.
Now, some may point out my definition of serverless here:
“A serverless application is one that provides maximum business value over its application lifecycle and one that costs you nothing to run when nobody is using it, excluding data storage costs.”
And you should, rightly, point out that this says it should cost you nothing if nobody is using it.
How does that square with running servers?
Well, it’s relatively simple: If nobody is using it, why are you running servers?
Servers are great for long running tasks, and for tasks where you have a relatively constant and known load. There are very few of those in the tech world that are not known in advance. Spinning up servers and containers when you have a known long running spike in load is not a bad idea either.
The key point of the definition is “maximum business value”.
Simply running servers because that is what you know is lazy and is not necessarily good value for the business.
Running servers because it is the right thing for business value? Go for it, but you have to make the case before you can do it, and that isn’t always easy.
The reason that FaaS is so closely intertwined with serverless is simple:
FaaS is the simplest and most obvious enabling technology for applications using a serverless approach
Serverless is a mindset shift and not a technology
I reckon I’m in the minority who thinks that this will be the accepted way we view serverless.
At least for the foreseeable future.
However, I think at some point soon, the mindset approach will become the accepted way that serverless is seen. I hope also that we will maybe get a new name, or maybe that the mindset approach will be given a new name and separate out from the conversation around technology.
If you focus on the technology, you’ll miss what I think is coming next. It’s not “no code” as many think (and many think is a funny joke on the serverless movement — spoiler: it’s not, it’s actually a bit insulting), but more a kind of “workload management service” that the cloud vendors will be doing for us:
What happens when we “upload code” and the vendor does the rest?
We may have to provide information in and around resources that we need of course, and so our resource configuration becomes ever more powerful as part of our application (another blog for another time).
What happens when they simply understand our traffic patterns, our needs, our usage, and provision everything for us?
What happens if they create those long running containers for us instead of us having to do it ourselves?
That will happen.
If we hold tightly to our understanding of the “server” too much, and hold tightly to our idea of “frameworks” and the fact it is the “code” that does the work, we’ll miss the value in this new paradigm.
Because developers think that the “code” is the value. It’s not. Over time, services are replacing the need for so much code. If you think about it, the more services get used, the more ability the developer has to develop business value. This should be seen as an opportunity, not a threat.
Building solutions for that kind of future means understanding that the applications of the future are built in and around events, key-value stores, queues and resources in a completely different and modular way.
This kind of “serverless” is as big a paradigm shift as “cloud” was.
This is the shift that will come, and is coming, although I’ll admit, it may be some way off.
That shift starts with what we now call “serverless”.
What is serverless? The 2020 edition is simple:
Serverless is not a technology, it’s a mindset.
It’s the next iteration of cloud.
Bonus: The serverless link to Climate Change
One of the other elements of my choices as a CTO was that AWS Lambda is an on demand compute platform. I chose it in part because my belief was that it would reduce my compute usage by not running servers constantly, and therefore reduce my electricity usage and my carbon footprint.
I see my whole serverless mindset as being informed in large part by this. Limiting compute, and usage is important to me. We have to reduce our impact where we can, and this approach allows me to do that.
It’s part of the reason why I don’t see serverless as being about technology and why I do see it as being a mindset. For me, it’s about still providing as high quality solution as possible, and doing my part in fighting Climate Change. It is always an imperfect gesture in an oil-based economy, but it is a step.
For more on this, I’ve written about this here:
