(upbeat music) >> Announcer: Live from San Diego, California, it's theCUBE, covering KubeCon and CloudNativeCon. Brought to you by Red Hat, the Cloud Native Computing Foundation, and its ecosystem partners. >> Welcome back, this is theCUBE's coverage of KubeCon, CloudNativeCon 2019. And a special segment, we're actually going to doing our 2020 predictions. I am Stu Miniman, joining me, my two co-hosts of the week. To my left is Justin Warren, who I believe's been to, you went to the first one? >> I've been to all four, yeah. >> All four of the North America shows. >> Yep. >> I personally have been now to three of the North American, as well as one in the Barcelona. And we have a first time KubeConner, but long time host of theCUBE and things, John Troyer to my right. Gentlemen, thanks so much for joining us. So first thing, the rapid fire. 12,000 in attendance. Last year 8,000, the year before 4,000. So, my math says that it will be 16,000 when we come next year to beautiful November in Boston, Massachusetts, which I can drive to. We've had snow in Austin, rain in San Diego. So, I'm predicting 60 to 70 degree weather in Boston, 'cause that never happens in Boston. Number of attendees next year, Justin? >> Well, it was doubling and now they have dropped it to 50%, so I reckon another 50%, I'll reckon 18 to 20,000. >> Stu: Oh, John? >> Yeah, I'll go higher. That many plus one. >> Okay, I feel like we'll do, I bet $1, $1. But, okay-- >> We have not hit peak Kubernetes yet. >> No. >> We definitely have not hit peak Kubernetes. One of the things, I keep looking for the theme of the show, and one of the things, we've been talking in some of the segments, is there needs to be simplification. When we talk about where we're at with cloud adoption, when we talk about some of these environments, there is a broad ecosystem. So, there needs to be some winnowing down of the technologies. We've seen some areas where things like MicroK8s and K3s to be able to be able to put Kubernetes at the edge. It's not that, that will replace Kubernetes, but things need to get simpler in some environments. Justin, I'll throw it to you first. Is simplification the theme of the show, is there something else that's grabbing you? >> The theme for me is that the money has arrived. We saw a little bit of that last year but this year it is definitely just the number of sponsors that we have here, the number of startups that we have here, the ecosystem, the number of parties, the VCs are here. This feels like a lot of other technology shows that we've been to before in their hay day. We are right here in the hay day of Kubernetes. So, I can see it getting bigger. Will there be consolidation? Yes, I think there will. But I think that this is going to broaden out further first. I don't think that we're quite at the point where things need to start collapsing in. I think we're still going to be exploring all the different options that we have. I think the theme is simplification, yes, I agree. But it's now going to be people trying to solve that problem by creating these higher-level services, managed-Kubernetes offerings. A lot of the different component projects that are there, we're going to see a lot of options where they try to manage that for you and make it easier to consume. But there will be several different attempts at that and not all of them are going to survive. >> Yeah, I'll go with you. Simplification's going to be an issue. Has to happen, we saw a lot of different stacks here at the show, if you go out on the show floor. A lot of people are trying to give you a generic platform. A general-purpose platform, maybe it has its own opinionated view of networking, or storage, or management, or security. But at the end of the day we need things on top of the platform. So, I'm hoping next year we see more things on top of the platform, more applications. We saw some big data applications this year. But people are still building engines and I want them to build cars, because not everybody can build the engine. >> Justin: Yes! >> Well, and actually, Justin, a question for you is when we talk about Kubernetes, there's so many people I interview here and they're like, "Well, no, "we know how to build it better than others "and when you want to go across all environments "we should do it." Is that, are we still going to see that for awhile? Or, can we all hold hands, and talk about open source and be able to just manage across all of these environments? >> Well, one of the key founding principles of Kubernetes is that you can operate it the same everywhere. If it's certified Kubernetes, it should function the same, no matter who's build of it it is. So, that just provides us a common platform that we then build on top of. So, I think the main differentiation's going to be on things like the tooling and the services that allow you to operate that base layer of Kubernetes. But that base layer of Kubernetes is about interesting as Ethernet. It's extremely pluggable and it's just ubiquitous, but no one really cares which brand of Ethernet you happen to be giving me. I care about all the stuff that I run on it. And that's what I think that we're going to see a lot more, I'm with you, John. We're going to see a lot more of those services. I'm seeing a bunch of startups at this show that are starting on that journey, they're providing a lot of things like database services, very highly-tuned monitoring and measurement telemetry systems. There's a big push to make sure that there is a certain amount of interoperability between these different services. Things like having open telemetry be the standard for sending telemetry information around. Because everyone knows that if we all build to Ethernet we're all going to have a much better time of it, than if we all start trying to come up with our own version of it and call it Banyan VINES, and FidoNet, and God knows what. >> Okay, I'm glad you brought up the example of Ethernet. First of all, I have no problem watching a 45-minute discussion of what 400 Gig's going to look like, and the challenge and the opportunities. And if you are talking Ethernet in someone's data center, for the most part they're going to run that on a single vendor because while there is interoperability, it's not until I go to the Internet, because layer two, I want to keep it single vendor, when I go layer three I want to do that. Is that, maybe it's not the best analogy but Kubernetes-- >> No, I think that's reasonable. And if you're trying to operate something across different environments then it's much easier if the two environments can talk to each other. Simple example that people tend to forget about is M&A. If one company goes and buys another one and I run Banyan VINES and you run, I don't know, FinLand or something, then we can't talk to each other, and integrating those two companies becomes impossible. But at least if we both have, you might have Juniper, I might have Cicso, those two network sets can still talk to each other. You might be running, I don't know ,Mesosphere, and someone else might be running Mirantis or Rantia, and that's their system for operating Kubernetes. Turns out, actually if you can operate it much the same, one of you can decide, you know what, we're going to operate everything with Rantia, 'cause we think that that's going to be the best thing for the holistic company. You may keep them separate. As long as you get the same outcome then it doesn't really matter. >> Yeah, that's why I think we aren't yet at peak Kubernetes. Those Kubernetes skills that are in high demand from a job market that people are being upskilled on, they're actually still going to be useful. Now, these stacks that these opinions that people are doing. I mean, they want us to talk about people over projects, right? That's a great philosophy, this is a very friendly community, it's very open source. But, cynically, I think, and sometimes people swap your company T-shirt for your project T-shirt that your company is the one that's behind. And that's kind of a, that's a little bit of a bait and switch. Yes, it's an open source stack. Yes, all the major vendors have open source, 100% open source stacks around Kubernetes. But they're all with different projects and they all pick their own projects. So, I think that is yet to be resolved. >> Well, it's interesting 'cause the thing that I heard is it used to be open source was something that people contribute to it. Now, the majority of people that contribute to open source do it as part of their job. So, there is some of that. Yes, I'm paid by company X, but my job is to participate in the community. There is a large company that got bought by $34 billion. They have a lot of contributors out there. Their job is open source, they are on those projects, they might switch from one project to another. We had Kelsey Hightower on today, he's like, "Hey, right, "but we need to think of people above project. "It's okay for them to move from one to the other "between projects or between companies." But, right, it is very much often companies that are behind the scenes and pushing people and dollars into these projects. One thing I like about the CNCF here is we do have, there's 129 end-user companies participating here, so we've reached a certain maturity level that they are driving it, not just companies driving it for the dollars. So, I guess the thing I want to ask though is, there's so many companies here, we started off the conversation this week, John, talking about Docker. And the cautionary tale of how many companies, when I asked, "What is your business model, what do you do?" Is, I created some cool new project. What does that mean? You look at the business model. You live right with Silicon Valley there. What are you seeing as you look forward? What do you expecting to see consistently? >> Oh sure, I mean, half the logos will be gone but they'll be swapped out for other logos, so that's all fine, right? If you have a point solution, as I was kind of pointing out, things are kind of stackifying. So, things need to consolidate from a buyer's perspective. A lot of the sessions here were about custom projects that people did, either in-house or for a customer. So, I think that's okay, that's the natural, it's the natural Cambrian explosion and then die off. >> Yep, creative destruction. (John laughing) That's the general point of how we do things. There's a lot of things that are basically a feature and you can't really build a company behind a feature. They're hoping that they will find some sort of pathway to money, we've seen some big acquisitions where they didn't really find a good route to money. That's fine, people will figure that out. And how you fund this development, Stu, I mean that's the perennial problem. At the moment it's possibly not the perfect solution but it's a pretty good one, in that we have developers are employed by a company that pays them to develop open source software. So, anyone can go and grab that software and then use it. So, we don't actually really depend on that company sticking around. >> And enterprise sales, it's still very expensive to have even a small booth here, and three or four people and nice T-shirts, and all of your swag, and you flew them here. And fly them all around the country to company after company, conference room after conference room. That is an expensive model to sell things. I mean, you need to have a fair amount of revenue. >> All right, so, Justin, a lot of progress, a lot of projects. >> Yeah. >> What's missing? Look out for 2020, is there an area or a space that needs to mature or needs work? What's your advice for this ecosystem? >> Well, for me it's all about the data. So, we've seen a lot of evolution in stateful sets and being able to manage state-based data within the Kubernetes ecosystem, a lot of progress on that, but there's still a long, long, long way to go. Also, just on the general operational tooling. So, the things that we are used to and have taken for granted in other traditional, like vSphere, or we've come from the VMware ecosystem. Simple things like higher availability. So, I need my data to always be available and I need to be able to have this managed. There's a lot of stuff in there but there's still a lot more stuff that needs to happen. Service mesh and that service discovery and making that easy enough for normal mortal humans to deal with, that still really isn't there. You kind of have to be a bit of a super genius to configure that and get it working and operating. So, there's still a lot of very hard work on these quite hard problems, to then make it look simple. >> Yeah, so, John, the one I want to throw to you is Dan Kohn came out on the keynote stage yesterday and he said, "Kubernetes has crossed the chasm, "yet most enterprises are still worried "about software failure." We know many people that are coming in new and shell-shocked when they come to look. What does the industry as a whole and this ecosystem, specifically, need to do to make sure that we don't come a year from now and say, "Wow, things slowed down "because we kind of couldn't get "the vast majority of people on board?" >> Well, I mean, we're going back to, I guess then the same thing, things have to be simpler. In times of uncertainty people either stop or they go to a trusted provider. There is, probably, although there's a high value on Kubernetes skills right now, that also means there's not enough folks. So, if you can't get the engineers. That was a problem in previous generations of some of these stacks, in that if you couldn't get enough engineers, or if the stack, if everybody had their own snowflake version of it and the skills were not transferable you could not move forward. So, I'm hoping we'll see more managed service providers. I'm hoping that we'll see more startups and services built on top of these existing infrastructures, I think we're seeing more of those. I see a lot of stuff in the operations space and kind of the SRE space, the incident management space. Kind of all the tooling you'll need to actually run these things in day two and beyond. And then, hopefully, the industry keeps pounding on digital transformation and process transformation. One project at a time, you start with one, you start small, you start tooling, you start tooling up, you get some small things under your belt and start to learn. But that's enterprise timeline. So, at a certain speed. >> All right, last thing, any aha moments, surprises, cool things as you've been going around the show? Justin? >> Oh, just walking into the show surprised me. Just how big it has gotten and how much energy there is here. It's amazing to me and I can just only see it getting bigger and, I hope, better. I am surprised by the reaction from people who haven't come into the Kubernetes ecosystem, I think. There's still a lot of people out there for whom this is a big surprise. That it's as big a show as this is, there are lots and lots of people out there who can't actually spell Kubernetes. So, there's a lot of work for us to go and do to figure out how we get those people to come into this ecosystem in a way that doesn't shock them and scare them away. >> Yeah, absolutely. Welcome to the party, those of you that had been joined. John? >> Hey, the thing that surprised me was this is both a multicloud show and a non-cloud show. This is the only show where people working in multiple public clouds can come together. So, that's one of the systemic forces causing it to grow. On the other hand, this is not a public cloud-only show. Over and over again, we talk to people here on theCUBE, I talk to people on the show floor, and most of their workloads, or many of their workloads, are on-premises, right? Kubernetes is fully functional and fully up to speed in private cloud, in people's data centers because it is useful. And they're starting to do that process tooling and process re-engineering, even on-site. And then they may be using a portfolio of different clouds. So, I think that was one of the surprising things to me is this was not 100% public cloud show. >> Yeah, and a little bit of caution I'll give there is we want to make sure we don't become complacent and say, oh, well, we could just kind of slide in what we were doing before and not make some change because the driver here, we've been talking about for decades now, was really kind of that application modernization. And Kubernetes and this whole, it is about cloud-native. It's not the Kubernetes, it's the cloud-native piece. >> You know what I didn't hear? I did not hear putting legacy apps on Kubernetes as much this year. Much quieter this year. >> So, and I'll just say, I'll highlight, we did an interview yesterday with the American Red Cross. Tech For Good, it's something that we've been highlighting, John, for especially helping lead the charge and make sure we highlight that. The Microsoft show, they very much talked about that this year. American Red Cross is saying, hey, we always want your dollars but we'd also love your skillset. So, if this community, and specifically Kubernetes, cloud-native ecosystem makes it easier. There's common tooling, something that I've been hearing a lot this year is when I go through that modernization I can hire the next-generation workforce. There's too many of those, oh, I'm doing it the old way. If I don't have somebody with 30 or 40 years experience in the industry, you won't understand our systems and we need that next generation of workforce to be able to get involved. So, love future jobs, Tech For Good, all good things. This community's always been strong on diversity and inclusion. And so, I guess final word I'll say, big shout-out to, of course, the CNCF, this event, they have a large menagerie that they need to take in here and manage, and they're doing a good job. There's always things to work on. They are listening and open. We have really appreciated the partnership. A huge shout-out, of course, to our sponsors that make it possible for us to do this. So, for Justin Warren, for John Troyer, I'm Stu Miniman, thanks so much. We definitely are excited for one more day. Tomorrow, as well as next year in 2020, Amsterdam and Boston. Please reach out always if you have any questions. And thank you so much for watching theCUBE. (upbeat music)

>> Announcer: Live from San Diego, California, it's theCUBE, covering KubeCon and CloudNativeCon, brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to theCUBE here at KubeCon CloudNativeCon, 2019. Second day of three days, wall to wall coverage. I am Stu Miniman, John Troyer is my cohost for the three days, and we've had a great schedule, but this one will be super dope, of course, 'cause it is the one, the only >> That's the right phrase to use >> Kelsey Hightower >> to bring me out. >> who is now a principal developer advocate at Google Cloud. Kelsey, thanks so much for joining us. >> Well, thanks for having me. >> All right, let's start. You did a keynote yesterday and I actually heard, not only did it rain in San Diego, people were talking about allergies. They were grabbing their tissues, eyes seemed to be tearing. You had stepped back for a little bit. When I first came into this show, we've been doing it for four years, it was, you know, Kelsey Hightower and Kubernetes almost seem to get top billing of the show. You specifically stepped back for a little bit, and you're here this week. So, talk a little bit about that piece. >> Yeah, so I stepped back to do some serverless stuff, right? So I worked on some cloud function stuff at Google, launching the ghost support for cloud functions, and really trying to understand the serverless base by being in it, and that means stepping back from Kubernetes quite a bit. So the keynote, I wanted people to have emotion. So no live demos, no slides, no speaker notes, and then just telling stories from the last six years of being a part of the Kubernetes community, and making people feel something. And I think it resonated with folks, and, of course, people got a little teary-eyed. I gave people a cover, so we just kept saying the allergies are starting to flare up in the room, and we really connected with people. >> Awesome. So you came back, which means serverless not completely taking over and obviating what we've been doing here for years. >> Yeah, I think serverless is just another tool in the toolbox, and I didn't want to miss it. So before I put it in its category, I wanted to make sure that I got super deep with it, used it myself, gave it a fair shot, and it definitely deserves a place. But I think the idea of serverless is the thing that's going to stick. This idea of eliminating as much infrastructure as possible and then putting that everywhere we can. >> I want to bring that idea of a tool in the toolbox to what we're talking about at this show. >> Kelsey: Okay. >> So, you know, Kubernetes is one of the most hottest topic at the show. The CNCF, now I mean, there's dozens and dozens of projects here. Dan Kohn, when he kicked it off, talked about Minecraft. And it's like there's that board there with all the tools, and, oh boy, which one do I pick, and how do I use it? >> How do you look at where Kubernetes fits in the overall landscape? Obviously, 12,000 people, it's really exciting. Why is there so much excitement around something that I think is really, it becomes another tool in the tool shed and baked into the platform? >> I think Kubernetes represents a problem that most people have. If you went down the Linux and then virtualization path, then you ended up with a bunch of virtual machines that you need to glue together somehow. So if you look inside of what Kubernetes has, like the scheduler, how it takes in the pain of running a workload. If you're running VMs in Linux, this is a problem you already have, so Kubernetes just resonates with almost everyone that is using virtualization. This is why it's so popular. So it fits. Now every tool in the landscape may not resonate the same way because everyone doesn't have the same set of problems around the edges, but Kubernetes is a very obvious thing to anyone that's managing more than a handful of machines. >> Well, I think that brings up an interesting question of, as companies and people assemble the stacks, right, assemble the engines out of the components, do you have any thoughts on, well, I guess we could take it from a couple of different ways. But maybe as a person coming here for the first time, representing their team, getting started, maybe not involved online with upstream Kubernetes but trying to make sense of the landscape here and all the different, the zoo of different projects. >> Lots of new people here. You talk to people, I think, what, 50% or more of the people are brand-new. People have been ignoring, rightfully so, Kubernetes for four or five years. "Maybe I don't need it, I'm good where I am." But we're at a point now where you can't ignore it. VMware's offering Kubernetes, every conference you go, where it's KubeCon or not, this is the thing they're talking about. It's just like Linux was years prior, right? It's just the thing that people are doing. So now, you're coming to see for yourself first-hand. You're coming to ask people how's it going, now that we're five years in? There's a sense of maturity, things are slowing down, the ecosystem's getting a lot more mature around it. So you almost have no choice but to be here because now it's in your world. >> All right, so, there's some people that I've been seeing online that are still looking at this a little bit skeptically, and said, "You know, we've been down this path before." You know, "Oh, everybody's involved in Kubernetes." you know, "There's my Kubernetes "versus some of the other environments." How should we think about that? 'Cause as you said, it's going to be baked into VMware when they do project-specific, and they've got a couple of ways to get you to Kubernetes. Yeah, Microsoft just announced an update. Is it an inter-operability issue? Is this the universal backplane? Do you have a good analogy as to how we should be thinking about where we are today and where we need to go so that we don't repeat the sins of the past when it was the multi-vendor mess that really didn't solve the customer's problems. >> You're going to always have multi-vendors because there's too many customers for one vendor to satisfy. That's always going to be the case, there's no way around that. But the way I look at Kubernetes now is like, take the web. Click around, webpages, link them together. And out of that, we extracted REST. People can build APIs, we build tooling on top, cloud providers built APIs to manage infrastructure. So the REST component comes out of the larger picture of the web. And when we take the larger components of Kubernetes, and we extract out that Kubernetes API, you get Istio, you get these network control plans, you get people building 5G infrastructure using that Kubernetes model. You get all the cloud providers saying, "Now, if the world's going to have "this set of APIs that are based on Kubernetes, "then I can actually build a global control plane "because I can assume that Kubernetes' API everywhere." Not just for containers, also for networking, authorization, management systems. So it's only natural that people start moving up the stack, and I expect even more panes, ever more fragmentation, if you will, because now it's so much easier to explore a new idea, even if it's only for a smaller subset of the market. So I expect it to explode. >> Yeah, one of the things we've been looking at this year is really the simplicity of the offering. You had done Kubernetes the hard way a couple of years back. We've been looking at things like lightweight Kubernetes, the K3s. How are we with that simplicity of the overall solution and making sure that Kubernetes can reach its potential to get to all of those use cases and end points that you were talking about? >> Kubernetes' job is to manage the complexity. If you need to run in multiple regions across the globe, that is a set up complexity, Kubernetes has one way of addressing it by sitting on top of all those VMs globally, and then providing a set of APIs. That Kubernetes set up end cluster is going to be way more complex than a MicroK8s, where you have a single virtual machine where you install the components on one machine, you don't deal with networking, you're not dealing with multiple nodes. That flow is super-easy. I think I did a tweet for the Canonical folks. They have a tool called MicroK8s, you just run one command, you have a Kubernetes cluster, and off you go. And that's great for a developer, but as the underlying infrastructure gets more complex, I think the overall cluster, and the components that you need in that cluster, matches the complexity. So I think Kubernetes has proven to scale up, and now you can see it's scaling down. So I think it's one of these things that's adapted to complexity, versus having to jump off of the platform because it can't meet either range. >> Now, Kelsey, we've talked a little bit about both Kubernetes as this universal API, but also being embedded, right, and being below a lot of application layer and other management-layer things, I mean, did you think about talking to our fellow technologists, right? There are some people who are going to be, we've also used the metaphor, mechanics, right? There's some people who are going to be the mechanics, but, like, everybody drives. So, as we get to this level of maturity here now at KubeCon 2019, any advice on how people should pick? Do I need to, and also online we hear a lot about, "Oh, I don't need, I don't know if I need Kubernetes. "I don't know if my particular use case right now, "boy, I don't know if I want to go there." So, I mean, how should people be looking at it? And also up scaling, should every IT and technologist and developer be working towards Kubernetes? >> Absolutely not. >> Thank you. >> If you're managing a bunch of machines, you got two choices. You could build a lot of custom tooling and build something that looks like Kubernetes, most people don't have the time to do that. So what we want to do is say, look, a lot of people are collaborating on that obvious thing that you should build to manage that. Now if I give you 80% of your time back, you should go and fill in that gap between what Kubernetes brings to the table and what your developers want to actually do. And at the end of the day, it's always been the same thing. You check in code, it should adopt the company's best practice, and I should be able to get an end point and some debugging tools. That has always been the north star, even when there was virtualization, early days of cloud. Kubernetes is no different. The thing that Kubernetes represents, though, is that you don't have to build as much glue between either your own VW ware or your pre-early cloud. Kubernetes has built all that stuff way up to this line, so maybe you actually finish that CICD part you were supposed to do anyway. >> All right, so, Kelsey, every year we try to figure out and distill down the theme of the event. A couple of years ago, the service matched really extensions were going at it. Here, there's so many different pieces, it's a little tough to kind of pin down. We talked about some of the edge simplicity use cases, security has, of course, been a discussion for a couple of years. Anything that you've distilled so far or the things that you are finding most interesting and new, kind of at the edges of this whole ecosystem? >> This whole thing is a Swiss army knife, so it depends on who's holding it. Whatever problem they have, that's the piece of the tool that they're going to make front and center. So that's what this is. And right now I think there's a lot of confusion on, do I even need all the other components in this Swiss army knife? Some people are just like, "Well, this tool looks interesting. "I don't have a problem that this tool is for." And some people are actively creating a problem so they can use the other tools in the Swiss army knife. I think the biggest thing that I've seen in the last two years is, make the new thing work the old way. So you're getting the more traditional vendors showing up and adding their Kubernetes integrations, and they're making the new thing more familiar to the people who have the existing tool. And when I look around, that's the thing that I see arise. "Hey, that firewall you were using? "We now have Kubernetes support. "That security tool you were using? "We now have Kubernetes support." The security tool works fundamentally the same, it's just now easier to adopt and maybe make Kubernetes things that are deployed in it, leverage those thing. >> So you're saying that's a good thing, not a bad thing. >> It's a good thing, but it can also be dangerous in some cases where we may get complacent a little bit, and what we end up doing is recreating the world that we tried to run away from a little bit. We try to create a little distance and maybe rethink a few of these approaches, maybe eliminate some need for some of these things. But if we get stuck in recreating the old world on top of the new thing, it doesn't really benefit anyone if we did that for too long. >> Yeah, it's interesting 'cause you talk to the enterprise and only 20% of applications are in the cloud, and if you talk about, out of my entire portfolio, how many are really new Cloud Native applications? Its much smaller than that 20%. So we know it's the long pole in the tent of modernization, but you spend a lot of time talking to customers, you're traveling the world, what are some of the best things that you're seeing out here that are helping people adopt those new environments and not just stake a place in, as you said? >> Pragmatism and leadership, if I see those two things. If there is someone that can make a decision. I see Spinnaker, I see Jenkins, I see a thousand things, I see the options. Leadership is pick one. They roughly do the same exact thing. You get someone that knows what they're doing, hires someone, get some help, make it work. And then the pragmatism is just be honest about your velocity. You might only bring in the VMs, and then you go to containers. So, this all or nothing approach never worked. You know it doesn't work. So I think when you have those two fundamental things, then you see a lot of success. And it's not about the age of the enterprise, either. There are hundred-year-old companies are making it work because they have the leadership component, and they're very skeptical, so they approach the problem with pragmatism, so they actually get to production. Sometimes faster than the startups that are trying 7,000 things in more of a reckless fashion, the whole thing catches fire. So, those are the positive outcomes that, there's so many tools now. You have your traditional vendors now with skin in the game, giving you documentation. I think right now, if you've got those two components, you're on your path to success. >> Yeah, I guess last thing, I want to get your thoughts just on this community these days. A couple of the keynote speakers today really talked about project over company, and definitely the open-source ethos is front and center at our show here. Give us your viewpoint how the community's doing and any highlight you want to share. >> So I have one more thing on top of that hierarchy, is people over projects always. And then that means that the people should be able to say, "Hey, I am not wedded to this project forever. "There's going to be a time when we have to jump off, "there's going to be a time when we have to learn "from the other communities." And if you do that, then we can actually be on the straight path. If we put the projects too much front and center I think we start to miss the boat. Kubernetes, Kubernetes, and the rest of the world is moving on. And then we look up, we've missed it, and we actually didn't even get to contribute to the new thing. So I think the biggest part about this community is that hopefully we keep the thing going where we keep reminding people, it's people over these projects. And I think in my keynote, I was trying to address the idea that we're just kind of pacesetters. You come in, you contribute, all contributions are welcome, documentation, code, or leadership, and then sometimes you got to jump back out and allow someone else to come in and set the pace and let the ecosystem become the marathon and let it keep running. >> All right well, Kelsey, thank you so much for sharing with our community. I tell ya, I've had countless stories of people over the years that have talked about how they've reached out to you, you've helped them along the way, and I know everybody in this ecosystem really appreciates everything that you've helped to move this to where we are today. >> Awesome, thanks for having me. >> All right, for John Troyer, I'm Stu Miniman. Super dope coverage of KubeCon CloudNativeCon continues. We'll be right back, thanks for watching theCUBE. (electronic beats)

>> Live from Barcelona, Spain, It's theCUBE. Covering KubeCon + CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and ecosystem partners. >> Welcome back, to theCUBE coverage here at KubeCon + CloudNativeCon. I'm Stu Miniman, my co-host is Corey Quinn. And happy to welcome back to the program Mark Shuttleworth who os the CEO of Canonical. Of course, the orange shirts of Ubuntu, are seen all throughout the show. Mark, thank you so much for joining us, great so see you. >> Great to see you. >> All right, so for years, actually, we've had these conversations at the OpenStack Summit. It's interesting that, every time you mention it around this show you get snark online, as like, it is dead, Kubernetes killed it and it's like wait, no, no, you know we're talking about, a couple of open-source projects. I've been talking to people, especially in the telco space, that's like, oh yeah, well no, we just run OpenStack underneath and Kubernetes on top and put all things together. Give us a little bit of your broad view of some of these big trends, and open-source monoliths and microservices and all these pieces, all kind of fly together. >> Yeah, I think if your in the Reddit SubChannels, then you know it can feel a bit like turf war, and gangster-type, free software riffing, right. But the reality is, OpenStack solves business problems for people. They want large scale, virtualized infrastructure, that's cheaper than VMware. We are deploying OpenStacks in enterprise environments at double the scale and double the speed, in other words, like twice as many every month, as we were a year ago. I think people have gotten comfortable with the idea that Kubernetes is an application operations construct. I think we will see virtualization blur into the Kubernetes lives, but mainly for security reasons. So I want deeper isolation of applications that come from third-party vendors, for example. And I'm willing to trade performance for isolation, in circumstances where I am bringing in third-party code into my private infrastructure. After we see a couple of significant security compromises, I mean, we saw the GitHub compromise. If you shave that Yak, it gets to a very uncomfortable place of, what are we actually running as root all over our data centers with Docker and Docker Hub. So, people are going to want that kind of isolation of containers, the Kata Containers work is going to bring that. But that's very different to the proposition of, essentially, give me large scale, machine virtualization which OpenStack addresses. OpenStack hasn't done itself any favors, don't need to go into that here. But nonetheless, as far as we're concerned, it's straight forward to deliver large scale, low cost, enterprise virtualization infrastructure for telco's or IT use cases. >> Let's get into this ecosystem here. I want to say the Cloud Native ecosystem, and I say that specifically because there are some that look at this and they say, oh, there's dozens of projects now, Kubernetes is a platform against platform. Somebody even mentioned the word big tent once. We've seen some projects merging, we've seen some various pieces. >> I saw making a bigger tent on the keynote and I was like, not my favorite choice of words. >> I seem to remember a certain article that you wrote poking a whole in the big tent thing. What's the same, what's different? What's your take on this? Is it an ecosystem? Is it Kubernetes and friends, as Corey has liked to say here? What's your take? >> Look, I think we're still trying to figure out what are the appropriate labels to attach to this kind of forum, it is a forum, right. There is a tremendous amount of value attached to being here, to the ideas that are getting bounced about. But I wouldn't call it a simple community in the sort of, traditional open-source sense. The reality is there's very serious money behind every, sort of project that's been framed as a community project. This is a new kind of consortium. And that brings with it certain, delicate, political posturing and so on. But, nonetheless, it's a valuable place to be. It's definitely staking out important concepts and operational platforms, ideas, regimes, whatever you want to call it. This is going to be a fun week. >> I started off my career in the Linux world as a grumpy Unix administrator because there really wasn't any other kind. Then I started dipping my toes into the Linux world and something struck me, almost immediately, about Ubuntu. Was how welcoming everyone was in the community. There was no such thing as a stupid question. I asked the kind of questions you would expect from someone working on a computer, wearing a suit. People were very eager to embrace newcomers into that. It was one of the absolute best things that I saw coming out of Canonical, in addition to the software itself. I love that you're here as a part of this. What is the larger picture? What do you see in the Cloud Native ecosystem that's resonating with what Canonical's doing? >> So, the big thing that we do is, essentially, try to figure out where, what's possible with open-source that's hard to do. And then make it really straight forward so that more people can do the important stuff easily. That doesn't stop people from doing all the crazy stuff at the periphery that you can do with Ubuntu. It's generally easier with Ubuntu than any other platform. But we try to make the really most important things really easy for everybody. That's the first thing. The second thing is, we're a little non-judgemental about the fact that there are different perspectives on the same stuff. In the Ubuntu ecosystem, we make a point of saying that GNOME guys, and the KDE guys, and the LXQt, and the MATE guys. The Ubuntu ecosystem is where they actually meet to hash out how they can do stuff in a way that means users get a real choice between those. There's a very similar role for us to play in an environment like this. It's kind of acronym soup out there. Like 50 new projects every KubeCon. They're all interesting, they're all important, there's a lot of overlap between them. There's work for us to do in figuring out which ones are going to be really more important in the tent. We did that very effectively with OpenStack. The people who rode the OpenStack wave with us haven't had to abandon their OpenStacks. Because the stuff that we really chose to make central and easy, turned out to be the stuff that was the important poles in the tent. And we'll do exactly the same stuff here with Kubernetes. So, to put that into context, it's been real fun to be on the booth. We had, just tons, of people coming up and saying thank you for Microk8s. Microk8s is a single package of Kubernetes, that works in lots Linux distributions. It gives you, in about a minute, it gives you a standard Kubernetes environment, that's pure upstream. That, for a developer, just let's you get productive immediately. Figure out these new development application operations, constructs. You can use it on an airplane, you can use it on a train. Of course, it's compatible with all of the public clouds so that's the second thing that we're doing. We work with Amazon, with the EKS team, I spoke at their event on Monday. We work with Azure, the AKS team, we work with Google, we work with Oracle, we work with IBM. Essentially making sure that all of them offer Ubuntu worker nodes for their Kubernetes, SaaS offerings. That means that the developer who's doing stuff on their workstation with Microk8s can take those containers straight to any other public clouds. So, we're not trying to force people to use a particular solution, we're saying, in all of those environments, there are going to be choices people have. We want to make that as easy as possible for them. We want to avoid unnecessary friction in that process. That kind of underlining culture is coming through in this forum, as well. >> We've had many conversations about how you've always tried to make the job of that developer really easy. One of the things we always look at on this show is how much of it is the infrastructure people, or the platform underneath and the developer, and how much are they coming together. Anything different about this ecosystem? >> Very much so, yeah. >> Or your customers here that you can share? >> Kubernetes is an application construct. You can think of it as a next generation message bus. It's how components of an application find each other, communicate with each other, essentially, coordinate with each other. That makes it very tightly woven in to the developer experience. By contrast, you can be sitting writing a Java application inside a bank and not know or care whether it's going to be running on a physical machine, a virtual machine or an OpenStack cloud. You just don't know, you don't care. It's too far away from the application. Kubernetes is right there. I think that's one of the really interesting things is that it's bringing those infrastructure brains together with the application, app dev brains, in a very interesting way. It's going to be challenging. I wouldn't underestimate it, there are a lot of people, sort of, wondering around here, feeling a little confused, but that's okay. Do you know what I mean, the stuff shakes out. >> So, something that's been a recurring theme here has been the idea of going in a multi-cloud direction. Where people are talking about wanting to build workloads that they can seamlessly deploy across different providers. People talk about that, periodically, as a strategic goal but I'm not seeing people do it very often in the real world. You're in a much better position than a lot of us, to see that. Is that something you're seeing people moving towards as an adoption? >> Well, yes. Because we work with all of the major public clouds to optimize Ubuntu there, in a way that I don't think any other Linux does. You get an optimized Amazon Ubuntu on Amazon. You get an optimized Azure Ubuntu on Azure, and so on. >> Going very deep in the Amazon ecosystem. Most of my customers are using Ubuntu far ahead of anything else out there. >> That's right. >> And it's the right answer for what they're doing. >> That's right. It gives them, essentially, the best of what Amazon's offering, it still gives them the ability to feel like if they want to go somewhere else, they can. And that actually works well for Amazon. In the early days, I think there was a little tension between us and the cloud guys, because they were saying, look, if people use Ubuntu then they can go somewhere else. Yes, but in a sense, that makes them more likely to be more relaxed about starting wherever they choose to start. We don't advise enterprises as to which cloud to use. We advise them to engage with those clouds and figure out their differences, they are different. Amazon's really good at some things that are different, to what Microsoft is good at. Oracle is really good at some things which are different too. And what we're starting to see is the level of maturity in the enterprise governance process. They know they want to work with multiple clouds. They initially thought that was a straight kind of commodity exchange, competition thing. They now realize that it's a bit richer than that. That there are actually business reasons to have deeper relationships with particular clouds, based on what those clouds are prioritizing, and what they are prioritizing. So, we're not going to say you should use this cloud, you should use that cloud. Obviously, we can draw a distinction between the clouds where we're deeply engaged and the clouds where, you know, where you just don't have the benefit of that. But, more importantly we can say, you know, here are the set of practices that you can adopt internally that will give you comfort that your getting the best out of those clouds, the ones that you've chosen. And you have the portability that you really need. The key turns out be, enabling your developers, to use multiple clouds and challenging the developers to do different phases of the development life cycle on different clouds. Develop on your private cloud or your work station, use Microk8s, for example. Do tests on one cloud. Do staging and production on a different cloud. Now you already know that that whole, seamless ecosystem works. If you want to go use a high value, proprietary function, effectively on a cloud, that's a business decision and it's not a bad business decision. There's some spectacular capabilities from Amazon that are unique to Amazon. Or from Microsoft that are unique, or from Oracle that are unique to Oracle. They're spectacular. Those are business decisions to use them. There's other stuff that effectively you can give yourself optionality on. I wouldn't be black and white about that, put yourself in a position to make smart choices. And our best customers are getting are getting there. PayPal, they're operating on Ubuntu in a very sophisticated way, across multiple public clouds and private infrastructure. >> All right, so Mark we're five years into Kubernetes now. We've seen adoption grow, people feel there's a certain level of maturity here. There's always that concern that we've reached that peak and we're about to fall off the cliff. What do we need to worry about? What does the ecosystem need to do to make sure we continue along the stability and security that customers are looking for. >> There will be an over shoot regardless. I don't think there's any sort of leadership or governance approach that could avoid that. It's a little bit like, if your stock is going crazy. On the one hand, you're kind of happy. On the other hand, if you feel it's over valued it's a difficult sort of thing to say. You need to say, guys, you know what I mean, we're humans too. We've got our challenges to work through. And no one likes volatility, but too a certain extent, there's always speculation and over shoot, and over-enthusiasm, and hype. Kubernetes will over shoot. There's a bunch of emperors walking around here that, frankly, have no clothes. My job, our job, is very calmly, to sort through the wheat from the chaff. Make sure that it's possible for people to experiment with everything. But, that the stuff that we think has legs, effectively, is nicely integrated for people, that they have that for the long term, they won't regret things. We have a good track record of doing that. We've done it in the Linux desktop. We did it in OpenStack, we're doing it in public cloud. We've done it here in the Cloud Native world. I'd say things like AI are going in the same direction. Again, tons of complexity, tons of new options. Helping people effectively navigate through that is what we do very well. >> Yeah, one of the questions that I started to see as well, as we look at the way that these technologies continue to evolve, has been that, for better or worse, when developers are writing applications now and even infrastructure people are working with a lot of the things they care about. What operating system, let alone what distribution they're using, is increasingly slipping beneath the waves. People don't think about that as a primary area of focus anymore. And as, I guess, of the foundational Linux vendors in this space, how are you seeing that evolving? And how does Canonical remain relevant in a world where suddenly, people in a serverless future, I just throw some code over somewhere else and it runs is the limit of where most companies get involved. >> Yes, of course, we can point to the servers. And on the servers, we can point to the operating systems and inside the containers, we can point to the operating systems and underneath the serverless code, we can point to the language runtimes. So, the reality is that those things matter less and less to the developer. >> Yes. >> They still matter to the institution. So, I'm super comfortable with the language that says, the OS doesn't matter. What it means is that that whole tangle is getting professionalized and abstracted. But to be confident in the abstractions, someone needs to do a lot of work. I know how much work we do with Google, with Amazon, with Microsoft, with Oracle, with IBM, to make sure that nobody else has to feel like the OS matters. That that stuff essentially just works. You can extend that out to what we do with VMware, what we do, essentially, on bare-metal, what we do on developer workstations, what we do with the Windows crowd, effectively, and Windows subsystem for Linux, so that developers really can just build on Windows subsystem for Linux, Ubuntu, effectively, and ship that container straight to Amazon EKS and have it just work. There are a ton of little lies that have to line up. Containers are all kind of a fiction. The fiction breaks if those pieces don't line up. So, being Ubuntu, effectively and being being able to be consistent in all of those places, is a ton of work to enable it not to matter for anybody upstairs. That's allowing developers to go faster. It's allowing them to be more productive. It's allowing them to be more heroic. And it's allowing the people who do worry about the middleware to have far fewer nights scratching their heads as to, why didn't this version of this library tie up to that driver with that kernel. All of those things are still there. When you drop that container onto Amazon, we've got to connect the GPGPU in the hardware, through the hypervisor, to the guest OS, up into the container. And there's code getting injected all the way up. It's only the fact that we can typically have Ubuntu everywhere there that, essentially, allows those pieces to line up without some spectacular fireworks. It satisfies me when people say they don't have to worry about that. >> It's a victory condition. >> Mark, I want to give you the final word. What should we be looking for, from Canonical, through the rest of the year? >> So, for us, this has been a big year in terms of visibility in the enterprise. In terms of penetration, Ubuntu's everywhere in the Fortune 500, everywhere in the Global 2000. What's changed this year, is the CIO suddenly is seeing Ubuntu on their desk. For two reasons, one is IBM Red Hat. The CIO suddenly wants to know, okay, what does this mean? What else are we running? Where else can we get 24/7 SLAs? Where else can we get long term commitments to Linux and so on? And the fact is Ubuntu's already in the building so that's one, sort of, easy connect. The other thing is, there's really interesting, new workloads that Ubuntu leads in the enterprise. Obviously the container story, the multi-cloud story, edge. It's not just telcos. Every retailer, every logistics company, anybody that has physical distribution is now trying to say, well how can I automate compute in my physical world, effectively. So, edge is super interesting and IoT beyond that. People transforming businesses through taking a Raspberry Pi with Ubuntu and putting a snap on it is really, really cool. Which of those is going to drive the biggest headlines or the scariest headlines, I can't tell you. We're just trying to take care of security, performance and operations across all of them. >> All right, well, Mark Shuttleworth, always a pleasure to catch up, thank you so much for the updates. >> Great to see you. >> All right, for Corey Quinn, I'm Stu Miniman. We'll be back with lots more coverage here from KubeCon + CloudNativeCon 2019 in Barcelona, Spain. Thanks for watching theCUBE. (upbeat music)

>> Live, from the Seattle, Washington. It's theCUBE, covering KubeCon and CloudNativeCon, North America 2018, brought to you by Red Hat, the Cloud Native Computing Foundation and it's ecosystem partners. >> Welcome back everyone. We're live here in Seattle for theCUBE's exclusive coverage of KubeCon and CloudNativeCon 2018. I'm John Furrier at Stuart Miniman. Our next guest Stephan Fabel, who is the Director of Product Management at Canonical. CUBE alumni, welcome back. Good to see you. >> Thank you. Good to see you too. Thanks for having me. >> You guys are always in the middle of all the action. It's fun to talk to you guys. You have a pulse on the developers, you have pulse on the ecosystem. You've been deep in it for many, many years. Great value. What's hot here, what's the announcement, what's the hard news? Let's get to the hard news out of the way. What's happening? What's happening here at the show for you guys? >> Yeah, we've had a great number of announcements, a great number of threads of work that came into fruition over the last couple of months, and now just last week where we announced hardware reference architectures with our hardware partners, Dell and SuperMicro. We announced ARM support, ARM64 support for Kubernetes. We released our version 1.13 of our Charmed Distribution of Kubernetes, last week And we also released, very proud to release, MicroK8s. Kubernetes in a single snap for your workstation in the latest release 1.13. >> Maybe explain that, 'cause we often talk about scale, but there is big scale, and then we're talking about edge, we're talking about so many of these things. >> That's right. >> That small scale is super important, so- >> It really is, it really is, so, MicroK8s came out of this idea that we want to enable a developer to just quickly standup a Kubernetes cluster on their workstation. And it really came out of this idea to really enable, for example, AIML work clouds, locally from development on the workstation all the way to on-prem and into the public cloud. So that's kind of where this whole thing started. And it ended up being quite obvious to us that if we do this in a snap, then we actually can also tie this into appliances and devices at the edge. Now we're looking at interesting new use cases for Kubernetes at the edge as an actual API end point. So it's a quite nice. >> Stephan talk about ... I want to take a step back. There's kind of dynamics going on in the Kubernetes wave, which by the way is phenomenal, 8000 people here at KubeCon, up from 4000. It's got that hockey stick growth. It's almost like a Moore's Law, if you will, for the events. You guys have been around, so you have a lot of existing big players that have been in the space for a while, doing a lot of work around cloud, multi-cloud, whatever ... That's the new word, but again, you guys have been there. You got like the Cisco's of the world, you guys, big players actively involved, a lot of new entrants coming in. What's your perspective of what's happening here? A lot of people looking at this scratching their head saying: Okay I get Kubernetes, I get the magic. Kubernetes enables a lot of things. What's the impact to me? What's in it for me as an enterprise or a developer? How do you guys see this market place developing? What's really going on here? >> Well I think that the draw to this conference and to technology and all the different vendors et cetera, it's ultimately a multi-cloud experience, right? It is about enabling workload portability and enabling the operator to operate Kubernetes, independently of where that is being deployed. That's actually also the core value proposition of our charmed Kubernetes. The idea that a single operational paradigm allows you to experience, to deploy, lifecycle manage and administer Kubernetes on-prem, as well as any of the public clouds, as well as on other virtual substrates, such as VMware. So ultimately I think the consolidation of application delivery into a single container format, such as Docker and other compatible formats, OCI formats right? That was ultimately a really good thing, 'cause it enabled that portability. Now I think the question is, I know how to deploy my applications in multiple ways, 'cause it's always the same API, right? But how do I actually manage a lot of Kubernetes clusters and a lot of Kubernetes API end points all over the place? >> So break down the hype and reality, because again, a lot of stuff looks good on paper. Love the soundbites of people saying, "Hey, Kubernetes," all this stuff. But people admitting some things that need to be done, work areas. Security is a big concern and people are working on that. Where is the reality? Where does the rubber meet the road when it comes down to, "Okay, I'm an enterprise. What am I buying into with Kubernetes? How do I get there?" We heard Lyft take an approach that's saying, "Look, it solved one problem." Get a beachhead and take the incremental approach. Where's the hype, where's the reality? Separate that for us. >> I think that there is certainly a lot of hype around the technology aspect of Kubernetes. Obviously containerization is invoked. This is how developers choose to engage in application development. We have Microservices architecture. All of those things we're very well aware of and have been around for quite some time and in the conversation. Now looking at container management, container orchestration at scale, it was a natural fit for something like Kubernetes to become quite popular in this space. So from a technology perspective I'm not surprised. I think the rubber meets the road, as always, in two things: In economics and in operations. So if I can roll out more Kubernetes clusters per day, or more containers per day, then my competitor ... I gain a competitive advantage, that the cost per container is ultimately what's going to be the deciding factor here. >> Yeah, Stephan, when I think about developers how do I start with something and then how do I scale it out in the economics of that? I think Canonical has a lot of experience with that to share. What are you seeing ... What's the same, what's different about this ecosystem, CloudNative versus, when we were just talking about Linux or previous ways of infrastructure? >> Well I think that ultimately Kubernetes, in and of itself, is a mechanism to enable developers. It plays one part in the whole software development lifecycle. It accelerates a certain part. Now it's on us, distributors of Kubernetes, to ensure that all the other portions of this whole lifecycle and ecosystem around Kubernetes, where do I deploy it? How do I lifecycle manage it? If there's a security breach like last Monday, what happens to my existing stack and how does that go down? That acceleration is not solved by Kubernetes, it's solved for Kubernetes. >> Your software lives in lots and lots of environments. Maybe you can help clarify for people trying to understand how Kubernetes fits, and when you're playing with the public cloud, your Kubernetes versus their Kubernetes. The distinction I think is, there's a lot of nuance there that people may need help with. >> That's true, yeah. So I think that, first of all, we always distance ourself from the notion of having our Kubernetes. I think we have a distribution of Kubernetes. I think there is conformance, tests that are in place that they're in place for a reason. I think it is the right approach, and we won't install a fourth version of Kubernetes anytime soon. Certainly, that is one of the principles we adhere to. What is different about our distribution of Kubernetes is the operational tooling and the ability to really cookie-cutter out Kubernetes clusters that feel identical, even though they're distributed and spread across multiple different substrates. So I think that is really the fundamental difference of our Kubernetes distribution versus others that are out there on the market. >> The role of developers now, 'cause obviously you're seeing a lot of different personas emerging in this world. I'm just going to lay them out there and I want to get your reaction. The classic application developer, the ones who are sitting there writing code inside a company. It could be a consumer company like Lyft or an enterprise company that needs ... They're rebuilding inside, so it's clear that CIOs or enterprises, CXOs or whatever the title is, they're bringing more software in-house, bringing that competitive advantage under application development. You have the IT pro expert, practitioner kind of role, classic IT, and then you got the opensource community vibe, this show. So you got these three things inter-playing with each other, this show, to me feels a lot like an opensource show, which it is, but it also feels a lot like an IT show. >> Which it also is. >> It also is, and it feels like an app development show, which it also is. So, opportunity, challenge, is this a marketplace condition? What's you thoughts on these kind of personas? >> Well I think it's really a question of how far are you willing to go in your implementation of devops cultural change, right? If you look at that notion of devops and that movement that has really taken ahold in people's minds and hearts over the last couple of years, we're still far off in a lot of ways and a lot of places, right? Even the places who are saying they're doing devops, they're still quite early, if at all, on that adoption curve. I think bringing operators, developers and IT professionals together in a single show is a great way for the community and for the market to actually engage in a larger devops conversation, without the constraint of the individual enterprise that those teams find themselves in. If you can just talk about how you should do something better and how would that work, and there is other kinds of personas and roles at the same table, it is much better that you have the conversation without the constraint of like a deadline or a milestone, or some outage somewhere. Something is always going on. Being able to just have that conversation around a technology and really say, "Hey, this is going to be the one, the vehicle that we use to solve this problem and further that conversation," I think it's extremely powerful. >> Yeah, and we always talk about who's winning and who's losing. It's what media companies do. We do it on theCUBE, we debate it. At the end of the day we always like ... There's no magic quadrant for this kind of market, but the scoreboard can be customers. Amazon's got over 5000 reputable customers. I don't know how many CNCF has. It's probably a handful, not 5000. The customer implications are really where this is going. Multi-cloud equals choice. What's your conversations like with customers? What do you see on the customer landscape in terms of appetite, IQ, or progress for devops? We were talking, not everyone's on server lists yet and that's so obvious that's going to be a big thing. Enterprises are hot right now and they want the tech. Seeing the cloud growth, where's your customer-base? What are those conversations like? Where are they in the adoption of CloudNative? >> It's an extremely interesting question actually, because it really depends on whether they started with PaaS or not. If they ever had a PaaS strategy then they're mostly disillusioned. They came out, they thought it was going to solve a huge problem for them and save them a lot of money, and it turns out that developers want more flexibility than any PaaS approach really was able to offer them. So ultimately they're saying, "You know what, let's go back to basics." I'll just give you a Kubernetes API end point. You already know how to deal with everything else beyond that, and actually you're not cookie-cuttering out post ReSQueL- >> Kubernetes is a reset to PaaS. >> It really does. It kind of disrupted that whole space, and took a step back. >> All right, Stephan, how about Serverless. So a lot of discussion about Knative here. We've been teasing out where that fits compared to functions from AWS and Azure. What's the canonical take on this? What are you hearing from your customers? >> So Serverless is one of those ... Well it's certainly a hot technology and a technology of interest to our customers, but we have longstanding partnerships with Galactic Fog and others in place around Serverless. I haven't seen real production deployments of that yet, and frankly it's probably going to take a little bit longer before that materializes. I do think that there's a lot of efforts right now in containerization. Lots of folks are at that point where they are ready to, and are already running containerized workloads. I think they're busy now implementing Kubernetes. Once they have done that, I think they'll think a little bit more about Serverless. >> One of the things that interest me about this ecosystem is the rise of Kubernetes, the rise of choice, the rise of a lot of tools, a lot of services, trying to fend off the tsunami wave that's hit the beach out of Amazon. I've always said in theCUBE that that's ... They're going to take as much inland territory on this tsunami unless someone puts up a sea wall. I think this is this community here. The question is, is that ... And I want to get your expert opinion on this, because the behemoths, the big guys are getting richer. The innovation's coming from them, they have scale. You mentioned that as a key point in the value of Kubernetes, is scale, as one of those players, I would consider in the big size, not like a behemoth like an Amazon, you got a unique position. How can the industry move forward with disruption and innovation, with the big guys dominating? What has to happen? Is there going to change the size of certain TAMs? Is there going to be new service providers emerging? Something's got to give, either the big guys get richer at the expense of the little guys, or market expands with new categories. How do you guys look at that? Developers are out there, so is it promising look to new categories, but your thoughts. >> I think it's ... So a technology perspective certainly would be, there could be a disruptive technology that comes in and just eats their lunch, which I don't believe is going to happen, but I think it might actually be a more of a market functionality actually. If it goes down to the economics, and as they start to compete there will be a limit to the race to the bottom. So if I go in on an economical advantage point as a public cloud, then I can only take that so far. Now, I can still take it a lot further, but there's going to be a limit to that ultimately. So, I would say that all of the public clouds, we see that increasingly happening, are starting to differentiate. So they're saying, "Come to me for IML." "Come to me for a rich service catalog." "Come to me for workload portability," or something like that, right? And we'll se more differentiation as time goes on. I think that will develop in a little bit of a bubble, to the point where actually other players who are not watching, for example, Chinese clouds, right? Very large, very influential, very rich in services, they can come in and disrupt their market in a totally different way than a technology ever could. >> So key point you mentioned earlier, I want to pivot on that and get to the AI conversation, but scale is a competitive advantage. We've seen that on theCUBE, we see it in the marketplace. Kubernetese by itself is great but at scale it gets better, got nobs and policy. AI is a great example of where a dormant computer science concept that has not yet been unleashed ... Well, it gets unleashed by cloud. Now that's proliferating. AI, what else is out there? How do you see this trend around just large-scale Kubernetes, AI and machine learning coming on around the corner? That's going to be unique, and is new. So you mentioned the Chinese cloud could be a developer here. It's a lever. >> Absolutely, we've been involved with kubeflow since the early days. Early days, it's barely a year, so what early days? It's a year old. >> It's yesterday. >> So a year a ago we started working with kubeflow, and we published one of the first tutorials of how to actually get that up and running and started on Ubuntu, and with our distribution of Kubernetes, and it has since been a focal point of our distribution. We do a couple of things with kubeflow. So the first thing, something that we can bring as a unique value preposition is, because we're the operating system for almost all GKE, all of AKS, all EKS, such a strong standing as an operating system, and have strong partnerships with folks like NVIDIA. It was kind of one of the big milestones that we tried to achieve and we've since completed, actually as another announcement since last week, is the full automatic deployment of GPU enablement on Kubernetes clusters, and have that identical experience happen across the public clouds. So, GPGPU enablement on Kubernetes, as one of the key enablers for projects like kubeflow, which gives you machine learning stacks on demand, right? And then a parallel, we've been working with kubeflow in the community, very active, formed a steering committee to really get the industry perspective into the needs of kubeflow as a community and work with everybody else in that community to make sure that kubeflow releases on time, and hopefully soon, and a 1.0, which is due this summer, but right now they're focused on 0.4. That's a key area of innovation though, opportunity. >> Oh, absolutely. >> I see Amazon's certainly promoting that. What else is new? I've got one last question for you. What's next for you guys? Get a quick plugin for Canonical. What's coming around the corner, what's up? >> We're definitely happy to continue to work on GPGPU enablement. I think that is one of the key aspects that needs to stay ... That we need to stay on top of. We're looking at Kubernates across many different use cases now, especially with our IoT, open to core operating system, which we'll release shortly, and here actually having new use cases for AIML inference. For example, out at the edge looking at drones, robots, self-driving cars, et cetera. We're working with a bunch of different industry partners as well. So increased focus on the devices side of the house can be expected in 2019. >> And that's key these data, in a way that's really relevant. >> Absolutely. >> All right, Stephan, thanks for coming on theCUBE. I appreciate it, Canonical's. Great insight here, bringing in more commentary to the conversation here at KubeCon, CoudNativeCon. Large-scale deployments as a competitive advantage. Kubernetes really does well there: Data, machine learning, AI, all a part of the value and above and below Kubernatese. We're seeing a lot of great advances. CUBE coverage here in Seattle. We'll be back with more after this short break. (digital music)