Key Takeaways
- WebAssembly, which became last year a web standard and the fourth language to run natively in browsers, has seen increasing adoption in non-browser environments to fulfill a variety of computational tasks, where sandboxing, portability or performance are essential.
- Various vendors have been building out custom functionality using Web Assembly (and sometimes WASI) as a base. A healthy ecosystem around Wasm could mean easier access to the security and performance characteristics that it provides, such as isolated execution.
- Suborbital seeks to combine the best aspects of Function as a Service (FaaS), mesh networking, and event-driven architecture while striving for security and ease of development.
- Future development (e.g., interface types, host bindings, WebAssembly procedure calls) will make developing with Wasm easier and more accessible and enable a new pattern of development that values modularity, simplicity, and security.
- With code written in arbitrary host languages securely running on any server platform or device, client applications will be able to leverage serverless services for a richer user experience.
Connor Hicks presented at QCon this year the opportunities linked to using Web Assembly outside of the browser. The talk was part of the QCon track Clientside: From WASM to Browser Applications. The talk addressed current and future use cases for server-side WebAssembly that enable richer and more interactive client applications.
InfoQ interviewed Hicks on the current development and potential of WebAssembly and how that connects with the Suborbital serverless framework.
InfoQ: Can you tell our readers about you?
Connor Hicks: Of course! I live in Ottawa, Canada. I’m a Senior Developer at 1Password where I lead the Product Discovery team, which is our Research & Development function. I’ve been at 1Password for 5 years. I have a lot of interest in distributed systems and backend architecture, and I identify primarily as a backend developer. I have a dog named Winnie, and my partner and I are in the process of converting a delivery van into a camper for a cross-country trip next summer.
InfoQ: How did you get acquainted with Wasm?
Hicks: I heard about Wasm years ago through the usual developer Twittersphere, back when it was purely a browser-based technology. I didn’t think much of it back then because I rarely work in the browser, but it piqued my interest again when people started to talk about it in a server-side context.
InfoQ: If we talk about Wasm outside of the browser, we necessarily talk about WASI, the WebAssembly System Interface whose goal is to provide a set of standard APIs that WebAssembly programs can use to interact with their surrounding environment. Just like Wasm, WASI is a work in progress. WASI currently includes APIs covering I/O, networking, time, and more. What can Wasm and WASI do server-side today? What do those technologies bring that is unmatched by the current, more mature server and serverless solutions?
Hicks: They can already do quite a lot! Various vendors have been building out custom functionality using Wasm (and sometimes WASI) as a base. Cloudflare for example has built an ecosystem around their Workers product which enables things like customized caching and even durable state using their V8-based runtime. As it stands today, I think the question isn’t “what can Wasm do that other technologies can’t?”, but more so “what could a Wasm ecosystem enable?” A healthy ecosystem around Wasm could mean easier access to the security and performance characteristics that it provides, such as isolated execution. Wasm is more about democratizing access to a newer, safer set of properties rather than winning over other technologies, in my opinion.
InfoQ: Tell us about Suborbital. How did it originate? What is it and what problems does it solve? Can you give us some use cases?
Hicks: Suborbital originated out of a desire to build a foundation for my own work, which historically had included a lot of repetition and boilerplate. I think every developer knows the annoyance of needing to write the same boilerplate every time they start a new project. After a few months of work, I realized that there was a very specific goal to the project, which was to build a new style of backend development platform that involved composable functions. I developed the idea of combining the best aspects of FaaS, mesh networking, and event-driven architecture to achieve something that values security and ease of development most of all. I call it the SUFA pattern (Simple, Unified, Function-based Applications).
It started with three building blocks. The first is Vektor, which is a Go framework for building API servers. Next comes Hive, the job scheduler, which serves the purpose of handling background tasks, batch jobs, and function execution. Finally, Grav, which I refer to as a “messaging mesh” because it is designed to be decentralized, using your Service Mesh to facilitate communication between nodes in your system.
With those three components built out, I started work on Atmo, which is really the main focus of Suborbital. Atmo is designed to take your functions (written in any number of languages), package them up into something I call a “Runnable Bundle,” and then use them to serve request and event-based traffic. Your application is defined declaratively using something called a “Directive.” The Directive includes a full description of your application, including routes, handlers, responses, and more. Atmo actually runs as a standalone binary, meaning that you only need to write your functions and build your Directive—Atmo handles everything else.
InfoQ: Do Atmo Directives aim at expressing computation flows of arbitrary shape? Can you for instance express retry flows or loop back to an arbitrary step of the flow?
Hicks: Currently no, the focus is squarely on the ability to model API calls. However, that is something I’m planning to add once Atmo is a bit more mature.
InfoQ: You mentioned in your talk the desire to make things simpler again and abstract away some of the complexity inherent to microservices (miscellaneous container runtimes, networking technologies, and more). In that perspective, Atmo Directives are reminiscent of Node-RED (a low-code visual programming framework for event-driven applications) and flow-based programming (a way of describing an application’s behavior as a network of black-boxes). How close are we to a future in which developers draw a distributed process/business logic by visually connecting pre-existing serverless functions and have it bundled and deployed automatically?
Hicks: That’s roughly what I’m aiming for in the (slightly further out) future. Having a community that contributes easy-to-use functions to some kind of repository would be the dream. It would mean that companies wouldn’t need to ship things like API libraries for a dozen languages, they could instead ship Wasm-packaged functions that could be easily slotted into the execution flow. As for how close we are to this awesome future, it’s hard to say how long it will take for something like that to become popular, but I’m hoping that within a year or so Atmo will be able to do just that!
InfoQ: Composable asynchronous functions—that sounds like actors. Actors may however be stateful. Is there a plan for Suborbital to accommodate durable functions and stateful workflows?
Hicks: The actor model is absolutely the basis for Atmo. The focus, for now, is on stateless applications, but I won’t rule out stateful execution in the future. For the current design of Atmo, each new request or event creates a shared piece of state that is updated to include the output of each function in the execution chain. Each subsequent function can then access that state. This is a pattern that I’m actively iterating on to see what is ergonomic in real-life development.
InfoQ: Wasm will add important features such as interface types, host bindings, dynamic linking, and more. WASI will continue to increase the surface of its API. Besides Suborbital, there are ongoing efforts in specific domains (e.g., WebAssembly Procedure Calls, WaSCC). How do you envision the server-side Wasm of tomorrow? What will be possible that isn’t easy or possible today?
Hicks: All of those things are building blocks which will make developing with Wasm easier and more accessible. As it stands today, there is a lot of glue code needed to make things like Atmo and WaSCC possible. waPC is hoping to make this problem better, and I am evaluating it to help replace some of the glue code I needed to write for Atmo. As the standards evolve and more functionality gets baked into the core, building these types of platforms will get easier and everyday use of Wasm will become more ergonomic. I envision Wasm modules as the future de-facto unit of computing for many different types of systems. I don’t believe it will supplant Docker, but I do believe that it will enable a new pattern of development that values modularity, simplicity, and security. Things like Serverless will be made more powerful and simpler, and sharing server and client code will be much easier when your code can run on any platform or device.
InfoQ: Suborbital constituent pieces are alpha and beta. What is the target timeline for the first major version?
Hicks: I am targeting stable releases of Vektor, Hive, and Grav early in 2021, and Atmo to follow mid-year. There are a lot of moving parts, and while they have all shown great promise, I’ve been taking great care to ensure that there is a solid foundation for this new style of backend development.
About the Interviewee
Connor Hicks lives in Ottawa, Canada, and he leads the Product Discovery team at 1Password. I have been fascinated by distributed systems and web service architecture for a long time, which led me to build the Suborbital Development Platform with the goal of enabling developers to build robust web services as easily as possible. I also love woodworking, camping, and my dog!