Some­times we fans get a lit­tle over-excited and de­claim that ev­ery­thing should be server­less. After al­l, we’re pret­ty con­vinced that own­ing da­ta cen­ters and com­put­ers is be­com­ing a thing of the past. Well then, how could con­fig­ur­ing your own hosts and pay­ing for them even when they’re not work­ing ev­er be a good idea? Let’s try to be mod­er­ate and prag­mat­ic: Server­less, where pos­si­ble.

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

But what does “Where possible” mean? Here’s a nice con­crete ex­am­ple from in­side AWS: the Ama­zon MQ ser­vice, which is a man­aged ver­sion of the ex­cel­lent Apache Ac­tiveMQ open-source mes­sage bro­ker.

How Amazon MQ works

To make this us­able by AWS cus­tomer­s, we had to write a bunch of soft­ware to cre­ate, de­ploy, con­fig­ure, start, stop, and delete mes­sage bro­ker­s. In this sort of sce­nar­i­o, Ac­tiveMQ it­self is called the “data plane” and the man­age­ment soft­ware we wrote is called the “control plane”. The con­trol plane’s APIs are REST­ful and, in Ama­zon MQ, its im­ple­men­ta­tion is en­tire­ly server­less, based on Lamb­da, API Gate­way, and Dy­namoDB.

I’m pret­ty con­vinced, and pret­ty sure this be­lief is shared wide­ly in­side AWS, that for this sort of control-plane stuff, server­less is the right way to go, and any oth­er way is prob­a­bly a wrong way. Ama­zon MQ is a pop­u­lar ser­vice, but how of­ten do you need to wind up a new bro­ker, or re­con­fig­ure one? It’d be just nuts to have old-school servers sit­ting there hum­ming away all the time just wait­ing for some­one to do that. En­vi­ron­men­tal­ly nuts and eco­nom­i­cal­ly nut­s. So, don’t do that.

The da­ta plane, Ac­tiveMQ, is a big Ja­va pro­gram that you run on an EC2 in­stance the con­trol plane sets up for you. Client pro­grams con­nect to it by nail­ing up TCP/IP con­nec­tions and shoot­ing bytes back and forth. MQ and its clients take care of the mes­sage fram­ing with a va­ri­ety of pro­to­col­s: STOMP, MQTT, AMQP, and JMS/OpenWire. This is ob­vi­ous­ly not REST­ful.

Be­cause of the per­ma­nent con­nec­tion (un­like an HTTP API that sets them up and tears them down for each re­quest) the mes­sag­ing la­ten­cy can be re­al­ly, re­al­ly low. Of course, the down­side of that that the scal­ing is lim­it­ed to what­ev­er a sin­gle bro­ker in­stance can han­dle.

Any­how, the da­ta plane is ab­so­lute­ly not server­less. Is this OK? I’m go­ing to say that it’s just fine. Among oth­er things, at the mo­ment we don’t have a good server­less way to si­mul­ta­ne­ous­ly use nailed-up TCP/IP con­nec­tions and dis­patch server­less func­tion­s; you can imag­ine such a thing, but we don’t have it now.

Be­cause it’s not server­less its scal­a­bil­i­ty is lim­it­ed, and you’re go­ing to be pay­ing for it to turn elec­tric­i­ty in­to heat 24/7/365 whether you’re do­ing any mes­sag­ing or not. But for a lot of cus­tomers who just want some­body else to man­age their MQ in­stances, or who have to in­te­grate with lega­cy apps that talk JMS or AMQP or what­ev­er, it’s still su­per use­ful.

Glob­al weath­er · Let me give you an­oth­er ex­am­ple. I was re­cent­ly talk­ing to a large public-sector weath­er ser­vice that main­tains a mod­el of the glob­al weath­er pic­ture. This needs to be up­dat­ed all the time, and the up­date needs to com­plete in 43 min­utes. The ac­tu­al soft­ware is a vast, sprawl­ing thing built up over decades and sub­stan­tial­ly in FORTRAN. To get ac­cept­able per­for­mance, they have to buy in­sane­ly ex­pen­sive su­per­com­put­ers and run them flat out.

Would server­less be a good idea? Well may­be, but they don’t know to de­com­pose the mod­el in­to small enough pieces to fit in­to server­less func­tion­s. “Are you look­ing at that?” I asked. “We’d love to,” was the an­swer “but any­one who can fig­ure it out will prob­a­bly get a No­bel Prize. Want to try?”

I think that, since weath­er fore­cast­ing is pret­ty im­por­tant to civic well-being, we can all agree that this is an­oth­er sce­nario where be­ing server­ful is OK. (Wel­l, un­til some­one wins that No­bel Prize.)

Back to the main­stream · Now, let’s stip­u­late that most cus­tomers are writ­ing nei­ther real-time mes­sage bro­kers nor mod­els of the glob­al at­mo­sphere. Most are run­ning some­thing with a Web front end and a database back-end and straight­for­ward ap­pli­ca­tion log­ic in be­tween. Th­ese days, it’d be un­sur­pris­ing if there were events stream­ing in from dumb ma­chines or us­er click­streams or what­ev­er. Why shouldn’t all of this be server­less? I think it usu­al­ly should be, but there are things that rea­son­able peo­ple wor­ry about and de­serve con­sid­er­a­tion. That’s nex­t.


Comment feed for ongoing:Comments feed

From: Ivan Sagalaev (Dec 28 2018, at 10:18)

Here's another, more down to Earth example of where serverless wouldn't fit.

I used to work on a search engine which was a Python/numpy app relying on having a custom 50 GB index consisting of numeric matrices in local RAM to walk over it fast with vector CPU instructions. There's no way of pulling it up on demand neither from a local disc, nor over the wire.

I'd say, anything that looks like a database (i.e., wants all the data near the computation) can't really be serverless.


author · Dad · software · colophon · rights

December 11, 2018
· Technology (85 fragments)
· · Cloud (15 more)

By .

I am an employee
of, 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.