We were ar­gu­ing at work about dif­fer­ent modes of com­put­ing, and it dawned on me that the big ar­gu­ments for go­ing server­less are busi­ness ar­gu­ments, not re­al­ly technology-centric at al­l. Maybe ev­ery­one else al­ready no­ticed.

[Dis­clo­sure: Not on­ly do I work at AWS, but as of ear­li­er this year I’m ac­tu­al­ly part of the Server­less group. I still spend most of my time work­ing on mes­sag­ing and event­ing and work­flows, but that’s server­less too.]

Now, here are a few com­pelling (to me, any­how) ar­gu­ments for server­less com­put­ing:

  1. Ca­pac­i­ty Plan­ning. It’s hard. It’s easy to get wrong. The penal­ties for be­ing wrong on the high side are wast­ed in­vest­men­t, and on the low side abused cus­tomer­s. Server­less says: “Don’t do that.”

  2. Ex­ploit Avoid­ance. There are no sure bets in this world, but one very de­cent weapon against next week’s Spec­tre or Heart­bleeed or what­ev­er is: Keep your hosts up to date on their patch lev­el­s. Server­less says: “Run func­tions on hosts that get re­cy­cled all the time and don’t linger unpatched.”

  3. Elas­tic Billing. There are a few servers out there, not that many, run­ning apps that keep their hard­ware busy do­ing use­ful work all the time. But whether it’s on-prem or in the cloud, you’re nor­mal­ly pay­ing even when the app’s not work­ing. Server­less says “Bill by the tenth of a second.”

Tech­nol­o­gy still mat­ters · Now, when we get in­to an ar­gu­ment about whether some app or ser­vice should be built server­less­ly or us­ing tra­di­tion­al host­s, the trade-offs get very tech­ni­cal very fast. How much caching do you need to do? How do you man­age your database con­nec­tion­s? Do you need shard affin­i­ty? What’s the idem­po­ten­cy sto­ry?

But some of the big rea­sons why you want to go server­less, when­ev­er you can, aren’t sub­tle and at the end of the day they’re not re­al­ly tech­ni­cal.

This is a new thing · I’m a grey­beard and have seen a lot of tech­nol­o­gy waves roll through. By and large, what’s driv­en the big changes are tech­ni­cal ad­van­tages: PCs let you re­com­pute huge spread­sheets at a keystroke, in sec­ond­s. Ja­va came with a pret­ty big, pret­ty good li­brary, so your code crashed less. The Web let you de­liv­er a rich GUI with­out hav­ing to write client-side soft­ware.

But Server­less isn’t en­tire­ly alone. The oth­er big IT wave I’ve seen that was in large part eco­nomics driv­en was the pub­lic cloud. You could, giv­en suf­fi­cient time and re­sources, build what­ev­er you need­ed to on-prem; but on the Cloud you could do it with­out mak­ing big cap­i­tal bets or fight­ing lega­cy IT ad­min­is­tra­tors.

Server­less, cloud, it all goes to­geth­er.


Comment feed for ongoing:Comments feed

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?


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.


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.")


author · Dad · software · colophon · rights
picture of the day
July 31, 2018
· Technology (84 fragments)
· · Cloud (9 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.