This week's news: Live from KubeCon!

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news on the Radio Cloud Native podcast.

This week, Eric and Cloud Native & Coffee host John Jainschigg recorded live from KubeCon NA 2022 and discussed:

• Updates for Mirantis Container Cloud and Mirantis Kubernetes Engine

• Why Basecamp/Hey is leaving the cloud

• Wasm microsurvey and Docker integration

• Kyverno policy engine adds Pod Security Admission Support

• And other stories on the podcast, including observations from the show floor, new Kubecost releases, the CNCF's new Istio course, the ko project for containerized Go apps, and much more

You can watch the entire episode below or download the podcast from Apple Podcasts, Spotify, or wherever you get your podcasts. If you'd like to tune into the next show live, follow Mirantis on LinkedIn to receive our announcement of the next broadcast.

Eric: Mirantis announced a big update for Mirantis Container Cloud that enables you to manage Ceph storage nodes seamlessly and consistently through the same single-pane-of-glass UI as all your other Kubernetes infrastructure. When you need more storage, Mirantis Container Cloud makes it easy to expand your capacity by adding additional storage nodes through the UI, or remove or reallocate these storage nodes. And that means in practice it’s a whole lot easier and more consistent to manage clusters running mission-critical workloads supporting millions of users, with petabytes of data storage accessible by Kubernetes clusters.

We also have an update for Mirantis Kubernetes Engine, which now supports Google Cloud Platform, so you can run MKE across all the big three cloud providers, in addition to hosted bare metal with Equinix, bare metal, or VMs. Of course, MKE lets you run Swarm and Kubernetes simultaneously, giving you the flexibility to use both orchestrators side-by-side for both Linux and Windows nodes, so it’s really never been more flexible.

John: David Hansson, of Basecamp, published a stunningly-lucid blog last week called ‘Why We’re Leaving the Cloud’ – which does NOT bury the lede. The reason is pretty simple: in a decade of experience with public clouds and successful applications, these folks have computed that they haven’t actually shed ANY complexity, and are paying a significant premium for the services they need to operate by comparison with what they would pay to gain these services from appropriately-configured private cloud.

Further, Hansson asserts that there are really only two families of use-cases that DO, at this point, genuinely save using public clouds. Either your app is nascent and you don’t have any users yet – so you really do save by not having a datacenter (yet), and don’t bleed money because you’re not yet running at scale. Or you have a profitable app with insanely bursty traffic, so you never know whether you’ll need ten servers running or 100. At that point, public cloud elasticity makes sense.

The bottom line, though, is that for maybe MOST organizations, with scaled-up, diverse operations, many apps, and fairly predictable traffic, you’re likely going to do better via repatriation: build a private cloud or clouds to enjoy the same kinds of services and resilience you get from public. The problem of complexity, meanwhile, is best met by working with a flexible, specialized partner who manages your cloud, lets you focus on apps, and guarantees your ROI.

Eric: The CNCF released what they’re calling a micro-survey on WebAssembly adoption in cloud native projects, talking to just about 100 cloud native developers about their Wasm usage. You can kind of get the vibe of their conclusions from the announcement blog title: “A transformative technology, yes, but time to get serious.” 

The topline result is that 28% of respondents are currently using Wasm in cloud native projects, and an additional 36% say they are planning to do so within the next twelve months. So that’s 64% either using it or planning to do so in the short term, which leaves another 36% saying they’re not using it and have no plans to do so.

Out of those using or planning to use Wasm, 42% are focused on server-side apps and 48% are focused on a mixture of server and client-side – only 18% are working or planning to work exclusively on client-side apps with Wasm. 

The folks turning to Wasm report they’re primarily doing so for language choice and speed in environments where performance might be constrained by context, and we get a little peek at what that means in the responses on target environments for Wasm usage: 54% say they’re targeting edge, and 63% say they’re targeting serverless.

So what about it being time to get serious? The survey suggests that developers still perceive the Wasm ecosystem as immature, with insufficient standards and a lack of consensus tooling, with almost half of respondents identifying both of those as major barriers to adoption. Respondents were exceptionally united in their prescription for a solution: 81% said the industry as a whole needs to build more fully-featured and stable Wasm tools and projects. 

There may be some good news for that 81% - at the Cloud Native Wasm Day satellite event, Docker and the WasmEdge project announced new integrations that will bring support for WasmEdge applications to Docker CLI, Docker Desktop, and Docker Compose. That means you can now build, run, and manage WasmEdge applications exactly the same way you do with containers via Docker. 

According to Docker:

“We see Wasm as a complementary technology to Linux containers where developers can choose which technology they use (or both!) depending on the use case. And as the community explores what’s possible with Wasm, we want to help make Wasm applications easier to develop, build, and run using the experience and tools you know and love.”

So if you’re looking for standardization in the toolchain, this should be pretty welcome news. The Docker+Wasm toolchain is currently available in a Technical Preview build of Docker Desktop—you can get to that from the Docker blog.

John: Kyverno is a policy engine designed for Kubernetes that manages policies as Kubernetes resources. So you don’t need to learn a new and potentially complicated representational language or specialized tools to work with them – use Kyverno to validate, mutate, and generate multiple resources, either manually or as part of a CICD pipeline.

In mid-October they dropped a significant new release, version 1.8 – adding Pod Security Admission – a new validation capability that uses Kubernetes Pod Security Admission libraries to implement Pod Security Standards more flexibly and simply than via conventional methods.

They’ve also been adding software supply chain security and validation capabilities, like the ability to validate encryption signatures on YAML manifests.

Check out the podcast for more of this week's stories.