 So, yesterday I talked a little bit about why we should make Kubernetes boring. And honestly, talking about boring things is boring, so today I wanted to talk a little bit about how we can make this ecosystem and this community really exciting. And it's because Kubernetes is part of something much bigger. It's bigger than container orchestration, and it's getting bigger all the time as evidenced by everybody here this week. There's a few things that I would like to highlight that are coming in the next year. You may have heard of them, you may not have heard of them. And I want to make sure that people are aware, this is kind of at the end of the conference, but over the next year if you can find and identify these technologies and these tools and these projects, you can orient yourself and maybe get an idea of what's coming, get involved, or participate. If you're already an expert, you might find something surprising in my list. If you contribute to or use one of the projects I mentioned, maybe you'll hear about others that could benefit from the work you're doing. If you're using Kubernetes, maybe one of these projects will help solve a problem for you, inspire you to contribute. And if every one of these projects is known to you, speak up, we actually need you to help. So, I'm gonna start with a call to action. We should be making everything better. This is somewhat broad, so we, the people in this room, this conference, this ecosystem, I assume a fair amount of folks here want to build things, what are we actually gonna build? Well, everything is somewhat broad, but let's be honest, software is pretty broad now. And I actually tried to scope this down, and I couldn't come up with a reasonable definition of software that didn't include most of the things that we were talking about. Everything is networked. Everything is on a different type of device. We don't just use the cloud, we depend on the cloud, we have our own clouds. And better, this is a little bit more subjective. But I think we're all here to try and make people happy or more successful or able to accomplish things that they weren't before. And so everything getting better does sound like a really good thing. So, how do we go do this? We already are. Judging by the 4,300 people here at Cloud NativeCon and KubeCon, judging by the sessions, I think it's pretty clear that we're everyone is already passionately engaged in this effort. So it's easy, everybody give yourself a pat on the back, great, we won. But if you haven't been engaged, or if you'd like to get more engaged, or you've been heads down in one particular area, I think this is the right talk for you. So I don't have time to describe everything. Everything is huge, 20 minutes is not enough to even cover the first glimpse of these. And I think that's a challenge, Michelle did a great orientation that first day. And I could do this for two days and probably not even begin to touch the surface of what's going on. So think of this as a high level, and if you can come find me later, I can talk to you to death about all those other things. And everybody else here in this community also wants to talk about these things because we all care. So there's 2,200 projects on GitHub that are labeled as Kubernetes. I did not go and look at each one of them. We have a cloud native landscape chart that doesn't fit on an 8K monitor. Dan like that. But out of these 2,200 projects, some of which are on GitHub, some of which aren't, here's some highlights. So if you're building new applications, expanding last year's applications, or integrating a new technology, 2018 is going to be exciting. There's tools that help you build and solve problems faster and better. That's been true for a long time, no surprise there. Does everybody remember Ruby on Rails? Maybe some of you are too young, I don't know. And I actually had that thought. I was like, my gosh, I'm so old that people may not remember Ruby on Rails. That was terrifying. So for those of you who are too young or for those of you who may not know what Ruby on Rails is, Ruby on Rails was a framework, a bunch of people who are very passionately involved in a very particular aspect of technology, building highly dynamic websites that empowered their clients and their users to very quickly spin up ideas. Ruby's on Rails was let's take that and open source it. Some basic ideas are it's so easy to add one more thing, where that one more thing is actually valuable to your users. But I think more than any other project in recent years, Ruby on Rails set a tone for the open source ecosystem. Because it wasn't just about Ruby on Rails, it was about all of the people on top of Ruby on Rails, who built gems and extensions and plugins and engines and templating. In a sense, Ruby really saw the birth of the modern web app. What we consider the modern web app, I'm sure next year it'll be a different modern web app. But dynamic JavaScript, data models that actually represented, these weren't new ideas, but it was about enabling people to build an ecosystem around those technologies. So 2018, I'm kind of a bold prediction here. If you went to any of the 700 talks on Istio at the conference. This actually might be the year of the service mesh, but this isn't new. Tools like Envoy and Istio, or the conduit project that was launched just a few days ago, help abstract out the interconnections between your services into a smart network. So that smart network can monitor, measure, trace, and authorize connections between participants, can detect and mitigate failures. It can connect services across clusters, operating systems and clouds. And that key idea is, rather than building all of these capabilities into each application, you're in a proxy next to each one, and dynamically program that proxy based on what the application author or the infrastructure knows about what's going on. This makes integration much easier. You don't have to write one client library for a framework or for an idea across every programming language that people use, basically JavaScript and Java. But taking that out means I don't have to worry about that problem. And just like Rails, these tools are going to empower applications to focus on the core idea and to make the problem somebody else's. And that person usually can solve the problem more effectively. So it takes key ideas, part of the first generation of libraries and tools for microservices, and it democratizes them. Like service mesh, machine learning, big data tools, and big data sets aren't new, but they're becoming easier to learn and easier to get started with. Tools like TensorFlow and Spark are increasingly becoming just something that's easy to install on a Kubernetes cluster. And then almost as easy to scale those. Project by Rad Analytics by Red Hat are taking the next steps to streamline that practical side of, I want to learn these concepts, and I want to put them to use, and then I want to get value out of them. Kubernetes is adding things like GPU support as just one more thing that belongs to the cluster, which means consuming and using GPUs on cloud or on bare metal should go from possible, but a little fiddly sometimes, to be fiddly if you do something really weird, which is actually a huge win for most people. We probably aren't all going to be machine learning experts at the next KubeCon. I do hope that we continue to focus on taking people not just into technologies, but through technologies. It's about getting out of the way and helping people get an outcome that matters. This one's maybe a little bit more wishy-washy because this is still a fairly new space. Functions as a service is continuing to improve across the cloud providers. People build more tools. There's still a lot of differences, and everybody's kind of piecing together their own solutions. Each of these three projects in one way or another takes the functions as a service idea and adds them to Kubernetes. They all have different strengths and different principles. I think there's a huge opportunity for the technologies in this space to kind of blur the line between function and container. Functions sit down at one extreme, and if you think about what a container is, it's really just a function that grew up and got a whole bunch more functionality because it was just easier. And so that just easier is something that should be true at either end of that spectrum. Many of the common patterns in serverless, fast startup, simple billing, event-driven behavior, idling, integration are also features that normal containers could use. If I have a function, it needs to talk to my services regardless of where they are. And if I'm in one cloud provider, that's really easy today. But I'm still willing to bet that for a good portion of the people here, one cloud provider isn't enough. On the application side, as Brendan noted, there's still a lot of work to go do. Applications are becoming complex, even more complex. That also has been true for the last five, 10, 50, 100 years. There are a huge number of people in this community who care a lot about helping control that complexity. I expect to see a huge amount of refinement in 2018. Brendan mentioned the app definition working group. In Kubernetes, this is an effort to help bring together tools and ideas that make everybody else's application definition easier. Maybe not to solve the problem, because if this was a solvable problem, we would have solved it already. But it tries to at least move the whole ecosystem forward to take the best ideas from people who are actually doing this in the real world, and to find the tools that work for all of us. Projects like Helm are going through a big effort to, for a new 3.0 roadmap for Helm. I think there'll be a lot of exciting things out there. Ksonnet recently announced some big improvements in how they focus on people. I think this space is going to grow, not shrink. And I think we're all going to get better at reusing common tools to make this easier. So I was voted most likely to make wildly optimistic predictions at KubeCon 2017. My classmates really, really did know me. I don't know either that or they should have played the stock market instead. The second part of this is if we're going to build more complex applications, understanding and managing them becomes even more important. Identity, if you may have seen, there was a few sessions at the conference this week around, how do we give containers identity? How do we give services identity? Istio, in a sense, is working on some of these ideas. A lot of people who are deploying Kubernetes have existing identity systems that they want to fit in to their clusters. Because it's not just enough in 2017 and 2018 to expose two public services on the internet and not protect them or not give them any authorization or authentication because there's lots of bad people out there. There's actually a lot of bad bots out there that people aren't even involved. They just go and they figure out your service and they take all your data. And so that needs to be easier. The basic idea that we'll be working towards in the container identity working group is ensuring that on a Kubernetes cluster, you can plug in identity systems that help your containers interconnect to work with other projects in the ecosystem, like Istio, but also with Spiffy. Spiffy stands for Secure Production Infrastructure for Everyone, which is a group of people and projects and companies that are working together to kind of set a combined identity system across cloud providers and clusters and provide a lot of power around who's identifying people and exchanging identity for credentials. As well, there's a lot of existing tools in this space, like Kerberos and Active Directory are a really good example that have existed for a very long time. And there's people who have massive deployments today where they're running things that are almost like containers at scale. And we want to take those lessons and bring them forward because if we just reinvent everything, I'm not really learning from history. In the policy space, this is an intentionally sparse slide because we're just now starting to really add the extension points in Kubernetes that make it possible for people to plug in in an open way. I would actually hope that throughout 2018, everyone who has talked about adding policy to Kubernetes or who has forked Kubernetes and added policy is able to start building these in ways that interoperate or make it easy to plug them in because we all need a lot more knowledge of what's going on or control. The Open Policy Agent is an open source project that I do like to talk about. They've worked with Kubernetes. And we've had a lot of discussions about how you can define. They have a simple and powerful language for doing policy rule definition. And they're planning to use the hooks that are being exposed in Kubernetes to be able to intercept when someone goes and creates a deployment to do things like, OK, well, I'm going to define a policy that says you're not allowed to update deployments outside of weekday work hours. And OPA would, in a fairly generic way, say, nope, you can't do that, reject it. And if we do our jobs right across the ecosystem, these tools will be increasingly easy to plug together. LDAP is another one. A lot of people use LDAP as a central store for their policy or their organizational identity. And I would really very much like to see better integration between the LDAP side of the fence and a Kubernetes cluster so that we can do a little bit less, a little bit more automation, a little bit more manual work. The container runtime interface in Kubernetes was a very deliberate effort started over a year ago to extract out the connections between Kubernetes and the container runtime, both for practical reasons to create a nice boundary to make Kubernetes easier to develop, but also to open up the space for better extensibility and for other people to innovate. And that has happened. There's a ton of new container runtimes out there. The most recent was Microsoft announced a virtual kubelet that could do much of the same things of calling out to the underlying services. But even under that, Cata containers, I have them up here as Hyper-V was an effort announced to take Linux clear containers and combine them with the existing Hyper-V Run-V approach of running a pod inside a VM. And to move that forward so that if people do want more secure VMs over time, they'll be able to use those in a Kubernetes cluster. The Cryo project is really about a simple and fast container runtime that exists only to serve Kubernetes needs. And to open up the doors in the future in this area for even more exploration and optimization. If we want to do serverless, we're gonna need something that can start containers pretty darn fast. And I think there's a lot of fruit left on that particular optimization tree. Debug containers is a long running thing. I had to throw it up here because I feel so terrible about this because I've been a neglectful reviewer of this proposal, which is really the idea that if you're running in a production environment, you want to jump into a pod and bring your debugging tools with you. We've gone through 15 iterations of this. Lee, if you're out there, I'm really sorry, I apologize. But I'd like to see this move to completion because there are a lot of interesting things that we can do if we can get visibility into what's actually running in production. And we don't want to take tools away, but we want to be very deliberate about how we add those tools. And as I've gone through a whole bunch of technologies, these four stood out to me because they really are awesome examples of taking the ideas in Kubernetes and going way past anything that we would have thought about. I mean, the possibilities were there, but each of these projects in their own way took some unique aspect of the ecosystem, made it simpler, easier, in ways that we couldn't predict when we started. And so the KubeD project by Appstee is a cluster enabler for cluster ops on Kubernetes and has a lot of great ideas around the dynamic nature of Kubernetes. They use extensions and API resources and annotations so that an administrator can declaratively do many of the helpful things on their application and the KubeD parts will go and make magic happen. I really recommend checking it out. Arc by Heptio is another great example. It makes it really easy to take a Kubernetes namespace or a set of Kubernetes namespaces or an entire cluster. And because of the effort that we put in to have a simple and declarative model for APIs in Kubernetes, Arc was able to just go and grab everything by discovering all the APIs, the Kubernetes APIs, the extension APIs, the custom resources, bundle them all up, back them up. And then if you wanna restore them, Arc is able to go and reapply those back to your cluster in a very predictable way. So again, not something that anybody in the direct core Kubernetes team ever planned for, which people who are knowledgeable about Kubernetes and the ecosystem were able to apply the concepts and make something that makes people's lives easier. The Kube Router project simplifies both networking and the Kube Proxy to make services much more efficient. And it leverages some really cool ideas from other projects to deliver something that feels very Kube-native, but it's also something that we could not have anticipated or would not have designed ourselves. And yesterday's keynote about the Kube MetaController, again, the idea of making it really easy to add the next incremental thing to your infrastructure to empower your developers, your operators, and more of these projects exist out there. I could only find four, or I could only find four to put on the slide because if I keep talking, I could again go on for 10 or 15 days. So there's a lot of stuff, but it's not even a fraction of what's out there. How do we, you participate? We're a community, we're an ecosystem. I'm not gonna stand up here and tell people what to do. In fact, I would much prefer to work and listen about what people want. If you build something, tell others. If you're using something and it doesn't work for you, talk to them. If you can find someone to help make the next step or to bring their idea to fruition, do it. And if you can, create something new with the tools that everyone here has built and make the world a better place. Thank you.