Node is the WRONG runtime for serverless
It’s a sensationalist trap —but the complexity of async code does not come with the same gains found in traditional architectures
Last week at Serverlessconf in Austin, I made a bold and inflammatory claim: Node is the wrong runtime for serverless FaaS.
As expected, some people … disagreed. Contextually, it was meant to grab attention, and then used to illustrate what I’ll explain below.
But is that useful in our brave new FaaS world?
Functions in serverless architecture should, in general, be single-threaded and single task. If you’re doing a lot of different things in a Lambda function, you’re probably doing it wrong. Yes, everybody’s got a fanout function somewhere that benefits from concurrency or other similar requirement. But as a general rule, if your function is taking on multiple unrelated tasks — you should probably redesign to split it apart.
Don’t build little webservers in your Lambda functions.
If our functions aren’t using asynchronous techniques, what happens to all the concurrency we need? Concurrency between calls/flows is provided by the FaaS platform’s scaling, but what about concurrency within a flow?
The answer is that it needs to move into our infrastructure. Serverless systems are more or less inherently event-driven, and event processing needs to be asynchronous. However — and this was the point in my talk — the existing FaaS providers do not yet have the functionality in place to build graphs of async FaaS. AWS Step Functions and Azure Logic Apps aren’t quite sufficient yet — and what that should look like is the subject of another post.
Note: IOPipe is leveraging Node to keep HTTP connections open between Lambda invocations. That’s actually a pretty huge deal, but I haven’t heard if it’s not possible with other runtimes.