Bhupathy works as Senior Technical Lead at Multicoreware, with 8+ years of experience in diverse areas, including Performance Optimization, Custom AI/ML Accelerator Software Stack, Linux, and Cloud Infrastructure.
Introduction:
WebAssembly (often abbreviated as WASM) is a low-level binary format and virtual machine that is designed to be executed by web browsers. It provides a way to run code written in languages other than JavaScript, such as C, C++, Rust, and many others, in a web browser. WebAssembly code is compiled from source code written in these other languages, and can be executed in a sandboxed environment, providing a high degree of security and portability.
History of WASM:
WebAssembly was created as a joint effort between several major browser vendors, including Mozilla, Google, Microsoft, and Apple, with the goal of providing a standardized way to run performance-critical code on the web. It is designed to be fast, compact, and secure, and can be used for a wide variety of applications, including games, scientific simulations, and video and audio processing.
One of the key benefits of WebAssembly is that it provides a way to reuse existing code written in languages other than JavaScript. This allows developers to take advantage of the performance benefits of languages like C and C++ without having to rewrite their code from scratch in JavaScript. Additionally, WebAssembly provides a way to run code in a sandboxed environment, which helps to prevent malicious code from causing harm to a user’s system or data.
Serverless Computing:
Serverless functions, also known as Functions as a Service (FaaS), provide a straightforward means of creating small cloud services. To understand the concept of serverless functions, it is helpful to compare them to traditional servers. A web server software listens for HTTP requests on a socket, parses each request, and then handles the requests. Over the lifetime of a web server, it may handle hundreds of thousands of separate HTTP requests. However, a typical HTTP server also must manage SSL connections, system processes, thread pooling and concurrency, and various other lower-level tasks, all in service of answering HTTP requests.
In contrast, a serverless function is designed to strip away much of the server-side complexity, allowing the developer to focus solely on responding to an HTTP request. There is no need to manage networking, SSL configuration, or request thread pool management. All of these aspects are handled by the platform, and a serverless function starts up, responds to one request, and then shuts down.
This design approach reduces the amount of code that needs to be written and simplifies the operational complexity of running serverless functions. Maintenance tasks such as updating HTTP or SSL libraries are handled by the platform, making error handling, upgrades, and other tasks easier for developers. Given this focus on simplicity, it is no surprise that millions of developers have written at least one serverless function. Amazon reports that they execute 10 trillion serverless functions every month.
Pain Points in Serverless Computing:
Despite the benefits of this programming paradigm, early iterations of serverless functions were plagued by several drawbacks, including slow start times, cumbersome packaging and deployment, and difficult debugging and troubleshooting. These problems stemmed from running serverless functions on top of virtual machines, per-language runtimes, and package managers that were not optimized for this type of computing.
WASM as a Solution
However, it turns out that the solution to these issues was hiding in plain sight – in the browser. By leveraging WebAssembly (Wasm) technology, we can improve the state of serverless functions and make them blazingly fast, ultra-secure, and able to hide server details. By avoiding the need for users to choose the operating system or CPU type, we allow developers to focus on serverless decisions rather than server decisions. Additionally, smaller binaries in well-defined package formats simplify the release process.
WASM’s design makes it well-suited for serverless functions. Its features – including fast startup time, cross-architecture and cross-operating system compatibility, compact binaries, and secure sandbox – align with the desired traits for a serverless functions platform. With a serverless functions platform that runs on Wasm, developers can easily build and deploy a wide variety of applications, including highly responsive HTTP apps, with confidence. This is precisely the goal of the open source Spin framework developed by Fermyon.
Conclusion:
As technologies evolve, their applications often expand beyond their initial scope. Wasm is currently undergoing such a transition, as new uses are discovered beyond the realm of the Web browser. Serverless functions have already proven successful, but to take the technology to the next level, faster and more robust underpinnings are required. Wasm is precisely the technology to meet these needs.