We talked to Sean Isom, Engineering Manager at Adobe about WebAssembly, an open standard that allows native C/C++/Rust applications to be reused in web browsers at near native performance. Here’s what he told us.

devmio: Thank you for taking the time out of your busy schedule to talk to us, Sean! Let’s begin with Kubernetes. 90% of Adobe’s container compute is with Kubernetes. Could you tell us why this is and what Kubernetes offers that other similar services don’t?

Sean Isom: Adobe’s Ethos project emerged from a desire to find better ways to ship cloud software. Focusing around containers, we first worked to port an exact replica of the developer's local environment in the cloud. Next, we created a standardized environment in which to run our software – a basic clusterization model. By building a centralized infrastructure platform, we could solve some developer pain and create economies of scale in efficiency, security, and operations. Fast forward eight years and Adobe’s Ethos platform runs more than 90% of Adobe's containers on Kubernetes, powering diverse applications across many different business units.

devmio: The Cloud Native Computing Foundation recently released a case study about using WebAssembly together with Kubernetes. For newcomers, could you please explain what exactly WebAssembly is used for?

Sean Isom: Having multi-tenant clusters has loads of operational benefits (flexibility, security), but efficiently managing resources for arbitrary workloads with different scaling and provisioning characteristics is challenging. A common assumption with containers is that they automatically enable one to run efficiently in the cloud. However, containers still have to map to a fixed-size virtual machine — fine if we’re dealing with small, agile distributed systems that can perfectly bin-pack. But, when mixed with larger, more monolithic systems, overall efficiency can drop.

We started to think: what if there was a more lightweight model that could be almost instantly scaled as traffic scales up, giving more scheduling flexibility than a coarse-grained container?

Wasm allows us to keep the same core C++ code base — compiled to the desktop, mobile, and browser.

I’m reminded of the quote from Docker creator, Solomon Hykes: “If WASM+WASI existed in 2008, we wouldn't have needed to have created Docker. That's how important it is. WebAssembly on the server is the future of computing.”

For the past 5 years, Adobe has invested heavily in WebAssembly (Wasm) to bring native codebases to first-class apps in a web browser. With much work in the cloud native community having been done to bring Wasm to more ‘beyond the browser’ use cases, we began experimenting to see if some of these benefits could be achieved directly in Kubernetes. In early experiments, we’ve found it does.

devmio: What does it mean to take WebAssembly into the backend? Why will this be the future of computing and in what ways?

Sean Isom: Even before Wasm, Adobe was a pioneer of bringing desktop applications to the web, utilizing technologies such as Web Workers, PNaCl, and even transpiling C++ to JavaScript to be able to reuse native codebases in the browser. As Wasm has standardized with features such as threads, and developer tooling for Wasm has improved, we have continued this journey to the web, culminating in our new web-based Photoshop experience. Wasm allows us to keep the same core C++ code base — compiled to the desktop, mobile, and browser.

Simultaneously, we have successfully optimized the use of web services for nearly a decade through improving client application utilization, optimizing autoscaling and bin-packing, and minimizing waste. We have been focusing these efforts on Kubernetes for over three years in our latest iteration of this platform, after DC/OS and raw Mesos. Our focus on making containers more efficient forms the groundwork of the natural next phase in our evolution — seeing if other architectures other than containers can run high-availability, high-scale cloud services.

Why? There’s a recognition that the architecture is changing. As server-side WebAssembly technologies have matured, we’ve grown curious to see how Wasm might be able to live alongside containerized services in Kubernetes to see efficiency and performance benefits without abandoning our existing investments.

devmio: What improvements did you see when you began using wasmCloud?

Sean Isom: We’ve embarked upon a couple of early projects designed to reveal the potential efficiencies of running Kubernetes together with the open-source wasmCloud platform for distributed applications by Cosmonic. Firstly, we experimented with running individual functions in wasmCloud. Whilst an early project we’re already seeing efficiencies.

We began collaborating on taking an existing function that removes the background from images, translating it into Rust, and porting it to wasmCloud. Colin gave a compelling demo, where you can see a) the original version, and b) compiled to Wasm and running as a wasmCloud Actor.

Here, we can spin up an actor instantaneously to service the request, with an extremely low memory footprint versus running a service that needs a level of always-on, baseline resources. Functions can easily be spun off to work on-device or in the cloud. This enables extremely efficient use of cloud resources while promoting code and module reuse across a variety of compute architectures.

This early working model has attracted interest amongst other teams. The focus has now shifted to finding ways to run more complex systems in the same way, in production.

devmio: How does wasmCloud run as a service in Kubernetes clusters? What advantage does this bring, and when would it be used?

Sean Isom: Having seen some success in porting individual functions to run as actors wasmCloud, we then wanted to see if we could take a full microservice, currently running in Kubernetes, and make it run in Wasm. Can we still see the greater efficiency and performance of Wasm without fundamentally changing the architecture of the service or our cloud platform?

We found the most direct path was to run wasmCloud directly in one of our Kubernetes clusters with an existing Rust service. We can strip out native dependencies as capability providers and reuse the Rust code in a wasm32-unknown-unknown build target. That makes porting to wasmCloud very easy. Then we simply need to install wasmCloud within Kubernetes. To follow the process step-by-step, visit the full case study on the CNCF blog.

We’re excited to share more soon. The entire service’s code is ported pending some dependencies that need to work in the Wasm environment. Now that wasmCloud has rolled out support for WASI, we should be able to clear the remaining blockers and get the service running end-to-end. The end goal would be to replace the entire service in production to see what kind of performance and efficiency improvements might emerge (and how that could scale to more services).

A major advantage of WebAssembly on the backend is that it can securely enable high performance and efficiency, while still being compatible with Kubernetes.

devmio: Are there any particular business sectors that you feel would benefit from wasmCloud in particular?

Sean Isom: A major advantage of WebAssembly on the backend is that it can securely enable high performance and efficiency, while still being compatible with Kubernetes. So, in organizations and cases like ours, where there are huge investments in Kubernetes operations, compliance, and automation, Wasm has real potential. We can integrate WebAssembly directly into our existing infrastructure. We can take advantage of new technologies today whilst understanding that the future may look completely different.

devmio: Does wasmCloud or WebAssembly in general come with any downsides or limitations that we should be aware of?

Sean Isom: WebAssembly developer tooling for backend services is still centered around Rust, which can be a challenge when integrating with existing services and codebases. C++ and AssemblyScript are also well-supported but not as relevant for web services, and TinyGo is viable for services using a subset of the Go standard library. There has been a lot of recent work on improving Python and Java support for WebAssembly that I believe will reach MVP in the near-medium term, which will greatly ease the cost of migration for existing web services.

Similarly, support for various system capabilities through WASI and the Wasm Component Model is still ongoing. It sometimes is not possible to work with codebases with complex dependency trees solely in Wasm — many native dependencies must be spun out to their own providers. As standardization work continues on these initiatives over the next year, I expect more core packages to be supported directly in Wasm, reducing the burden of splitting off dependencies on developers.