The focus of developers for many years has been on event-driven execution (EDE) and its serverless implementation, Azure Function Apps. In their lightweight and simple forms, they are gaining traction, with demand continuing to grow.
However, if you have been involved in the grass roots development of SaaS or systems for enterprise organizations, you are aware that function apps do have a caveat: Every time you want to customize logic because you have onboarded a new client or a change in the workflow, code must either be redeployed or a new Azure Function pushed out. This form of implementation creates downtime, increases the likelihood of operational risk, and ultimately, delays deployment.
3 WebAssembly (WASM) Advantages for Function Apps
- Security: WASM runs in a sandbox, ensuring memory safety and preventing unauthorized access.
- Flexibility: New logic can be plugged in at runtime without redeployment or downtime.
- Extensibility: Supports custom plugins for SaaS, IoT, compliance and data pipelines.
Now, consider a better model. Instead of redeploying function apps, what if we can just “plug in” new logic and execute it, at runtime, in a safe and secure way? That’s what WebAssembly (WASM) does. If we can put in a WASM runtime inside of a function app, we can load user-defined plugins that execute in a safe sandbox, without re-deploying and bloating codebases. In this article, we’ll examine why this matters, how it works in real-world scenarios, and provide a simple demo of running WASM plugins inside of Function Apps.
The Limitations of Normal Function Apps
Function apps can handle discrete units of work well, whether a webhook, timer or event from a queue, but their limitations emerge when you need flexibility.
Take a multi-tenant SaaS platform. Each tenant will want slightly different business rules. Maybe they’ll want a different way to apply discounts, one tenant adds compliance checks, and another has a custom data pipeline. You will generally have three bad options with standard functions:
- Hardcode everything: have conditionals for each tenant in the same function. This quickly becomes a maintenance challenge.
- Deploy different functions: deploy a new function app instance for every tenant. This does not scale well, both technically and operationally.
- Enable inline scripts: allow users to upload code in the app’s native language. This is reckless since it could break or compromise your application.
None of these are very good options. And in typically fast-moving SaaS or enterprise projects, the cost of redeployment isn’t just technical but organizational. It delays delivery and frustrates customers waiting for just one small change.
This is where WASM provides a better pathing.
What Is WebAssembly (WASM)?
WebAssembly, or WASM, started off in the browser world as a way to run near-native code safely alongside JavaScript. But it has grown far beyond that. WASM is now a lightweight, portable runtime that will execute code compiled from multiple languages: Rust, Go, AssemblyScript, even C# (when using WASI).
What makes WASM so perfectly suited to function apps is the sandboxing model it uses. A WASM module can only do what the host gives explicit permission to do. By default, a WASM module has no access to the file system, network or operating system calls. This isolation and containment makes it safe to execute untrusted or external code inside your function app.
3 Advantages to WebAssembly (WASM)
Security: The Real Differentiator
Allowing plugins from the outside may raise eyebrows: is this safe? This is where WASM truly shines.
- Memory safe: There are no buffer overflows, and no chance of memory leaks escaping into your host.
- Sandboxed: Modules won't touch your file system and can't access your network without your permissions.
- Deterministic: Invocations will be predictable and bounded.
Compared to allowing users to drop unsupported DLLs or run arbitrary scripts, a WASM model is much safer, similar to the difference between allowing guests to use your coffee maker versus handing them the keys to your house.
Architecture Behind the Curtain
The technical configuration is simple: The function app hosts a WASM runtime (like Wasmtime or Wasmer).
When triggered, the runtime will grab the appropriate plugin from storage. The plugin executes inside the sandboxed runtime; inputs and outputs go through clearly delineated interfaces. WASM modules are small enough that cold start times are negligible, and with caching, repetitive calls can only get faster.
Greater Use Case Openness
The discount rule is just one example. WASM plugins offer all kinds of opportunities across size and sorts of use cases:
- IoT: Tenants can define custom transformations on sensor data.
- Compliance: You can drop in regional rule sets without touching the main app.
- Workflow automation: End users can build and share reusable plugins.
- Data pipelines: Custom ETL steps built as isolated WASM modules.
WASM plugins can really help in any scenario you can identify that includes “lots of custom rules.”
The Future of Function Apps and WASM
This is just the beginning of the story. As WASM matures and grows in openness and adoption, I believe that more serverless platforms will make use of WASM for extensibility. Azure Functions seems like a natural fit, though the same model could be applied to AWS Lambda or Google Cloud Functions. Envision a marketplace of plugins where customers could expand the functionality of their serverless apps without deployment touching.
That’s a world where serverless offers not only speed and cost, but also adaptability.
