Ambassador post by Liam Randall, CNCF Ambassador and CEO, Cosmonic
We recently had the opportunity to reflect on the state of platform engineering within large companies—and the role WebAssembly has to play in the discipline’s future. In this post, we’ll take a look at the cost and complexity challenges faced by teams building and running applications at scale. Then, we’ll consider the role of WebAssembly—and platforms like incubating Cloud Native Foundation (CNCF) wasmCloud—in overcoming these obstacles.
The pitfalls of modern platform engineering
Platform engineering as a practice really began during the “container era” of compute. We split archaic systems into manageable microservices, packaged those microservices into containers, then orchestrated those containers with Kubernetes.
This brought infrastructure and platform teams closer together. Infrastructure teams became part of the same team that provisioned common application services for developers to build with—everything from Secrets management to authentication and authorization. Without a doubt, containers have improved engineering for the better, but they’ve also brought along some big problems.
💡 For a more in-depth analysis of the challenges facing platform engineering teams Bailey Hayes’s recent Innovation Day keynote is unmissable.
The high price of application build-run-maintain
Today, it is simply too expensive to build, run, and maintain applications. This starts with the choice of language, and the “golden template” we use for all our different enterprise applications. We are tied into specific clients and frameworks that are built for a specific language. All of this means we have to build and maintain applications on an app-by-app basis.
When platform engineers need to update a given platform, they need their users—application developers—to update dependencies for every application. Because most applications are composed largely of open source dependencies, they inherit the cost of maintaining these to prevent vulnerabilities. Engineers churn on a hamster wheel of application maintenance which is expensive and unproductive.
Containers can’t solve the hamster wheel. Moreover, containerization runs up against some significant limits in portability. We have to build differentiated containers for diverse architectures. Even at their leanest, Kubernetes and containers are too unwieldy to run on sensors, on IoT devices, and in many other edge environments.
So how can we make applications that are truly portable? While we’re at it, can we solve the hamster wheel and language silo problems?
The answer lies in portable, interoperable WebAssembly components. We’re entering a new era of componentization where our distributed units of compute are WebAssembly components—orchestrated by wasmCloud.
Wasm vs Containers
It’s important to mention, wasmCloud loves Kubernetes—Wasm runs really well alongside containers. The wasmcloud-operator and Helm charts make deploying Wasm on Kubernetes pretty simple.
💡 For an example of a large organization bringing Wasm to its Kubernetes estate, Adobe’s use case is a great starting point.
Having said that, Kubernetes is designed for infrastructure orchestration, not application management. wasmCloud is designed for application orchestration at-scale, and it can handle that job either standalone or on a Kubernetes cluster.
Think of WebAssembly as a tiny VM. A Wasm application is compiled with components into a highly efficient binary format which is smaller and more lightweight than traditional container images. This reduced size minimizes memory and storage requirements, allowing more workloads to fit into the same amount of space. Containers are much larger—ranging from MBs to GBs—where a componentized WebAssembly application ranges from KBs to MBs.
Wasm components themselves are sandboxed, stateless, and secure by-default because they are incapable of interacting with an operating system on their own. With containers, there are a host of processes, best practices, and tools required to achieve the right level of security and isolation. Containers are an intrinsically safe way to sandbox and isolate arbitrary user code.
While containers enhance the portability of applications, those images are still bound to specific CPU architectures. With WebAssembly components, the .wasm binary is the same for any environment, as long as that environment has a WebAssembly runtime. Wasm’s portability allows workloads to run across heterogeneous environments, such as cloud, edge, or even resource-constrained devices.
Container cold-starts take seconds, whereas WebAssembly components start in less than a millisecond. The latency of a user’s request is typically about 200ms, which means containers must be running at all times, ready to service requests even when they’re not needed.
We’ll soon see new types of architectures evolve that capitalize on the size and speed of components. Why make a network request to somewhere else when you run that compute locally, on a user’s device?
This all sounds great. But what if you’ve spent years putting Kubernetes at the center of your universe—if containers work well enough, does adopting Wasm equal another heavy lift into the unknown? To answer that, we need to explore how components work.
Components…everywhere!
We often pack the whole world into containers, with Wasm components we get down to the application’s core logic. Packaged as OCI artifacts, components radically simplify the way that developers build applications. We compose applications with standard, reusable building blocks (components) that only contain the logic we need and that are compiled at runtime.
That’s huge. We can reuse our components—rather than rewriting them—and they only contain the code required. By eliminating boilerplate code (the stuff we import in libraries) vulnerabilities are completely eliminated. When thinking about the time spent identifying, reporting, and remediating vulnerabilities, this is transformational.
Components build on top of each other, just like Lego blocks. They run anywhere components are supported and, of course, because they’re tiny, we can run componentized applications in resource-constrained environments at network edges. As we’ll see later manufacturing and IoT is emerging as a clear use case for wasmCloud.
💡 The Components Starter Guide is a fantastic resource for those at the start of their journey with components.
Most importantly, components are interoperable and polyglot. First principles dictate that we use applications written in many different languages, all of which must be supported. Components communicate over a common set of shared, standardized interfaces—WASI—bound together with Wasm Interface Types (WIT). One might be written in Go, another in Rust, and another in JavaScript, but they can all communicate with one another over these shared APIs.
💡 Check out Alex Creighton’s documentation which perfectly explains the ways in which the WIT IDL supports the WebAssembly Component Model.
Teams use their favorite libraries in their favorite languages, and once they compile the code to a Wasm component, other components can make use of the functions they expose—regardless of the language and libraries used to write those components.
💡 The Bytecode Alliance also has extensive resources on the WebAssembly Component Model. And check out the WIT cheat sheet.
Composing in wasmCloud
An incubating, open source CNCF project, wasmCloud is designed to bring the WebAssembly Component Model to life in real-world use cases. Components are the portable unit of code, and wasmCloud orchestrates deployments across distributed environments. Like Kubernetes is the chosen orchestration platform for containers, wasmCloud is cloud-native application orchestration, at-scale.
WebAssembly eliminates the rinse-and-repeat, app-by-app maintenance cycle common in most organizations. wasmCloud allows teams to create one lean set of core applications, built on common standards, and portable to any location.
The architecture of wasmCloud makes it naturally suited to hybrid clouds and multi-tenant environments, with automatic failover and load balancing built in. wasmCloud can stand alone or run on Kubernetes with the wasmcloud-operator.. Moreover, wasmCloud is designed to integrate with existing cloud native tooling and standards such as OpenTelementry and Open Policy Agent.
In wasmCloud, Wasm applications use open standards and common interfaces for platform capabilities. These can be swapped runtime, allowing us to switch vendors or do maintenance upgrades on-the-fly. Because these are high-level APIs, they’re vendor-agnostic which means teams can use their own tooling.
💡 Take a look at the growing set of capability providers to see how wasmCloud integrates with common cloud native tools.
wasmCloud also allows engineers to write their own custom capabilities and interfaces—completely essential given every organization’s use cases and infrastructure are different.
Industrial adoption
We’re seeing WebAssembly being adopted in a wide variety of use cases in banking, manufacturing, telecommunications, digital services, gaming, and more. In every case, this idea of being able to build one set of applications, capable of running everywhere is what engineers are asking for.
Manufacturing and IoT use cases are proliferating because orchestrators like wasmCloud make it possible to put compute power on devices and in production lines. A great example is industrial analytics company MachineMetrics: deploying wasmCloud on factory machinery to put real-time analytics on expensive machinery and improve performance and longevity.
Adobe has been a long-time user of wasmCloud. They first proved the value of bringing wasmCloud to its Kubernetes infrastructure to improve the efficiency of microservices running in Kubernetes. Lean and lightweight, wasmCloud can be almost instantly scaled as traffic scales up, giving more scheduling flexibility than a coarse-grained container. Now, the use cases for Wasm are growing at Adobe.
Adoption in telecoms is growing. Orange is working with wasmCloud to improve service delivery on customer handsets. Orange is also part of a wider group which includes Vodafone, Etisalat and nbnco who have proved the potential value of replacing Kubernetes with Wasm in managing the TM Forum’s estate of open APIs. The WebAssembly Canvas project is now in Phase II which will look at the value of bringing wasmCloud together with Kubernetes.
Akamai’s recent presentation at wasmCloud Innovation Day gave us an insight into how platforms like wasmCloud can extend compute power to the edge in even more advanced use cases. And our celestial-terrestrial mesh demo shows how space agencies could put Wasm to use in super-distributed, multi-tenant use cases.
Finally, it was incredible to see engineers from global financial services company American Express, on stage at WasmCon, showing how they’re bringing Wasm, and wasmCloud, to their architecture to elevate serverless platforms with Wasm components.
Will Wasm replace containers?
Like in past epochs of computing, VM’s did not disappear with the advent of containers, just as containers will not be completely replaced by Wasm. Stateful, long-running compute and appliances like databases are unlikely to be replaced with Wasm. This evolution in technology will not occur overnight and so Wasm apps will continue to run alongside the thousands of apps already running in containers and on Kubernetes.
Take a look at our documentation and click on Quickstart for a tour of wasmCloud, its features and functionality.
Don’t forget, the wasmCloud community meets every week on Wednesday at 1pm EST. You can add the meeting to your calendar, or join us on YouTube. Oh, and come join the discussion on Slack!