Deploying Next Gen Serverless Functions with WebAssembly and Module Federation
No deployment automation needed. Part 2 of 3.
In part 1 of the article, we discussed the advantages of Wasm as a serverless runtime and some of the problems it solves, like eliminating cold start performance issues. But we were left to consider how to deploy Wasm serverless functions.
No Docker containers, right? Right. Wasm is a substitute for containers. Think of it as a nano-container. It already provides the isolation needed to protect the host and other containers.
If we’re not deploying Docker containers, what are we deploying exactly and how? At this point, you’ll recall that the suggestion was to avoid installing software on the server, but to instead stream it over the network at runtime. Instead of taking the time and resources to copy it to (ephemeral) disk or remote storage (e.g. S3), we’ll load the program directly into memory.
Considering we can stream from anywhere, a source repo or even a CDN, our backend architecture could potentially look a lot like our frontend — if we were using JamStack. Just add one extra arrow pointing from serverless to CDN.
Federated Serverless Platform
What would be needed to build such a platform? K8s, Istio, Casandra, Etherium, Beat-complexity-into-submission-ly? What we need is a federation runtime that can be told what modules to stream and execute as they are requested. Recall in the previous article, we considered such a runtime and how to embed it in, or port it to, Wasm. The building block, then, of a federated serverless platform is a Wasm-based module federation runtime. That’s all that’s needed: no additional software to coordinate or execute deployment.
In the third and final article we’ll examine the federated serverless platform in detail.
