 From around the globe, it's theCUBE, covering Google Cloud Next on Air 20. Hi, I'm Stu Miniman and this is theCUBE's coverage of Google Cloud Next. Happy to welcome back to the program. One of our CUBE alumni, Clayton Coleman, he's the architect for Kubernetes and OpenShift with Red Hat. Clayton, thanks for joining us again. Great to see you. Great to see you. All right, so of course one of the challenges in 2020 is we love to be able to get the community together. And while we can't do it physically, we do get to do it through all of the virtual events and online forums. Of course, we had the CUBE at Red Hat Summit, CUBECon for the European show, and now Google Cloud. So, first give us kind of your state of the state 2020. Kubernetes, of course, it was Google taking the technology from Borg, a few people working on it. And just that this project that has just had a massive impact on IT. So, where are we with the community in Kubernetes today? So, 2020 has been a crazy year for a lot of folks. A lot of what I've been spending my time on is taking feedback from people who, in this time of change and concern and worry and huge shift to the cloud, working with them to make sure that we have a really good foundation in Kubernetes and that the ecosystem is healthy and the things are moving forward there. So, there's a ton of exciting projects. I will say, the pandemic had an impact on the community. And so, in many places, we've reacted by slowing down our schedules or focusing more on the things that people are really worried about, like quality and bugs and making sure that the stuff just works. I will say, this year has been a really interesting one in open source. There's been much more focus, I think, on how we start to tie this stuff together and new use cases and new challenges coming into what maybe the original Kubernetes was very focused on helping you bring stuff together, bring your applications together and giving you common abstractions for working with them. We went through a phase where we made it easy to extend Kubernetes, which brought a whole bunch of new abstractions in. And I think now we're starting to see the challenges and the needs of organizations and companies and individuals that are getting out of, not just in Kubernetes, but across multiple locations, across placement edges, been huge in the last few years. And so, the projects in and around Kubernetes are kind of reacting to that. They're starting to bridge many of these disparate locations, different clouds, multi-cloud, hybrid cloud, connecting enterprises to data centers or connecting data centers to the cloud, helping workloads be a little bit more portable in and of themselves, but helping workloads move. And then I think we're really starting to ask those next big questions about what comes next for making applications really come alive in the cloud. Where you're not as focused on the hardware, you're not as focused on the details, but you're focused on abstractions like reliability and availability, not just in one cluster, but in multiple. So that's been a really exciting transition in many of the projects that I've been following. Certainly projects like Istio have been dealing with spanning clusters and connecting existing workloads in. And each step along the way, I see people starting to broaden their scope about what they want open source to help them solve. Yeah, it's been fascinating to watch just the breadth of the projects that can tie in and leverage Kubernetes. You brought up edge computing and want to get into some of the future pieces, but before we do, let's look at Kubernetes itself. 1.19 is kind of where we are at. I already see some threads talking about 1.20. Can you just talk about the base project itself, contributions to it, how the upstream works, and how should customers think about their Kubernetes environment? Obviously Red Hat with OpenShift set a very strong position. You've got thousands of customers now using it. All of the cloud providers have their Kubernetes flavor, but also you partner with them. So walk us through a little bit about the open source, the project and those dynamics. The project is really healthy. I think we've gone through a couple of big transitions over the last few years. We've moved from the original. I was on the Bootstrap Steering Committee trying to help the governance model. The full Bootstrap Committee has handed off responsibility to new participants. There's been a lot of growth in the project governance and community governance. I think there's huge credit to the folks on the steering committee today, folks part of contributor experience and standardizing and formalizing Kubernetes as its own thing. I think we've really moved into being a community managed project. We've developed a lot of maturity around that and Kubernetes and the folks involved in helping Kubernetes be successful have actually been able to help others within the CNCF ecosystem and other open source projects outside of CNCF be successful. So that angle is going phenomenally well. Contribution is up. I think one of the tension points that we've talked about is Kubernetes is maturing. One 19 spent a lot of time on stability and while there's definitely lots of interesting new things in a few areas like storage and we have Service V2 and Ingress V2 coming up on the horizon. Dual stack support's been hotly anticipated by a lot of on-premise folks looking to make the transition to IPv6. I think we've been a little bit less focused on chasing features and more focused on just making sure that Kubernetes is maturing responsibly. Now that we have a really successful ecosystem of integrators and vendors and unification of the conformance efforts in Kubernetes, there've been some great work. I happen to be involved in the architecture conformance definition group and there's been some amazing participation from that group of people who've made real strides in growing the testing efforts so that not only can you look at two different Kubernetes vendors but you can compare them in meaningful ways, that's actually helped us with our test coverage in Kubernetes. There's been a lot of focus on really spending time on making sure that upgrades work well, that we've reduced the flakiness of our test suites and that when a contributor comes into Kubernetes they're not presented with a confusing mass of instructions but they have a really clear path to make their first contribution and their next contribution and then the one after that. So from a project maturity standpoint I think 2020 has been a great year for the project and I want to see that continue. You know, one of the things we talked quite a bit about at both the Red Hat Summit as well as the KubeCon, CloudNativeCon Europe was operators and maybe I believe there was some updates also about how operators can work with Google Cloud. So can you give us that update? Sure, there's been a lot of growth in both the client tooling and the libraries and the frameworks that make it easy to integrate with Kubernetes. And those integrations are about patterns that make operations teams more productive but it takes time to develop the domain expertise in operationalizing large groups of software. So over the last year, the controller runtime project which is an outgrowth of the Kubernetes SIG API machinery so it's kind of an out shoot that's intended to standardize and make it easier to write integrations to Kubernetes that next step of going in past that Red Hat's worked with others in the community around the operator SDK which unifying that project and trying to get it aligned with others in the ecosystem. Almost all of the cloud providers have written operators. Google's been an early adopter of the controller and operator pattern and have continued to put time and effort into helping make the community be successful and we're really appreciative of everyone who's come together to take some of those ideas from Kubernetes to extend them into whether it's running databases and service on top of Kubernetes or whether it's integrating directly with the cloud. Most of that work or almost all of that work benefits everybody in the ecosystem. I think there's some future work that we'd like to see around folks from a number of places have gone even further and tried to boil Kubernetes down into simpler mechanisms that you can integrate with. So a little bit more of a beginner's approach or a simplification, a domain specific operator kind of idea that actually really does accelerate people getting up to speed with building these sorts of integrations. But at the end of the day, one of the things that I really see is the increasing integration between the public clouds and the Kubernetes on top of those clouds through capabilities that make everybody better off. So whether you're using a managed service on a particular cloud or whether you're running the elements of that managed open source software using an open source operator on top of Kubernetes, there's a lot of abstractions that are really productive for admins. You might use the managed service for your production instances but you want to use throwaway database instances for developers. And there's a lot of experimentation going on. So it's almost really difficult to say what the most interesting part is. Operators is really more of an enabling technology. I'm really excited to see that increasing glue that makes automation and makes DevOps teams more productive just because they can rely increasingly on open source or managed services offerings from the large cloud providers to work well together. Yeah, you would mention that we're seeing all the other projects that are tying into Kubernetes. We're seeing Kubernetes going into broader use cases, things like edge computing. What from an architectural standpoint, needs to be done to make sure that Kubernetes can be used, meets the performance, the simplicity in these various use cases? That's a good question. There's a lot of complexity in some areas of what you might do in a large application deployment that don't make sense in edge deployments but you get advantages from having a reasonably consistent environment. I think one of the challenges everybody's going through is what is that reasonable consistency? What are the tools? One of the challenges obviously is we have more and more clusters and a lot of the approaches around edge involve, whether it's a single cluster on a single machine and in a fairly beefy but remote computer that you still need to keep in sync with your application deployment. You might have a different life cycle for the types of hardware that you're rolling out, whether it's regional or whether it's tied to, whether someone can go out to that particular site that you've been updating the software. Sometimes it's connected, sometimes it isn't. So I think a need that is becoming really clear is there's a lot of abstractions missing above Kubernetes and everyone's approaching this differently. We've got GitOps and centralized config management. We have architectures where you boot up and you go check some remote cloud location for what you should be running. I think there's some productive abstractions that haven't been explored sufficiently yet that over the next couple of years, how do you treat a whole bunch of clusters as a pool of compute where you're not really focused on the details of where a cluster is or how can you define applications that can easily move from your data center out to the edge or back up to the cloud but get those benefits of Kubernetes in all those places. The fascinating thing about this is we're so early that what I see in open source and what I see with people deploying this is everyone is approaching this subtly differently but you can start to see some of those patterns emerge where you need reproducible bundles of applications, things that Helm can do well or you can do with just very simply with Kubernetes. Not every edge location needs an ingress controller or a way to move traffic onto that cluster because their job is to generate traffic and send it somewhere else but then that puts more pressure on, well, you need those, where you're feeding that data to your APIs whether that's a cloud or something within a private data center, you need enough of commonalities across those clusters and across your applications that you could reason about what's going on. So there's a huge amount of space here and I don't think it's just going to be Kubernetes. In fact, I want to say, I think we're starting to move to that phase where Kubernetes is just part of the platform that people are building or need to build and what can we do to build those tools that help you stitch together computer across a lot of footprints, parts of applications across a lot of footprints and there's a bunch of open source projects that are trying to drive to that today, projects like, I guess, DO and Knative with the work being done with eventing in Knative and obviously eventing is a hugely, we talk about edge, we'd almost be remiss not to talk about moving data and you talk about moving data, well, you want streams of data and you want to be reacted to data with compute and Knative and Istio are both great examples of technologies within the Qube ecosystem that are starting to broaden outside of the, well, this is just about one cube cluster to we really need to stitch together a mindset of development, even if we have a reasonably consistent Kubernetes across all those footprints. Yeah, well, Clayton's so important, there's so many technologies out there, it stops becoming about that technology and it's just a given, it's an underlying piece of it. We don't talk about the internet, we don't talk as much about Linux anymore because it's just in the fabric of everything we do and it sounds like we're saying that's where we're getting with Kubernetes. I'd love to pull on that thread, you mentioned that you're hearing some patterns starting to emerge out there. So when you're talking to enterprises, especially if you're talking 2020, lots of companies all of a sudden have to really accelerate those transformational projects that they were doing so that they can move faster and keep up with the pace of change. So what should enterprise be working on? What feedback are you hearing from customers? What are some of those themes that you can share and what should everybody else be getting ready for? The most common pattern, I think, is that many people still find a need to build platforms or standardization of how they do application development across fairly large footprints. I think what they're missing, and this is what everyone's kind of building on their own today that is a real opportunity within the community is abstract abstractions around location, not really about clusters or machines, but something broader than that, whether it's folks who need to be resilient across clouds, and whether it's folks who are looking to bring together disparate footprints to accelerate their move to the cloud or to modernize their on-premise stack, they're looking for abstractions that are productive to say, I don't really want to worry too much about the details clusters or machines or applications, but I'm talking about services and where they run, and then I need to stitch those into, I need to stitch those deeply into some environments, but not others. So that pattern has been something that we've been exploring for a long time within the community. So the open service broker project has been a long running effort of trying to genericize one type of interface operators and some of the abstractions in Kubernetes for extending Kubernetes and new dimensions as another. What I'm seeing is that people are building layers on top through continuous deployment, continuous integration, building their own APIs, building their own services that really hide these details. I think there's a really rich opportunity with an open source to observe what's going on and to offer some supporting technologies that bridge clouds, bridge locations, let you deal with computed a little bit more of an abstract level, and really double down on making services run well. I think we're kind of ready to make the transition to say officially, it's not just about applications, which is what we've been saying for a long time. I've got these applications and I'm moving them, but to flip it around and say, we want to be service focused and services have a couple of characteristics. The details of where they run are more about the guarantees that you're providing for your customers. We lack a lot of open source tools that make it easier to build and run services, not just to consume as dependencies or to run open source software, but what are the things that make applications more resilient in and of themselves? I think Kubernetes was a good start. I really see organizations struggling with that today. You're going to have multiple locations. You're going to have the need to dramatically move workloads. What are the tools that the whole ecosystem, the open source ecosystem can collaborate on and help accelerate that transition? Well, Clayton, you teed up my last thing I want to ask you. We're here at the Google Cloud show and when you talk about ecosystem, you talk about community, Google and Red Hat, both very active participants in this community. So you peer, you collaborate with a lot of people from Google on the floor. So give our audience a little bit of insight as to Google's participation, what you've been seeing from them the last couple of years. Google's been a great partner in the Cabrera's ecosystem for Red Hat. We worked really closely with them on Istio and Knative and a number of other projects. As always, I'm continually impressed by the ability of the folks that I've worked with from Google to really take a community focus and to concentrate on actually solving use cases. I think there's always the desire to create drama around technology or strategy or business and open source. We're all coming together to work on common goals. I really want to thank the folks that I've worked with at Google over the years who've been key participants. They've believed very strongly in enabling users, regardless of business or technology, it's about making sure that we're improving software for everyone. And one of the beauties of working on an open source project like Kubernetes is everyone can get some benefit out of it. And those are really, the sum of all of the individual contributions is much larger than what the simple math would apply. And I think that's, Kubernetes has been a huge success. I want to see more successes like that. Working with Google and others in the open source ecosystem around infrastructure as a service. This broadening domain of places where we can collaborate to make it easier for developers and operations teams and DevOps and SecOps to just get their jobs done. There's a lot more to do. And I think open source is the best way to do that. All right, well, Clayton Coleman, thank you so much for the updates. Really great to catch up on. It was a pleasure. All right, stay tuned for a lot more coverage at Google Cloud Next 2020. Virtually, I'm Stu Miniman. Thank you for watching theCUBE.