A simple definition of “Serverless”
tl;dr: A Serverless solution is one that costs you nothing to run if nobody is using it (excluding data storage)
I’ve had long conversations about what makes something serverless and I’ve always had a few simple elements to talk about but I’ve come up with something that I think might help.
I wrote a blog post about defining Serverless in 2016
Often in people’s minds, Serverless means that you’re using “Functions as a Service” (FaaS) which is only one part of a possible Serverless solution.
Or Serverless is something that is “event driven”.
Or that you’re using Firebase or similar and you have a “thick client” in front of it.
Or it’s something that you can easily scale (like Heroku dynos or EBS).
Except that I don’t think that’s what Serverless is.
Because even if you do those things, then it is still possible to run a non-serverless solution alongside this, and then your system isn’t Serverless any more.
Non-serverless systems like a relational database,
or using a MongoDB service,
or even running third party services like Wordpress (either your own, or via another service),
because those things need maintaining (and that means cost),
and it’s irrelevant if anyone is using it. You still have to pay!
A solution is Serverless when…?
For me, a serverless solution can be identified in a relatively simple way:
A Serverless solution is one that costs you nothing to run if nobody is using it
… excluding data storage costs.
You simply don’t pay for idle servers anywhere.
For example, if you take an AWS based Serverless solution, you would have something like this:
API Gateway + Lambda + DynamoDB + S3 + SNS + DynamoDB Streams + SES + Cognito
If nobody was using the system, the resources would essentially be dormant. The data would be stored within the cloud based system ready for use at the first event and you’d have to pay for it of course (e.g. DynamoDB tables and S3).
So you would be paying for the storage of data, but not for idling servers.
While the system is always available, it’s not always “on”.
So, taking this idea, then something like a backend using Heroku would not be Serverless because you’re likely to always have a dyno running. It might however be better than other solutions (it’s scalable for example).
Serverless isn’t (and never was) about “no servers”, at least not in the way that we would think about it.
Serverless isn’t about just scalability.
Serverless isn’t about Functions (FaaS) only, because you can always run non-Serverless elements and then pay for idle.
A Serverless system such as this would be very low on maintenance too and is inherently event driven. If it wasn’t event-driven, then you’d need to pay to ensure that a system is always available and idle (like an EC2 instance)
So if you want to do a Serverless system, then you have to design it with the idea that if nobody is using it, then nothing is running.
That will require thought and commitment, and that means that you have to ditch ideas about running web servers and database servers.
In fact, going serverless means you should ditch all ideas about running servers at all.
And that includes Containers. Because they are just another form of server.
Because going serverless is quite simple really.
Isn’t it?
I think it is.
Go serverless and stop paying for (and maintaining) idle servers.
Just because you’ve always done it, doesn’t mean you should keep doing it.
Other blogs I’ve written
For a selection of other Serverless blog posts that I’ve written, please look here:
