 Live from San Francisco, it's theCUBE, covering DevNet Create 2017, brought to you by Cisco. Okay, welcome back everyone. We're here live in San Francisco for theCUBE's exclusive two days of coverage for Cisco Systems inaugural event called DevNet Create Extension of DevNet, their classic developer program for the Cisco install base of network routers. Now, going to the cloud, native, going to the developer where DevOps and the enterprises are connecting. I'm John Furrier, my co-host, Peter Burris, our next guest is Dan Cohen, who's the executive director of the cloud native compute foundation, CNCF, formerly known as KubeCon, which is the event, kubecon.io. Dan, great to see you, executive director. How's business is going good? Fantastic, yeah, six months ago we chatted at our last event in Seattle and it's just amazing to see the progress since then, projects. It's been a whirlwind, so, I mean, even I can't keep track of it. You guys are like announcing all these new projects. What's the current count of projects that you guys have under the cloud native compute foundation? So we're up to 10. I should definitely start with the fact that Kubernetes is the kind of anchor 10 in our original project and a lot of ways the foundation was set up around that and that project is just continuing to do incredibly well where it's actually one of the highest velocity projects in the history of open source in terms of number of authors, number of commits, pull requests, issues, but now we have a constellation of other projects that are in support of that one that can be used in a lot of different ways that we've been adding in. And we had Craig McClucky on earlier now. He's with Heptio again when he was doing that work at Google back in the days with, what's his name from Microsoft now? Brendan Burns, yeah. Now it's an interesting question where you say, oh, wait a minute, the three sort of key people behind Kubernetes, Craig McClucky, Joe Beta, who's his co-founder at Heptio and then Brendan Burns, they all left Google. Is this a bad sign for the project and the technology? No, I don't think so. And we would actually say it's a spectacularly good sign. Now if they had left and said, oh, you know, containers, I'm going to go do virtual machines. But in fact, they said, oh, there's such an enormous market for this and to have Microsoft and Azure step in and say, we really want to invest in the space and we want to bring on one of the co-founders, Brendan, and then for the other two co-founders to say, hey, Google is making a huge investment but we also think there's an opportunity for independent venture funding to start. Well, Craig is completely passionate about this because there is an interoperability ethos that's always been around the open web, okay? And certainly open source has the same ethos. So cloud native brings an interesting thing and it's clear now that people, that there's not going to be one cloud winning them all. It's a multi-cloud world. Right. How is the cloud native foundation floating in the open source world? Is it gravitating towards more infrastructure, more edge, software edge? Are you guys kind of in the middle? Are you guys the glue layer? I mean, how do you view that? Sure, so one way of looking at what we're doing is helping to build a stack of software that allows you to run your applications either on bare metal in your own data center or on any of the public clouds or a hybrid solution where you're mixing back and forth. But the key idea is that all of the core parts of that are open source. They're supported by multiple different vendors and what that means is that you get to avoid lock it. So today, I mean, Amazon Web Services has some of the most extraordinary engineering. They have all these great services that make it very easy to go on board. But if you build your whole architecture around that, then you're stuck with AWS forever. And when it comes up, time to renegotiate your contract in a year or two, you're back again and don't have a lot of leverage. Where we think AWS is a fantastic platform to run Kubernetes, to run our other projects on top of. But we don't think you want to lock into those services to such a degree. So why don't I just, if I'm Amazon, first of all, pretend I'm Amazon and I'm a competitive strategist, lock in, I got to get you locked in. I'm just going to run Kubernetes on Amazon. Why don't I just do that and... We think that's a great solution. And Heptio and lots of other folks make it very easy to run Kubernetes on Amazon. But we also think you should at least look at Kubernetes on Bluemix, on Google, on Azure and know that in the future, when your negotiation comes up, even if you never leave, you can at least threaten to leave, that you're not locked into that one vendor forever. So if you think about how the cloud industry structure is starting to lay out, we knew we were going to have IAAS, and SaaS has been around for quite some time. And the big question is what happens with that platform as a service, the developer world. Some people think it's going to end up in the IAAS element, some people will end up in the SaaS. If it ends up in the IAAS and you got to lock in. Do you see a world going forward where developers have their own place where they go and create and build software independent of either target, but then add it to the various platforms? Is that a direction that you think this is all going to end up in? I do, our view is that Heroku, which really invented this platform as a service concept or popularized it, this you do get push Heroku and magically your application is up. And then Cloud Foundry, which came along and created an open source version of that, that those were two building blocks, but that Cloud Native is essentially taking that scenario and saying, hey, that continuous integration, continuous deployment pipeline, that ability to deploy your software dozens of times per day, that's an absolute table ante for being a modern company, not just a software company, but arguably every company today needs to be doing software development like that. And then Cloud Native is a whole set of infrastructure around that to allow you to not just have that environment and development, but also to push it into production. So compare and contrast based on your vision of how things are going to play out, a developer spends her time today doing this, and in three years, she's going to spend her time doing that. Kind of give us a sense of how you think that's going to play out. I mean, the simplest way to say it is that Docker came along a few years ago and was an incredibly transformative technology for software development and solved this really basic problem that you hire a new employee and does it take her an entire day or entire week to get her environment together or can she just copy over the Docker container and be ready to go? And so I would argue it had the fastest uptake of any developer technology in history. But now when you have all those pieces running, okay, that's great in development, how do you get it in production? And my goal is that in a few years that, or hopefully much sooner, that those developers that are getting the container, they're getting the different pieces of their microservices working, and then it's this tiny little YAML file that just says, here's the requirements for my application, here's what kind of redundancy it needs, what it's backend databases, other sorts of things, and they're deploying it up. And for most developers, they can get out of that business of DevOps of having to worry about all those issues. And then your DevOps team can be so much more efficient because Kubernetes and the related platform really enables that. I got to ask you, I just tweeted because I had wanted to get this on, make sure I captured it. I'm blown away by your success on the sponsorship participation. It usually is a sign of opportunity because there's money making to be made, but having the big vendors in there. But the growth of Kubernetes you mentioned out of the success, we're very well aware of that. But you got a lot going on. You got the tiger by the tails, your hair is blown back, you're running as hard as you can. Why are you guys successful? What's your gut here? Was it executive director? You got to have the 20-mile stare, but also you got to implement it here and now, how are you rationalizing the success? So I think the most important point is there's not some sort of magic formula that CNCF has done or the Linux Foundation and we're just so much better at promoting your marketing. At the end of the day, it really comes down to the developers behind Kubernetes that they built a tool that tons and tons of people want to use. And that leverages 15 years of work that Google has done on containerization, work that IBM and Docker and all of our other member companies, Red Hat, have put together. And now, I think tiger by the tail is the right analogy that we just happen to be, or luckily do have the technology and the constellation technologies that a lot of folks want to do. And so the biggest thing that we're trying to deal with is some of the challenges around scaling. That there's over 1,700 authors, individual developers, contributed to Kubernetes in the last 12 months, trying to figure out how can we get good reviews of all of their codes that are- Well, there is a secret formula to look at it. I mean, in a way, relevance is one of them, right? Being relevant and being an awesome technology. But what I want to get your thoughts on is, I looked at Kubernetes right out of the gate and said, hmm, will this be a map reduced moment for Google? And interestingly enough, they didn't pull the same move. They didn't just let Cloudera walk away with it or someone. They made sure that if they preserved it, I mean, Google kind of left map reduced on the side of the road and Google picked it up. I mean, Cloudera ran away with it. But Google also had something that they replaced it with. I mean, there's a- Yeah, Spanner's pretty damn good. You know, so, I mean, that's an interesting thing because in the world of strategy and a process technology, and this is related to this, is that it used to be that you define a process, and then let's call it the end level process, and then you go off and you make it obsolete because you had something that was more efficient, more effective, and then you license the old technology and that way the industry built capacity around the old technology and you had the new, more efficient technology that drove your business forward. And I think that, I'm not saying that's exactly what, I'm not saying that Google did that, but that's the- Yeah, Google knew. I mean, I have sources that tell me, I investigated this story three years ago, or maybe four, maybe three years ago, Google had conferences going up to the Eric Schmidt level and Larry Page level, do we keep Kubernetes? Do we open source them? And it went all the way to the top, and they almost wanted, because they were afraid of MapReduce because MapReduce was a lost opportunity, and now they made it up, but- Now, I would argue that there's actually a slightly subtler decision they had to make where, you know, they have this internal system board that is just tons of engineering and analysis and improvement has gone into it. They wrote Kubernetes as essentially a next generation version of that, and I think they kind of had four paths. So it was Craig Mclucky who was one of the key people behind that, where they could have made it a proprietary service that if you're a customer of Google Cloud, you get access to it. That's essentially what Amazon Elastic Container Service is today, or they could have said, hey, we're going to open source it, but we're going to still keep control of it, and essentially that's the path they went with the Go language, where lots of people use it, lots of people contribute to it, but it's Google who decides at the end of the day which direction it goes. Or they could have gone and created a Kubernetes Foundation, and if they'd gone to the Linux Foundation and said, we want to create a Kubernetes Foundation, they absolutely could have, and that would have been a home for it, but when you look at all the complimentary technologies that have come in, they would never have gone into a Kubernetes Foundation. So instead, they really chose the most open path of saying, no, we want to have a cloud native computing foundation, have Kubernetes be the anchor tenant for it, but then have a place that companies like Mesosphere with Mezos and Docker with Docker Swarm and other partners can come in and agree on something. So today we're really pleased to announce the container network interface just got accepted as our 10th project, and that's used by those and also by Cloud Foundry, and then they can disagree on others about the orchestration. So it's a liberating movement really, if you think about it, because at the time this happened, there was a lot of land grab talk going on, and certainly Amazon was winning big, the hockey stick was going up, we saw the numbers on the financial performance, but there was a fear of lock-in to your point. I think Kubernetes provides a nice layer, and you guys as a group are looking holistically and saying choice and multi-cloud, is that the vision? Definitely, but I mean, you can see strategically why Google decided to do it, because if you pick an open source platform and say, hey, this is a best of breed approach, now you're actually willing to evaluate the clouds on what the prices are, the supplementary services, et cetera, where before that you might have just said, eh, AWS is the safe service, I'm going to just go with that. But Kubernetes is an invasive technology, and I don't mean that in a bad way. When you decide to move with Kubernetes, you are foreclosing other options at your disposal. And so I think what you're saying is that Google wanted to ensure that it remained a consistent, coherent thing, while at the same time making it obvious to others around them that also wanted to invest in it, that their investments were going to be safe and sound going forward. I think that's fair, but on the other hand, I do want to say that very few companies have moved their entire business and all of their IT over to Kubernetes. Oh, I'm not saying that they would. And we do recommend that they start with the same services. But Mezzo and some of those other companies that are now investing in Kubernetes or making a bet on Kubernetes want to make sure that their bets are as good as their company is. Sure, but there are other orchestration platforms still. So Kubernetes has plenty of competition, and our biggest competition, of course, is inertia of folks not changing to anything. I got to ask you a question. So Leonard, our producer, is just telling me, Kubernetes is boring per Craig Mclucky. So Craig said earlier than theCUBE today, Kubernetes needs to be boring. And he said his biggest problem with Kubernetes is it's too exciting right now. That's great. Now, what he means by that is he's kind of making a play on words, but his point is it should be abstracted away in terms of Kubernetes. But that's the problem you have. It's too exciting. What's your reaction to his comment that Kubernetes needs to be boring? Well, he and I did a little Google Trends comparison of Kubernetes and TensorFlow, which is another open source project out of Google. And TensorFlow is something like three or four acts. And artificial intelligence is just so much more interesting and exciting. And yeah, I certainly would love to see a situation. You know, we have this metaphor for Linux with the Linux Foundation, that we describe it as plumbing, where it's so intrinsic to almost every piece of technology in existence. And like plumbing, you'll get very upset if it stops working and you'll know it and you'll complain, but there's a huge piece of what we're trying to do, which is just the infrastructure to make things work. Here's an idea, a marketing idea. Just call it AI for containers. And it will be the hottest thing on the planet. Dan, great to see you. You've been more exciting. Dan, great to see you. Congratulations on your success. So I do want to just make a quick mention. December 6th through 8th is CloudNativeCon. And CubeCon, it's our biggest annual conference. We're looking to actually triple in size from Seattle to 3,000 people or more. We have every expert coming in. Michelle Nourali and Kelsey Hightower are the co-chairs and are going to be speaking there. We would love to see a lot of you there. In Austin, guys, the Cube will be there. We'll definitely be there. Yeah, as well. We've been to the inaugural show for CubeCon and CloudNative Conference. We'll definitely be there. December 6th through the 8th in Austin. Great time for you to be in Texas. Congratulations on all your success. And as Kubernetes and the nine other projects continue to get traction, it's still exciting times. And as they say, we live in interesting times. It's theCUBE with more interesting, exciting, not boring stuff coming back from the inaugural event here at Cisco DevNet Create. I'm John Furrier Peter Burrow, stay with us. Hi, I'm April Mitchell and I'm the Senior Director of Strategy and Planning.