Can WebAssembly (Wasm) ease the pain of cloud-native development?
This is a contributed piece for Computer Weekly Open Source Insider written in full by Liam Randall in his role as co-creator and maintainer of CNCF wasmCloud and CEO Cosmonic – a company that aims to simplifies application development by giving developers secure, composable and reusable building blocks that scale applications across every device.
Randall writes as follows…
Cloud Native WebAssembly (Wasm) was born of an inconvenient truth: modern application development is frustrating, particularly when building distributed applications.
Despite numerous attempts to improve the experience, complexity is growing, particularly as multi-cloud and edge strategies mature. Ultimately, developers don’t care about the choice of architecture. What they do care about is going from ‘I have an idea’ to running code quickly and everywhere.
Above all, they want to have fun building again.
Managing non-functional requirements (NFRs) has become a major headache – stifling creativity and slowing development velocity to a snail’s pace. NFRs are the attributes and policies that determine the way an app behaves: security and compliance, performance, reliability and more. Given they comprise 85% of most apps, it’s easy to see where developers’ efforts go and why joy is ebbing.
App dev scenario
Today, creating an application goes something like this:
- Create a new project in an approved language (probably copied from some company-blessed template)
- Write your code, making sure to use all the approved or internal libraries to connect to services (databases, queues, secret stores) your company uses
- Create a dockerfile, making sure to pick the right base image and then install all its dependencies (likely copied from another project, along with all existing vulnerabilities)
- Build your docker image
- Choose which Kubernetes objects you need. Deployments, CRDs, sidecars, services, etc.
- Package them using Helm, Skaffold, etc.
- Push your Dockerfile to version control, building and deploying to a dev/QA environment for testing
- Repeat ad nauseam
Added to the time it takes to code NFRs app-by-app, the method has a more serious drawback: applications inherit the vulnerabilities of their imported libraries. Large companies look to standardise application teams, so they provide common templates for tools like Java Spring Boot. Java Spring Boot includes Log4j by default. As vulnerabilities are handled on an application-by-application basis, SBOMs like Log4j bring companies to a standstill and take developers months of manual remediation.
Kubernetes and Istio pull common networking components out of applications but managing Kubernetes has created its own set of problems. Even with the abstractions of a service mesh, applications still need to pay careful attention to the networking NFRs.
It falls far short of its vision to ‘compile once, run anywhere’, right?
Delegated computational intensity
Wasm started life in the browser, designed to speed up code execution by delegating computationally intensive tasks to Wasm functions and re-use existing C libraries. Adobe, for example, uses WebAssembly within its flagship web browser-based products Photoshop, Lightroom and Acrobat.
Randall: Above all, software developers want to have fun building again.
Engineers there are seeing value in Wasm beyond the browser using wasmCloud (a Wasm distribution platform and CNCF Sandbox project). By bringing these open source technologies into their Kubernetes architecture, they’re seeing improvements in performance and efficiency.
The same features that make Wasm good for the browser make Wasm good for compute workloads in the cloud. It abstracts complexity at the application level, allowing portability across diverse CPUs, clouds, browsers, edges and Kubernetes distributions. wasmCloud further abstracts boilerplate code, pulling away complexity up to layer seven – removing all application libraries. The benefits are developers write just their application code, none of the supporting NFRs. By abstracting complexity, developers write the right code, applications are smaller and easier to understand and inherited vulnerabilities are removed.
In wasmCloud (and new platforms like the Cosmonic PaaS, built on wasmCloud), developers start in a sketchpad environment where they connect and iterate on composable, reusable components to create applications capable of running anywhere.
Development now looks dramatically simpler:
- Create a new project in Rust or TinyGo soon to be any language of your choice (more languages are adding support for Wasm every day)
- Write pure-logic code with common abstractions (implementations for key-value stores, message queues, databases etc. picked at runtime)
- Compile to WebAssembly using the language toolchain (usually just the addition of –target wasm or CLI helpers like cosmo build)
- Run your application anywhere you’re running wasmCloud (even locally) or on a hosted service with cosmo launch
- When requirements change, or you want to change where your application runs, just swap out your implementations or cosmo launch on different virtual hosts to fully distribute your application.
Finalisation of WebAssembly’s component model in 2023 will lead to even greater interoperability as developers get to pick and choose applications written in their chosen languages.
Non-functional requirements can be implemented as a component and plugged in at runtime with wasmCloud, so that the development process can be flexible. Think of using components like how you use electrical outlets. You don’t think about how the power gets there but you just know when you plug in it just works.
Ultimately, this saves developers and organisations reputation, time and money.