ADAM GLICK: Hi, and welcome to the Kubernetes Podcast from Google. I'm Adam Glick.

CRAIG BOX: And I'm Craig Box.

[MUSIC PLAYING]

What was your game of the week this week, Adam?

ADAM GLICK: [CHUCKLING] You know me too well, Craig. I was tinkering around with one of the two main franchises of tower defense games on mobile. And the one I've been playing is called Bloons. And Bloons 6 had a big update this week that allows for co-op play.

CRAIG BOX: Aha.

ADAM GLICK: So it was nice to be able to actually not only play one of these tower defense games-- this one, you're monkeys popping balloons-- but you get to do it with up to three other people. And that was a really interesting twist on tower defense. So been enjoying that one. I remember you were playing Day of the Tentacle a little while ago?

CRAIG BOX: I was and it's a good remaster. I, unfortunately, remembered all the solutions. So I wasn't able to go through with fresh eyes, but fun to play through again. But a game I didn't play at the time was one of the subsequent games from LucasArts, Full Throttle. And in my purchasing for all of £3 each on Good Old Games, I was able to buy Full Throttle, Day of the Tentacle, and Grim Fandango.

So I completed Full Throttle over the weekend, nice, short game. And I understand that you also have Grim Fandango in the queue to play. So perhaps we might have a little co-op adventure gaming session there.

ADAM GLICK: Indeed. Let's see if we can make it through that one.

CRAIG BOX: What else is happening around Seattle?

ADAM GLICK: Well, we had the 4th, obviously. And I watched the neighbor's cats go sprinting off for cover as the fireworks were on display here. That often can spook people's animals and such. How about you?

CRAIG BOX: We didn't have any fireworks, but we do have a lot of cats around our neighborhood. We go for a walk in the evening along a little alleyway that runs near our house, and there's a couple of cats that live-- we thought-- sort of opposite each other. There's one who's always very friendly and loves to see us. And recently, there's been another cat that basically sits on the fence opposite this house and stares down at the first cat.

And then we met some people the other day who actually tell me that those two cats are brother and sister. And I would not have expected that. They look like for all the world that they were staring daggers at each other and didn't like to interact, but--

ADAM GLICK: [LAUGHING] Maybe that's because they're brother and sister.

CRAIG BOX: Perhaps. But there was a third cat who we think lives a little bit further down the lane, and when all three of them came together, there was a little bit of hissing and running off in the other direction, which would be a bit similar to fireworks, but--

ADAM GLICK: Should we get to the news?

CRAIG BOX: Let's get to the news.

[MUSIC PLAYING]

CRAIG BOX: Kiali 1.0 is out. From its humble beginnings as a service graph for the Istio service mesh over a year ago, Kiali has grown into a full featured observability interface for Istio and has been the default visualization add-on since Istio 1.1. It handles topology, service health, metrics, and tracing, as well as allowing editing and validation of configuration.

Kiali is primarily developed by Red Hat with a team of contributors from all around the world.

ADAM GLICK: If you're using Docker files to build your containers, you might be able to put them on a diet. Docker engineer Tibor Vass has posted some best practices on writing your Docker file. You can learn how to reorder the lines of your Docker file to improve the engine's ability to cache results for faster build times. You can also learn where to put the ampersands to cut out unneeded files from your image, as well as how to work your way up to a multi-stage build for improving reproducibility and the smallest image sizes.

CRAIG BOX: Cockroach Labs SRE and former Googler Josh Imhoff has posted explaining why they chose to run their managed CockroachDB offering on top of Kubernetes. The post contrasts the benefits of Kubernetes orchestration and the efficiency of bin packing with the costs and complexity of management.

Unsurprisingly for an ex-Googler, the article draws many comparisons to Borg and makes the case that even for a very small organization, the benefits of using Kubernetes is substantial and thus worth the costs.

ADAM GLICK: If you're thinking about running an open source database and you're not in the company that wrote it, Google Cloud Solution architect Benjamin Good has posted an article this week talking about the pros and cons of end users running databases on Kubernetes. He provides a simple flowchart for deciphering if you're better off running your own install of the database on VMs, in Kubernetes, or just using a managed service for the database.

CRAIG BOX: Banzai Cloud, our guest in episode 59, has now given a name to their hosted Istio service. It is called Backyards, so named for a surf spot in Oahu, Hawaii. Backyards provides automation for Istio set up and operation across multiple clusters. And in the new post on the topic, they show a nice animated GIF of Backyards and pipelines working across GCP and other environments.

The name was announced sometime after the product, which makes us suspect that Janos had to go surf there in order to approve it.

ADAM GLICK: The official transparency report and event summary for KubeCon EU has been released. Highlights include an 84% increase in attendance, tipping the scales 7,700 people from 93 countries and six continents. Kubernetes, Prometheus, and Helm topped the interest charts for CNCF projects, while learning and networking were the top reasons for attendance.

CRAIG BOX: And that's the news.

[MUSIC PLAYING]

CRAIG BOX: Jeremy Rickard is a senior software engineer with Microsoft Azure working on the CNAB spec Duffle and Porter. Ralph Squillace is a principal PM focused on the open source developer user experience for Azure, working on CNAB and other open source project like Helm, Draft, and Brigade. Welcome to the show.

JEREMY RICKARD: Thanks.

RALPH SQUILLACE: Thank you.

JEREMY RICKARD: Happy to be here.

ADAM GLICK: You work on the Cloud Native Application Bundle, or CNAB, as it's more commonly referred to. How would you describe CNAB to a Kubernetes user?

JEREMY RICKARD: Cloud Native Application Bundles you can think of as a way to take the things you might use with Kubernetes but also the things you might use in terms of cloud infrastructure, maybe not even using Kubernetes at all, but taking those things and packaging them together in a way that you can share and distribute these things but also have a good idea about what credentials and parameters are required and specified in a standard way along with a good view of what is actually going to be installed.

So Docker containers have a digest associated with them. So if you're going to pull a container down, you can get the SHA for that and know exactly that you're going to install the thing that you think you're going to install. CNAB is trying to do the same thing for the broader application definition, so not just the things that might run on your cluster, could be the other things, like manifests for creating ARM resources or CloudFormation for Amazon, putting all those things together into a signable, discrete unit that has a manifest associated with it.

RALPH SQUILLACE: Everything Jeremy says is absolutely correct. But at the same time, there's another way to frame the discussion about what it is and what it can do. It's a container that has a manifest that can install anything on any target runtime with any deployment technology as well.

CRAIG BOX: That sounds narrow in scope.

RALPH SQUILLACE: Yeah, very narrow.

ADAM GLICK: Like when you say, any deployment technology.

RALPH SQUILLACE: So Terraform Cloud Formation templates, Ansible, bash scripts, literally anything that deploys something in the world that we live in today, most of which is extremely heterogeneous. It's really nice if you're a company that can focus on one deployment technology. Most people are a mix and match, a number of things that have been there for a while, and brand new things, so yeah.

CRAIG BOX: Do you guys remember RightScale and Scalr and those kind of-- in the early days of the cloud, there was the idea that you could just deploy your thing to this and it would figure out the back-ends. And I don't see a lot of people using those technologies today because everything underneath was different. And you actually have to either accept the lowest common denominator of what you're going to deploy, or you need to use annotations or overrides or something for different back-ends.

JEREMY RICKARD: Yeah.

CRAIG BOX: So let's start with-- how does CNAB not suffer from that problem?

JEREMY RICKARD: So CNAB doesn't suffer from that problem because it's not specifying any of that. It's really specifying three things. One is the manifest that defines the things you're going to install. The second is the installer piece. So the spec defines a couple of things. One of them is that bundle and what the format looks like. The other one is the invocation image, and you can kind of think of that as the installer.

And that's really where the spec ends. And how that bundle is going to do the things that it's going to do really lives inside of that invocation image. You can kind of think of it as like the MSI for the cloud. Chris Crone from Docker did an intro to CNAB. And it was interesting at the end because people kept asking questions-- can I use cloud conformation with that? And the answer is yes. Can I use that with Kubernetes? And the answer is yes.

Because you, as the person authoring the bundle, are responsible for putting the things into the invocation image that are going to do the things that it's going to do. The contract between that invocation image and the runtime tooling that's going to use it is really constrained to here are the credentials that are necessary, here are the parameters that are necessary, and here are all the images that are going to get run eventually.

RALPH SQUILLACE: And just really quickly, of all the images that get run, eventually is the sort of the normal case for Kubernetes, right? But it really says, here are all the things that are going to get deployed. And those things will be often a bunch of containers in Kubernetes, but often any number of other things, maybe a DNS somewhere or CloudFlare-- CDM kind of approach or something like that could be involved as well.

JEREMY RICKARD: Yup. So one of the demos Chris did in his intro talk that I thought was good was installing OpenFaaS to his local Docker machine and then using the bundle to also install the function itself. So when you're authoring a bundle, if you exclude any of the tooling, you're first going to write a Docker file that will build the invocation image.

So in that case, he had to add the Docker CLI so that he could use Docker Compose to stand up the stack that was going to have all of the OpenFaaS services associated with it and then also the logic necessary to deploy that function on to OpenFaaS. So that stuff gets baked into the invocation image.

You build that invocation image, and you end up with a digested, immutable container. And then you write the bundle descriptor for that that references that invocation image and then defines what parameters are available.

So in his case, he wanted to be able to show what images were going to run. So that was a flag that he passed. He needed basic auth credentials to identify how you access OpenFaaS once it's installed. So those are the things that get baked into the bundle. The bundle is that descriptor plus that invocation image.

So it doesn't suffer from that lowest common denominator problem because it's not trying to specify anything other than that contract of going into the invocation image. And the invocation image has all of the very specific things that are necessary to do that thing. I worked in Service Catalog for a while before coming to this project-- and definitely has that problem where you're trying to define an interface for provisioning a thing, and it's very different from cloud to cloud. And when you end up trying to make it fit, you get a really bad abstraction.

And I think that CNAB's trying to not tackle that problem by only focusing on the shell of the things that are going to run.

ADAM GLICK: You mentioned two things that was deployed in that example. So you were installing OpenFaaS on Docker Compose and then you're installing a function on top of OpenFaaS.

JEREMY RICKARD: Yep.

CRAIG BOX: Is that two invocation images, or is it one?

JEREMY RICKARD: It's one invocation image. You could do multiple invocation images if you wanted to, chain different CNABs together. We're working on some notion of dependencies right now. But as an example, we've been building a tool that we're trying to make it much easier to author these bundles.

And we do it in such a way that we have little pieces of functionality that we call mixins that we can put together and order and say, first go to Azure and create a Cosmos DB-- which is like our crazy database that can do Mongo DB-- and then install an application onto Kubernetes using Helm. But between those steps, we have to take some information from creating that Azure instance and pass it down.

So the things that are going to happen, generally, you're going to be contained within that single invocation image. And you know that from installation 1 installation 2, you're going to get the exact same thing because it's going to be a digested reference. It's going to be contained within a bundle. That bundle should be signed and then distributed. Then you could put the bundle down and the behavior should be the same because they're the same thing.

ADAM GLICK: Does the logic that you're building into this, is that using a standard language that people may be familiar with or does it have its own language that people define the steps and action?

JEREMY RICKARD: So that's where the spec ends. The spec doesn't define any of that. In our tool that we're building, we have taken an opinionated approach and we're defining what that looks like in YAML. So you can think of it like a pipeline of steps to make that up. But CNAB doesn't specify the language or anything. Really, what CNAB specifies is the shape of that invocation image.

So the invocation image should have an entry point in the container that is slash CNAB slash app slash run. And it should expect environment variables to be set with the action that's going to happen-- install, upgrade, whatever. So you can implement inside of that with whatever makes the most sense for your organization or your team, with the assumption that it's going to follow that contract and any tool can run it.

CRAIG BOX: Got you. So it's a specification as opposed to an implementation.

RALPH SQUILLACE: CNAB.

JEREMY RICKARD: CNAB is a specification.

RALPH SQUILLACE: And really, after talking about the structured nature that that spec lays out for how the invocation image should be started and the values and how those should be injected, outside of that, it's really a Docker container as a deployment of a structured, distributed app. That's it. It's literally a container application. It just so happens that the format for a CNAB bundle in the end is also an OCI image.

So the bundles itself can be pushed and pulled in the normal way you might use Docker Hub or any other OCI registry.

JEREMY RICKARD: Yeah. I think that's one of the coolest things that we're seeing as we're working on tooling associated with it, but also talking to people. If you walk through the scenario of, I'm going to build a Helm chart. I can publish that Helm chart somewhere right now, but it's probably going to be, like, a chart repository or chart museum somewhere. It's not necessarily a standard like an OCI reference.

But once you get beyond that, if I also need to run Terraform to stand up some infrastructure or I need to use CloudFormation to stand up some infrastructure, there's not a great way of sharing those things, necessarily. Same thing for Docker Compose.

I can send you a file. Here's the Docker Compose file attached to this email, or I can set it on Slack or something. But there's not a specified way of distributing all of those things together. And that's what CNAB is also specifying.

So it's specifying the core piece which is that runtime aspect, but the second piece that we're working on now is the distribution of those things. So kind of like Helm is experimenting in Helm 3 with pushing charts and library charts that are pushed to OCI registries, we're doing the same thing. So we're working with Docker and others to figure out what it looks like to share these bundles. We have a couple of different competing ways of doing that right now.

But essentially, you push to the OCI registry just like you would a container image. So it's reusing a lot of that prior art associated with how we use containers to make the software delivery lifecycle really fun for people and easy. The same thing is going to be applied to bundles.

CRAIG BOX: A lot of people are talking about operators now in a Kubernetes context. And I think that the easiest way to describe that is that there is a resource definition of something that describes the state that you want--

JEREMY RICKARD: Yup.

CRAIG BOX: --end up with. And then there is some code that needs to be written to do that. And the code could be written in any language, and it's not a standardized thing. It's something you have to provide. That sounds a little bit conceptually to me like what this is but a level up. So CNAB has that same idea, where you provide a container that runs the steps against a standardized definition, which might be like the CID in this case, and then it can run. Is that a fair thing to say?

JEREMY RICKARD: I think it's a fair analogy to make. The big difference is that CNAB isn't focused purely on Kubernetes.

CRAIG BOX: No, of course.

RALPH SQUILLACE: Yeah, but metaphorically, you're talking about the same kind of approach. That's a good way to frame it.

CRAIG BOX: OK.

RALPH SQUILLACE: --especially from the Kubernetes knowledge standpoint.

CRAIG BOX: Yes.

ADAM GLICK: You said you're not focused specifically on Kubernetes with this. Is this something that will find its way into the next generation of Windows Installer, MSI? Do you see this deploying containerized applications in other orchestrators? How big is the vision and the scope for this?

RALPH SQUILLACE: The real way to think about this is really Cloud Native Application Bundles. So the spec is really flexible. You said it earlier that, you know, good thing it's not narrowly defined. Or another way to think about--

CRAIG BOX: Is it Turing complete?

RALPH SQUILLACE: Yeah, exactly. It's Turing completely infinite. So it's designed to solve a problem in the world that we see in companies and in organizations today in which there are multiple target runtimes and there are a wide array of artifacts that do the deployment and operations of those target runtimes.

And because of that, we think of that as the distributed application world of cloud native, loosely defined, obviously. Cloud native is one of those highfalutin words that we like to use a lot because it sort of refers to something that we think we know. But what that means is those are really the first targets of the specification.

Now that said, the specification does point out that the invocation image, or the installer image, whatever you want to call it, is actually not required to be an OCI image. So it can be anything that can be executed in a runtime that knows what to do if given the format that the bundle defines. That could be a native process.

CRAIG BOX: Mm-hmm.

RALPH SQUILLACE: It could also be we have in Duffle-- Duffle is the reference implementation that demonstrate and exercise the specification. In Duffle there's an experimental driver flag where we've implemented a VM driver. So the invocation image could be a VM, right? And as long as runtime knows how to hydrate that VM and then pass the parameters and the arguments correctly, then it'll work fine.

So there's lots of flexibility in the future in the spec. There's lots of things that can be done. But the Cloud Native Distributed Application target is really the space that we're going after first.

CRAIG BOX: Now you've just bought up Duffle, which is the reference implementation that was released alongside the spec. What was the decision to release a reference implementation to suggest that there might be many versus saying, this is a project, and this is the engine? For example, Docker released the specification and the engine that they saw as being the primary thing that you used to implement that.

JEREMY RICKARD: Duffle is the reference implementation. And the reason that we did that was twofold. One, we are primarily interested in the spec right now. We, as Microsoft, want to push the spec forward with our partners Docker and Pivotal. We didn't want to address the complete runtime picture right now. We wanted the reference implementation to be there to exercise pieces of the spec to help us validate things as we were defining what the spec looks like. But we didn't want to say that this was the only tool.

Obviously, Docker has different use cases for what they want to use CNAB for. Pivotal is working with us, and they have some very different use cases on what they want to use CNAB for. So we are working on other tooling for CNAB. But it's really a separate effort from building the reference implementation and making that available.

The reference implementation also kind of serves-- like we've also started a new project called CNAB where we're extracting a lot of the stuff out of Duffle to make it into a reusable library. So like Docker App was vendoring part of Duffle into Docker App. So instead, it makes more sense for us-- like instead of having crazy circular dependencies on Docker and then on Duffle and back and forth because dependency management in Go is so awesome.

RALPH SQUILLACE: Easy, easy. Down boy.

JEREMY RICKARD: We extracted a lot of that into a library. So another tool we're building in Porter is building on a lot of the same things. Pivotal's using the CNAB-Go library as well. There've been some others. Gareth Rushgrove, formerly of Docker, has a Python library.

At DockerCon, we met somebody from Intel, and he's writing a Node.js library, which is pretty interesting. We're also interested in Rust. So there's a Rust library.

ADAM GLICK: Is Erlang coming soon?

JEREMY RICKARD: Yeah, Erlang will be the next Azure language.

RALPH SQUILLACE: We're all in on Kotlin.

JEREMY RICKARD: Kotlin is next, yes. We'll-- back to the JVM. Really, Duffle was intended to be that reference implementation. It's not really trying to address any experience. It's just showing minimally how to build something and minimally how to run something.

RALPH SQUILLACE: It's built to exercise every angle of the spec such that we can prove out that it's doing the job correctly and serve as a model, a code model, for other people to get a quick start if they wish to build a custom runtime.

CRAIG BOX: And then Porter is a tool that helps you author invocations of the spec?

JEREMY RICKARD: Yeah. So as we were building Duffle, one of our end goals-- our non goals-- was to address experience of authoring bundles. But during that time, we had a lot of, man, this is really painful sometimes. It would be better if there was a tool that helped us do this. So it's more focused on trying to provide an opinionated way of doing this, much like Docker has taken the experience of Docker Compose.

And that's really what drives building things with Docker App now. It's that familiar Compose experience. So for us, we were trying to think of ways where we didn't have to write big bash scripts that would orchestrate calling the Azure CLI, using Helm to install something onto a cluster or use customize.

We wanted to make those things more declarative and less imperative. So we first thought, what does that look like? Probably the YAML manifest is a good way to go because that's what we're familiar with. How can we make reusable pieces of logic? Because another thing that Duffle makes no attempt to do and CNAB, really-- because CNAB doesn't care about what's really inside the invocation image-- there was no good way of reusing pieces of bundles. So we wanted to address that piece.

So Porter's really focused on allowing you to take the existing tooling you're using, like kubectl, to a bunch of manifest and apply those, or Helm, or Terraform, or Azure. Maybe I've got a bunch of ARM templates that I'm really familiar with and I want to use those in addition to my cluster. I don't want use Service Catalog. I don't want to write an operator myself to make these things and use CRDs. I want to use the existing tooling that I have.

Porter was really focused on how we can take those things and let you use those, but also build that into a CNAB bundle without having to know CNAB. Its main goal is to try to put CNAB as an implementation detail to make it easy for you to build these things and then later share them-- because taking advantage of the distribution aspect of the spec, but not really making you know that I need to go build an invocation image, I need to go build a bundle.json. We wanted to make that happen for you.

RALPH SQUILLACE: One of the interesting things about the container world that we live in is that a Docker file is really, aside from a couple of commands, is just a bash script, and as a result, is completely unstructured. It's not emotionally, satisfyingly structured.

CRAIG BOX: Don't tell their investors that.

RALPH SQUILLACE: OK. I won't-- I won't do that. It turns out that that's extremely functional, as we all know in this world. But the functionality from the engineering standpoint comes with this baggage that is not really satisfying, even though it's super useful. And so CNAB invocation images-- because the invocation image is a container, by default at least-- you have the same problem.

The more complex the workflow is for installing, upgrading, or removing the deployment, whatever it is-- the artifacts-- the more complex that gets, the more dependencies like bash and Terraform, like Jeremy is saying, you can imagine that those images might get pretty complex just doing, like, if they were all just dumping bash in there.

So Porter, another way of thinking about Porter is really an attempt to actually bring some form of structured composition to building Docker images. And it's a pretty good experiment in doing that. But it's tailored toward the CNAB as an output. That's another way of thinking about it.

CRAIG BOX: Could you use Porter to build a traditional Docker container to run a non-CNAB workload?

RALPH SQUILLACE: You could. Except for, by default, it'll produce a bundle. But the actual approach could easily be used for that. I mean, it is definitely an experiment in seeing if there is a way that we can really usably structure Docker files. At core, that's a main portion of its experiment.

ADAM GLICK: And for each of these, do you have one file that will be implemented per container that you're doing, or will you be able to define the entire application that might have multiple containers connected together?

JEREMY RICKARD: In general, CNAB is allowing you to define a bundle that will have multiple containers connected. In the example of Chris Crone's OpenFaaS demo, in the bundle definition, you have a list of all of those referenced images that'll be used. So however 25 images or whatever are necessary to run OpenFaaS or Istio or whatever, and those will be defined inside of that manifest.

The spec, again, is really not constraining you to do a single image or multiple images. It's fairly open ended. Porter is the same. Porter is allowing you to just take those technologies that you want to use, put them together, and connect the applications.

ADAM GLICK: So there's many technologies. There's the spec, and then there's how it actually gets used. And I think back around where Java started versus where Java has ended up. How do you think this will be used? Like, what's your vision for the use cases of where people will do it? Because you've mentioned a lot of things that people can do with it. It sounds very flexible. What's kind of the ideal use case?

JEREMY RICKARD: So I think it's pretty early. And it's hard to know exactly where it's going to go, just like you didn't know with Java. But I think we have a few in mind. One of the goals we do have is to enable definition of applications and then allowing you to share those across air-gaps. So you might think of a highly regulated military or government data center that's not connected to the internet, but your developers might be.

In a previous life, I lived in that environment. And we would build on classified networks. And then we'd have to ship things. And the fact that the bundle defines all the things that are going to be necessary to install it-- you know, in terms of we know exactly which containers are going to be used. The invocation image is going to contain all of the manifests or whatever that are necessary. We can use that fact to build a thing that we can ship and verify. And we know that it's going to look exactly like we think it's going to look and ship that across the network.

CRAIG BOX: Is there some sort of testing story for how I will verify that other than installing it?

JEREMY RICKARD: You'll be able to verify that through calculating hashes just like you would any of the software that you're going to ship across. So that's one goal. We want to be able to enable marketplace scenarios where people can define what a complicated application might look like that's going to get set up in a cloud environment in repeatable ways that can be shared.

ADAM GLICK: Yeah, and it's verifiable in that way. Mm-hmm.

JEREMY RICKARD: Pivotal has different use cases. I don't want to talk about what theirs are, but they have some very specific things in mind. And then Docker obviously has some very specific things in mind with Docker App. As part of Docker Enterprise now, they're sharing-- they added a top level thing where you can define what applications are and share them across the enterprise in a way that's defined by spec. So I think those are the most common use cases we have in mind right now.

RALPH SQUILLACE: Yeah. And then the other one, too, I should mention because it's interesting, and that is that the spec makes it clear also that if the bundle declares all of the images, and in this case, OCI images, if your distributed application is composed of images and those are all in the bundle manifest, the bundle.json then what you can do is actually export that bundle which will pull and serialize all the images necessary to deploy it and write them into the bundle itself. And then you can serialize that off to the classic USB key or Sneakernet if you're old enough.

CRAIG BOX: I was going to say CD-ROM.

RALPH SQUILLACE: Exactly. CD-ROM. Oh, you young man.

JEREMY RICKARD: That's still-- in my previous life, that was still the common thing because that's a write-once thing.

RALPH SQUILLACE: Exactly.

JEREMY RICKARD: Like you're going across--

RALPH SQUILLACE: So you can do that and then go to the what we typically call the air-gap scenario now. And you can actually install it locally because all the artifacts necessary to install it are there. And you still come along with the signing capability, the attestation capability, and so forth. So that's another use case that we're hoping will be enabled with the specification.

ADAM GLICK: A little bit of a cloud native tarball?

JEREMY RICKARD: Yeah.

RALPH SQUILLACE: Yeah-- that comes with these other features wrapped into it, that most of the other deployment technologies you might use do or do not have, the signing, the attestations at various stages, and so forth.

ADAM GLICK: Do you foresee Helm becoming an implementation of the CNAB spec in the future?

RALPH SQUILLACE: I guess I would say no. I don't perceive that.

ADAM GLICK: OK.

CRAIG BOX: Especially if you're in charge of making it happen.

JEREMY RICKARD: Yeah. But I think Josh Dolitsky asked-- when we had a face-to-face-- he said that Helm charts could be packaged as CNABs--

RALPH SQUILLACE: Yes, yes.

JEREMY RICKARD: --and shared.

RALPH SQUILLACE: They could be.

JEREMY RICKARD: And that's a way the things could go.

RALPH SQUILLACE: Right. And right now-- so the interesting thing, the reason the answer's off the top of my head, no, it's not because they can't be at all. It's because that the way the Helm 3 work is going right now, the project is, as Jeremy mentioned, trying to see if the charts themselves can be OCI images, in which case they can be pushed and pulled and used with Docker Hub and other container registries.

That gets you a lot of that functionality, and it's not really clear that once you have that, which if they are OCI images, they can then be signed and everything like that-- it's not clear that Helm needs that functionality. Because it's a very directed tooling workflow, whereas CNAB is deliberately wide open but tries to bring in those features for a wide array of targets.

So that's one of those questions that makes sense, but I can't imagine that's something that needs to be done.

CRAIG BOX: Microsoft acquired Deis in April of 2017. And then after that the contribution that was done by the joint team, a lot of that was under the Microsoft brand. This is one of the first things that came out again under the Deis Labs brand, the sort of a revival of sorts. What was the decision to do that?

RALPH SQUILLACE: So the Deis labs is an interesting thing because one of the things we wanted to do was have a place-- I wouldn't call it overly branded or engineered or anything-- what we really needed to do is have a place for our purely open source work that was not really Azure-branded in that sense. And I mean the word branded in the sense you're sort of tagging and named as something. And then people have feelings about names and stuff.

And what we needed was a home for projects that were deliberately intended to go into the community and a governed body somewhere, whether that was CNCF, or some LF-- you know, Linux Foundation-- thing, or Apache, or whatever it might be. The idea was that things that happen in Deis Labs are destined for outbound community work, and that's our commitment for Deis Labs.

If we do something in Azure, in the Azure organization, for example, it might end up moving to Deis Labs and then be outbound. But people don't necessarily know whether that's true or not, right? Like, it might also be open source but live there forever.

CRAIG BOX: Right.

RALPH SQUILLACE: So that was the intention for Deis Labs. And so far it's worked really, really well because it definitely sends a message that, OK, this is a different place. We're working in the open source world. We're working with the community. And everything there should graduate to a governed foundation in some way, or we'll archive it, or stop it, like, in sort of a formal way.

ADAM GLICK: What does success look like for the project?

RALPH SQUILLACE: So I would love to see people actually using this in a repeatable way. And so if you asked me about scale of success, that's sort of an amorphous thing. If we start bumping into it in different use cases all over the world in every once in a while, I would be happy with that as a use for it. But I have to say that we did this work because we needed it ourselves, as I think good open source software starts with a need.

And we needed this ourselves. The partners that jumped on it to start collaborating with us, they needed it for the same reasons, different tailored cases, or the way that fits in with our ecosystem, but it's a needed part of the ecosystem. Whether it's exactly finely tuned in version one of this spec or whether you have to get to version 2, or whether you need x number of tools for different scenarios, I have no idea. But I think that's how I think about it right now.

JEREMY RICKARD: Yeah. I'm of the same opinion.

RALPH SQUILLACE: Yeah.

CRAIG BOX: You mentioned that Docker is using it to power their applications. What did Microsoft need it for?

RALPH SQUILLACE: So for example, the thing that Jeremy mentioned earlier, so a marketplace in general would need a trustable, signable, attestable bundle of distributed things. And customers in the big cloud space, they bring all of the stuff they're already running. And they don't have the time and energy and resources to rewrite everything.

So they bring a whole set of services that are VMs. They bring an Oracle database that's high availability failover and they walk in with 14 VMs right off the bat. And you want some sort of repeatable, trustable, signable package such that the marketplace can take a bet on that kind of thing.

So we're working with Azure, not just the marketplace, but also other services to understand how they can systematically deploy, redeploy, and operate those things both with marketplace partners and customers, but also internally for making sure that our own deployment systems are trustworthy and maybe even in some cases support on-prem deployments just as well as they do in Azure.

CRAIG BOX: So I've heard that there are some interesting implementations of the spec.

RALPH SQUILLACE: There are some that are different than the original motivation, which is clearly a distributed, cloud-native kind of approach that we've already talked about. But some people have been showing up with very interesting implementations that we would not have predicted. So for example, one of the valued professionals, the MVPs at Microsoft in Europe Nuno do Carmo has implemented a CNAB bundle that actually replaces-- so in Windows 10, there's this Windows subsystem for Linux where you can sort of do Linux work inside Windows without having VMs and so forth.

That turns out to be really interesting, but of course, people want to bring different distributions to the WSL, right, that environment. And not all the distributions are in the Microsoft store, right? So he actually implemented a CNAB bundle that actually swaps out the Linux distributions on the fly. And it's just a local CNAB bundle executing in Docker on Windows.

And you can totally replace your testing environment or your client environment. And he deploys all kinds. He's got like 16 or 17 different distributions that are all customized for his operational environment. So he can just swap it in, swap it out, swap it in, swap it out.

So there are things like this that you wouldn't really-- like, we certainly did not ever imagine. When he showed that-- he tweeted it and stuff like this and we saw that-- we were like, I had no idea that that was what it was capable of doing it. It was just not on our radar.

And we bumped into-- another implementation actually has the core verbs in the spec are three-- install, upgrade, and uninstall-- because those are the lowest common denominator. But you can add custom commands. So at DockerCon, a gentleman from Intel, I believe it was, actually described his custom runtime that implemented, like, 20 different custom verbs. And that becomes really, really interesting because if you think about the spec, it's really easy to stop at the first three verbs. And he didn't stop at all. He just kept on going.

CRAIG BOX: You might want to have Backup or Snapshot or those kind of things I can imagine immediately being valuable. Yeah, diff, state report, lots of things that may come in custom environments you can go ahead and do. So the Spec is much broader than just the distributed targets that we originally thought we needed to do it for.

ADAM GLICK: You mentioned the MSI installers. And I was curious-- those have been around for a long time-- if you used any of the knowledge that Microsoft has building those installers and using those for yours as you came up with the Spec.

RALPH SQUILLACE: Absolutely. That is an interesting question. And of course, we went back and found the original implementers and owners to the extent that they were still at the company. And a couple of them are very prominent and have done so many other things since then. But that was a long time ago.

And we spent actually any number of meetings going back and forth over the way that MSI has worked in important set of cases and the ways they've failed. And we had long conversations about things that did not work with MSI. And many of those directly informed the original sketching out of what the Spec had to look like and do.

But in addition, one of the big bits of feedback we got from those conversations was how important a declarative approach to creating these things was. So if you're old enough for the old MSI lore, it couldn't really have an install shield, right? It had to be just straightforward, simple to understand, simple to comprehend, and relatively speaking, simple.

So that's essentially why not only the original format was YAML but also then a whole bunch of the motivation for Porter.

CRAIG BOX: When you were talking about declarative installations, if I installed my Cosmos DB and that step failed for some reason, you stopped out in the zone or something like that, how does the system deal with something has to happen successfully in step A or be retried before I can do the thing in step B?

JEREMY RICKARD: Yeah, so that's really going to end up being implemented by whatever tooling is doing that installation. So in Porter, we're trying to do retries. We try to delegate down to the tools as much as possible to say, retry this if you know how to do that. We have some baked in. For example, when we do the Cosmos deployments and stuff, we're using ARM. So we know how to talk to the Azure resource manager.

We know how to handle the failures for that, and we can retry it within limits. CNAB itself specifies how to handle a bundle that fails and a bundle that succeeds and store that stuff into Acclaim so that you can operate on it and maybe go clean up things manually if you need to. Generally if you're going to build bundles to handle any kind of tooling freeform, you would need to build those things in as appropriate.

For Porter, though, we are trying to bake as much of that as possible into the little mixing components that we have so that we can have some assurance that well, A, this is going to succeed and go on to the next step and pass the information that's necessary or B, clean up after yourself if you're unable to actually do this.

RALPH SQUILLACE: Right. And so we had mentioned somewhere else in the conversation that other people had implemented other custom verbs in their runtimes. For example, in some of that functionality if you were building a bundle by scratch, by hand, that Docker file literally can do whatever-- the invocation image can do whatever you need it to do. Porter is just trying to give you a couple of legs-- steps-- up, something up, you know, in theory.

CRAIG BOX: Seven's up.

JEREMY RICKARD: Carrying the bags up.

RALPH SQUILLACE: Yeah, it's carrying the bags up. It's the Porter. It's trying to carry the bags up a couple of steps for you and help you get to a structured approach to that without having to do all those custom verbs yourself.

ADAM GLICK: Thank you both for joining us today.

JEREMY RICKARD: Thanks for having us.

RALPH SQUILLACE: Sure. Been great fun.

ADAM GLICK: You can find CNAB on Twitter @CNAB_spec. You can find Jeremy Rickard on Twitter @jrrickard, and you can find Ralph Squillace on Twitter @Ralph_Squillace.

[MUSIC PLAYING]

ADAM GLICK: Thanks for listening. As always, if you've enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on Twitter @KubernetesPod, or reach us by email at kubernetespodcast@google.com.

CRAIG BOX: You can also check out our website at kubernetespodcast.com, where you will find transcripts and show notes. Until next time, take care.

ADAM GLICK: Catch you next week.

[MUSIC PLAYING]