Microsoft announced the closure of its experimental support for WASI (WebAssembly System Interface) node pools within the Azure Kubernetes Service (AKS). This shift wasn’t entirely unexpected, especially for those closely monitoring the trajectory of WASI on Kubernetes. As a result of this change, users running server-side WASI code on AKS will need to consider migrating to alternative runtimes, which will require some adjustments and planning. While this decision is a notable one, it also opens up the opportunity for better solutions and a clearer roadmap for WebAssembly on AKS.
However, it’s crucial to understand that Microsoft’s move does not signal the end of WASI itself on AKS. WebAssembly and Kubernetes remain highly compatible technologies, and several open-source projects have stepped up to fill the gap, ensuring that WASI workloads can continue running on AKS with minimal disruption. Microsoft’s shift does not force a complete abandonment of WebAssembly, but rather provides a new path forward with different tools and strategies for those utilizing AKS.
For those still relying on WASI node pools in AKS, it’s important to act before May 5, the last day new WASI node pools can be created. While existing WASI workloads can continue, users are encouraged to start planning alternatives for any new development or upgrades. It’s advisable to avoid waiting until Microsoft’s own WASI AKS service is completely phased out, as this will allow for a smoother transition. Microsoft has provided two alternative approaches to ensure that the migration is as seamless as possible for current users.
The root cause behind this transition lies in the reliance on the experimental Krustlet project, which utilized Rust to create WebAssembly-compatible Kubelets for AKS. Despite its early promise, Krustlet was eventually abandoned by its maintainers, leaving AKS without a key dependency. With Krustlet no longer supported, it became clear that Microsoft would need to change its strategy for handling WebAssembly on AKS. Fortunately, AKS’s support for Kubernetes and its standard APIs allow for new options, ensuring continued support for WASI workloads. One notable alternative is SpinKube, which allows users to run WASI functions on AKS without needing to modify the Kubernetes infrastructure. This approach leverages the work of the Fermyon team, known for their contributions to Kubernetes tools, making it a promising option for the future of WASI on AKS.