Originally published at winterwindsoftware.com.
Like many industry buzzwords before it — "cloud computing", "DevOps", "big data" — debates over the definition of the term “serverless” have become somewhat of a honeypot for pedants.
"But there are still servers involved!"
– Dave from Reddit.
Thanks for that, Dave. 😏
If you're reading an article about anything serverless-related today, there's a fair chance that the author will have stated their definition of the term in the introduction (probably to avoid incurring the wrath of the Daves of the internet).
Experienced practitioners will just skip to the next paragraph, but if you're new to the space, adding some depth to your understanding of the concept is worthwhile.
In this article, we'll walk through the definitions provided by several prominent advocates in the serverless space and extract some common themes along the way, finishing off with me attempting my own inelegant definition.
Note: All emphasis is mine in the quotes below.
What the experts said
We'll start with AWS themselves:
"Serverless computing allows you to build and run applications and services without thinking about servers. Serverless applications don't require you to provision, scale, and manage any servers. You can build them for nearly any type of application or backend service, and everything required to run and scale your application with high availability is handled for you." (source)
The authors of the Serverless Framework share a similar message:
"Just like wireless internet has wires somewhere, serverless architectures still have servers somewhere. What ‘serverless’ really means is that, as a developer you don’t have to think about those servers. You just focus on code.
... You don’t have to actively manage scaling for your applications. You don't have to provision servers, or pay for resources that go unused." (source)
In his definition article, Tomasz Janczuk, VP at Auth0, provides a high-level summation:
"The essence of the serverless trend is the absence of the server concept during software development." (source)
Ajay Nair, Product Manager of AWS Lambda, focuses on the specifics of the tasks which go away:
"Owning servers comes with responsibilities:
- You own how your primitives (functions in the case of applications, or objects when it comes to storage) map to server primitives (CPU, memory, disk etc.)
- You own how your capacity scales to handle your application scale
- You own provisioning (and therefore paying) for the capacity to handle your application’s projected traffic, independent of whether there’s actual traffic or not
- You own managing reliability and availability constructs like redundancy, failover, retries etc.
For me, serverless means activities/responsibilities related to servers are no longer on your radar." (source)
📖 Related: List of concerns that go away in a serverless world.
Paul Johnston, ex AWS Serverless Snr DA, gives a pithy, financially-focused explanation:
"A Serverless solution is one that costs you nothing to run if nobody is using it (excluding data storage)." (source)
Paul also points out a common misconception that I often encounter:
"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."
Peter Sbarski, VP Engineering at A Cloud Guru, gives his take:
"Serverless is about abstracting users away from servers, infrastructure, and having to deal with low-level configuration or the core operating system. Instead, developers make use of single purpose services (such as S3 for storage or Auth0 for identity management) and elastic compute platforms (such as AWS Lambda) to execute code." (source)
Common themes
Extracting the meat from the quotes above, there are re-occurring ideas around what serverless includes and what it excludes:
What's in
- Resource costs must be tightly aligned with usage levels
- Greater focus on application code
What's out
- Server provisioning and maintenance
- Active management of service availability and scaling
My definition
I'm going to stand on the shoulders of the giants mentioned above and organise these points into prose to give my own definition:
A serverless solution is one where developers are freed up to focus more on application development without needing to worry about provisioning, scaling or maintaining servers (or containers), and whose running costs are proportional to the system's usage levels.
And finally, if you're that person writing an article about serverless and feel the need to define the term for your readers, just copy and paste the following into your post and get back to writing! 😎
👉 Not sure what serverless is? Check out this curation of serverless definitions from the experts.
💌 If you enjoyed this article, you can sign up to my weekly newsletter on building serverless apps in AWS.
Top comments (15)
Great collection!
But .. I do not think the last two quoted definitions are correct.
Paul Johnstons definition is only an effect of the serverless not the source. You can achieve the same effect with zero scaling technologies like AppEngine too, which are not serverless.
Peters is not so completr, you do not need to focus on low level when dealing with containers, but you still have to handle some configs like os type and min max scaling limits, which are not low level but still missing from serverless.
A good list of definitions. What if the provider's server (We've recently faced issue with Microsoft servers and all our apps are down for hours) is down? Should we call it server-less :P
There's always a Dave...
Great article!
I'm thinking of trying the serverless approach in my next pet project. As a PHP developer I've always worked with a server. Do you know any guide ir article for a serverless implementation with PHP?
Thanks! 😀
Jelly Fin is planning on using serverless with Firebase. I'm going this route because I don't want to have to deal as much with setting up server boxes, vms, or containers and then have to monitor them for stability, uptime, etc. etc.
I just want an endpoint I can hit, when I want, and how I want. The beauty is that is scales with the app. When you hit a serverless endpoint once, it takes a few hundred milliseconds longer to execute. This is known as a cold start. In most small apps, this is ok.
As the app scales, you need a faster response. Whatever service you use begins keeping the endpoint in memory and highly-available as it gets used more often resulting in faster responses.
To many, this is a dream come true! Setting up infrastructure in an automated fashion is a pain. You have to provision vms, install operating systems, patch them for security holes, THEN install your app, monitor performance, make sure your servers aren't slammed...the list goes on.
Whenever we cross these boundaries from shared hosting and now serverless architecture, it begs the question...what's next?
That means it's synonymous with PaaS. And it's inferior to the term PaaS, as PaaS comes packaged with the terms IaaS and SaaS to differentiate against.
I don't get why a new word is hyped for an old concept, a word that is both misleading and uninspired. I understand that marketing people use it, but engineers have no justification talking like that. They should know better.
Its a great platform you created...Hats off
TL;DR: Name things after what they are, not what they feel like.
This is a great description of what serverless is. Very readable and easy to understand. Thanks for that!
In my opinion ...
You're totally right.
I think, especially the billing part is left out too often.
"Cloud" is Marketingish for "other people's computers". Say "other people's computers" if you mean that.
I actually did mean the cloud, as in, run on a cloud provider vs. the server my neighbor has in their basement.
So it makes a huge difference for you whether the computer of other people stands in a rack or in a basement?
It does! If it's in a basement and the basement floods or a tornado hits or the neighborhood experiences a power outage, I'm done. A major motivation for going to the "cloud" is to take advantage of features like high availability and regional failover that I don't get from my neighbor's basement. I'd rather not have to set up things like BGP on my own.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.