If you’ve been following anything in the Cloud Native space right now, chances are that you’ve heard of WebAssembly (Wasm). As someone who works at a Wasm company, it should come as no surprise that I think Wasm is the future of software development. But, let’s be honest, you probably aren’t going to just dismiss Kubernetes and go all-in on the first Wasm-related project you find.
At Cosmonic, we’ve always believed it important that Wasm and wasmCloud (the soon-to-be incubating CNCF project we contribute to and help maintain) are compatible with, but not dependent on any pre-existing technology. Guided by that principle, we have long provided integrations with Kubernetes, as most people operating in the cloud native ecosystem are running in or integrated with it. What has been interesting to see is how people are choosing to integrate with it. This post outlines a couple of ways to integrate Wasm with Kubernetes, and it gives a clue as to why we’ve designed our platform to integrate with Kubernetes the way it does. With that in mind, let’s dive in!
This post will outline the reasons why Nomad is an ideal container orchestrator for WebAssembly and wasmCloud, and how we created Netreap to run Cilium in our Nomad clusters alongside the rest of our infrastructure. In my next post, I'll walk you through how to run Cilium on a Nomad node, and how Netreap performs in practice.
At the Pasadena leg of Kubernetes Community Days (co-located with SCaLE 20x), I had the chance to talk to 100 or so Kubernetes enthusiasts, to give my perspective on WebAssembly, through the lens of a Kubernetes veteran.
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:
Subscribe to Cosmonic for occasional communication straight to your inbox.
