 Live from Vancouver, Canada. It's theCUBE. Covering OpenStack Summit North America 2018. Brought to you by Red Hat, the OpenStack Foundation, and its ecosystem partners. Welcome back to theCUBE's coverage of OpenStack Summit 2018 in Vancouver, I'm Stu Miniman, with a co-host for the week, John Troyer. Happy to welcome back to the program, Stefan Fable, who is the director of Ubuntu Product in Development at Canonical. Great to see ya. Great to be here, thank you for having me. All right, so, boy, there's so much going on at this show. We've been talking about doing more things, and in more places, is the theme that the OpenStack Foundation put into place, and we had a great conversation with Mark Shuttleworth, and we're going to dig in a little bit deeper on some of the areas with you. So we have theCUBE, and we're going to go into all the Kubernetes, Kubeflow, and all those other things that will mispronounce how they go. Yes, yes, absolutely. What's your impression of the show, first of all? Well, I think that it's really a, I think there's a consolidation going on, right? I mean, we really have the people who are serious about open infrastructure here, serious about OpenStack, they're serious about Kubernetes. They want to implement, and they want to implement at a speed that fits the agility of their business. They want to really move quick with the upstream release. I think the time for enterprise hardening delays and inertia there is over. I think people are really looking at the core of OpenStack. That's mature, it's stable, it's time for us to kind of move, get going, get a success early, get it soon, then grow. And I think most of the enterprises, most of the customers, we talk to adopt that notion. Yeah, one of the things it sometimes helps is help us lay out the stack a little bit here, because we actually commented that some of the base infrastructure pieces, we're not talking as much about, because they're kind of mature, but OpenStack, very much at the infrastructure level, your compute storage and network need to understand, but then when we start doing things like Kubernetes as well, I can either do ore or on top of, and things like that. So give us your view as to what canonical seeing and customers as to how you lay out that stack. I think you're right. I think there's a little bit of pathfinding here that needs to be done on the Kubernetes side. Ultimately, I think it's going to really converge around OpenStack being operator-centric and operator-friendly, working and operating the infrastructure, scaling that out in a meaningful manner, providing multi-tenancy to all the different departments, and then having Kubernetes be developer-centric and really help to onboard and accelerate the workload adoption and the next gen initiatives. So what we see is absolutely a use case for Kubernetes and OpenStack to work perfectly well together, be an extension of each other, possibly also sit next to each other without being too incumbent on there. But I think that ultimately having something like Kubernetes container-based developer APIs that are providing that orchestration layer the next thing, and they run just perfectly fine on canonical OpenStack. Yeah, there's certainly been a lot of talk about that here at the show. But let's see, let's go level above that. Things we run on Kubernetes. I wanted to talk a little bit about ML and AI and Kubeflow. It seems like we're, I'd almost say we're, this is like if this was a movie, we're in a sequel, like AI, five, this time it's real. I really do see real enterprise applications incorporating these technologies into the workflow for what otherwise might be kind of boring, line of business business. Can you talk a little bit about where we are in this revolution? You mean John, only since we've been talking about it since the mid-1800s? So, yeah, I was just going to point that out. I mean, AI is not new, right? We've seen it since about 60 years, right? It's been around for quite some time. I think that there is an unprecedented amount of sponsorship of new startups in this area, in this space, and there's a reason why this is heating up. I think the reason why ultimately it's there is because we're talking about a scale that's unprecedented. We thought the biggest problem we had with devices was going to be the IP address that's running out. And it turns out that's not true at all, right? At a certain scale and a certain distributed nature of your rollout, you're going to have to deal with just such complexity and interaction between the underlying, the under cloud, the over cloud, the infrastructure, the developers, how do I roll this out? If I spin up 1,000 VMs over here, why am I experiencing drop calls over there? So those types of things need to be sort of correlated. They need to be identified. They need to be worked at. So there's a whole operator angle just to be able to cope with that whole scenario. And I think there's projects that are out there that are trying to ultimately address that, right? For example, Acumus and the Linux Foundation. Then there's, of course, the new applications, right? The smart cities, the connected cars, all of those car manufacturers are right now faced with a problem. How do I deal with mobile distributed inference rollouts on the edge while still capturing the data, continually train my model update, then again distribute out to the edge, right? To get a better experience. How do I sort of catch up to some of the market leaders here that are out there? So as the established car manufacturers are going to come catch up, put more and more miles autonomously on the asphalt, we're going to basically have to deal with a whole lot more of productization of machine learning applications that just have to be managed at scale. And so we believe, and we believe we're also in good company in that belief that having to manage large applications at scale that containers and Kubernetes is a great way to do that, right? They did that for web apps. They did that for the next generation applications. This is one example where with the right operators in mind, the right CRDs, the right frameworks on top of Kubernetes managed correctly, you are actually in a great position to just go to market with that. I wonder if you might have a customer example that might be able to walk us through kind of where they are in this discussion. Talk to many companies, the whole IoT even piece is where we're early in this. So what's actually real today? How much is planning? How many, you know, is this years we're talking before some of these really come to fruition? So yeah, I can't name the customer, but I can say that every single car manufacturer we're talking to is absolutely interested in solving the operational problem or running machine learning frameworks as a service. Making sure those are up running and up to speed at any given point in time. Spin them up in a multi-tenant fashion. Make sure that the GPU enablement is actually done properly at all layers of the virtualization. These are real operational challenges that they're facing today and they're looking to solve with us. So yeah, pick a large car manufacturer you want. Nice. We'll go and down to something that I can type on my own keyboard then and go to GitHub, right? One of the places to go is to run TensorFlow, a machine learning framework on Kubernetes, is Kubeflow, and you would talk, demo that a little bit. Mark demoed that a little bit yesterday on stage. You want to talk about that, maybe just- Oh, absolutely, yes. I mean, that's the core of our current strategy right now, where we're looking at Kubeflow as one of the key enablers of machine learning frameworks as a service on top of Kubernetes. And I think they're a great example because they can really show how that as a service notion can be implemented on top of a virtualization platform, whether that be KVM, pure KVM, on bare metal or on open stack and actually provide machine learning frameworks such as TensorFlow, PyTorch, Seldencore, you have all those frameworks being supported and then basically start mix and matching, right? I think ultimately it's so interesting to us because the data scientists are really not the ones that are expected to manage all this, right? Yet they are at the core of having to interact with it. So in the next generation of the workloads we're talking to PhDs and data scientists, they have no interest whatsoever in understanding how all of this works on the backend, right? They just want to know this is where I'm going to submit my artifact that I'm creating, this is how it works in general and companies pay them a lot of money to do just that and to just do the model because that's where until it's found, until the right model is found, that is exactly where the value is. So Stefan, so does Canonical go talk to the data scientist or is there a class of operators who are facilitating the data scientists? We talk to data scientists to understand their problems, we talk to the operators to understand their problems and then we work with partners such as Google to try and find solutions to that. Great, what kind of conversations are you having here at the show? I can't imagine there's too many of those, great to hear if there are, but where are they? I think everybody here knows containers. You wouldn't know Kubernetes and how far up the stackers are building new stuff. You'd be surprised, I mean we put this out there and so far I want to say the majority of the customer conversations we've had took an AI turn and said this is what we're trying to do next year, this is what we're trying to do later in the year, this is what we're currently struggling with, so glad you have an approach because otherwise we would spend a ton of time thinking about this, a ton of time trying to solve this in our own way that then gets us stuck in some deep end that we don't want to be, so help us understand this, help us kind of pave the way. Nice, nice. I don't want to leave without talking also about micro-Kates, that's a Kubernetes snap, you could code your download and talk a little bit about that, that was a new announcement. Yeah, glad to. This was an idea that we sort of conceived that came out of this notion of, all right, well if I do have, talking to a data scientist, if I do have a data scientist, where does he start? Because Kubernetes has a learning curve to date. It does, yeah, it does, but so here's the thing, right? Like you have, as a developer, you have what options do you have right when you get started? You can either go out and get a Kubernetes cluster stood up on one of the public clouds, but what if you're in the plane, right? You don't have a connection, you want to work on your local laptop, possibly that laptop also has a GPU and you're a data scientist and you want to try this out because you know you're going to submit this training job now to a Kubernetes cluster that runs on-prem behind the firewall for the limited training set, right? You know, but all of those, like this is the situation we're talking about. So ultimately the motivation for creating micro-Kates was we want just to make this very, very equivalent and you can deploy Kubeflow on top of micro-Kates today and it'll run just fine. You get your TensorBoard, you have your Jupyter Hub notebook and you can do your work and you can do it in a fashion that will then be compatible to your on-prem and public machine learning framework. So that was the original sort of motivation for why we went down this road. But then we noticed, you know what? This is actually a wider need. People are thinking about local Kubernetes in many different ways. There are a couple of solutions out there. They tend to be cumbersome or more cumbersome than developers would like it. And so we actually said, you know, maybe we should turn this into a more general purpose solution. So hence micro-Kates. And it's just, it works like a snap, you know, on your machine, you kick that off. You have a Kubernetes API in under 30 seconds or a little longer if your download speed is that, you know, as it plays a factor here. You enable DNS and you're good to go. Yeah, Stefan, want to just give you the opportunity. Is there anything in the Queens release that your customers have been specifically waiting for or any other product announcements before we wrap? Sure. We're very excited about the Queens release. We think Queens release is one of the, you know, one of the great examples of the maturity of the code base and really the sort of the knot towards the operator. And that I think was the big challenge in the olden days, you know, of OpenStack where the operators took a long time for the operators to be heard and sort of to establish a conversation. We're glad to say and to see that OpenStack Queens has matured in that respect. And, you know, we like things like Octavia, you know, we're very excited about low balancing as a service, taking its own, its own life and being treated as a first class citizen. I think that's, it was a great decision of the community to go on that road and we're supporting it as part of our distribution. All right, well, appreciate the updates. Really fascinating to hear about all, you know, everybody's thinking about it and really starting to move on all the ML and AI stuff. All right, for John Troyer, I'm Stu Miniman. Lots more coverage here from OpenStack Summit 2018 in Vancouver. Thanks for watching theCUBE.