Key Takeaways
-
WebAssembly, since its inception 5 years ago, has been continuously increasing its range of features, reach and adoption. While originally targeting browsers, WebAssembly is expanding to non-browser environments to fulfill a variety of computational tasks, where sandboxing, portability or performance are essential.
-
In this context, some companies are fully invested in WebAssembly; others are betting increasingly large on WebAssembly; yet some others are observing what use cases WebAssembly will be the best at addressing before making a commitment.
-
Sentry sees great potential in the technology and is already using it internally in the context of its ingestion system. However, further usage is hampered by the limited capabilities of WebAssembly when debugging in production.
-
There are proposal for making the DWARF standard debugging format work with WebAssembly. More work remains to be done, in particular when it comes to tooling support.
InfoQ interviewed Armin Ronacher, head of new product development at Sentry.io, on its perspective about WebAssembly, its potential, and use cases from a Sentry perspective.
Sentry provides self-hosted and cloud-based error monitoring that helps software teams discover, triage, and prioritize errors in real-time. Sentry strives to provide deep context about errors and processes 40+ billion errors per month from a varied range of companies, such as Cloudflare, GitHub, Disney and Microsoft. Sentry software is provided under the MIT License, the Apache-2.0 License and the Business Source License 1.1 (BSL-1.1).
Ronacher is a prolific open source contributor. He created Flask, a widely adopted Python web framework, used by companies like Linkedin and Pinterest.
InfoQ: What is WebAssembly?
Armin Ronacher: WebAssembly is a great technology because it's so practical! At the core, it's just a standardized bytecode format that browsers and other runtimes can execute. In other words, it allows you to run compiled C, C++, Rust, or other code in an environment like a browser.
While WebAssembly is not the first system that does this, it is the first that achieved widespread adoption. It is being supported by all major browser vendors and also found a home in other environments, such as edge computing.
InfoQ: We have seen a number of ports of desktop applications to the web. That includes popular applications such as Google Earth or the AAA game Doom3. Ported applications are originally written in a series of languages including, but not limited to Rust, Go, C, and C++. Tell us more about your use cases of WebAssembly at Sentry.
Ronacher: At Sentry, we're very interested in how it is evolving and where it will be in the future and are running various experiments with it. Since we handle a high volume of events every day we recently ported our main ingestion system to Rust, which handles the first part of the event ingestion. This also performs the removal of personally identifiable information so that it does not end up in event reporting. Because it is written in Rust, it is easy for us to compile to WebAssembly. One of our engineers built a little tool that lets you perform the removal of PII in real-time in the browser. This allows us to experiment with the config without having to write this tool a second time in JavaScript or having to go through a backend service.
InfoQ: What were the key motivators behind your use of WebAssembly? What does WebAssembly perform really well?
Ronacher: We're interested in WebAssembly for two reasons. One is that because a lot of our core infrastructure is now in Rust we can — within reason — cross-compile some code to JavaScript so that users can experiment with some functionality directly in the browser without having to talk to a backend service. The second is that it lets us do the inverse as well. We could take user code and use the WebAssembly runtime to execute it safely as part of our processing pipeline. We are working with a very large volume of data, so talking to external web services is rarely an option. WebAssembly allows us to unlock some customization we previously wouldn't be able to offer.
InfoQ: What use cases for other companies using WebAssembly in production today do you find interesting?
Ronacher: Personally, I'm excited about the type of use cases where it unlocks something that was previously unreasonable or impossible to do without browser plugins or native browser support. For instance, there are projects that perform fairly complex audio processing directly in the browser now. Earlier systems that attempted similar things (Java Plugins, Flash Runtime, Google's NaCL/PNaCL, etc.) really never left the browser environment — but WebAssembly has. For instance, CloudFlare lets users run WebAssembly code directly on their content delivery network (CDN) infrastructure.
InfoQ: WebAssembly is now an official W3C recommendation and the fourth language to run natively in browsers. It is however still a developing standard. What challenges did you meet while using WebAssembly? What are the missing parts?
Ronacher: The main reason we're not adopting WebAssembly entirely at the moment — and also why we don't have native support for WebAssembly on Sentry yet — is because WebAssembly has limited capabilities when debugging in production. For example, source maps, a well-known debug format, is the main debug format for WebAssembly and it cannot support many of the functions required to fix errors quickly. As a simple example, source maps are currently incapable of telling us the original function names, which variables exist in a stack frame, etc. There are attempts at the moment to extend the common DWARF format for Wasm but the tooling support is still quite weak.
[Editor's note: DWARF is a standardized debugging data format used by many compilers and debuggers to support source level debugging.]
InfoQ: What is DWARF and what are the issues related to DWARF with respect to WebAssembly?
Ronacher: DWARF is an open standard for debug information. Historically, it's being used on UNIX platforms (macOS, Linux, BSD and others) to describe debug information of native code (C, C++, Rust, etc.). In the web world — and that, unfortunately, includes WASM — source maps are more common, which are very restrictive and cannot be used to solve nearly enough debug related problems. There are proposals for making DWARF work with WASM, but there is a lot more work to be done to enable it in practice. There is still not enough agreement on how to use DWARF with WASM and WASM also does not have debug IDs yet that would allow us to match WASM files to their DWARF debug files.
InfoQ: What is WASI?
Ronacher: When WebAssembly runs in the browser, it's quite easy to reach from WebAssembly to the rest of the browser JavaScript runtime and call browser APIs. This is, in many cases, already necessary because very little is exposed to WebAssembly itself natively. When WebAssembly is executed in a different, non-browser environment, there is no JavaScript API outside to interface with. WASI fills this gap. WASI exposes a standardized ABI that WebAssembly applications can use to perform functions that require operating support, such as getting the current time, reading or writing files, etc. WASI is to WebAssembly what the operating system syscalls are to a native programmer. However, unlike syscalls, WASI is OS-independent, which is quite exciting.
InfoQ: Solomon Hikes said that if Wasm + WASI existed in 2008, [they] wouldn't have needed to create Docker. Can you explain to our readers the reasoning behind this assertion? Do you foresee Docker being displaced in favor of WebAssembly-based technologies?
Ronacher: I don't know if Docker will actually be replaced by WebAssembly or other technologies considering how much infrastructure now sits on top of it. However, when we look at where Docker came from, WebAssembly looks like a pretty good fit. The idea is to let some code co-exist in an environment where security boundaries are not as strictly enforced as they would be by a real virtual machine. This is by no means a new concept. PHP, for instance, became big as just an Apache plugin and many shared hosting providers let their customers run custom PHP code on it. They were content with the sandbox that PHP provided out of the box for security. WebAssembly extends this sandbox to the core runtime. In theory, applications could be compiled for WASI and a WebAssembly runtime could provide most of the sandboxing. WASI is indeed quite an exciting concept here because it lets you intercept pretty much everything in the runtime. The runtime can in fact become the sandbox for a lot of use cases, and because this runtime is much better defined than many that came before it, it's also going to become possible to run the same code in many different environments. Now imagine the same binary run in the browser as well as on a "serverless" server environment. I think that's where the puck is going!
About the Interviewee
Armin Ronacher is director of engineering at Sentry, an application monitoring and error tracking software company that helps software teams discover, triage, and prioritize errors in real time. He’s the creator of the Flask web framework, and is very emotional about APIs and system architecture.
