From the beginning of our days developing wasmCloud, we took a stance to be compatible with today's technology without being dependent on it. So, wasmCloud needed to be able to:
- Run inside or outside of a container
- Run inside of Kubernetes or another orchestrator and run without it
- Run on Linux, but also support Mac and Windows (and not just WSL)
We've embraced this ideology with Cosmonic as well, most recently with Super Constellations that can connect any infrastructure into your Cosmonic network. Cosmonic doesn't run Kubernetes in our platform, but a Cosmonic constellation can be easily extended into any existing Kubernetes installation. The wasmCloud application runtime itself simply runs as a few OS processes, and thanks to the portability of WebAssembly, application components run the same regardless of the underlying platform. The beauty of running wasmCloud in a container on Kubernetes is just that you run wasmCloud; the fundamentals of the platform don't change.
If you're interested in how we built our PaaS on HashiCorp Nomad and wasmCloud, check out our recent talks at Hashiconf Distributed Flexibility: Nomad and Vault in a Post-Kubernetes World and Who Knew Dogfood Could Taste This Good? at KubeCon + CloudNativeCon NA 2022.
One of the biggest questions around WebAssembly revolves around its ability to replace containers, Kubernetes, or both. The reality is that these technologies are proven, integrated into many platforms, and fantastic for their specialized use cases. WebAssembly is not built to encompass a Linux kernel, nor is it built to be a platform for orchestrating containerized applications. Rather than being a case of 'either or', developers are starting to realize Kubernetes and Wasm can work better together. Teams and enterprises with significant investments into a specific infrastructure or platform, be it cloud, orchestrator, or data center, don't need to pivot to adopt Wasm.
Our long-time friends and collaborators over at Adobe, Sean Isom and Colin Murphy, just published this blog outlining how they're seeing the benefits of bringing Wasm to their Kubernetes environment via wasmCloud. For Adobe, this makes a lot of sense: they have a significant investment in Kubernetes (90% of its container compute) and re-engineering that would take much more effort, money, and time. Instead, their engineering teams can rethink use cases that are better implemented in Wasm and take advantage of the strengths of both platforms. The team expects to see major performance improvements by combining wasmCloud with Kubernetes… find out more about their use cases from their post on the CNCF blog and try them out for yourself.
We're convinced that WebAssembly will change the way that people write server-side software, especially distributed systems. The path to adopting this technology will be different for everyone, and it's just as important for teams to be able to use their existing infrastructure as it is to not require new tooling. You can start using WebAssembly now without needing to learn about containers or Kubernetes, or you can easily build on top of those technologies. Compatible with, but not dependent upon.
We're excited to see what comes next and look forward to working with Colin, Sean, and all of you to bring Wasm to ever more use cases. On our end, we maintain a wasmCloud Helm chart so that developers can easily run inside a Kubernetes environment, and we've open sourced our kubernetes-applier for automatically creating service endpoints for wasmCloud HTTP servers. If you're interested in trying this out, sign up for our free developer preview then check out our user guide for how to extend Cosmonic to any infrastructure. For questions, problems, or general feedback, please join us on Discord.