 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The WebAssembly System Interface (WASI) Subgroup recently reached a significant milestone by voting to launch WASI 0.2, also known as WASI Preview 2. This exciting new WASI standard is based on the Wasm component model, allowing application developers to build software like LEGO bricks, where different components can be easily connected to create larger and more complex applications. This approach makes it simpler to write, reuse and maintain code, while ensuring that the final product is secure, fast and compatible across different devices and systems.
WebAssembly was originally developed with the browser in mind so people could run performance-critical code or heavy workloads like image-editing programs and video games in the browser. Concurrently, there was considerable discussion about its potential outside of browsers. Node.js was successful in doing this with JavaScript, and the developer community had similar aspirations for WebAssembly.
But this desire was fraught with complexity. WebAssembly depended heavily on running in web browsers and lacked direct access to system resources and APIs outside of the browser environment. There were also concerns around sandboxing and security, which were crucial considerations in the context of browser execution, with sandboxing ensuring that code executed within the browser couldn’t access sensitive system resources or interfere with other browser processes.
However, despite these initial limitations, the vision to extend WebAssembly beyond the browser environment prevailed. As developers and stakeholders began to recognize its potential for secure, cross-platform application development, they worked to broaden its scope. This led to the development of WASI, which aimed to provide a standardized interface for executing WebAssembly code in non-browser environments such as servers, command-line tools and embedded systems.
The introduction of WASI Preview 1 in 2019 included features aimed at helping WebAssembly interact with the outside world such as the filesystem and the command-line interface. WASI Preview 1 resembles a super-portable subset of POSIX, the Portable Operating System Interface, which left open the question of whether to go the rest of the way toward POSIX, following a well-trodden path that we knew would lead to containers, or whether WASI should forge a new trail toward something that could be fundamentally lighterweight, faster to start, more secure and more resistant to supply chain attacks.
After spending some time working in the POSIX direction with Preview 1 and developing a shared vision of the future, we decided to embark on the second path, forging a new trail but also creating a bunch of new questions.
Once we decided to venture off the well-trodden POSIX path, we needed to find something new to take the place of POSIX-style executables and shared objects, which are the primary units of code in a traditional POSIX system upon which applications are built. After distilling a motivating set of goals and use cases, we decided on a high-level design for a new unit of code called a “component” that would be built on top of and contain WebAssembly modules.
So what is the difference between a module and a component? Modules, which are already fully standardized and supported in browsers, contain very low-level code that tries to be as close to the CPU as possible (while ensuring safety and portability).
Components bring the magic by acting as a wrapper around the module and knowing how to interact with other components no matter which language they are written in. Components also help resolve a number of security issues by providing a structured way for modules to communicate and interact with each other without sharing low-level memory, kind of like traditional POSIX processes. This helps reduce the risk of unauthorized access or malicious behavior, as well as helps to mitigate the risk of vulnerabilities spreading across the system.
The developer community is celebrating the launch of WASI 0.2 as it marks an official stabilization point for both the Component Model and a collection of WASI APIs, and establishes a robust and versatile foundation for WebAssembly outside the browser. The launch is just the beginning and there is still a lot of work ahead, but it provides a line of sight toward completely modular apps and new possibilities for composability and compatibility.
WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal.
The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.
As WASI continues to evolve, there are exciting prospects on the horizon. The roadmap for future releases includes plans for incremental updates, feature enhancements and support for composable concurrency. The goal is to create a robust ecosystem that can accommodate diverse use cases and programming languages, including Rust, C#, JavaScript, Python, C++, Kotlin and Go.
The principles of composability and compatibility will guide the transition from WASI 0.2 to future versions. With the flexibility of the component model, WASI aims to facilitate seamless upgrades and interoperability between different versions. This iterative approach ensures that WASI remains adaptable to emerging technologies and evolving developer needs.
WASI 0.2 symbolizes the culmination of years of collaborative effort and innovation, paving the way for a new era of cross-platform development and deployment.
As we look to the future, the journey of WASI continues, driven by the collective vision of a vibrant and diverse developer community. With each release, WASI brings us closer to a world where code portability, security and interoperability are not just ideals but fundamental principles of software development.
To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon Europe in Paris, from March 19-22.
