« Stuff The Internet Says On Scalability For July 29th, 2016 | Main | Stuff The Internet Says On Scalability For July 22nd, 2016 »

Economics May Drive Serverless

We've been following an increasing ephemerality curve to get more and more utilization out of our big brawny boxes. VMs, VMs in the cloud, containers, containers in the cloud, and now serverless, which looks to be our first native cloud infrastructure.

Serverless is said to be about functions, but you really need a zip file of code to do much of anything useful, which is basically a container.

So serverless isn't so much about packaging as it is about not standing up your own chunky persistent services. Those services, like storage, like the database, etc, have moved to the environment.

Your code orchestrates the dance and implements specific behaviours. Serverless is nothing if not a framework writ large.

Serverless also intensifies the developer friendly disintermediation of infrastructure that the cloud started.

Upload your code and charge it on your credit card. All the developer has to worry about their function. Oh, and linking everything together (events, DNS, credentials, backups, etc) through a Byzantine patch panel of a UI; uploading each of your zillions of "functions" on every change; managing versions so you can separate out test, development, and production. But hey, nothing is perfect.

What may drive serverless more than anything else is economics. From markonen

In my book, the innovation in Lambda is, above everything else, about the billing model. My company moved the work of 40 dedicated servers onto Lambda and in doing so decimated our costs. Paying for 1500 cores (our current AWS limit) in 100ms increments has been a game changer.
I'm sure there are upsides to adopting the same programming model with your own hardware or VMs, but the financial benefit of Lambda will not be there.

There are many more quotes likes this, but that's the jist of it. And as pointed out by others, the pay off depends on some utilization threshold. If you can drive the utilization of your instances to some high level then running your own instances makes economic sense.

For the rest of us taking advantage of the aggregation of a big cloud provider is a winner. Setting up a highly available service on the cloud, dealing with instances and all the other overhead is still a huge PITA. Why deal with all that if you don't have to?

Developers pick winners. Developers follow ease of use. Developers follow the money. So serverless is a winner. You'll just have to get over the name.

Reader Comments (3)

I *really* hate the term serverless. It's just another marketing buzzword for a type of product or platform - guess what it always runs on when you look at it - servers!

There isn't some magical dragon that does calculations or stores data in his/her memory on your products behalf, it's just an offering, generally inferring that a third party has provided you with a PaaS / application endpoints where you're not seeing servers, doesn't mean they're not there.

It's a bit like me saying that I live an infrared free life - just because I can't see the infrared sprectrum (and may not need to) doesn't mean it's not there.

July 27, 2016 | Unregistered CommenterSam McLeod

Totally agree. I wrote about that being the major benefit / driver in this post about too: https://www.iron.io/what-is-serverless-computing/

July 27, 2016 | Unregistered CommenterTravis Reeder

Also remember that once AWS gets their act together they will be able to effectively scale Lambda from very low scale services (where you get slices of an instance) to very high scale services (where they effectively run many instances on your behalf). There is no reason that Lambda can't be as cheap or cheaper than running your own instances for the majority of use cases.

August 1, 2016 | Unregistered CommenterDust Appeal

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>