 LIE from Santa Clara in the heart of Silicon Valley. It's theCUBE, covering Cloud Foundry Summit 2017. Brought to you by the Cloud Foundry Foundation and Pivotal. Hi, this is Stu Miniman joined by my co-host, John Troyer. Happy to welcome to the program a first time guest. Chip Childers is the CTO of the Cloud Foundry Foundation. Chip, fresh off the keynote stage. Yep. How's everything going? It's going great. We're really happy with the turnout at the conference. We're really happy with the number of large enterprises that are here to share their story. You know, the really active vendor ecosystem around the project. So it's great. It's a wonderful event so far. Yeah, I was looking back. I think the last time I came to the Cloud Foundry show, it was before the foundation existed. Sure, yeah. You know, we were in the Hilton in San Francisco. It was obviously a way smaller group. Tell us kind of the goals of the foundation, doing the event, you know, bringing the community in. Yeah, yeah. So really, you can think about our goals as being, of course, we're the stewards of the intellectual property, actual software that the vendors distribute. But we see our role in the ecosystem as being really two key things. One, we're focused on supporting the users, the customers, and the direct users of the open source software. That's first and foremost. Second though, we want to make sure that there's a really robust market ecosystem that's wrapped around this project, right? Both in terms of the distributions, the regional providers that offer Cloud Foundry-based services, but also large systems integrators that are helping those customers go through digital transformation, replatform applications, really figure out their way through this process. So it's all about supporting the users and then supporting the market around it. Yeah, as we go to a lot of these events, there's certain themes that emerge. There were two big ones that both of them showed up in what you did in the keynote. Number one is multi-cloud, and number two is we've got all of these various open source pieces. What fits together, what interlocks together, which one sits side by side. Why don't we start with the open source piece first? Because you're heavily involved in a lot of those. Cloud Foundry, what are the new pieces that are bolting on or sitting on top or digging into it and what's going on there? I think first I want to start with a basic, the philosophy of our upstream community. There are billions of dollars that rely on this platform today, and that continues to grow, because we're showing up in Fortune 500, Global 2000, as well as lots of small startups that are using Cloud Foundry to get code shipped faster. So our community that builds the upstream software spends a lot of time being very thoughtful about their technical decisions. So what we release and then what gets productized by the downstreams is a complete system from operating system all the way up to including the various programming languages and frameworks and everything in between. And because we release a complete platform at a really high velocity, and so many people rely on its quality, we're very thoughtful about when is the right time to build our own? When should we adopt and embrace and continue to support another open source project? So we spend a lot of time really thinking about that. The areas today that I'd highlight around specific collaborations include the Open Service Broker API, which we actually spun out of being just a Cloud Foundry implementation, and we embraced other communities and found a way to share the governance of that, so we move forward as a big industry together. Yeah, and it speaks to that a little bit more. Very interesting to see, I saw Red Hat participating with OpenShift, Kubernetes is there, so how should customers think about this? Is it now, are the past wars over and now you can choose all the pieces that you want? Or it's probably oversimplifying it. I mean, I think it's oversimplifying, it depends, you can go try to build your own platform if you want, through a number of series components, or you can just use something like Cloud Foundry that has solved for that. But the important thing is that we've specifically designed Cloud Foundry to allow for the backing services to come from anywhere. And so it's both a differentiator for the various distributions of Cloud Foundry, but also an opportunity for cloud providers. And even more importantly, it's an opportunity for the enterprise users that they live in complex worlds, right? They're going to have multiple platforms, they're going to be multiple levels of abstraction from VMs to containers, the Paz abstraction, even event-driven frameworks. We want that all to work really well together, regardless of the choices that you make, because that's what's most valuable to the customers. Okay, the other piece, networking you talked about, why don't you share the update? Yeah, yeah, so besides the service broker API, we're adding, we have added support for what's called container-to-container networking. I don't necessarily need to dig into the details there, but let's just say that when you're building microservices, the application that the user is experiencing is actually a combination of a lot of different applications that all talk to each other and rely on each other. So we want to make sure that there's a policy-based framework for describing how the web tier is going to talk to the authentication service or is going to talk to the booking service or the inventory service. They all need to have rules about how they communicate with each other. And we want to do that in the most efficient way possible. So we've adopted the container networking interface as the standard plugin that's now at the CNCF, the Cloud Native Computing Foundation. We think it's the right abstraction. We think it's great. It gives us access to all the fascinating work that's going on around software to find networking, overlay networking, industry standard API to plug into our policy-driven framework. Along the same theme, Tubo, a big new news, a new project, also kind of integration of some Cloud Foundry concepts with a broader ecosystem. In this case, another CNCF project, Kubernetes. Speak a little bit to that. The Kubernetes community is doing a great job creating a great container-driven experience. And that abstraction is all about the container. It's not about the code. So it's different than Cloud Foundry. There are workloads that make sense to run in one or the other. And we want to make sure that they run really well. So the problem that we're solving with a Kubo project is what deploys Kubernetes? What supports Kubernetes if there's an infrastructure adage and a node goes offline? Because it does a great job of restarting containers, but if you have 10 nodes in the cluster and then now you're down to nine, that's a problem. So what Bosch does is it takes care of solving the node adage level problem. You can also do rolling upgrades that are seamless, no downtime for the Kubernetes cluster. It brings a level of operational maturity to the Kubernetes users that they may not have had otherwise. Can you burst inside a little bit? The creation of Kubo, is that something that the market and customers drove towards you? I've talked to a couple other Cloud Foundry ecosystem members that were doing some other ways of integrating Kubernetes. So what led to this way of deploying it with Bosch? Yeah, absolutely. So it came out of a direct collaboration between Pivotal and Google. And it was driven based on Pivotal customer demand. It also, if you speak with people from Google that are involved in the project, they also see it as a need for the Kubernetes ecosystem. So it's driven based on real world, large financial services companies that wanted to have the multiple distractions available. They wanted to do it with a common operational platform that is proven and mature, that they've already adopted. And then as that collaboration bore the fruit of the project, and it was announced by Pivotal and Google several months back, they realized that they needed to move it to the vendor neutral location so that we can continue to expand the community that can work on it, that can build up the story. The other topic I raised at the beginning of the interview was multi-Cloud. So you had a panel, Microsoft, Google, empty seat for Amazon was there. All of the cloud guys are going to tell you we have the best platforming and do the best thing for you. How do you balance the, we want to live in a multi-Cloud world and be able to go there versus they're, oh, I'm going to take standards plus and get in a little bit deeper to make sure that we're stickier with the customers there. What role does Cloud Foundry play? What are you seeing in the marketplace for that? Well, the public cloud providers, if you look at the services that they offer, you could roughly categorize into two things. One are the infrastructure building blocks. Two are the higher level services like their database capabilities, their analytics capabilities, log aggregation, and they all have a portfolio that varies. Some have specific things that are very similar. So when we talk about multi-Cloud, we talk about Cloud Foundry as a way to make use of those common capabilities. Now they're going to differentiate bates on speeds and feeds, availability, whatever they choose to, but you can then as a user have choice. And then secondarily, that open service broker initiative, it was really about saying, great, there's also all these really valuable additional capabilities that as a user, I may choose to integrate with a Google machine learning service, or I may choose to integrate with a wonderful Microsoft capability or an Amazon capability. And we just want to make that easy for a developer to make that choice. Chip, we, Cloud Foundry was very early in terms of a concept of a platform of services, let's not call it platform as a service right now, but this platform that's going to make developers' lives easier, multi-target, multi-Cloud, we call it now, on your, from your laptop to anywhere. And it's been a really interesting discussion over the last couple years as this kind of parallel container thread can come up with Kubernetes and Mrs. Fair and all the orchestration tools. And the focus has been on orchestration tools. And I've always thought Cloud Foundry was kind of way ahead of the game and saying, wait a minute, there's a set of services that you're going to have for a full lifecycle, day two operation at scale that you all are going to have to pull together from components. Is, as we're doing this interview here and this year at Cloud Foundry Summit, are there anything that you think people don't kind of realize that over and over again people who are using Cloud Foundry go, wow, I'm really glad I had logging or identity management or what is some of the framework that people sometimes don't realize is in there that actually is a huge OPEX and time saver? Yeah, there are a lot of operational capabilities in the Cloud Foundry platform, when you include both our Bosch layer as well as the Elastic Runtime, which is the developer-centric experience. Anything that people don't quite, don't often realize is in there? Well, I mean, I think that it's, the right way to think of it is, it's all the things you need to deploy an application, right? So we've been doing this for years as developers. We, you know, an application operations team. We've been doing it. We've just been doing it via a bunch of tickets, we've been doing it via a bunch of scripts. What Cloud Foundry does is it takes all of those capabilities you needed to really trust a platform to operate something on your behalf and then give you the right view into it, right? The appropriate telemetry, log aggregation, and know that there's going to be good health monitoring there. It makes it really easy, right? So, you know, we were talking earlier about the haiku that Ancik Bakuri from Pivotal had authored. It's appropriate. It's a promise that the platform makes. And Cloud Foundry's designed to let a user trust that the declarative nature of asking the platform to do X, Y, or Z will be delivered. Chip, we've been hearing, Pivotal talks a lot about spring when Cloud Foundry's involved. Is it so much so that the foundation needs to be behind that or support that? How does that interact with work? Well, we're super supportive of all the language in framework communities that are out there. You know, even if you pick a particular vendor, they, Pivotal in this case, has a very strong investment in the spring, spring Cloud, spring boot. They're doing really amazing things, right? But that's also open source software. You know, they steward that community. So all the other vendors actually get the advantage of that. Let's take .NET and Microsoft. Microsoft opensource.net, right? So now you can run .NET applications on Linux. They're embrace of the container details and the APIs in their operating system is making it so that now it could also run on Windows, right? So the whole Microsoft technology stack, languages and frameworks, they matter quite a bit to the enterprise as well. So we see ourselves as supportive of all of these communities, right? And even ones like the Ruby community. So when there's an enterprise developer that chooses to use something like Ruby with Ruby on Rails framework, they, if they use platform, they're getting the latest and greatest version of that language framework. They know that it's secure. They know it's going to be patched for them. So it's actually a great experience for that developer that's working with the language. So we'd like to support all of them. We're big fans of any that work really well with a platform and maybe integrate deeper. But it's a polyglot platform. I want to give you the final word. Just people take away from Cloud Foundry Summit 2017. What do you want to then do? Yeah, the simple takeaway that I'd give you is that this is an absolutely enterprise grade open source ecosystem. And you don't hear that often, right? Because normally we talk about products being enterprise grade. Did somebody say in the keynote, enterprise grade mean that there's a huge sales force that's going to try to sell you stuff? Well, that's coming from the buying side of the market for years. And it was a bit of a joke, right? But is enterprise grade? Well, it means that there's a piece of paper that says this product will cost X dollars and the sales person is offering it to you. So of course it's going to be enterprise grade. But really, we see it as four key things, right? It's about security. It's about being well integrated. It's about being able to scale to the needs of even the largest enterprises. And it's also about that great developer experience. So Cloud Foundry as an ecosystem and all of our downstream distributions get the advantage of this really robust and mature technical community that's producing the software. I really appreciate you sharing all the updates with us and appreciate the foundation support to bring theCUBE here. We'll be back with lots more coverage here from the Cloud Foundry Summit 2017. You're watching theCUBE.