 All right, everyone could hear me. Everyone's awake, because I'm not. So as Jim mentioned, I'm going to go over some updates from the Cloud Native Computing Foundation. Obviously, in this room, it seemed like more people knew about one of our first projects, Kubernetes, more than the foundation itself. But that's sometimes how it is. So I want to tell you a little bit about our origin story. So working, clicker, Theo? We got a little snafu, but there we go. It's a hard click. All right, so a little bit of an origin story around CNCF. So I think we're good. Ah, thanks. You told me this would happen, so cool. So a little origin story. I was fortunate enough to join the Linux Foundation a little around two years ago to be involved with the formation of the Cloud Native Computing Foundation. So for those who aren't aware, Cloud Native is really a form of computing that was pioneered by the internet scale giants out there, like Google, Facebook, Twitter, Netflix, and so on. And when I say Cloud Native, all I mean is you have services that live in containers that are orchestrated by some central system like Kubernetes. And so we started with this kind of simple goal of bringing Cloud Native Computing to the masses. And when we started the foundation, we humbly started with 22 members and Kubernetes as kind of our seed project. And so that was about two years ago, like technically under two years ago, because we didn't hold our first board meeting until December of 2015. But it's been amazing to kind of see the growth over time. As Jim alluded to, I arguably think we are the fastest growing open source foundation with the Linux Foundation, but some people will debate me on that one. But as of today, we've basically experienced over 6x growth in under two years. We're at 141 members. It's really amazing to kind of see a wide variety of companies really trying to adopt Cloud Native Computing. And for me, if you kind of were studious and looked at this list of members, I think for the first time in the history of open source, we have the top six cloud providers under one open source foundation umbrella working together to advance the notion of Cloud Native Computing to me, which is amazing for being someone who's been involved in open source for a long time. Also, as kind of like a geeky nerdy thing, I completely find it fascinating that Kubernetes, our first project, is actually technically self-hosted on itself for the first time. I'm sure some of you have heard, but GitHub is re-platformed on Kubernetes. So Kubernetes source code is on GitHub. GitHub runs Kubernetes, so it's self-hosted. So I find this as a fun, kind of a fun geeky thing to think about. But in reality here, CNCF, the lifeblood of CNCF is its projects. I love all my projects equally, and we have 12 of them. We've grown to 12 projects over the last two years. They cover spaces from orchestration to monitoring to tracing. I'm sure some of you have seen this wonderful Cloud Native landscape. If you haven't, it's a bit of a crazy diagram. It kind of shows the complexity of this space. But I think the important thing here is that when it comes to Cloud Native, there are multiple paths to get to Cloud Native. There's different technologies out there that could use. Obviously, we love for you to consider CNCF projects. We think they're of high quality and something you should consider. But we're realists, right? We understand there's other technology and projects out there that you may want to use for specific things. But the important thing in this diagram is there's some missing holes here, just some missing pieces. So today, I'm happy to announce that we're going to fill some missing gaps in this diagram. And I'd like to introduce Riaz Fazilaboy from Docker to talk about some of these new gaps that we're filling today. So please welcome Riaz to the stage. Thanks, Chris. So as Chris mentioned, today we are filling a couple of gaps on that past diagram. And so with great excitement, I'm happy to announce two new projects to the CNCF, the update framework, and Notary. So thank you. So to give you some context, both projects are focused on security. And both projects focused on a trusted delivery of content. What that means is getting some data from point A to point B. The data could be anything across platform in a trusted way. So many of you are probably thinking, OK, we have a way of doing this. We maybe can use signatures. So here's a signature. And you may recognize the signature. You may not, in which case you have some authenticity of the signature. But what we're really missing from just signatures, we're missing a lot of context. We're missing when was the signature made? Is it still valid? Is one signature enough for our data, or software, or the document that this was on? And so what Tough, the update framework, really strives to achieve is providing context for more robust software updates in a trusted way. So for some background on Tough, Tough was developed by a group of researchers at the New York University, the engineering school. And they drew some ideas from TOR, which many of you may know as an anonymity piece of software, communication. And TOR had a very exciting update framework called FANDI, where they sought out to make a very secure update system for TOR, even in the face of some of the strongest adversaries. And so in developing FANDI and developing Tough, the Tough researchers decided to really tackle giving more context around signatures so that you can make very robust decisions. So for example, from signatures, you may already get authenticity, understanding who signed, integrity, understanding if a signed is the same thing that you want. But Tough goes beyond that by giving you freshness guarantees. Is this the most up-to-date signature, the most up-to-date package? It allows you to do multi-signature thresholding. So do I have all the signatures that I need? Do I have three signatures, five signatures? And very importantly, in Tough, if a key is compromised, it's not an end of the world event. You can rotate the key and your consumers of your package or whatever software or data you're providing can still verify your signature and continue with the up-to-date process. And so Tough, as I mentioned, is cross-platform. And many platforms and programming languages have already adopted or in the process of adopting Tough today, which brings me to Notary, which is an open-source project from Docker that implements the Tough specification. It's open source on GitHub. You can go there today. It's written in Go. You get a command line interface, a couple of microservices for the server side operations of signing and holding data. And you have a robust library to integrate with. Many of you might already know about Notary. As Notary has been at the forefront of container image provenance, so understanding where an image comes from is entrusted. But for those of you who aren't too familiar with image provenance, I'd like to draw an analogy to normal PDF, JPEG images, especially in the Photoshop world we live in. So for example, this is not a real image, right? In some parts of the world, penguins do go and go to the beach. But you're not going to see one drinking a tropical drink sunbathing and wearing some flowers and a hammock. You're more likely to see something like this. And you expect something like this to be a real image. So in the same way that you'd want to expect real images for photos, you want to expect that your containers are untampered with and trusted. You want image provenance. You want to know that the same developer or person who wrote the code for this image and packaged the image and pushed it, that same image is the one that you're downloading and deploying your infrastructure. And so Notary by implementing the tough spec gives you all of those great guarantees of freshness, authenticity, integrity, key compromise that's survivable, and allows you to apply it to your Docker containers and other containers. And with Notary, you actually can go one step further and have a cryptographic chain of custody. What I mean by this is that you can mandate cryptographically by requiring signatures at each stage of your CICD pipeline. Did my image pass CI? Did my image get a security scan? Did my image successfully deploy to development and pass tests there? And before deploying to a production, you can check and verify each of these signatures and mandate that they exist before your container is deployed in your production environment. So Notary and Tough are very powerful. Notary has been adopted by, as well, many platforms, including Docker, CoreOS, VMware, Linux Kit, and many others. So I'd ask you to please join us. Both projects are open source. On the tough side, the spec is a living spec. So there are augmentation proposals where you can propose new additions to the spec in edits called taps. And in Notary, we're approaching 1.0 and thinking about signing service specs, pod specs, and many other features. So we'd invite you to come join us. And with that, I'd like to invite Chris back up on stage. Thank you, Riaz. So yeah, now we're 14 projects. And we've added both Notary and Tough to the landscape. So thank you, Riaz, for your time. And just a final kind of notice and shout out for the audience is we're hosting KubeCon, CloudNativeCon in Austin in a little less than a couple of months now. So if you're interested in meeting the CloudNative community and working with our projects, please make your way to Austin and attend the conference. And we'll be back in Europe in May in Copenhagen. But thank you for your time. And I'm going to hand it back to Jim to steer us forward.