Ok, I have seen the phrase "serverless" a few times recently. Can someone explain to me what it is (as I am pretty sure it involves a server - it runs on AWS ffs) and why I should want to use it?
And most importantly, is it web scale?
- We used to have our own machines in our own data centers
- Then we started renting machines in data centers
- We then moved to the cloud model where we would get compute capacity on demand. But the minimum unit was an hour
- But what if you could deploy your code and you were only charged for the compute and memory you take for the fulfillment of that request? That is what the "serverless" model is. You don't constantly run a server like apache; instead, when you receive a user Request, the relevant function is called, executed and results returned to the user. You are billed for the ram ⨉ CPU.
This has many benefits:
- For low traffic sites, this has significant cost savings
- For high traffic sites, this is auto-scaling without thinking about launching machine instances
This isn't without problems, naturally. This lends itself well to certain type of problems better than others. For example, if you need lots of hot-cache data, the response times on a serverless stack would be slower.
But as you can see from the above, this is the logical direction cloud computing will evolve. Infrastructure will truly be shared and you should be able to extract efficiencies down to the minute.
If I've understood lambda correctly, rather than spinning up a process (as with CGI), it spins up an entire vm/container. I suppose it might do the fast-cgi thing - spin up a container, and keep it running while there are requests coming in, and then kill it off.
I'm sure there are other benefits of "container-on-demand" vs "process-on-demand" -- but I'm not sure "scales better" is one of them. Well, I'm sure it "scales better" in the sense of organization (human resources), but not necessarily in terms of machine resources.
At any rate, I like the analogy.
For me, most of the benefit comes from data processing, where my usage is very bursty. The classic example used on most of the tutorials is image thumbnails/scaling/similar. All you want to say is "Do X to every file in this folder of 50k images" and let someone else handle starting and stopping as many machines as they can in order to get this done as quickly as possible.
We used to have "web hotels". Then they grew server side programming support, such as Perl and later PHP. Customers were at first not separated at all but later they were with Virtuozzo and similar systems.
This was later rebranded PaaS, to differentiate from cheap PHP hosting of yore. Some has now rebranded to serverless. It's not so much a "direction" as it is market differentiation.
Ultimately, there is a server somewhere, as you might expect. It's just not yours to manage/worry about.
https://aws.amazon.com/lambda/pricing/
If you were hosting something like a little message board for your friends and family, or something you are demoing to to possible employers, etc, it'd be borderline free, but available all the time.
For that, Lambda is great. We have lowered our price since migrating to Lambda for this relatively simple script.
It's actually a boon to entrepreneurial types who really do know the full stack inside and out. So many startups these days are "slap a web or mobile app in front of a manual process", so people who really do understand computation and all the things computers can do have less competition.
Having a t2 up the whole time would have been way more, plus it would have been subject to our Chaos Monkey.
Really, the "serverless" term does more to obscure than to illuminate.
Lambda's are just units of code that run only On-Demand and without having to manage one or more EC2 instances or a container platform.