 So, my name is Vincent Batts. I hope you have not heard my name because I try and stay out of the limelight as much as possible, but I've been in the container space now for about three years. I've been with Red Hat for about five years. Got involved with Docker in late 2013. At that time, I was on the OpenShift team, and as we were looking at what was the next iteration of OpenShift v2 to v3, we started realizing that the containers that we had framed up for ourselves needed to be more reproducible and more community-based, and so it led us to start investigating community containers, and around that time was when Docker was getting off the ground. I've been around in the open-source community for a number of years. It's fun running into people at conferences like this because we realize that some of us have contacts that we've been working with each other for 10 or more years, but in different contexts, all in open-source. It's good stuff, so feel free to reach out to me at any time. So I want to say it is fantastic and completely ironic that I'm the first person that gets to command their slides and have animations today, and I have zero technical content to cover in this presentation. You're going to see lots of cat gifts. So containers. As you've seen, I could go with the Longshoreman analogy here and all the fantastic tools that they have, and crane lifts and all this kind of stuff, and how to pack containers, but it's still just a box to deliver goods in. At the end of the day, there's any number of conforming containers that people use to package goods, deliver goods, and see how they're actually going to get used in production. It really doesn't matter. You could just as well look at actual shipping containers and how people are using them, and people are using them to build houses and do all kinds of stuff, where I'm sure the people that are actually shipping goods from China to San Francisco look at a house being built out of shipping container, and you say, that's clever. That's not what it was meant to do. That's clever. And it's led us in a lot of interesting directions, and what the last three years have been about has mostly seen, how are people using these containers? I mean, a lot of the technology's been there. It's either been not approachable or there weren't enough patterns that had arisen. I mean, LXC's been there, but nobody's really wanted to touch it in a meaningful way. So now we have a lot of patterns, and people have done a lot of interesting things with them. There was a few years ago, Simon, I got a Syripsen, if anybody's used the Logris, Syripsen's Logris container, a Gelleng library, it's a great logging library. Simon was giving a talk, and he gave the example of before, I think it was the Queen of England, had ever, she had heard about a walrus, and she wanted to see what a walrus was. And so somebody went on an expedition and found, you know, killed a walrus, tanned the hide, brought it, brought back a box of bones in this tanned hide, and the people that were reassembling it for the Queen in a stuffed manner had never actually seen the live animal. And so what they reassembled was this preposterous, overblown monster of a creature, and Simon was saying, this is pretty much where the phase we are in, and he said this two years ago with containers, that most of us are doing all kinds of things, and it's only in a couple of years from now when we start to see what that pattern is, the proper way to assemble it. How is it going to come together? There's lots of ways that you can use containers, but now let's move the conversation up a little bit. How are we making it useful? So in the container ecosystem particularly, I mean, we as an industry have gone through patterns like this, and I'm not saying the technology, but the types of iterations over and over, whether it was operating systems, whether it was virtualization, whether it was orchestrating virtualization with like OpenStack and so forth, and now it's just kind of churned to keep refining the method. For whatever reason, the ecosystem is the big question now, because it's exciting, but to some extent it's a foregone conclusion that a lot of this is happening in the open. So now it's open source, and how companies that are going to compete with each other, how they're working together, and in the container community, that's, for whatever reason, led to a lot of conversations and a lot of trepidation and mixed feelings. And so people ask, well, what's happening in the container ecosystem? And for a lot of us, I feel like I say us developers involved, this is often like myself at the time working with folks from Docker and folks from CoreOS and IBM and Google and now Amazon and Huawei and all these people, and many of us have competing offerings. But at the end of the day, when the people with their hands on the keyboards just trying to make it work, I feel like some of this like container wars and all these flurry conversations that are going on, a lot of people that are actually working on it are just kind of watching that go by. And like, we'd prefer there not to be any feelings of contention, just want to work on good technology and work on it together, even if there are higher level constructs that people are worried about. So some of the fights that people feel like and, you know, tit for tat, at the end of the day, it's actually us just trying to figure out where it is that we're going and find the common ground so that we're not fighting with ourselves and realizing that I've made a decision, you know, I invented it, I'm not going to use your stuff because you didn't invent it and, you know, you end up fighting against yourself because of some decision you made at some point. It's difficult because there's humans involved, and so as soon as we can move past that, the conversation gets a lot easier. Yeah, that's where some people that have been involved, you can ask, I sympathize with this. If you don't sympathize with this, good for you. But some of the conversations when we go round and round, it leads you to a state of just ready to make it boring. Like, a lot of the things that people get really hyped about, especially, or at least over the last few years, it's time to move the conversation up the next level. And this is where the last, almost two years, but I'll say a year and a half, the conversation that I've been most involved in, my primary focus has been in the Open Containers Initiative. It was launched by a donation of part of the runtime code of Docker. At that time, it was like NSNIT. RunC was just kind of a term that we were working through. It got formally launched as RunC. There was a period of transition there. It boasted the ability to have distributable code and like configuration files that were portable. At the time that all that was going on, it was mostly library calls. It wasn't actually a command line tool, or a lot of the things that we were working on over a period of probably six months or so. We made that into, anyhow, the conversation has started with standards for better or worse, and at the time, standards to a lot of people meant de facto, de facto meaning it's where we are. It's what we have. Most people would say that's the standard to them. And as far as people are not looking forward to adopting a specification, if I went around the room and asked you, can you prove that your application is POSIX compliant? I could guarantee I would hear half of your teeth grinding of like, well, maybe. Yes, but we try to not do it. Or FHS, like your FHC file system is completely compliant. You're putting all your files in the right place. And people grind their teeth because they're doing it how they know it works for their application, but not to somebody else's specification. So we have brought standards in. And as soon as you start saying, we're going to specify this, like it was one of the things that I think because we had gone round and round and the developers involved just wanted it to work. We wanted it to be consistent. We needed that base runtime, the distribution of images to work right. No matter whatever application platform you're working on, we needed to move on. At the time when it was like, we need a standard, I think that got a lot of people very excited. And by the same token, that got a lot of people very like, oh, god, what is it, 13 competing standards. So we need to unify these. Now you have 14 competing standards. And that was where we're at. But the conversation has progressed in such an open and the Open Containers Initiative, OCI, has been about a year and a half in the works. We are working on the image specification and the runtime specification. And some folks within the industry ask why is it moving so fast? Because I think in many industries, to have something that's going to be industry adopted, that's two years in the making only has like fledgling adoption within various tools. That's pretty fast moving. I feel like by a lot of technology firms and even startups that a year and a half is an eternity. Like why are we not done with this already? But the best part about this is that as we are working our way through just these two building blocks, the process has been entirely open and equitable between the companies involved. And we've effectively started with just the two basic building blocks within OCI and that's packaging and runtime. How are you going to distribute? How are you going to make it available to anybody else? If you're using something like a registry, how are you pushing and pooling? What is it that you're actually pushing and pooling? Does it have basic constructs that I can build other security principles off of like content addressability? A lot of things that we've been working on and refining in the Docker format over the last couple of years and it's gotten us through the Docker v1 registry format and v2 and then v2 schema too. These things were being refined over the time but we wanted to codify it. We wanted to put it to a spec. Likewise for RunC and the ability to have interchangeable underpinnings. Some of the other pieces of standards that are in the works but are not covered in OCI particularly is networking and as it's now becoming is the cloud orchestration layer. Like this is pretty much where the conversation is. So this is just a little bit of backstory on it. It started around June 2015 and at that time it was the open container specs. It was all one big umbrella project. Around, I forget, a little more than a year ago we decided that to have it all under specs was a little confusing so we split up to a runtime spec and an image spec. Currently the runtime spec is that a V100 RC5 we're about to enter the voting period for a 1.0 final so I could pretty safely say expect that V1.0 final on the runtime side within the next month. A plug for network, these are a little out of order. The primary one like what Kubernetes and many different back ends are using is CNI. There are some others out there. The CNI has been most widely adopted to my knowledge. So this is where the packaging side that I personally like spending most of my time. The de facto standard has been the Docker image whether that's on disk or when you Docker save and load it, whether you push and pull it, the actual pieces involved here, how do you serialize what it is that you're needing to move around has been the de facto standard and because of that what we've been working through on the OCI image spec has been a carryover from largely the Docker V2 schema to format so what you push and pull is if you have any tooling or implementations that are there if you already have like Clayton was talking about a registry, it will not be a large leap to add just this additional MIME type or media type and we're already seeing even though this is pre-release also it's an RC5, it might go through one more release candidate. We're already seeing industry adoption. There's a number of tools that are supporting it already. I don't have it on here but recently even Amazon's elastic containers registry, ECR, is that what they call it or is it ECS? ECR, yeah elastic container registry, they added a OCI support in that you could actually push a Docker image and then ask for the MIME, that same image that you just pushed but in the MIME type of the OCI format and it would do the translation on their backside. Likewise you could push an OCI MIME or media type to it and pull a Docker V2 schema to back and this is what is intended to happen. It's a low risk step so it's that you have actually a specified like V1 version, a commonality point as long as you know that you've produced this artifact or can consume this artifact, you have a compatibility layer on the low level building blocks. Precisely what it was intended to do is intended to be boring. So as the conversations moved up now to cloud Kubernetes kicked off the CNCF party but has had lots of friends join along and most recently as it relates to this talk has been proposed Container D which is how many folks are familiar with have played with Container D? Pretty slim. So what's interesting is Container D is pretty much some of the underbelly execution of the Docker daemon or Docker engine. Originally a thin execution layer now various features like the image push and pull, some aspect of like what was the graph driver now the snapshot layer are being moved from the engine down into the Container D layer. It's an independently useful tool it's for pulling, pushing, running images. Likewise, Rocket's been around for two and a half, two years. A little over two years, about two years and three months that has formats, the ACI formats and under the app C spec as well as supporting Docker. Both Rocket and Container D are being donated or have the conversation started to donate to the CNCF umbrella. How this is interesting is like was talked about earlier the CRI interface, the Container Runtime Interface for Kubernetes allows for as long as it meets you can write a CRI shim to talk to any Container Runtime because nobody expects there, nobody really expects there to only be one winner because there might be different use cases and that gets into talking about thin VMs or anything like that. There might be more than one Container Runtime you just write a CRI shim and you can choose that use case. Red Hat's working on, called Cryo. For a little while it was called OCID but Cryo and it's pretty much a thin CRI shim just to call out to RunC. These two options give a little bit more in that sense of like a full feature tool that also will be callable by Kubernetes. And it's pretty much what a lot of people have asked for over the years. Particularly especially in the Kubernetes use case we didn't need all the functionality but mostly the execution and push and pull of images and so there's now within the CNCF umbrella there's collaboration there, there's a way forward that hopefully will be boring and people are trying to get things done can just go work on a project together and have open governance. Even if the conversation gets long and drawn out and there's a lot of people involved because there are people involved the conversation needs to stay open. It doesn't need to have like a single choke point for some of these projects. It's a very exciting time if you're into the space if you like working on boring stuff that has meaning. I recommend you get involved. I say that because a lot of the hype will burn you out and sometimes it's working on the boring stuff that often times nobody else wants to get involved in that can have meaningful impact all the way up the stack and I feel like that's where we are at this point so that we can get the conversation to orchestrating containers so that we can distribute these things. We can actually have a higher level application like we can actually talk about a lot of the fun concepts that you see coming down the pipeline for OpenShift and Kubernetes. So particularly a call to action in my world is getting involved. Open Containers Initiative we have IRC channels, we have mailing lists, there's a dev at opencontainers.org, email list that's welcome to get involved in. If you're working on various types of parts of the stack that interoperate with things that I've talked about, it is imperative that you get involved either because your use case is valid, which because you're working on it, I assume that's true. You need to make sure that this stuff works for you so that we can take that feedback but as well get involved because as it's already being adopted, it will mean some point of interoperability which would further leverage whatever it is that you're working on but also make sure that other people consume the work that you're doing. So yeah, it's an interesting time for this line of work and any other questions, feel free to hit me up later. I'm VBATS at most places or VBATS at redhat.com. Yeah.