>> Announcer: From around the globe, it's theCUBE, with digital coverage of Red Hat Summit 2020, brought to you by Red Hat. >> Hi, I'm Stu Miniman, and this is theCUBE's coverage of Red Hat Summit, happening digitally, interviewing practitioners, executives, and thought leaders from around the world. Happy to welcome back to our program, one of our CUBE alumni, Ashesh Badani, who's the Senior Vice President of Cloud Platforms with Red Hat. Ashesh, thank you so much for joining us, and great to see you. >> Yeah, likewise, thanks for having me on, Stu. Good to see you again. >> All right, so, Ashesh, since the last time we had you on theCUBE a few things have changed. One of them is that IBM has now finished the acquisition of Red Hat, and I've heard from you from a really long time, you know, OpenShift, it's anywhere and it's everywhere, but with the acquisition of Red Hat, it just means this only runs on IBM mainframes and IBM Cloud, and all things blue, correct? >> Well, that's true for sure, right? So, Stu, you and I have been talking for many, many times. As you know, we've been committed to hybrid multi-cloud from the very get-go, right? So, OpenShift supported to run on bare metal, on virtualization platforms, whether they come from us, or VMware, or Microsoft Hyper-V, on private clouds like OpenStack, as well as AWS, Google Cloud, as well as on Azure. Now, with the completion of the IBM acquisition of Red Hat, we obviously always partnered with IBM before, but given, if you will, a little bit of a closer relationship here, you know, IBM's been very keen to make sure that they promote OpenShift in all their platforms. So as you can probably see, OpenShift on IBM Cloud, as well as OpenShift on Z on mainframe, so regardless of how you like OpenShift, wherever you like OpenShift, you will get it. >> Yeah, so great clarification. It's not only on IBM, but of course, all of the IBM environments are supported, as you said, as well as AWS, Google, Azure, and the like. Yeah, I remember years ago, before IBM created their single, condensed conference of THINK, I attended the conference that would do Z, and Power, and Storage, and people would be like, you know, "What are they doing with that mainframe?" I'm like, "Well, you do know that it can run Linux." "Wait, it can run Linux?" I'm like, "Oh my god, Z's been able to run Linux "for a really long time." So you want your latest Container, Docker, OpenShift stuff on there? Yeah, that can sit on a mainframe. I've talked to some very large, global companies that that is absolutely a part of their overall story. So, OpenShift-- >> Interesting you say that, because we already have customers who've been procuring OpenShift on mainframe, so if you made the invest mainframe, it's running machine learning applications for you, looking to modernize some of the applications and services that run on top in OpenShift on mainframe now is an available option, which customers are already taking advantage of. So exactly right to your point, we're seeing that in the market today. >> Yeah, and Ashesh, maybe it's good to kind of, you know, you've got a great viewpoint as to customers deploying across all sorts of environments, so you mentioned VMware environments, the public cloud environment. It was our premise a few years ago on theCUBE that Kubernetes get staked into all the platforms, and absolutely, it's going to just be a layer underneath. I actually think we won't be talking a lot about Kubernetes if you fast-forward a couple of years, just because it's in there. I'm using it in all of my environments. So what are you seeing from your customers? Where are we in that general adoption, and any specifics you can give us about, you know, kind of the breadth and the depth of what you're seeing from your customer base? >> Yeah, so, you're exactly right. We're seeing that adoption continue on the path it's been on. So we've got now, over 1700 customers for OpenShift, running in all of these environments that you mentioned, so public, private, a combination of the two, running on traditional virtualization environments, as well as ensuring that they run in public cloud at scale. In some cases managed by customers, in other cases managed by us on their behalf in a public cloud. So, we're seeing all permutation, if you will, of that in play today. We're also seeing a huge variety of workloads, and to me, that's actually really interesting and fascinating. So, earliest days, as you'd expect, people trying to play with micro-services, so trying to build new market services and run it, so cloud native, what have you. Then as we're ensuring that we're supporting stateful application, right. Now you're starting to see if your legacy applications move on, ensuring that we can run them, support them at scale, within the platform 'cause we're looking to modernize applications. We'll talk maybe in a few minutes also about lift-and-shift that we got to play as well. But now also we're starting to see new workloads come on. So just most recently we announced some of the work that we're doing with a series of partners, from NVIDIA to emerging AI ML, AI, artificial intelligence machine learning, frameworks or ISVs, looking to bring those to market. Been ensuring that those are supported and can run with OpenShift. Right, our partnership with NVIDIA, ensuring OpenShift be supported on GPU based environment for specific workloads, whether it be performance sensitive or specific workloads that take advantage of underlying hardware. So starting now to see a wide variety if you will, of application types is also something that we're starting, right, so numbers of customers increasing, types of workloads, you know, coming on increasing, and then the diversity of underlying deployment environments. Where they're running all services. >> Ashesh, such an important piece and I'm so glad you talked about it there. 'Cause you know my background's infrastructure and we tend to look at things as to "Oh well, I moved from VM to a container, "to cloud or all these other things," but the only reason infrastructure exists is to run my application, is my data and my application that are the most important things out there. So Ashesh, let me get in some of the news that you got here, your team work on a lot of things, I believe one of them talks about some of those, those new ways that customers are building applications and how OpenShift fits into those environments. >> Yeah, absolutely. So look, we've been on this journey as you know for several years now. You know recently we announced the GA of OpenShift Service Mesh in support of Istio, increasing an interest as for turning microservices will take advantage of close capabilities that are coming in. At this event we're now also announcing the GA of OpenShift Serverless. We're starting to see obviously a lot of interest, right, we've seen the likes of AWS spawn that in the first instance, but more and more customers are interested in making sure that they can get a portable way to run serverless in any Kubernetes environment, to take advantage of open source projects as building blocks, if you will, so primitives in, within Kubernetes to allow for serverless capabilities, allow for scale down to zero, supporting serving and eventing by having portable functions run across those environments. So that's something that is important to us and we're starting to see support of in the marketplace. >> Yeah, so I'd love just, obviously I'm sure you've got lots of break outs in the OpenShift Serverless, but I've been talking to your team for a number of years, and people, it's like "Oh, well, just as cloud killed everything before it, "serverless obviates the need for everything else "that we were going to use before." Underlying OpenShift Serverless, my understanding, Knative either is the solution, or a piece of the solution. Help us understand what serverless environment this ties into, what this means for both your infrastructure team as well as your app dev team. >> Yeah, great, great question, so Knative is the basis of our serverless solution that we're introducing on OpenShift to the marketplace. The best way for me to talk about this is there's no one size fits all, so you're going to have specific applications or service that will take advantage of serverless capabilities, there will be some others that will take advantage of running within OpenShift, there'll be yet others, we talked about the AI ML frameworks, that will run with different characteristics, also within the platform. So now the platform is being built to help support a diversity, a multitude of different ways of interacting with it, so I think maybe Stu, you're starting to allude to this a little bit, right, so now we're starting to focus on, we've got a great set of building blocks, on the right compute network storage, a set of primitives that Kubernetes laid out, thinking of the notions of clustering and being able to scale, and we'll talk a little bit about management as well of those clusters. And then it changes to a, "What are the capabilities now, "that I need to build to make sure "that I'm most effective, most efficient, "regard to these workloads that I bring on?" You're probably hearing me say workloads now, several times, because we're increasingly focused on adoption, adoption, adoption, how can we ensure that when these 1700 plus, hopefully, hundreds if not thousands more customers come on, how they can get the most variety of applications onto this platform, so it can be a true abstraction over all the underlying physical resources that they have, across every deployment that they put out. >> All right, well Ashesh, I wish we could spend another hour talking about the serverless piece, I definitely am going to make sure I check out some of the breakouts that cover the piece that we talked to you, but, I know there's a lot more that the OpenShift update adds, so what other announcements, news, do you have to cover for us? >> Yeah, so a couple other things I want to make sure I highlight here, one is a capability called ACM, advanced cluster management, that we're introducing. So it was an experimental work that was happening with the IBM team, working on cluster management capabilities, we'd been doing some of that work ourselves, within Red Hat, as part of IBM and Red Hat coming together. We've had several folks from IBM actually join Red Hat, and so we're now open sourcing and providing this cluster management capability, so this is the notion of being able to run and manage these different clusters from OpenShift, at scale, across multiple environments, be able to check on cluster health, be able to apply policy consistently, provide governance, ensure that appropriate applications are running in appropriate clusters, and so on, a series of capabilities, to really allow for multiple clusters to be run at scale and managed effectively, so that's one set of, go ahead, Stu. >> Yeah, if I could, when I hear about multicluster management, I think of some of the solutions that I've heard talked about in the industry, so Azure Arc from Microsoft, Tanzu from VMware, when they talk about multicluster management, it is not only the Kubernetes solutions that they're offering, but also, how do I at least monitor, if not even allow a little bit of control across these environments? So when you talk about cluster management, is that all the OpenShift pieces, or things like AKS, EKS, other options out there, how do those fit into the overall management story? >> Yeah, that's absolutely our goal, right, so we've got to get started somewhere, right? So we obviously want to make sure that we bring into effect the solution to manage OpenShift clusters at scale, and then of course as we would expect, multiple other clusters exist, from Kubernetes, like the ones you mentioned, from the cloud providers as well as others from third parties and we want the solution to manage that as well. But obviously we're going to sort of take steps to get to the endpoint of this journey, so yes, we will get there, we've got to get started somewhere. >> Yeah, and Ashesh, any guides, when you look at people, some of the solutions I mentioned out there, when they start out it's "Here's the vision." So what guidance would you give to customers about where we are, how fast they can expect these things to mature, and I know anything that Red Hat does is going to be fully open source and everything, what's your guidance out there as to what customers should be looking for? >> Yeah, so we're at an interesting point, I think, in this Kubernetes journey right now, and so when we, if you will, started off, and Stu you and I have been talking about this for at least five years if not longer, was this notion that we want to provide a platform that can be portable and successfully run in multiple deployment environments. And we've done that over these years. But all the while when we were doing that, we're always thinking about, what are the capabilities that are needed that are perhaps not developed upstream, but will be over time, but we can ensure that we can look ahead and bring that into the platform. And for a really long time, and I think we still do, right, we at Red Hat take a lot of stick for saying "Hey look, you form the platform." Our outcome back to that has always been, "Look, we're trying to help solve problems "that we believe enterprise customers have, "we want to ensure that they're available open source, "and we want to upstream those capabilities always, "back into the community." But, let's say making available a platform without RBAC, role-based access control, well it's going to be hard then for enterprises to adopt that, we've got to make sure we introduce that capability, and then make sure that it's supported upstream as well. And there's a series of capabilities and features like that that we work through. We've always provided an abstraction within OpenShift to make it more productive for developers and administrators to use it. And we always also support working with kubectl or the command line interface from kube as well. And then we always hear back from folks saying "Well, you've got your own abstraction, "that might make that seem impossible," Nope, you can use both kubectl GPUs or C commands, whichever one is better for you, have at it, we're just trying to be more productive. And now increasingly what we're seeing in the marketplace is this notion that we've got to make sure we work our way up from not just laying out a Kubernetes distribution, but thinking about the additional capability, additional services that you can provide, that would be more valuable to customers, and I think Stu, you were making the point earlier, increasingly, the more popular and the more successful Kubernetes becomes, the less you will see and hear of it, which by the way is exactly the way it should be, because that becomes then the basis of your underlying infrastructure, you are confident that you've got a rock solid bottom, and now you as a customer, you as a user, are focusing all of your energy and time on building the productive application and services on top. >> Yeah, great great points there Ashesh, the vision people always talked about is "If I'm leveraging cloud services, "I shouldn't have to worry "about what version they're running." Well, when it comes to Kubernetes, ultimately we should be able to get there, but I know there's always a little bit of a delta between the latest and newest version of Kubernetes that comes out, and what the managed services, and not only managed services, what customers are doing in their own environment. Even my understanding, even Google, which is where Kubernetes came out of, if you're looking at GKE, GKE is not on the latest, what are we on, 1.19, from the community, Ashesh, so what's Red Hat's position on this, what version are you up to, how do you think customers should think about managing across those environments, because boy, I've got too many scars from interoperability history, go back 10 or 15 years and everything, "Oh, my server BIOS doesn't work on that latest "kernel.org version of what we're doing for Linux." Red Hat is probably better prepared than any company in the industry, to deal with that massive change happening from a code-based standpoint, I've heard you give presentations on the history of Linux and Kubernetes, and what's going forward, so when it comes to the release of Kubernetes, where are you with OpenShift, and how should people be thinking about upgrading from versions? >> Yeah, another excellent point, Stu, it's clearly been following us pretty closely over the years, so where we came at this, was we actually learned quite a bit from our experience in the company with OpenStack. And so what would happen with OpenStack is, you would have customers that are on a certain version of Openstack, and then they kept saying "Hey look, we want to consume close to trunk, "we want new features, we want to go faster." And we'd obviously spent some time, from the release in community to actually shipping our distribution into customer's hand, there's going to be some amount of time for testing and QE to happen, and some integration points that need to be certified, before we make it available. We often found that customers lagged, so there'd be let's say a small subset if you will within every customer or several customers who want to be consuming close to trunk, a majority actually want stability. Especially as time wore on, they were more interested in stability. And you can understand that, because now if you've got mission critical applications running on it you don't necessarily want to go and put that at risk. So the challenge that we addressed when we actually started shipping OpenShift four last summer, so about a year ago, was to say, "How can we provide you basically a way "to help upgrade your clusters, "essentially remotely, so you can upgrade, "if you will, your clusters, or at least "be able to consume them at different speeds." So what we introduced with OpenShift four was this ability to give you over the air updates, so the best way to think about it is with regard to a phone. So you have your phone, your new OS upgrades show up, you get a notification, you turn it on, and you say "Hey, pull it down," or you say at a certain point of time, or you can go off and delay it, do it at a different point in time. That same notion now exists within OpenShift. Which is to say, we provide you three channels, so there's a stable channel where you say "Hey look, maybe this cluster in production, "no rush here, I'll stay at or even a little behind," there's a fast channel for "Hey, I want to be up latest and greatest," or there's a third channel which allows for essentially features that are being in developed, or are still in early stage of development to be pushed out to you. So now you can start consuming these upgrades based on "Hey, I've got a dev team, "on day one I get these quicker," "I've got these applications that are stable in production, "no rush here." And then you can start managing that better yourself. So now if you will, those are capabilities that we're introducing into a Kubernetes platform, a standard Kubernetes platform, but adding additional value, to be able to have that be managed much much, in a much better fashion that serves the different needs of different parts of an organization, allows for them to move at different speeds, but at the same time, gives you that same consistent platform regardless of where you are. >> All right, so Ashesh, we started out the conversation talking about OpenShift anywhere and everywhere, so in the cloud, you talked about sitting on top of VMware, VM Farms is very prevalent in the data centers, or bare metal. I believe since I saw, one of the updates for OpenShift is how Red Hat virtualization is working with OpenShift there, and a lot of people out there are kind of staring out what VMware did with VSphere seven, so maybe you can set it up with a little bit of a compare contrast as to how Red Hat's doing this rollout, versus what you're seeing your partner VMware doing, or how Kubernetes fits into the virtualization environment. >> Yeah, I feel like we're both approaching it from different perspective and learnset that we come at it, so if I can, the VMware perspective is likely "Hey look, there's all these installations of VSphere "in the marketplace, how can we make sure "that we help bring containers there," and they've come up with a solution that you can argue is quite complicated in the way how they're achieving it. Our approach is a different one, right, so we always looked at this problem from the get-go with regard to containers as a new paradigm shift, it's not necessarily a revolution, because most companies that we're looking at are working with existing application services, but it's an evolution in the way you're thinking about the world, but this is definitely the long term future. And so how can we then think about introducing this environment, this application platform into the environment, and then be able to build a new application in it, but also bring in existing applications to the form? And so with this release of OpenShift, what we're introducing is something that we're calling OpenShift Virtualization, which is a few of our existing applications, certain VMs, how can we ensure that we bring those VMs into the platform, they've been certified, data security boundaries around it, or certain constraints or requirements have been put by your internal organization around it, and we can keep all of those, but then still encapsulate that VM as a container, have that be run natively within an environment orchestrated by OpenShift, Kubernetes as the primary orchestrator of those VMs, just like it does with everything else that's cloud-native, or is running directly as containers as well. We think that's extremely powerful, for us to really bring now the promise of Kubernetes into a much wider market, so I talked about 1700 customers, you can argue that that 1700 is the early majority, or if you will, almost the scratching of the surface of the numbers that we believe will adopt this platform. To get, if you held the next setup, whatever, five, 10, 20,000 customers, we'll have to make sure we meet them where they are. And so introducing this notion of saying "We can help migrate," with a series of tools that Rock's providing, these VM-based applications, and then have them run within Kubernetes in a consistent fashion, is going to be extremely powerful, and we're really excited about it, by those capabilities, bringing that to our customers. >> Well Ashesh, I think that puts a great exclamation point as to how we go from these early days off to the vast majority of environments, Ashesh, one thing, congratulations to you and the team on the growth, the momentum, all the customer stories, I'd love the opportunity to talk to many of the Red Hat customers about their digital transformation and how your cloud platforms have been a piece of it, so once again, always a pleasure to catch up with you. >> Likewise, thanks a lot, Stuart, good chatting with you, and hope to see you in person soon sometime. >> Absolutely, we at theCUBE of course hope to see you at events later in 2020, for the time being, we of course fully digital, always online, check out theCUBE.net for all of the archives as well as the events including all the digital ones that we are doing, I'm Stu Miniman, and as always, thanks for watching theCUBE. (calm music)

>> Announcer: Live from Copenhagen Denmark, it's theCUBE covering Kubecon and CloudnativeCon Europe 2018. Brought to you by the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome back everyone, live here at Copenhagen, Denmark, Cube's coverage of Kubecon 2018 in Europe, this is all about the Kubernetes the future of cloud native, CloudNativeCon part of the CNCF Cloud Native Foundation, I'm John Furrier and my co-host Lauren Cooney, founder of Spark Labs industry expert of open source. So, we have two end user customers of Kubernetes and Cloud Native, Zach Arnold, software engineer Ygenre energy fund, and Austin Adams software development manager, same company. You guys are doing really interesting business model around energy and equity in buildings and homes, but you're writing code, so you have to make all this stuff work, so I'm sure you're cloud native, why have a data center when you can have the cloud >> Austin : We were born in the cloud. >> You were born in the cloud. So take us through, explain the business real quick, and then what's your back end, technical scaling situation look like in terms of infrastructure, software and what's the make up of the systems. >> Zach: You know the business best. >> Yeah, so Ygrene operates under something called PACE, property assess clean energy. We operate in a couple of different states. We work with local governments to create a PACE program that is accepted in different counties or jurisdictions within the state, and then we allow homeowners and contracting companies to provide financing for home improvements that are specifically within the domain of renewable energy or energy efficiency. >> So, you basically finance a solar panel that I put on my house or building if there's benefits there, and then you guys get the financing and you tie in with the government so the property taxes, the leverage the security is the building right, or the asset. >> Yeah, and the way that we're chartered is basically we can put a tax on the property which gives us some guarantees on repayment and things like that, and it's a great model so far. >> It's a new financial engineering around energy efficiancy so you've got to build systems, so you're working with government, so now we all know how government systems work, so you've got to be agile and nimble. Take us through how the back end works, what's it look like, what's the system look like, you're hosted in the cloud, is it Amazon, Google? >> So everything that we have is in a cloud provider that starts with an A, and ends with an S, it's AWS I don't know if I can say that, I think I can say that, AWS all the way-- >> Yes, it's good. >> And we have tons of services, we have Kubernetes running most of our main services. Within our migration we actually started with our main service. A lot of people start with, you know, their smallest microservice, we just went whole-hog and just went in for it, so they system is mainly a lone-management system. Underwriting data aggregation and underwriting processing, so every application that comes in we have to underwrite it and make sure every little thing checks out, and our underwriting system has won awards for how accurate it is and how high quality it is as well. >> So, I'm doing a mental white board in my mind, just kind of graphing this so just help me out here and take us through this. So, you guys are a cutting edge company, new progressive business model, real innovative, great stuff. Cloud native, so you're born in the cloud no data center, cool, check, it's what everyone does, and now you're like okay, now I've got to deal with these legacy systems. So, you're putting containers around things, so you have to interface, you build your own system so that's cool, but you're dealing with other systems and then how are you handling that, you are just containerizing it, so take us through some of those linkages. >> Yeah, so where we're creating, a lot of times when we have to integrate with another system, we'll create a small service that is code that we own, and we'll reach out to those integrations, those vendors and we'll do aggregation within our system and provide an interface back to our systems. You know, like everyone, we're breaking up the monolith or whatever, maybe in 10 years we'll go back to a monolith, who knows but you know we're slicing out things, making microservices, it looks like a mess on the back end, just tons of microservices going everywhere and that's why we're using all these Cloud Native tools to be able to manage that. So, in order to move quickly, we're wanting to containerize everything, everything runs in a container at this point. >> Lauren: Great. >> A lot of our services follow this kind of we're kind of calling the container adaptor pattern, it follows the software adaptor pattern where, just like Austin was saying, let's say for example we're interfacing with a credit vendor, we create a service where we talk to our own service that has a well defined interface that we know will always get a credit report back with the following fields, but then where that information actually comes from, whether it's one of the big three credit vendors or someone else who has a well defined API, that's largely not the concern of the main loan management system, it's the concern of the microservice that's responsible for reaching out to that other entity there. So, that's how we've kind of gotten to beat around the legacy interfacing of all these other different financial services and tools that help to aggregate data.. >> It's super clever you can optimize on a service basis but now you have to orchestrate and kind of conduct everything through-- >> And keep everything secure. >> That's really interesting, I mean I think what I'm looking at here is a huge ecosystem of partners and companies and end users coming together and one of the questions, beyond why you are here, what are you looking at here, what is interesting to you, what do you want to learn about that you might bring into your, you know, architecture essentially? >> Austin and I were talking about this, we kind of tend to look at the CNCF list of projects as a dinner menu. (laughs) >> We're refreshing that page frequently, because we're adding projects at an alarming rate, but one project we're using FluentD, Notary, Kubernetes, of course, Prometheus, things like that, we want to start using those things more extensively. One's that we're really excited about are Spire and Spiffy, the identity, kind of a new take, not necessarily new but new for cloud native take on identity of services and authentication, as well as the open policy agent to provide a single DSL to do all of your policy and authorization-- >> Lauren: That's a lot of work, load and management and identity correct? >> Yeah, yes. >> Authorization and authentication are two of the most important things that happen in our system and we have so many different ways that it happens right now, it can tend to look a little clogy, just from the sense of the fact that we need a little more coordination or standardization around it, I mean we have well written policies that are documented but the way that those actually get enforced are, it's individualized based on the service, you know, if it's a cloud based policy, then it's AWS IAM, if it's Kubernetes based policy it's RBAC using Kubernetes RBAC, so it kind of looks like if we can abstact a lot of that functionality out of the services, the containers, the orchestration tool or the cloud, to making those decisions, that would really, really simplify things for us. >> So, you guys are end users, so are you part of like an end user group that gives feedback directly into the community or how does that work, and do you contribute to that? >> Yes, so we're on the fringes of the contributor community as well, and we're definitely on GitHub on all these projects posting issues and in some cases providing our own PR's or whatever. None of us are within the Kubernetes orb but that's definitely something we all are achieving or aspiring to be is jumping into some of these projects, especially some of the smaller projects that we're using on a daily basis on our build servers like, Portheurs or Notary, some of those things we're actively contributing to those. >> So, you've traded on mastery of product but being active on the project is the key, the balance there. >> Yeah, I mean typically what you find in the fiance industry is when they go for a solution, they lead with their wallet as for what we can purchase, or what we can sponsor, but Ygrene has been, our managers and management have been incredibly empowering this way, they say well what can we give, we lead with our hands. >> Yeah, and this is interesting, if you have a good business model innovation, which you guys have, you can be a completely clean sheet of paper to build it. >> Right >> So, that's the best thing about the cloud. You can really move fast and go from, you know, point A to point B, move the needle. >> Yeah, with it at the same time there's kind of a clean slate, there's even a clean slate in terms of best practices within our industry. Now if we were in mortgage, there's a lot of rules, there's a lot of clear guidelines on how to do security and auditing and things that you need, where in our industry that's all emerging, so we have a chance to also set the pace, set the tone for what security might look like, or what cloud usage might look like within the PACE industry. But at the same time, we're getting increasing government regulations, so we're having to make these decisions around, what are the tools that are going help us achieve maximum customer protection and audit-ability while maintaining our business model without totally-- >> And you're going to need flexibility because you don't know what's going to come next you've got to be ready for anything, and that is what leads to my next question, two points, how do you guys prepare for what's next, what's the main ethos around, technical architecture around being prepared for that, ready state that's coming to you, and then two, what have you learned over the, what's the scar tissue look like, what's the moments of joy and despair going on because you're reiterating, your learning, you're always constantly getting knocked down, standing back up. so this is what innovation is, it can be fun and also grueling at the same time. >> Yeah, so how we deal with what's new beyond our like software process, we have a well-defined process that everything gets churned into. Government is really good about giving us notice about when stuff's going into effect, so we always have target dates that we're going toward. But, in terms of what's next in terms of our software, we have this interesting culture within our organization, everyone wants to improve everything, I think it's called a Kaizen culture, just people are looking at stuff they want to improve it, and so our process allows for anyone to throw something on the backlog. It will get prioritized and put around, but we're allowing all of our engineers to say, hey we want to do this, and you know, putting it into an open forum where, you know, we might not do it but we have the discussion, and we have all the channels to have those discussions and, like most technology companies or technology focused companies, we spend a lot of time talking about technologies, and making those decisions. >> You guys really have the cultural ethos but the people to bate and then commit. >> And that's one of my, you know, recommendations for any company trying to move to cloud native or Kubernetes is, always, you have to have your evangelists, on your team, because you can't expect people who have been doing it one way forever to instantly be onboard. You need some sort of technical evangelist whether that's outside company, it works best, I think, if it's someone you've hired, or someone in your organization who's preaching the gospel of Kubernetes or cloud native. >> Spark Labs, Lauren's company's doing a lot of that work, but that really nails it, I mean, you got to just, it's not a technical issue, per se-- >> Exactly. >> We're hearing that all through the show here. What's on your wish list, what is the holiday's want to bring for you? If you could throw your wish list out there, and you can, a magic wand, crystal ball >> EKS, if Amazon would respond to our request. >> Okay, we just had AG on yesterday, he said it's coming >> It's coming. >> He said, months, >> Did he say months, I thought it was a few months, So maybe >> We'll check the transcripts. >> Alright >> Yeah, it wasn't tomorrow. >> That's alright. >> And that's one of our, that's our scar tissue right? We're doing this ourself, you know, there's this huge control board and we got people, you know, doing the knobs and things and we're relatively small, you know, we're a small engineering organization so we're doing a lot of this ourselves where we can abstract a lot of that work out to a cloud provider that we are already on. >> Well it's going to be good reps for you guys as this thing gets abstracted away, you're going to have a great core competencies in Kubernetes, I think that is a notable thing there. >> Austin: For sure. >> One of the things on my wish list, I was speaking to Jace and Josh Burkus and a lot of the core contributors in Kubernetes at the Contributors Summit, I kind of realized that I would love to see a coordinated cross cutting after, either on part of the CNCF or on part of The Kubernetes Project proper, to have a proactive security, I wouldn't call it a working group, I guess a SIG, a Special Interest Group. It would be, I know that we can deal with zero day issues really, really quickly. For example, the Azure host path mapping issue that was a few months ago, but right now it's kind of on the responsibility of each SIG to implement whatever security looks like to them individually, which is great, it means there are people thinking about security, that makes me sleep better at night. But, seeing some coordination around that and kind of driving towards, okay we have this tool that seems to be changing the game, how are we going to change the game with security? Like is there a way to look at that and even, 'cause authentication and authorization have been around since more than one user used a terminal in the 1960's and 70's. But, even with this new step of admission controllers, where we have more fine grain control around how stuff gets into the cluster. I think it would be great to look at what a coordinated cloud native security effort would look like. >> I think that's great, I mean we've been talking to a lot of vendors here and a lot of folks that have projects, and we bring security every single time and they kind of have an answer, but they really don't. >> They body swerve you, we've got this we've got that. >> Or you're the developer and you have to build it in yourself, so I totally agree with that recommendation I think it's fabulous. >> Yeah, Kubernetes is making so many things simpler at certain levels. Now, if we can focus those efforts at making security simple for people, because they're security experts, they can put their two cents in >> Lauren: Let's build it in and not block it on. >> Build it in and not expect every developer to know. >> Zach: Don't bolt it on, build it in. >> Build it from the beginning, there are all kinds of new ways. The fact there is no perimeter with the cloud brings up, really kind of throws everyone for a loop because you have to go to the chipset down, I mean what Google got, I think is a very interesting approach, they're trying to push forward this multilayer approach from chip to kernel to OS to app, interesting. They've got, managing through all their security, they've got android, I mean spear phishing is a huge problem right now, we're seeing and a lot of enterprises we talk to are like, well, it's like the firewalls and VPN's like that's old school, they need to modernize that so this is going to get them thinking about that. So great, hey guys, thank you for coming on and sharing your feedback-- >> Thank you. >> And your data and your place and how you are architected on AWS and your work with Kubernetes. Congratulations. >> Thank you. >> Cube coverage here in Copenhagen. It's theCUBE's coverage at Kubecon 2018. We'll be back with more after this short break.

>> Announcer: Live from Austin, Texas, it's theCUBE. Covering KubeCon and CloudNativeCon 2017. Brought to you by: Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Hey, welcome back everyone. And we're live here in Austin, Texas. This is theCUBE's exclusive coverage of the Cloud Native conference and KubeCon for Kubernetes Conference. This is for the Linux Foundation. This is theCUBE. I'm John Furrier, the co-founder of Silicon ANGLE Media. My co, Stu Miniman. Our next guest is Dustin Kirkland Vice-President of product. The Ubuntu, Canonical, welcome to theCUBE. >> Thank you, John. >> So you're the product guy. You get the keys to the kingdom, as they would say in the product circles. Man, what a best time to be-- >> Dustin: They always say that. I don't think I've heard that one. >> Well, the product guys are, well all the action's happening on the product side. >> Dustin: We're right in the middle of it. >> Cause you got to have a road map. You got to have a 20 mile steer on the next horizon while you go up into the pasture and deliver value, but you always got to be watching for it always making decision on what to do, when to ship product, not you got the Cloud things are happening at a very accelerated rate. And then you got to bring it out to the customers. >> That's right. >> You're livin' on both sides of the world You got to look inside, you got to look outside. >> All three. There's the marketing angle too. which is what we're doing here right now. So there's engineering sales and this is the marketing. >> Alright so where are we with this? Because now you guys have always been on the front lines of open source. Great track record. Everyone knows the history there. What are the new things? What's the big aha moment that this event, largest they've had ever. They're not even three years old. Why is this happening? >> I love seeing these events in my hometown Austin, Texas. So I hope we keep coming back. The aha moment is how application development is fundamentally changing. Cloud Native is the title of the Cloud Native Computing Foundation and CloudNativeConference here. What does Cloud Native mean? It's a different form of writing applications. Just before we were talking about systems programing right? That's not exactly Cloud Native. Cloud Native programming is writing to API's that are Cloud exposed API's, integrating with software as a service. Creating applications that have no intelligence, whatsoever, about what's underneath them, Right? But taking advantage of that and all the ways that you would want and expect in a modern application. Fault tolerance, automatic updates, hyper security. Just security, security, security. That is the aha moment. The way applications are being developed is fundamentally changing. >> Interesting perspective we had on earlier. Lew Tucker from Cisco, (mumbles) in the (mumbles) History Museum, CTO at Cisco, and we have Kelsey Hightower co-chair for this conference and also very active in the community. Yet, in the perspective, and I'll over simplify and generalize it, but basically was: Hey, that's been going on for 30 years, it's just different now. Tell us the old way and new way. Because the old way, you kind of describing it you're going to build your own stuff, full stack, building all parts of the stack and do a lot of stuff that you didn't want to do. And now you have more, especially time on your hands if DevOps and infrastructure as code starts to happen. But doesn't mean that networking goes away, doesn't mean storage goes away, that some new lines are forming. Describe that dynamic of what's new and the new way what changes from the old way? >> Virtualization has brought about a different way of thinking about resources. Be those compute resources, chopping CPU's up into virtual CPU's, that's KVM ware. You mentioned network and storage. Now we virtualized both of those into software defined storage and software defined networking, right? We have things like OpenStack that brings that all together from an infrastructure perspective. and we now have Kubernetes that brings that to fare from an application perspective. Kubernetes helps you think about applications in a different way. I said that paradigm has changed. It's Kubernetes that helps implement that paradigm. So that developers can write an application to a container orchestrator like Kubernetes and take advantage of many of the advances we've made below that layer in the operating system and in the Cloud itself. So from that perspective the game has changed and the way you write your application is not the same as a the monolithic app we might have written on an IBM or a traditional system. >> Dustin, you say monolithic app versus oh my gosh the multi layered cake that we have today. We were talking about the keynote this morning where CNCF went from four projects to 14 projects, you got Kubernetes, You got things like DSDU on top. Help up tease that a little bit. What are the ones that, where's canonical engaged? What are you hearing from customers? What are they excited about? What are they still looking for? >> In a somewhat self-serving way, I'll use this opportunity to explain exactly what we do in helping build that layered cake. It starts with the OS. We provide a great operating system, Ubuntu that every developer would certainly know and understand and appreciate. That's the kernel, that's the systemd, that's the hyperviser, that's all the storage and drivers that makes an operating system work well on hardware. Lot's of hardware, IBM, Dell HP, Intel, all the rest. As well as in virtual machines, the public Clouds, Microsoft, Amazon, Google, VM ware and others. So, we take care of that operating system perspective. Within the CNCF and within in the Kubernetes ecosystem, It really starts with the Kubernetes distribution. So we provide a Kubernetes distribution, we call it Canonicals Distribution of Kubernetes, CDK. Which is open source Kubernetes with security patches applied. That's it. No special sauce, no extra proprietary extensions. It is open source Kubernetes. The reference platform for open source Kubernetes 100% conformed. Now, once you have Kubernetes as you say, "What are you hearing from customers?" We hear a lot of customers who want a Kubernetes. Once they have a Kubernetes, the next question is: "Now what do I do with it?" If they have applications that their developers have been writing to Google's Kubernetes Engine GKE, or Amazon's Kubernetes Engine, the new one announced last week at re:Invent, AKS. Or Microsoft's Kubernetes Engine, Microsoft-- >> Microsoft's AKS, Amazons EKS. A lot of TLA's out there, always. >> Thank you for the TLA dissection. If you've written the applications already having your own Kubernetes is great, because then your applications simply port and run on that. And we help customers get there. However, if you haven't written your first application, that's where actually, most of the industry is today. They want a Kubernetes, but they're not sure why. So, to that end, we're helping bring some of the interesting workloads that exists, open source workloads and putting those on top of Canonical Kubernetes. Yesterday, we press released a new product from Canonical, launched in conjunction with our partners at Rancher Labs, Which is the Cloud Native platform. The Cloud Native platform is Ubuntu plus Kubernetes plus Rancher. That combination, we've heard from customers and from users of Ubuntu inside and out. Everyone's interested in a developer work flow that includes open-source Ubuntu, open-source Kubernetes and open-source Rancher, Which really accelerates the velocity of development. And that end solution provides exactly that and it helps populate, that Kubernetes with really interesting workloads. >> Dustin, so we know Sheng, Shannon and the team, they know a thing or two about building stacks with open source. We've talked with you many times, OpenStack. Give us a little bit of compare and contrast, what we've been doing with OpenStack with Canonical, very heavily involved, doing great there versus the Cloud Native stacking. >> If you know Shannon and Sheng, I think you can understand and appreciate why Mark, myself and the rest of the Canonical team are really excited about this partnership. We really see eye-to-eye on open source principles First. Deliver great open source experiences first. And then taking that to market with a product that revolves around support. Ultimately, developer option up front is what's important, and some of those developer applications will make its way into production in a mission critical sense. Which open up support opportunities for both of us. And we certainly see eye-to-eye from that perspective. What we bring to bare is Ubuntu ecosystem of developers. The Ubuntu OpenStack infrastructure is a service where we've seen many of the world's largest organizations deploying their OpenStacks. Doing so on Ubuntu and with Ubuntu OpenStacks. With the launch of Kubernetes and Canonical Kubernetes, many of those same organizations are running their own Kubernetes along side OpenStack. Or, in some cases, on top of OpenStack. In a very few cases, instead of Openstack, in very special cases, often at the Edge or in certain tiny Cloud or micro Cloud scenarios. In all of these we see Rancher as a really, really good partner in helping to accelerate that developer work flow. Enabling developers to write code, commit code to GitHub repository, with full GitHub integration. Authenticate against an active directory with full RBAC controls. Everything that you would need in an enterprise to bring that application to bare from concept, to development, to test into production, and then the life cycle, once it gains its own life in production. >> What about the impact of customers? So, I'm an IT guy or I'm an architect and man, all this new stuff's comin' at me. I love my open source, I'm happy with space. I don't want to touch it, don't want to break it, but I want to innovate. This whole world can be a little bit noisy and new to them. How do you have that conversation with that potential customer or customer where you say, Look, we can get there. Use your app team here's what you want to shape up to be, here's service meshes and plugable, Whoa plugable (mumbles)! So, again, how do you simplify that when you have conversations? What's the narrative? What's the conversation like? >> Usually our introduction into the organization of a Fortune 500 company is by the developers inside of that company who already know Ubuntu. Who already have some experience with Kubernetes or have some experience with Rancher or any of those other-- >> So it's a bottoms up? >> Yeah, it's bottoms up. Absolutely, absolutely. The developer network around Ubuntu is far bigger than the organization that is Canonical. So that helps us with the intro. Once we're in there, and the developers write those first few apps, we do get the introductions to their IT director who then wants that comfy blanket. Customer support, maybe 24 by seven-- >> What's the experience like? Is it like going to the airport, go through TSA, and you got to take your shoes off, take your belt off. What kind of inspection, what is kind of is the culture because they want to move fast, but they got to be sure. There's always been the challenge when you have the internal advocate saying, "Look, if we want to go this way "this is going to be more the reality for companies." Developers are now major influencers. Not just some, here's the product we made a decision and they ship it to 'em, it's shifted. >> If there's one thing that I've learned in this sort of product management assignment, I'm a engineer by trade, but as a product manager now for almost five years, is that you really have to look at the different verticals and some verticals move at vastly different paces than other verticals. When we are in the tele close phase, We're in RFI's, requests for a quote or a request for information that may last months, nine months. And then go through entering into a procurement process that may last another nine months. And we're talking about 18 months in an industry here that is spinning up, we're talking about how fast this goes, which is vastly different than the work we do in Silicon Valley, right? With some of the largest dot-coms in the world that are built on Ubuntu, maybe an AWS or else where. Their adoption curve is significantly different and the procurement angle is really different. What they're looking to buy often on the US West Coast is not so much support, but they're looking to guide your roadmap. We offer for customers of that size and scale a different set of products something we call feature sponsorships, where those customers are less interested in 24 by seven telephone support and far more interested in sponsoring certain features into Ubuntu itself and helping drive the Ubuntu roadmap. We offer both of those a products and different verticals buy in different ways. We talked to media and entertainment, and the conversation's completely different. Oil and gas, conversation's completely different. >> So what are you doing here? What's the big effort at CloudNativeCon? >> So we've got a great booth and we're talking about Ubuntu as a pretty universal platform for almost anything you're doing in the Cloud. Whether that's on frame infrastructure as a service, OpenStack. People can coo coo OpenStack and point OpenStack versus Kubernetes against one another. We cannot see it more differently-- >> Well no I think it's more that it's got clarity on where the community's lines are because apps guys are moving off OpenStack that's natural. It's really found the home, OpenStack very relevant huge production flow, I talk to Johnathon Bryce about this all the time. There's no co cooing OpenStack. It's not like it's hurting. Just to clarify OpenStack is not going anywhere its just that there's been some comments about OpenStack refugees going to (mumbles), but they're going there anyway! Do you agree? >> Yeah I agree, and that choice is there on Ubuntu. So infrastructure is a service, OpenStack's a fantastic platform, platforms as a service or Cloud Native through Cloud Native development Kubernetes is an excellent platform. We see those running side by side. Two racks a systems or a single rack. Half of those machines are OpenStack, Half of those are Kubernetes and the same IT department manages both. We see IT departments that are all in OpenStack. Their entire data center is OpenStack. And we see Kubernetes as one workload inside of that Openstack. >> How do you see Kubernetes impact on containers? A lot of people are coo cooing containers. But they're not going anywhere either. >> It's fundamental. >> The ecosystem's changing, certainly the roles of each part (mumbles) is exploding. How do you talk about that? What's your opinion on how containers are evolving? >> Containers are evolving, but they've been around for a very long time as well. Kubernetes has helped make containers consumable. And doctored to an extent, before that the work we've done around Linux containers LXE LEXT as well. All of those technologies are fundamental to it and it take tight integration with the OS. >> Dustin, so I'm curious. One of the big challenges I have the U face is the proliferation of deployments for customers. It's not just data center or even Cloud. Edge is now a very big piece of it. How do you think that containers helps enable the little bit of that Cloud Native goes there, but what kind of stresses does that put on your product organization? >> Containers are adding fuel to the fire on both the Edge and the back end Cloud. What's exciting to me about the Edge is that every Edge device, every connected device is connected to something. What's it connected to, a Cloud somewhere. And that can be an OpenStack Cloud or a Kubernetes Cloud, that can be a public Cloud, that could be a private implementation of that Cloud. But every connected device, whether its a car or a plane or a train or a printer or a drone it's connected to something, it's connected to a bunch of services. We see containers being deployed on Ubuntu on those Edge devices, as the packaging format, as the application format, as the multi-tendency layer that keeps one application from DOSing or attacking or being protected from another application on that Edge device. We also see containers running the micro services in the Cloud on Ubuntu there as well. The Edge to me, is extremely interesting in how it ties back to the Cloud and to be transparent here, Canonical strategy and Canonical's play is actually quiet strong here with Ubuntu providing quite a bit of consistency across those two layers. So developers working on those applications on those devices, are often sitting right next to the developers working on those applications in the Cloud and both of them are seeing Ubuntu helping them go faster. >> Bottom line, where do you see the industry going and how do you guys fit into the next three years, what's your prediction? >> I'm going to go right back to what I was saying right there. That the connection between the Edge and the Cloud is our angle right there, and there is nothing that's stopping that right now. >> We were just talking with Joe Beda and our view is if it's a shoot and computing world, everything's an Edge. >> Yeah, that's right. That's exactly right. >> (mumbles) is an Edge. A light in a house is an Edge with a processor in it. >> So I think the data centers are getting smarter. You wanted a prediction for next year: The data center is getting smarter. We're seeing autonomous data centers. We see data centers using metals as a service mask to automatically provision those systems and manage those systems in a way that hardware look like a Cloud. >> AI and IOT, certainly two topics that are really hot trends that are very relevant as changing storage and networking those industries have to transform. Amazon's tele (mumbles), everything like LAN and serverless, you're starting to see the infrastructure as code take shape. >> And that's what sits on top of Kubernetes. That's what's driving Kubernetes adoption are those AI machine learning artificial intelligence workloads. A lot of media and transcoding workloads are taking advantage of Kubernetes everyday. >> Bottom line, that's software. Good software, smart software. Dustin, Thanks so much for coming theCube. We really appreciate it. Congratulations. Continued developer success. Good to have a great ecosystem. You guys have been successful for a very long time. As the world continues to be democratized with software as it gets smarter more pervasive and Cloud computing, grid computing, Unigrid. Whatever it's called it is all done by software and the Cloud. Thanks for coming on. It's theCube live coverage from Austin, Texas, here at KubeCon and CloudNativeCon 2017. I'm John Furrier, Stu Miniman, We'll be back with more after this short break. (lively music)