The “serverless” computing paradigm emerged a couple of years ago in Amazon Web Services (AWS) as a new cloud service called Lambda – a serverless computing platform. And now, even though it’s mainstream, it nonetheless can still be new or unknown to many in the IT industry. This blog explains and visualizes serverless for IT professionals who are new to the topic, covering:
So please read on to learn more about serverless.
Why is the name “serverless” misleading? It’s because code still needs to run on a server somewhere. But in the case of serverless, it’s not your server.
With serverless, the cloud service provider (CSP) is doing all the low-level infrastructure work for you. You don’t see the servers (even though they’re out there somewhere). So, therefore, from your perspective, there are no servers to manage, hence – it’s serverless.
There has been much rhetoric about the name. Some people have wanted to change it to functions-as-a-service (FaaS), which is very accurate but it didn’t stick. Maybe we are now all aaS-ed out?
So “serverless” it is then. And there’s even a series of global serverless conferences now.
There are five simple steps to understanding how serverless works, under the covers, but first, the headline – serverless is an event-driven compute paradigm.
It works as follows:
You can log in to AWS directly and do this manually but, in reality, this will be part of an automated DevOps pipeline, integrated into other systems such as AWS S3 storage, Dynamo databases, and SQS queues.
If you’re an artist, and have a big enough napkin, you could try to draw this example application of serverless on AWS while you sip on your gin and tonic.
Image source: AWS
To go beyond the napkin, head over to the Serverless Framework to dig deeper into the topic thanks to the site’s excellent content.
Over time, moving from left-to-right in the image below, organizations are increasing their use of:
Image source: ViewYonder
So where do you buy these serverless “things”?
As serverless lives at the bleeding-edge of the technology wave, it’s still a mixed, and changing, bag. The table below lists some popular serverless offerings:
|AWS Lambda||Yes||No||2014||Node.js, Python, Java|
|Azure Functions||Yes||Yes||2016||C#, Node.js, Python, F#, PHP, Java|
|IBM OpenWhisk||Yes||Yes||2014||Node.js, Swift|
Everything isn’t going to go serverless, and rightly so, because there are some use cases for which it doesn’t make sense. The diagram below shows the current sweet spot for serverless:
Image source: ViewYonder
Latency is the time measured from the trigger of your code until it completes. This can vary depending on how CSPs load and run your code. Unchanging, infrequently accessed code can be “unloaded,” or “spun down,” but this means more latency when this code is run because it has to be reloaded and “spun up.”
A good rule of the thumb to use when considering serverless is that: the more sensitive and more-frequently accessed your code is, then (at high levels) it might be better to run it on dedicated hardware somewhere, with you managing the server.
In terms of the serverless sweet spot, here are some examples of application types:
So, there you have a quick guide to serverless. If you already know about serverless, what would you say are the most important things to know (and understand) about it that I haven’t already called out?