This week's news: From Azure to Zed

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:

• Mirantis Container Runtime coming to the Microsoft Azure Marketplace

• The release of OpenStack Zed

• The 2022 State of DevOps report from Google's DevOps Research and Assessment team

• Go's potential change to redefine loop variable semantics

• And other stories on the podcast, including cloud spend trends, Cloudflare's startup fund, questions on SBOM use, and 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: This week, Mirantis Container Runtime released in the Microsoft Azure Marketplace. Specifically, this is a VM image for Windows Server 2019 with Mirantis Container Runtime—formerly Docker Engine Enterprise—baked in and ready to go. If you’re running containers on Azure-based Windows Server instances, this gives you access to features like FIPS-140-2 validation, the Docker CLI, and Docker Swarm that aren’t available with more rudimentary runtimes. The new image includes full support from Mirantis and is pay-as-you-go, so you can launch an instance with a click of a button and know that you have enterprise-grade support.

Nick: Last week saw the release of OpenStack Zed, the 26th semi-annual release of the software, which includes a ton of new features spread of literally dozens of projects, including a new experimental Dashboard called Skyline, the ability to transfer encrypted volumes between projects, and Venus, a new log aggregation and management project targeted at large deployments.

But probably the biggest news about this release is the release process itself. See, if you think that trying to install Kubernetes on your own is difficult, try installing OpenStack.  I mean, Mirantis customers are spoiled because Mirantis OpenStack for Kubernetes makes it pretty easy, but rolling out OpenStack at the scales in which you usually see it is not a fun job, and can take a non-trivial amount of time.  So this 6 month release cycle has been a problem for a lot of companies for a long time.

So now, as we ready the milestone of having gone through an entire alphabet of 6 month releases, the Open Infrastructure Foundation has announced that starting with the next release, wrapping back around to Antelope, every other release will be a SLURP release, short for Skip Level Upgrade Release Process.  Here's what that means.

Currently, if you want to upgrade your OpenStack cloud, you can only move one release at a time.  So if you're on Xena, and you want to upgrade to Zed, you can't just go directly.  Instead you'd have to do an FFU, or fast forward upgrade, where you go Xena to Yoga to Zed.  And if you've gone longer than a year, you'd have to do a longer chain, say, T to U to V to W to X to Y to Z and you can see that it gets ridiculous after a while.

So going forward, every other OpenStack release will be a SLURP release, and you'll be able to skip from one SLURP release to the next.  So A and C will be SLURP releases, so you can go from A directly to C if you want to, or you can just keep going between single releases, so you can go Z to A, or A to B, etc.  To test things out, you will theoretically be able to go from Yoga to Antelope, though they don't guarantee that everything will go smoothly.

Of course you won't be able to move infinitely between SLURP releases, but if you wanted to go from Antelope to, say, the E release, you can fast forward from A to C to E, skipping between SLURP releases rather than having to hit every single one.

Eric: The State of DevOps report from Google’s DevOps Research and Assessment (DORA) team is a reasonably long-running annual report in industry terms, having been released since 2014. This year it surveyed 1,350 IT professionals balanced between giant 10,000+ employee companies and organizations with just a couple dozen people.

It’ll surprise absolutely no one that the researchers took care to emphasize security practices and the software supply chain this year, and they came to some really interesting conclusions that go beyond the usual best practice and toolchain recommendations. Here’s one topline analysis from the Google DORA team:

“One thing we found surprising was that the biggest predictor of an organization's software security practices was cultural, not technical: high-trust, low-blame cultures — as defined by Westrum — focused on performance were significantly more likely to adopt emerging security practices than low trust, high-blame cultures focused on power or rules. Not only that, survey results indicate that teams who focus on establishing these security practices have reduced developer burnout and are more likely to recommend their team to someone else.”

Another interesting finding in the report pertains to the outcomes of certain security practices. The researchers looked for use of standards and controls from the Supply chain Levels for Software Artifacts security framework (which gets shortened to SLSA or “Salsa”). They were a little surprised to find that SLSA usage was a positive predictor for not just security outcomes, but also software delivery performance and overall organizational performance. Additionally, they found “teams that focus on establishing these security practices have reduced developer burnout; teams with low levels of security practices have 1.4x greater odds of having high levels of burnout than teams with high levels of security.”

Eric: The Go team started a fascinating conversation this week with a proposal from Google Distinguished Engineer Russ Cox to redefine for loop variable semantics. 

As it stands today in Go, loop variables—that is, the variables defined in the header of the loop—are defined per-loop rather than per-iteration, which runs against a lot of folks’ intuitions. This is one of those things that’s probably better demonstrated than explained. If you run...

The output will be:

I’ll leave it to the proposal author Russ Cox to break this down:

“This code prints 3, 3, 3, because all the closures print the same v, and at the end of the loop, v is set to 3…

We have talked for a long time about redefining these semantics, to make loop variables per-iteration instead of per-loop...

In the Go 2 transitions document we gave the general rule that language redefinitions like what I just described are not permitted. I believe that is the right general rule, but I have come to also believe that the for loop variable case is strong enough to motivate a one-time exception to that rule. Loop variables being per-loop instead of per-iteration is the only design decision I know of in Go that makes programs incorrect more often than it makes them correct.”

So, this is potentially a really singular change, and so far it’s met with general approval from Go community commenters. Notably, languages like C# have gone through similar semantics changes in the past, and C# team member Jared Parsons chimed in on the Go discussion with support. If you’d like to pitch in with your own thoughts, you can join the conversation on GitHub.

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