This week's milestones and new frontiers

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, Nick and Eric discussed:

• Cloud Custodian, the CNCF's newest incubating project

• Ethereum changes to Proof of Stake

• Wasmtime hits 1.0

• And more, including a framework for interplanetary networking

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: The CNCF announced a new incubating project called Cloud Custodian, a governance-as-code tool for automated policy enforcement. “Policy” is a pretty wide umbrella here—Cloud Custodian integrates with your infrastructure and then provides notifications and remediations around security, compliance, cost, and more. The idea is to centralize policy management and enforcement so organizations aren’t either writing bespoke scripts or using a bunch of different tools. 

So, maybe not the most exciting for developers, but if you’re planning infrastructure-as-code, this might be an ingredient to consider for the stew. The announcement blog touts usage by HBO Max, Intuit, and Siemens, and if you are a developer, you can take heart that it’s at least nominally designed to get policy out of your way. The project roadmap points to Kubernetes support this fall.

Nick: So when we talk about cryptocurrency, we talk a lot about how we're burning down the world with all the electricity it uses, and for Bitcoin this is still an issue, but Ethereum a second blockchain that is used less for financial speculation and more for actually doing things like transferring assets and making smart contracts (OK, yes, and making money), well Ethereum has moved from Proof of Work to Proof of Stake.

So...what does that mean exactly?

Well, without getting into a whole treatise on blockchain and how it works, the basic idea is that you have a string of cryptographically verified blocks, and every transaction on that chain is verified by the fact that everyone agrees that that chain is accurate.

The big question is how you come to that agreement, or consensus.

Proof of Work, which is what Bitcoin uses, and what most cryptocurrencies used starting out, is where you have miners who verify blocks by finding the right hash by trial and error, because of course that's how cryptography works. The longer the chain, the harder it gets, and the more energy it takes,  And miners are incentivized to do this because if they do manage to solve a block before anyone else, they get a coin.  And of course that can be worth tens of thousands of dollars.

But in Proof of Stake, which is what a lot of more energy-conscious cryptocurrencies, now including Ethereum, have been using, a validator is chosen at random, from those who have pledged at least a certain amount of the currency -- in this case, 32 ETH, or about $48,000  into the system - and they get a portion of the fees paid by the person trying to make a transaction, known in this case as Gas Fees

So this means a few really important things. First, remember, Proof of Work requires potentially thousands of attempts to solve a block, but Proof of Stake involves simply verifying the block, which is one simple transaction.

So Proof of Stake uses 99.95% less power than Proof of Work, but there's also one more important thing.

Proof of Work requires specialized hardware.  Remember the run on ASICs and other GPUs for the last couple of years.  You couldn't even get a gaming PC because the Bitcoin miners had them all. 

But now, with Proof of Stake, that's no longer the case.  So as long as you have the appropriate amount of ETH you can participate even on a moderately sized VM.  So now we're in a situation where companies and banks and other organizations can use Ethereum for Smart Contracts.

And these Smart Contracts are really important. We've also got news that SWIFT, the international banking clearinghouse, is looking at using them to help communicate events at public companies, such as dividends, bankruptcies, acquisitions, and so on. So it's not like they're putting their financial transactions on a blockchain, but they are working with Symbiont’s proprietary technology platform, Assembly, to find a way to reliably and quickly pass on this information without all the confusion of 162 middle-men and different communication standards.

Eric: The Bytecode Alliance announced yesterday that Wasmtime has reached 1.0 and production-readiness. Wasmtime is a WebAssembly runtime, and this is exciting news in part because it gives me an excuse to dig in and talk about WebAssembly.

Before we talk about Wasmtime, we should explain WebAssembly, also known as Wasm.

So, WebAssembly is an assembly language. Just for a little CompSci 101 review, you’ve got your human-friendly high level languages, your JavaScript/Python/PHP/Java/what-have-you, and then down closer to the machine you’ve got your assembly languages. WebAssembly is really exactly what it says on the tin—it’s an assembly language for applications that live on the web. 

WebAssembly is often framed as a fourth language of the web, and that’s true: It’s maintained as a web standard by W3C and it’s been embraced by all the major browsers. But as much as that sounds like a big deal, I think it *still* kind of underplays the significance here, because WebAssembly is filling a totally unoccupied niche. With HTML and CSS you’ve got a markup and stylesheet language respectively, about as far toward the “high-level” end of the scale as you can get. JavaScript is an incredibly robust language and can achieve some really incredible speed, but at the end of the day it’s a pretty quintessential high-level language. So WebAssembly is bringing something totally new to the table—a standard for writing code that’s much closer to the machine. 

So here’s where things get even more interesting: Wasm is intended to be portable, and it’s meant to provide a foundation for compiling code in high-level languages like Rust or C++. All the different browsers have their own WebAssembly runtimes, and they’re standards-compliant and run the same Wasm code. Now you can have a portable Wasm sandbox that runs your choice of high-level language in the browser. 

That’s starting to sound a little bit like a container. But right now we’re still in browser world—we’re running Wasm modules in Chrome or Firefox or whatever. 

And that’s where Wasmtime comes in. This is a runtime for WebAssembly code that sits outside the browser. The same way Node.js said hey, we can use JavaScript outside the browser for all kinds of server-side purposes, Wasmtime lets you use WebAssembly in other contexts. That opens up some really interesting possibilities, especially from a cloud native point of view. Wasm modules can serve as vehicles for microservices, for example. According to the Wasmtime maintainers:

So, just to do the easy math for you there, that’s one-one-thousandth the startup time. 

Another interesting use case is portable clients. The same way server-side JavaScript opened up possibilities like Electron for cross-platform client development, server-side Wasm provides a foundation for portable client development, and we’re already starting to see it—the announcement blog cited BBC iPlayer as an app that has recently started using Wasmtime.

So with the runtime hitting 1.0, this is definitely a space to watch.

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