One of the best rea­sons to go server­less is that you might save a lot of mon­ey. This is es­pe­cial­ly true when your load is peaky and has qui­et times; be­cause when your in­fras­truc­ture isn’t work­ing, you’re not pay­ing. But, not all loads are peaky. And here’s a quote from an AWS in­ter­nal mail­ing list: “For ev­ery com­pute load, there’s some lev­el of TPS where Lamb­da is go­ing to be more ex­pen­sive than servers.” So, when is that? And how much should you care?

[This is part of the Server­less­ness se­ries.]

Sav­ing mon­ey with servers · The an­swer, of course, like al­ways, is “it depends”. But let’s just jump straight to what strikes me as the canon­i­cal ex­am­ple of some­one for whom server­less didn’t work out fi­nan­cial­ly. To learn about it, check out this blog piece by Co­ry O’Daniel, From $erver­less to Elixir.

Tl;­dr: No, wait, I don’t want to do a Tl;­dr! The piece is fun­ny and wise and in­struc­tive and if you care about this stuff, you should just go read it. Go ahead, I’ll wait and be here when you get back.

There’s no doubt at all that they saved a lot of mon­ey. The key lessons I took away from O’Daniel’s piece:

  1. They were smart to start up server­less, the app was run­ning fine and re­quir­ing no man­age­men­t.

  2. It was hard to get the server­ful ver­sion run­ning; they saw suc­cess on the third at­temp­t, and end­ed up need­ing to know a whole lot about the in­ner work­ings of the Er­lang ecosys­tem.

  3. As Co­ry says, “Mind that we al­ready have an ops team and we al­ready have a Ku­ber­netes clus­ter running.”

  4. Elixir is mas­sive­ly cool. I want to use it for some­thing be­fore I give up on com­put­er­s.

And of course, Cory’s clos­ing sound­bite (most high­light­ed on Medi­um) is worth re­pro­duc­ing:

So, should ev­ery­one go and rewrite their Server­less ser­vices in Elixir? Roll out Ku­ber­netes? Get a nose pierc­ing? Ab­so­lute­ly not … What ev­ery­one should do is think about where your ser­vice is go­ing, and can you af­ford those costs when you get there. If you don’t have a team of ops peo­ple and you aren’t fa­mil­iar with server­ful stuff, spend­ing $30k/­mo on HTTP re­quests might be cheap­er than an ops team.

Do I agree? · Most­ly, I think. Although if Co­ry worked for me I prob­a­bly would have been sort of pushy about mak­ing ab­so­lute­ly sure that there was no way to keep the cur­rent sys­tem around and still save some mon­ey, rather than toss-and-replace (on the third at­temp­t). I note that a lot of their charges were API Gate­way, and there are oth­er ways to get da­ta in­to the sys­tem. The da­ta was on Ki­ne­sis, which is fine, but there are cas­es where some­thing like SQS or Kaf­ka can be cheap­er. But in the last anal­y­sis, it’s not writ­ten in let­ters of gold on stone that server­less will al­ways be cheap­er.

Cheaper server­less · To get a feel for the kind of thing I’d look for, let’s head over to an­oth­er blog piece, How We Mas­sive­ly Re­duced Our AWS Lamb­da Bill With Go, by Sam Bash­ton of Run­book.­cloud, a nifty-looking mon­i­tor­ing/trou­bleshoot­ing ser­vice. His nar­ra­tive sort of echoes Cory’s, off the top: A pop­u­lar Lambda-based app start­ed run­ning up some big bill­s, to the point where it was be­com­ing painful.

This par­tic­u­lar Lamb­da (like Cory’s) didn’t do much more than pull some da­ta in over the net­work and per­sist it. What was hurt­ing is that they were run­ning the func­tion for each cus­tomer, for each AWS re­gion, ev­ery five min­utes. And since busi­ness was good the num­ber of cus­tomers was in­creas­ing fast; well, you do the math.

Rather than re­treat­ing to server­s, what they did was smash all those func­tions to­geth­er in­to one, and bring the mag­ic of the Go lan­guage Lamb­da run­time to bear. Let me quote Sam:

In a sin­gle morn­ing we refac­tored the code to use a sin­gle Lamb­da in­vo­ca­tion ev­ery min­ute, op­er­at­ing on 20% of the cus­tomer base each time. This Lamb­da spawns a Gorou­tine per cus­tomer, which spawns a Gorou­tine per re­gion, which spawns a Gorou­tine per AWS ser­vice. The Lamb­da ex­e­cu­tion time hasn’t in­creased sig­nif­i­cant­ly, be­cause as be­fore we’re main­ly wait­ing on net­work I/O - we’re just wait­ing on a lot more re­spons­es at the same time in a sin­gle Lamb­da func­tion. Cost per cus­tomer is now much more man­age­able how­ev­er, be­com­ing low­er and low­er with ev­ery sign up.

Isn’t that nice? And no throw­away code, ei­ther.

Clos­ing thoughts · My opin­ion hasn’t changed at al­l: For build­ing soft­ware, use server­less where you can. Ob­vi­ous­ly, “where you can” de­pends a lot on the specifics of your app and your bud­get and your sen­si­tiv­i­ties.

And when you’re work­ing out the costs of server­less vs server­ful, ask your­self: How much is it worth to you to not have to man­age host­s, or con­tain­er­s, or ca­pac­i­ties, or Ku­ber­netes? I don’t know the num­ber, but I’m pret­ty sure it’s not ze­ro.


author · Dad · software · colophon · rights
picture of the day
December 30, 2018
· Technology (85 fragments)
· · Cloud (16 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.