We were arguing at work about different modes of computing, and it dawned on me that the big arguments for going serverless are business arguments, not really technology-centric at all. Maybe everyone else already noticed.
[Disclosure: Not only do I work at AWS, but as of earlier this year I’m actually part of the Serverless group. I still spend most of my time working on messaging and eventing and workflows, but that’s serverless too.]
Now, here are a few compelling (to me, anyhow) arguments for serverless computing:
Capacity Planning. It’s hard. It’s easy to get wrong. The penalties for being wrong on the high side are wasted investment, and on the low side abused customers. Serverless says: “Don’t do that.”
Exploit Avoidance. There are no sure bets in this world, but one very decent weapon against next week’s Spectre or Heartbleeed or whatever is: Keep your hosts up to date on their patch levels. Serverless says: “Run functions on hosts that get recycled all the time and don’t linger unpatched.”
Elastic Billing. There are a few servers out there, not that many, running apps that keep their hardware busy doing useful work all the time. But whether it’s on-prem or in the cloud, you’re normally paying even when the app’s not working. Serverless says “Bill by the tenth of a second.”
Technology still matters · Now, when we get into an argument about whether some app or service should be built serverlessly or using traditional hosts, the trade-offs get very technical very fast. How much caching do you need to do? How do you manage your database connections? Do you need shard affinity? What’s the idempotency story?
But some of the big reasons why you want to go serverless, whenever you can, aren’t subtle and at the end of the day they’re not really technical.
This is a new thing · I’m a greybeard and have seen a lot of technology waves roll through. By and large, what’s driven the big changes are technical advantages: PCs let you recompute huge spreadsheets at a keystroke, in seconds. Java came with a pretty big, pretty good library, so your code crashed less. The Web let you deliver a rich GUI without having to write client-side software.
But Serverless isn’t entirely alone. The other big IT wave I’ve seen that was in large part economics driven was the public cloud. You could, given sufficient time and resources, build whatever you needed to on-prem; but on the Cloud you could do it without making big capital bets or fighting legacy IT administrators.
Serverless, cloud, it all goes together.
Contributions
Comment feed for ongoing:
From: Tim (but not THE Tim) (Aug 02 2018, at 19:36)
So, there are a lot of computers providing services, but they aren't "servers" - are they just "water molecules" in the cloud?
[link]
From: Hal Berenson (Aug 03 2018, at 06:35)
There is tension between Elastic Billing and Deterministic Behavior. I'm currently in a discussion with a few people over https://queue.acm.org/detail.cfm?id=3215876. Now I find most of KV's response to the question pretty bogus, but let's step back to the problem. A close read of the question leads me to believe that "Rained on our Parade" migrated to Heroku. It doesn't matter why I believe that, what matters is the serverless-like characteristics of Heroku and the implications for serverless solutions in general.
In the discussion I'm in the issue is that the user application values deterministic behavior. So they take issue with a solution where at the edges they could experience non-deterministic behavior. In particular, the lag in scaling responding to a surge in requests. Something they see as even worse should resources be released prematurely by the serverless infrastructure. They realize they could reserve resources to address that problem, but that reduces or eliminates the benefits of Elastic Billing.
Ultimately for Elastic Billing to offer the full benefits it promises the services will need to offer more capabilities for achieving deterministic (or predictable, as the term I prefer) performance without the user having to pay for unused but reserved resources. Otherwise the business case and technical case are too much at odds for many(?) applications.
[link]
From: Bob Wyman (Aug 04 2018, at 11:04)
Is there anything new to this discussion that we didn't debate to death back in the days when "time sharing" was the "new thing?" Even Hal's concern for deterministic response was considered well and fully back in those now ancient debates...
Time sharing was good then and it is good now. Also, "client server," (a form of time sharing) is usually good and the right way to go. It has always been this way.
bob wyman
(yet another "greybeard.")
[link]