Sometimes we fans get a little over-excited and declaim that everything should be serverless. After all, we’re pretty convinced that owning data centers and computers is becoming a thing of the past. Well then, how could configuring your own hosts and paying for them even when they’re not working ever be a good idea? Let’s try to be moderate and pragmatic: Serverless, where possible.
[This is part of the Serverlessness series.]
But what does “Where possible” mean? Here’s a nice concrete example from inside AWS: the Amazon MQ service, which is a managed version of the excellent Apache ActiveMQ open-source message broker.
To make this usable by AWS customers, we had to write a bunch of software to create, deploy, configure, start, stop, and delete message brokers. In this sort of scenario, ActiveMQ itself is called the “data plane” and the management software we wrote is called the “control plane”. The control plane’s APIs are RESTful and, in Amazon MQ, its implementation is entirely serverless, based on Lambda, API Gateway, and DynamoDB.
I’m pretty convinced, and pretty sure this belief is shared widely inside AWS, that for this sort of control-plane stuff, serverless is the right way to go, and any other way is probably a wrong way. Amazon MQ is a popular service, but how often do you need to wind up a new broker, or reconfigure one? It’d be just nuts to have old-school servers sitting there humming away all the time just waiting for someone to do that. Environmentally nuts and economically nuts. So, don’t do that.
The data plane, ActiveMQ, is a big Java program that you run on an EC2 instance the control plane sets up for you. Client programs connect to it by nailing up TCP/IP connections and shooting bytes back and forth. MQ and its clients take care of the message framing with a variety of protocols: STOMP, MQTT, AMQP, and JMS/OpenWire. This is obviously not RESTful.
Because of the permanent connection (unlike an HTTP API that sets them up and tears them down for each request) the messaging latency can be really, really low. Of course, the downside of that that the scaling is limited to whatever a single broker instance can handle.
Anyhow, the data plane is absolutely not serverless. Is this OK? I’m going to say that it’s just fine. Among other things, at the moment we don’t have a good serverless way to simultaneously use nailed-up TCP/IP connections and dispatch serverless functions; you can imagine such a thing, but we don’t have it now.
Because it’s not serverless its scalability is limited, and you’re going to be paying for it to turn electricity into heat 24/7/365 whether you’re doing any messaging or not. But for a lot of customers who just want somebody else to manage their MQ instances, or who have to integrate with legacy apps that talk JMS or AMQP or whatever, it’s still super useful.
Global weather · Let me give you another example. I was recently talking to a large public-sector weather service that maintains a model of the global weather picture. This needs to be updated all the time, and the update needs to complete in 43 minutes. The actual software is a vast, sprawling thing built up over decades and substantially in FORTRAN. To get acceptable performance, they have to buy insanely expensive supercomputers and run them flat out.
Would serverless be a good idea? Well maybe, but they don’t know to decompose the model into small enough pieces to fit into serverless functions. “Are you looking at that?” I asked. “We’d love to,” was the answer “but anyone who can figure it out will probably get a Nobel Prize. Want to try?”
I think that, since weather forecasting is pretty important to civic well-being, we can all agree that this is another scenario where being serverful is OK. (Well, until someone wins that Nobel Prize.)
Back to the mainstream · Now, let’s stipulate that most customers are writing neither real-time message brokers nor models of the global atmosphere. Most are running something with a Web front end and a database back-end and straightforward application logic in between. These days, it’d be unsurprising if there were events streaming in from dumb machines or user clickstreams or whatever. Why shouldn’t all of this be serverless? I think it usually should be, but there are things that reasonable people worry about and deserve consideration. That’s next.
Comment feed for ongoing:
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.
[link]