 Good morning. My name is Dan Kahn. I'm the executive director of the Cloud Native Computing Foundation and very happy to be back again at the Open Networking Summit. I've been attending this now in both the US and Europe for the last couple years and it is really, I find, one of the most productive events. I like the sessions. I like the keynotes, but just the hallway track that I have here, the people that I run into from around the world who are using Kubernetes and other cloud-native technologies or eager to use them and looking for a little bit of guidance on it, has been extremely productive for me. CNCF is part of the Linux Foundation. We are a sister organization of LF Networking and LF Edge, and Arpit and I have had a really productive collaboration over the last few years as these different worlds merge together. We're best known for our project Kubernetes, which is one of the largest and fastest growing open source projects ever. We actually now have six graduated projects and 16 incubating. These are different levels of maturity and our recommendations for the world. Kubernetes sort of has a gravitational force around it, but in order to have a complete solution, a lot of these other projects are really quite valuable for things like connectivity and observability and storage and a lot of other areas. And then you can see here the 18 Platinum members that help back our cloud-native ecosystem. We were very pleased to add Apple as an end-user Platinum member this summer. So raise your hand for me if you've seen this cloud-native landscape before. Yeah, about half. So you can pick this up in the CNCF booth outside and the URL at the very top, l.cncf.io, lets you download it and actually interact with an interactive version of it. This document has been called helpful. It's been called overwhelming. It's been described as the hellscape. And this is legitimately an absurdly complicated and detailed document. I do feel like we get a lot of criticism for, oh, why are you making things so complicated? And it's sort of like, oh, this trail is really rocky. I'm going to go blame the map maker. What we're doing here is legitimately trying to map out all of the different options for the different aspects of the ecosystem. But actually, we like to have this document be the backside and the front side, we like to have the cloud-native trail map. And again, this is available at l.cncf.io and you can pick it up at our booth. This is our recommended path for enterprises to adopt a cloud native where the very first step is to containerize normally with Docker containers. The second step is to implement continuous integration, continuous delivery that you need to be able to rebuild all of your software from source constantly at any time. And then only step three is orchestration with Kubernetes. And then you get into the more complicated areas. So observability and analysis using things like Prometheus for monitoring, fluency for logging, the new open telemetry project and Yeager for tracing, and it keeps going from there. So this is the path that a number of enterprises have adopted over time. And you can really see that in terms of Kubernetes and the search trends on Google Trends where this has just been a spectacular level of engagement and adoption and interest over time. When we started CNCF less than four years ago, it was really one of many orchestration platforms and people were a little unclear around how big containerization, how big cloud native was going to be. I don't think there's a lot of confusion at this point. Another really great piece of evidence of this is that when we started less than four years ago, we had three companies in our end user community. And we really appreciated their support. They're still with us as NCSoft from Korea, eBay and Goldman Sachs. But wow, we have 115 now. And so if you look at Adidas and Amadeus here in Europe, all the way up to Zolando and Zendesk and tons of pretty exciting folks in between. Now we did define the end user community as people who are making use of cloud native technologies internally but are not selling them to their customers. So folks like Apple will sell you an iPhone but they're not selling you a hosted Kubernetes service. And so we do explicitly exclude telcos from taking part in our end user community. And this was almost just kind of a definitional issue. Which is why we were very excited earlier this year to launch our CNF testbed. And the idea here is to compare the performance and the capabilities of virtual network functions, VNFs to what we call cloud native network functions or CNFs. And so to do this we partnered with LF Networking and we in particular took some code, some open source code out of ONAP, the VB and G use case that's part of the VCPE. And we packaged it as a virtual machine and ran it on OpenStack and then ran it on bare metal servers from our great member and supporter of CNCF, the bare metal hosting company packet. Then we took the identical networking code and we packaged it as a container, ran it on Kubernetes on the identical bare metal servers. But one of the key thoughts here is that we didn't just do this once and then publish the results. We actually created an entire open source project and have all of this available on GitHub today under an Apache 2.0 license that anyone is able to go replicate these results. And what we've been able to show are some performance improvements and some latency improvements in terms of the time it takes to spin up and how many network functions you can run simultaneously on a whole variety of different measures. And then at the bottom, I want to point out this URL, github.com slash cncf slash telecom hyphen user hyphen group. This is our telecom user group or Tug that Cheryl hung our director of ecosystem runs. And this was our way to engage with the networking and telecoms communities where unlike the end user community, we wanted to bring together both the vendors and the telco operators and have them collaborate together. And so this has just really gotten kicked off over the last couple months, but I would love to encourage you to engage with us and participate. It is open. We have the first Monday of every month, a call that's friendlier for the West Coast of the U.S. in Europe and the third Monday we have a time that's friendlier for Europe and Asia. And we are working to extend the CNF test bed and try and make these use cases more practical. So this is just a quick look and you can download these slides later from Schedge and take a look at it. But it's showing this summer that we've been adding a number of use cases and functionality to the test bed. I'll give a quick shout out to a sandbox project that's part of CNCF called the Network Service Mesh that's been adding some additional functionality on top of Kubernetes that's particularly valuable for these kinds of telco applications. And here are our rough plans for the next four months where we have a lot of additional functionality that we're adding in. But at the big picture, if you look at really what we're aiming for with the CNF test bed over the next six months or so, there's two big pieces. One is that we would like to evolve it to become actually a development platform for cloud-native network functions, for CNFs, so that as you're looking at taking your existing networking code, porting your VNF to be a CNF, that rather than just running it on your own environment, both telcos and their vendors would be running it on the CNF test bed. And what's great is that you can get an API key from packet and you can replicate our whole environment, or you're also welcome to run this on your own bare metal infrastructure that we would love to support with you with it. And then over time, we are talking with the OPNFV verification program, OVP, that's part of ELF networking, to explore using the CNF test bed as a platform for certification, where we do have an aspiration here that CNFs can actually be even more interoperable than I think a lot of the goals were with VNFs that you should be able to have CNFs from multiple different vendors running on platforms from other vendors. So I'll finish by saying if you are interested in cloud-native and adopting some of these technologies, looking at how they can be valued to you, this is a good conference. Please also consider coming to KubeCon Cloud-NativeCon. We are going to be in San Diego on November 18th, and we are going to actually have the largest open-source developer conference ever. We're expecting more than 12,000 people to attend that. We're then going to be back here in Europe in Amsterdam, short train ride away on March 30th. We'll be back in China in Shanghai July 28th for KubeCon Cloud-NativeCon open-source summit, and then Boston. I'll just finish with a look at the, when you talk about the level of engagement and excitement around Cloud-Native, four years ago we had just about 500 people at the first KubeCon event in San Francisco, and that's grown to now be 23,000 developers from across our three different events here in 2019. And at some point we're going to hit KubeCon and go down, but we don't think we're quite there yet, and there's no sign yet that 2020 will be that point. So I hope many of you and your colleagues will be able to attend our events either in U.S. or Europe or China. And please do feel free to grab me at the break, and I would love to talk about any of these areas. Thank you very much.