>>Hello and welcome to the cubes coverage of dr khan 2021. I'm john Kerry, host of the cube agent I own L. C. Ceo and co founder chairman of Morantes cube alumni Adrian Great to see you. Thanks for coming on the cube here for dr khan coverage. Good to see you. Hey >>john nice to see. You gotta do. >>So obviously open source innovation continues. You guys are at the forefront of it. Great to see you what's new Miranda's, give us the update on what's happening. >>Well, I mean what's, what's interesting is we've had one of the best years ever last year and it's very much more continuous, you know, into this year. It's pretty fantastic. We wanted about 160 new customers. Kubernetes is definitely on a tear. We see customers doing bigger and bigger and more exciting things, which is absolutely great to say lens is getting tremendous destruction and I think we have a five fold increase in user base within a year. So it's a lot of fun Right now, customers are definitely pushing the boundaries of what benefits can do. And they want to get the cloud native infrastructure and they want to get there faster and they want to be big and exciting things. And we are so happy to be part of the right. >>You guys are investing in brand new open source solutions for customers. Give us an update on on why and why do they matter for your customer? >>Well, there are, let me unpack this a little bit and there are really two elements to this. One is wide. Open Source and what's new. What matters. So the open source is not new, but open source is being embraced more and more heavily. Bye bye companies everywhere because just a very flexible and cost efficient and highly innovative way to to use innovation and to continue software and a lot of innovation these days is happening the open source communities, which is why it's super exciting for many, many users now. What's new with us? I think there are two really terrific things that we brought the market that we see, get a lot of interest and attention from our customers and create value. One is this idea of delivering, including the infrastructure that's been in space as a service for some of the largest news cases out there. Very large enterprises. We want to have a cloud experience on prime just like they have it in public clouds. That is absolutely fantastic. And that's new and different and very, very exciting. Customs. The second thing that's new and compelling and exciting is the is lands which is this kubernetes, i. e. that has empowered in the meantime, close to 180,000 communities, developers around the world to make it much much easier to take advantage of genetics. So you can think of it as a I. D. And a D. Bugger for anybody who is using genetics on public clouds or on on private infrastructure. That is getting tremendous traction and adoption. >>The interest in kubernetes has been unbelievable. I mean in coop con we saw kubernetes almost become boring in the sense of like it's everyone's using it and there's still now it's enabling a lot more cloud native development. Why does that lens matter what is the benefit? Because that's that's a killer opportunity because kubernetes is actively being adopted. The general consensus is it's delivering the value. >>Yeah. So let me unpack this in two aspects why Wise Bennett is important, why people adopting it and then how it lands adding value on top of it for people who want to use humanity's common. It is tremendously important is because it solves some very, very fundamental problems for developers and operators when building cloud native applications. These are problems that are very essential to actually operating in production but are really unpleasant people to solve, like availability, scalability, reusability of services. So all of that with amenities comes right out of the box and developers no longer have to worry about it. And at the same time, the benefits gives you a standard where you can build apps on public clouds and then move them on prem or build them on trend with them on public clouds and anywhere in between. So it gives a kind of this universal cloud native standard that you as a developer can rely on. And that's extremely valuable for developers. We all remember from the java times when java came online, people really value this idea of white ones run anywhere and that's exactly what benefits does for you in a clown in the world. So it's extremely screaming valuable for people. Um now how does let's add value in this context is also very exciting. So what's happening when you build these applications on a minute? This is that you have many, many services which interact with each other in fairly complex and sometimes unpredictable ways and they're also very much interact with the infrastructure. So you have you can you can imagine kind of this jungle this label building of many different cloud native services working together to build your app, run your app well, how are you going to navigate that and debug that as a developer as you build and optimize your code. So what lengths does it gives you kind of like a real time poppet of pounds of console. You can imagine like you're a fighter pilot in this jet and you have all these instruments kind of coming out here and gives you like this fantastic real time situational awareness. So you can very quickly figure out what is it that you need to do? Either fixing a bug in your application or optimize the performance of the code of making more your rival fixing security issues. And it makes it extremely easy for developers to use. Right? But this tradition has been hard to use complicated, this makes it super fast, easy, have a lot of fun. >>You know, that is really the great theme about this conference this year and your point exactly is developer experience making it simpler and easier. Okay. And innovative is really hits the mark on productivity. I mean and that's really been a key part. So I think that's why I think people are so excited about kubernetes because it's not like some other technologies that had all the setup requirement and making things easier to get stood up and manage. Its huge. So congratulations. A great point, great call out there, great insight. The next question to ask you is you guys have coined the term software factory. Um, yeah, this kind of plays into this. If you have all the services, you can roll them up together with lens and those tools, it's gonna be easier, more productive. So that means it's more software, open source is the software factory to what does that term mean? And how >>it is leverage. Yeah, So here's what it means to us. And so, as you know, today, Soft is being produced by two groups working together to build software, uh, certainly the poor people are the developments, these are the people who create the core functionality. Imagine all the software should be architected and ultimately ship the code right? And maintain the code, but the developers today don't operate just by themselves. They have their psychics, they have their friends for often platform engineering and platform engineers. These are the people who are helping developers, you know, make some of the most important choices as to which platform states we should use, which services they should use, how they should think about governance. How should they think about cloud infrastructure they should use, which open source libraries they should use. How often they should be fresh those libraries and support. So this platform engineers create if you want the factory, the substrate and the automation, which allows these developers to be highly productive. And the analogy want to make is the chip design, right. If you imagine ship design today, you take advantage of a lot of software, a lot of tooling and a lot of free package libraries. You get your job done, you're not doing it by yourself. Uh just wiring transistors together or logical elements. You do it using a massive amount of automation and software, like recent polls. So that's that's what we aim to provide you to customers because what we discovered is that customers, I don't want to be in the business of buildings off the factories, They don't want to be in the business or building platform engineering teams. If they can avoid it, they just do it because they have no choice. But it's difficult for them to do. It's cumbersome, it's expensive. It's a one off. It really doesn't create any unique business value because the platform engineering for a bank is very similar to the platform engineering for, let's say, an oil gas company or the insurance company. Um So we do it for them turnkey as a service. So they can be focusing on what Madison's for that. >>That's a great inside. I love that platform engineering, enabling software developers because, you know, look at sas throwing features together. Being a feature developer is cool. And and and the old days of platform was the full stack developer. And now you have this notion of platform as a service in a way, in this kind of new way. What's different agents? You've seen these waves of innovation? Certainly an open source that we've been covering your career for over a decade uh with more Anderson and open stick and others. This idea of a platform that enables software. What's changed now about this new substrate, you mentioned what's different than the old platform model? >>Uh That's a wonderful question. Uh a couple of things are different. So the first thing that's different is the openness and uh, and that everything is based on open source frameworks as opposed to platforms that we that are highly opinionated and, and I lock in. So I think that's that's a very, very fundamental difference. If you're looking at the initial kind of platform as a service approaches, there were there were extremely opinionated and very rigid and not always open source or just a combination between open source and proprietary. So that's one very big difference. The second very big difference is the emphasis on, and it goes along with the first one, the emphasis on um, multi cloud and infrastructure independence, where a platform is not wedded to a particular stack, where it's a AWS stack or a uh, an Azure stack or the EMR stack. And, and but it's truly a layer above. That's completely open source center. >>Yeah. >>And the third thing that is different is the idea that it's not just the software, the software alone will not do the job, you need the software and the content and the support and the expertise. If you're looking at how platform engineering is done at the large company like Apple, for example, facebook, it's really always the combination of those three things. It's the automation framework, the software, It's the content, the open source libraries or any other libraries that you create. And then it's the expertise that goes all this together and it's being offered to developers to be able to take advantage of this like soft factory. So I think these are the major differences in terms of where we are today was five years ago, 10 years ago. >>Thank you for unpacking that for I think that's a great uh great captures the shift and value. This brings up my next uh question for you because you know, you take that to the next level. DeVOps is now also graduating to a whole another level. The future of devops uh and software engineering more and more around kubernetes and your tools like lens and others managing the point. What is the new role of devops? Obviously Deb see cops but devops is now changing to What's the future of devops in your opinion? >>Well, I believe that there is going to become more and more integrated where our option is going to become uh something like Zero Arts, where are you going to be fully automated And something that's being delivered entirely through software and developers will be able to focus entirely, on, on creating and shipping code. I think that's the major, that's a major change that's happening. The problem is still yet I think to be solved like 100% correctly is the challenge of the last mile. like deploying that code on on on the infrastructure and making sure that he's performing correctly to the sls and optimizing everything. I also believe that the complexity veneta is very powerful by the same time offers a lot of room for complexity. There are many knobs and dials that you can turn in these microservices based architecture. And what we're discovering now is that this complexity kind of exceeds the ability of the individual developer or even a group of developers who constantly optimize things. So I believe what we will see is a I machine learning, taking charge of optimizing a lot of parameters, operating parameters around the applications and that unemployment benefits to ensure those applications perform to the expectations of the illness. And that might mean performing to a very high standard security. Or it might mean performing to a very a low latency in certain geography. Might mean performing too a very low cost structure that you can expect and those things can change over time. Right? So this challenge of operating an application introduction Burnett is substrate is I think dramatically higher than on just additional cloud infrastructure or virtualization. Because you have so many services inter operating with each other and so many different parameters you can set for machine learning and Ai >>I love the machine learning. Ai and I'd love to just get your thoughts on because I love the Zero ops narrative Because that's day one zero ops now that you're here day to being discussed and people are also hyping up, you know, ai Ops and other things. But you know this notion of day to, okay, I'm shipping stuff in the cloud and I have to have zero ops on day 234 et cetera. Uh, what's your take on that? Because that seems to be a hot air that customers and enterprises are getting in and understanding the new wave, writing it and then going, wait a minute pushing new code that's breaking something over there I built months ago. So this is just notion of day to obstacle. But again, if you want to be zero ops, it's gonna be every day. >>Oh, I think you hit the nail on the head. I don't think there's going to be a difference between they want the zero they want and today chair, I think every day is going to be the zero. And the reason for that is because people will be shipping all the time. So your application will change all the time. So the application will always be fresh, so it will always be there zero. So zero ops has to be there all the time. Not just in the birthday. >>Great slogan! Every day is day zero, which means it's going well. I mean there's no no problems. So I gotta ask you the question was one of the big things that's coming up as well as this idea of an SRE not new to devops world, but as enterprises start to get into an SRE role where with hybrid and now edge becoming people not just industrial, um there's been a lot of activity going on a distributed basis. So you're gonna need to have this kind of notion of large scale and 00 ops, which essentially means automation, all those things you mentioned, >>not everyone can >>afford that. Um Not every company can afford to have you know hardcore devops groups to manage and their release process, all that stuff. So how are you helping customers and how do you see this problem being solved? Because this is the accelerant people want, they want the the easy button, they want the zero ops but they just they don't they can't pipeline people fast enough to do this role. >>Yeah. What you're describing is the central differentiator we bring to customers is this idea of as a service experience with guaranteed outcomes. So that's what makes us different versus the traditional enterprise infrastructure software model where people just consume software vendors and system integrate themselves and then are in charge of operations themselves and carrying the technical risks themselves. We deliver everything as a service with guaranteed outcomes through the through cloud native experience. That means guaranteed as L. A. Is predictable outcomes, continuous updates, continuous upgrades. Your on prem infrastructure or your edge infrastructure is going to look and feel and behave exactly like a public cloud experience where you're not going to have to worry about sRS or maintaining the underlying being delivered to you as a service. That's a big part, that's a central part of what makes us different in this space. >>That's great value proposition. Can you just expand give an example of a use case where you guys are doing that? Because this is something that I'm seeing a lot of people looking to go faster. You know speed is good but also it could kill right? So you can break things if you go to a. >>Yeah absolutely. I can give you several examples where we're doing this um very exciting company. So one companies booking dot com booking dot com as a massive on from infrastructure but they also massive public cloud consumer. And they decided they want to bring their own infrastructure to the cloud level of automation, cloud level Sophistication, in other words, they want to have their Aws on brand, they wanted to the old, so eccentric and we're delivering this to them with very high in the cell is exactly as a service turnkey Where there is nothing for them to system in grade or to tune and optimize and operate is being really operating 24/7 guaranteed sls and outcomes by us. Well, combination of soft film expertise that we have at massive scale and to the standards of booking dot com. This is one example, another example and this is a very large company um is the opposite side of the spectrum. You know, because they're not called Mexico super successful. Soft as a service company in the security space, growing in leaps and bounds in very high technical demands and security demands. And they want to have an on prem and cloud infrastructure to complement public clouds. Why? Because security is very important to them. Latency is very important to them. Control the customer experience is very important to them. Cost is very important to them. So for that reason they want that in a network of data centers around the globe And we provide that for them. Turnkey as a service than before seven, which enables them to focus 100% on building their own sense on their the functionality which matters to their customers and not have to worry about the underlying cloud infrastructure in their data centers. All of that gets provided to them has guaranteed about experience to their end users. So this would be the examples where we're doing a >>great service. People are looking for a great job. Adrian, Great to see you. Thank you for coming on the cube here, doc are gone 2021. Um, take a minute to put a plug in for the company. What are you guys up to? What you're looking for hiring? I'll see. You got great tracks with customers, congratulates on lens. Um give a quick update on what's going >>on. Happy happy to give it up in the company. So he, here are the highlights. It was super excited about about what we achieved last year and then what we're up to this year. So last year, what we're proud of is despite Covid, we haven't laid off a single person. We kept all the staff and we hired staff. We have gained 160 new customers, many of them, some of the world's largest and best companies and 300 of all existing customers have expanded their business with us last year, which is fantastic. We also had a very strong financial physical cash flow positive. It was a tremendous, tremendous here for us. Uh, this year is very much growth here for us and we would incredible focus on customer outcomes and customer experience. So what we are really, really digging in super hard on is to give the customers the technology and the services that enable them to get to ship software faster and easier to dramatically increase the productivity of dissolved the development efforts on any cloud infrastructure on crime and public clouds using containers and is and to do that as scale. So we're extremely focused on customer outcomes, custom experience and then the innovation is required to make that happen. So you will continue to see a lot of innovation around lens. So the last better release of lens that we brought about has now a cloud service and have a lot of feature where you can share all your cloud automation with your bodies, in, in uh, in uh, in your development team. So the lens used to be a single user product. Now it's a multi user and team based product, which is fantastic, continues to grow very quickly. And then container cloud as a service. Uh, it's a very big part that we're meeting on the infrastructure side. Are you get quite >>the open source cloud company. Adrian. Congratulations. We've been again following even on the many waves of innovation. Open stack, large scale open source software. Congratulations. >>Uh chris >>Thank you very much for coming on the cube. >>Yeah. >>Okay. Dr khan 2021 cube coverage. I'm john furrier here where the Gi Enel Ceo, co founder and chairman of Miranda's sharing his perspective on the open source innovation with their process and also key trends in the industry that is changing the game in accelerating cloud value cloud scales. Cloud native applications. Thanks for watching. Mhm.

>> Announcer: From around the globe, it's theCUBE, with digital coverage at Mirantis Launchpad 2020, brought to you by Mirantis. >> Welcome back. And I'm Stu Miniman, and this is theCUBE's coverage of Mirantis Launchpad 2020. Of course we're spending a lot of time talking about Kubernetes. We're going to be digging in talking about some of the important developer tooling that Mirantis is helping to proliferate in the market, solve some real important challenges in the space. So happy to welcome to the program Miska Kaipiainen. He is the senior director of engineering with Mirantis. Miska, thanks so much for joining us. Welcome to theCUBE. >> Thank you so much. >> All right, so Miska, I notice you've got on the Kontena sweatshirt. You were the founder of the company, did some tools. One of the tools that you and your team helped create was Lens. You and your team joined Mirantis, and recently Lens was pulled in. So maybe if you could just give us a little bit about your background. You do some coding yourself, the team that you have there, and let's tee up the conversation, 'cause it's that Lens piece that we're going to spend a bunch of time talking about. >> Yeah, so the background of what we did, basically Kontena, we started back in 2015, and we a the focus on creating technologies around the container orchestration technologies to basically to make developer tooling that are very easy to use for the developers. So during the years at Kontena, we did many different types of products, and maybe the most interesting product that we created was Lens. And now really when we joined Mirantis in January this year, so we have been able to work on Lens, and actually, since the Lens was made open source, fully open source in March this year, so it's been really kind of picking up, and now Mirantis acquired the whole technology, so we can really start investing even more in the development. >> All right, so let's talk specifically about Lens. As I teed up at the beginning, we're talking about managing multiple clusters. Gosh, and I think back to 2015. It was early on. Most people were still learning about Docker, Docker swarms, Kubernetes, Mesos. There were a lot of fights over how orchestration would be done. A little bit different discussion about what developers were doing, how they scaled out configurations, how they manage those. So help us understand kind of that core, what Lens does, and how the product has matured and expanded over those last five years. >> Yeah, so over the last five years, so originally Lens was developed for our internal product. So like Mesosphere and Docker, and they all have their own orchestration technologies even before Kubernetes. And we also started working on our own orchestration technology. And I'm a huge believer in when we are dealing with very complex technologies, so if you can visualize it and make it kind of more interesting to look at, so it will kind of help with the adoption, and it's kind of more acceptable to the market. And that's why we started doing Lens. And over the years, we turned Lens to work with Kubernetes environments, and nowadays really Lens is very much loved by the Kubernetes developers, who are those people who need to deal with the Kubernetes clusters on a daily basis. So they are not necessarily those ops people who are creating those clusters , but they are the people who actually use those clusters. >> Well, of course that that general adoption is something that, you know, super important. You have some stats you can share on, you talk about the love of developers. You said it's open source, it's available on GitHub, but how many people are using it? What are some of those usage stats? >> Yeah, so it was interesting. So when we released Lens open source under MIT license in March, so since then we have been getting, in half a year, we have been getting 8,000 stargazers on GitHub. That is kind of mind-blowing because we try to create projects and trying to create anything that would get a lot of traction in the past, but truly, it totally happened just now after years of trying. So it has been since the last six months, it's been just amazing the adopts and we have more than 50,000 users using Lens and the retention is great. People keep on coming back. So yeah, the numbers look very, very good for Lens, and we are just getting started. >> Yeah, well, it's something that this community definitely is huge growth, and anybody in this space remembers just the huge adoption of Docker, which of course the enterprise piece of Docker is now part of Mirantis. Inside those developers, help us understand a little bit more, what is it that has them really not only looking at the GitHubs, starring it, as you said, they're the stargazers. It's like a favorite, for those that aren't in the system. I've had a chance to look at some of the demos, and it seems rather straightforward. But if you could, just in your words, explain what it is that it solves for developers that otherwise they either had to do themselves or they had to cobble together a lot of different tools. We know developers out there. The wonderful thing is there's no shortage of tools to choose from. It's about the right tool that can do the right thing. >> Absolutely, absolutely. So Lens, we are calling it IDE for a reason. So we are talking about IDE for Kubernetes developers. And what does it mean actually is that we are taking all those necessary tools and technologies and packaging them, integrating them seamlessly together for the purpose of making it more easy for developers to deploy, operate, observe, inspect their workloads that are running on Kubernetes clusters. And I think the main benefits that Lens will provide for these developers is that if you're a newcomer in the Kubernetes ecosystem, so Lens gives you a very easy way to learn Kubernetes because it's so visual. And for more experienced users, it just radically improves the, let's say the speed of business and the way how you can perform things with your clusters. >> So one of the pieces that that Lens does is that multi-cluster management. So first of all, I believe, as you said, it's open source and can work with, is it any certified Kubernetes out there, whether it be from the public cloud, companies like VMware and Red Hat that have Kubernetes, of course, Mirantis has Kubernetes, too. And secondly, I think you teased out a little bit, but help help us understand a little bit. Multi-cluster management is something that the big players, you hear Azure and Google Cloud talking about how they look at managing not only other environments, but oh yeah, we can have other clusters and we can help you manage it. I think that's more on the ops side of things, as opposed to, as you said, this is really a developer tool set. >> Yeah, so of course, all the organizations, they want to most likely have some sort of centralized system where they can manage multiple clusters, and some companies provide systems for on-premises, and some public cloud vendors, they provide systems for provisioning those clusters on their own own systems. And then we have also the kind of multicloud management systems. Most of these technologies, they are really designed for the operations side, so how the IT administrations can manage these multiple clusters. So now if you look at the situation from the developer's perspective, they are now given access to certain number of clusters from different environments. And by the way, some of these clusters are also running on their local development environments on their laptops. So what Lens is doing is basically provides a unified user experience across all these clusters no matter what is the flavor of the Kubernetes. It can be the Minikube. It can be from AKS. It can be Mirantis Enterprise, Docker Enterprise offering, or whatever. So it kind of brings them all together and makes it very easy to navigate and go around and do your work. >> Yeah, well, that's, the promise of Kubernetes isn't that it just levels the playing field amongst everything. As I've talked to the founders of Kubernetes, people like Joe Beda said it's not a silver bullet. It's a thin layer. But that skillset is what's so important because there is a lot of difference between every platform they deal with. So as a developer, it's nice to have some tools that I can work across those environments. From a developer standpoint, I think it's on Windows, Linux, Mac, works across those environment. What do you hear from your customers? How are they using it? Is this something that they're like, oh hey, I can go make an adjustment on my mobile when I'm not necessarily in the office? Are we not quite there yet? >> Actually, it's kind of funny, because sometimes we hear these type of requests that we would like to have a mobile app version of Lens. I don't know how that would actually work in practice. So we haven't been doing anything on that front yet. I think still the most common use case is that developers, they are given access to clusters from somewhere and they are just desperately trying to find a kind of convenient way how to navigate around these different clusters and how to manage their workloads. And I think Lens is hitting the sweet spot in there with the ease of use. >> All right, so let me understand. It's been open sourced, yet Mirantis owns it. Is there a service or support? Does this tie into other products in the Mirantis portfolio? How do people get it? What do they need to, if anything, pay for it? And help us understand how this fits into the broader Mirantis story. >> Yes, so it's still kind of early days, so we just kind of announced that Lens is now part of Mirantis, let's say portfolio. So I must say that still the kind of main focus for us is around improving Lens and making it better for developers. So that's much more important than trying to think about the ways how potentially we could monetize this. So, but there are plans going ahead, going around for different ways how we can better support bigger enterprises who want to start using Lens in a big scale. >> Well, yeah, that's so important. Of course, developers, we need to lower the friction, help them adopt things fast. Miska, just get your general viewpoint, though. One of the big value propositions that Mirantis has is of course allowing enterprises to take advantage of these new types of solutions, especially today around Kubernetes. So help us understand from your standpoint the philosophy of what your team's helping to build and the customer engagements that you're having. >> Yes, so Mirantis, of course, has a broad portfolio of products, and many of those products, of course, are related to Kubernetes. And so we have many products which I'm also one of the leading development efforts around those. So some of the products are related to how to manage image repositories and registries. Some of them are related to how to handle the helm charts, which has basically become the defacto packaging format for Kubernetes applications. And we are kind of trying to bring all these different products and technologies together in a way that make it even more easy for developers then to access through Lens. So it's still a little bit work in progress, of course, since the Lens ecosystem is quite new, but we are on track there trying to make a beautiful one kind of experience for our customers. >> All right, well, final question I have for you. As you said, it's new there, but it gives a little taste as to feedback you're getting from the community. Anything we should be looking at on kind of the near to mid-term road map when it comes to Lens. >> Oh yeah, so we are just barely scratching the surface of the potential on what we can do with Lens. So one of the big features that we will be releasing still during this year in a couple of months time is going to be the extension API, which will allow all these cloud-native technology ecosystem vendors to bring their own technologies easily available and accessible through Lens. So it is possible for third parties to extend the user interface with their own kind of unique features and visualizations. And we are already actively working with certain partners to integrate their technologies through this extension API. So that's going to be huge. It's going to be game-changer. >> Well, the great thing about an open source project is people can go out, they can grab it now, they can give feedback, participate in the community. Miska, thank you so much for joining us and great to chat. >> Thank you for having me. Thank you. >> All right, stay with us for more coverage of Mirantis Launchpad 2020. I'm Stu Miniman and thank you for watching theCUBE. (bright music)

>> Narrator: From around the globe, its theCUBE with digital coverage of Mirantis Launchpad 2020 brought to you by Mirantis . >> Welcome back, I'm Stu Miniman and this is theCUBE coverage of Mirantis Launchpad 2020, really looking at how Mirantis Docker Enterprise are coming together, changes happening in the field and to help us dig into that customer and product discussion. Happy to welcome to the program, Shaun O'Meara. He is the global Field Chief Technology Officer with Mirantis coming to us from Germany. Shaun thanks so much for joining us. >> Thanks for having me. >> All right, so let's start with the customers. I always love talking to the Field CTOs you're out there. You're talking strategy, you're getting into some of the architecture, lots of customers, probably still, trying to figure out that whole cloud native containerization, Kubernetes and modernization piece. So when you talk to your customers, what are some of their biggest challenges they're facing and those main discussion points that bring them to talk to Mirantis. >> Very good question, I think you've just laid it out yourself in many ways. It's complexity our customers are dealing with more and more change, more and more options, and it's driving complexity in their environments, and they're looking for ways to deal with that complexity and to allow more and more access and reduce barriers to getting applications and getting tools to market. And if we look at it and we look at the way the world is going today, we have multiple cloud environments. We have every single developer on the face of the planet wants to use different tools, different ways to build applications that don't want to be dictated to. Now, if you turn that around and you look at what operators have to deal with, it's just more and more complexity. Ultimately, that complexity is growing and we're looking for ways to make it easier, simpler, and subsequently increase the speed of getting applications to market for our customers. >> Yeah, You know we talk a bit about some of the macro challenges that customers have. What talk you kind of teed up a little bit, the operators and the developers. I remember a couple of years ago, I had the opportunity to interview Solomon Hykes and of course the founder from Docker. And there was that talk of well, containerization, it's this wonderful thing for developers. And he's like, hold on Stu we actually, really started looking at this or the operators we want that unit of operation to be closer to the application. So it should be simpler, it used to be okay, how many different applications do they have on a server or VMs all over the place and containers I could really have this microservice or this application is a container. So there is some operational simplicity there, but how is that dynamic inside the customer? Of course, we've seen the growth and the importance and the embracing of developers, but there's still the DevOps adoption and we'd love to be able to say one of these years that, oh, we don't have silos anymore and everybody works together and we're all on the same page. >> Oh yeah, the reality is in the big enterprise companies and the companies that are building applications for market today, your big financial services companies, there's still a very clear separation between operators and developers. A lot of that is driven by legislation, a lot of that's driven by just old fashioned thinking in many ways, but developers are starting to have a lot more influence on what applications are used and the infrastructure. We just see with the rise of AWS, all the contenders to AWS in the form of Azure and Google. Developers are starting to have a lot more power over that decision, but they're still highly dependent on operators to deliver those platforms that they use, and to make sure that the platforms that they're running their applications on top of, are stable and run well in production situations. There's a big difference between building something on your laptop in one or two instances, and then trying to push it out to a massive scalable cloud platform. And I think those are the areas that we can have a lot of impact, and that's where we are building our tools for at the moment. >> Well, great. Let's dig into those tools a little bit, as I said, at the beginning, we're familiar, Mirantis had the Mirantis Cloud Platform for a few years, big embrace of Kubernetes and then Docker Enterprise, it comes into the mix. So help me understand a little bit, what is kind of the solution set to portfolio? How does Mirantis present that today? >> Yeah, well, it's been an interesting eight, nine months now of the whole process since with the Docker Enterprise business, a couple of key areas. So if we look at what MCP was, and MCP still here today apparently, it focuses on delivering all the components necessary to have an effective cloud platform. So lifecycle management, lifecycle management of all those underlying components, which in their own right is extremely complex set of software. What we focused on there was understanding in enterprise infrastructure, the right way to do that. As soon as you bring in from the Docker Enterprise business is that they have a scalable, large, well deployed container platform. And many thousands of users across the world in all sorts of different scales and production systems. We are merging that knowledge that we have around infrastructure, infrastructure management, and simplifying access to infrastructure with this platform that provides for all that application, hosting provides for all the control of containers, plus all the security components around the container lifecycle. And delivering in such a way that you can choose your underlying preference. So we're no longer looking to lock you in to say, you have to go on-prem, you have to go into cloud. We're saying, we'll give you the choice, but we'll also give you a standardized platform for your developers across all of those potential infrastructure environments, so I'll use it again, public cloud, private cloud, bare metal on-premise, or your options like the VMware of this world. By consolidating all of that into one platform, we're giving you that as a developer, the ability to write applications that'll run anyway and sorry, go on. >> No, please finish up, I've just got to follow, yeah. >> But that simplicity drives and like that's simple choice across all those platforms essentially drives speed. It takes away the typical barriers that we're seeing in our customers. We hear every reason, we love Docker Enterprise because it solves the problem of getting containers, it solves a problem of securing containers, but it takes four teams to deploy it. Same for the MCP, we're saying is we cannot do that in a day and provide other self sets. So you can deploy a brand new container cloud in minutes rather than days or weeks. And that's one of the biggest changes that we're bringing to the product. >> Yeah, so absolutely what we hear from customers that agility, that speed that you talk about is the imperative, especially talk about 2020, everybody has had to readjust often accelerating some of the plans they had to meet the realities of what we have today. What I want to understand is when you talk about that single platform being able to be in any environment, oftentimes there's a misnomer that it's about portability. Most customers we talked to, they're not moving things lots of places. They do want that operational consistency, wherever they go. At the same time, you mentioned the rise of AWS and the hyperscalers often when they're now going to have to manage multiple clusters, it's not that I choose one Kubernetes and I use it anywhere, but I might be using AKS Azure had an early version of it, of course, Amazon has a couple of options now for enterprises. So help us understand how the Mirantis solutions, fit with the clouds, leverage cloud services and if I have multiple clusters, you even mentioned VMware, I might have a VMware cluster, have something from Mirantis, have something from one of the hyperscalers. Is that what you're seeing from your customers today? And how do they and how do they want to manage that going forward? Because we understand this is still a maturing space. >> So I mean, that's exactly the point. What we're seeing from our customers is that they have policies to go cloud first. They still have a lot of infrastructure on-premise. The question is which cloud, which cloud suits their needs in which region. Now, all of a sudden you've got a risk management policy from an organization that says, well, I have to go to Azure and I have to go to AWS. That's using them as examples. The deployment and management of those two platforms is completely different. Just the learning curve for a developer who wants to focus on writing code, to build a platform on top of AWS is barely extensive. Yes, it's easy to get started, but if you really want to deal with the fine print of how to run some in production, it's not that simple. There are potentially a thousand different buttons, you can click when deploying an instance on Amazon. So what we're saying is, instead of you having to deal with that we're going to abstract that pain from you. We're going to say we'll deploy Docker Enterprise on top of Amazon, on top of Google, on top of Azure, on top of your VMware cluster, give you a consistent interface to that, consistent set of tools across all those platforms, still consuming those platforms as you would, but solve all those dependency problems. To set up a cube cluster on top of Amazon, I'm not talking about an AKS or something like that right now, but the sort of cube cluster means I have to set up load balances, I have to set up networks, I have to set up monitors, I have to set up the instances, I have to deploy Kubernetes, and then I'm only getting started. I still haven't integrated that to my corporate identity management. We're saying we'll bring all that to give them, we are bringing all that together in the form of Docker Enterprise container cloud. >> Yeah, definitely as you said, we need more simplicity here. The promise of cloud it's supposed to be simplicity and now of course we have the paradox of choice when it comes there. >> Yeah. >> One of the other things we've seen, rapid change a lot the last year or so is many of the offerings out there are now managed services. So as you said, I don't want to have to build all of those pieces. I want to just be able to go to somebody. What are you hearing from your customers? How does manage service fit into what Mirantis is doing? >> Great, well, what we're hearing from customers is they want the pain to go away. The answer to that could be delivered through software that's really easy to use and doesn't set up any barriers and gets them started fast, which is where we focus from a product perspective. Mirantis also has a strong manage services on so we've been doing manage services for some of the biggest enterprises in the world for MCP products for many years. We've brought those teams forward and we're now offering those same managed services on top of all of our platforms. So Docker Enterprise container cloud, we'll deploy it for you, we'll manage it for you. We'll handle all the dependencies around getting container cloud up and running within your organization, and then offer you that hands on service. So when you build clusters, when you want clusters that are much more longer lived, we can handle all the extra detail that goes around those. Short term, so if you just want quick clusters for your developers, easy access, you still have that as part of the service. So we're focusing on how fast can we get you started? How fast can you get up the cushions to market, not put any infrastructure barriers on the way, or where there are traditional infrastructure barriers find ways around us. That still acceptable to those enterprise operators who still have list as long as my arm, probably twice as long as my arm of fine print that they have to comply with for everything under the sun, the regulators, et cetera. >> Yeah, Shaun since you are based in Europe, I'm wondering if you can give us a little bit of the perspective on cloud adoption there, here in North America, discussion point has been for many years, just that massive movement to public cloud, of course governance the key issue in Europe and above also kind of the COVID impact, anecdotally there's lots of discussions of acceleration of public cloud. So what's the reality on the ground? How do your enterprise customers look at public cloud? How fast or slow are they moving and what is the 2020 impact? >> So interesting if you'd asked me this question, six months ago, seven months ago, pre COVID, I would have said public cloud is growing. People are still building some small private clouds for very unique use cases, looking at where our customers are now, all of a sudden there's a risk balance. So they're driving into public cloud, but they want those public clouds to be with European companies and European operators, or at least to have some level of security. You know, recently the European community canceled the privacy shield legislation that was in place between the US and Europe, which meant all of a sudden, a lot of companies in Europe had to look for other places to store their data, or had to deal with different rules around storing the data that they may have but in the US previously. What we're seeing customers saying is we have to go multicloud. The drive is no longer we can accept one vendor risk. We want to remove that risk, we will still have equipment on-premise. So on-prem equipment is still important to us, but as a backup to the public cloud, and as a way to secure our data and the mechanisms that we own and can touch and control. That's the operator's view. If we talk to developers, people writing applications, if they are not forced to, they will go public cloud almost every time. It's just easier for them. And that's really what we're, that's really the challenge that we're also trying to focus on here. >> Yeah, I'm curious, are there any European cloud providers that are rising to the top the big three have such a large megaphone that they kind of drown out a lot of discussion and understand that there's pockets and many local suppliers, and of course thousands of kind of cloud service providers out there, but any ones that are good partners of Mirantis or ones that you're hearing. >> There are a couple. >> Yeah. >> Sorry, there are a couple, I dunno if I can mention them here, but there's some great ones providing very unique businesses, places like the Netherlands, very unique, very focused business where they're taking advantage of specific laws within, well, the Netherlands and Germany, there's another company that we're working very closely with that feels that they can do a much more affordable, much more hands on service or cloud. So their cloud experience provide everything developers want, but at the same time handle those operator requirements and those enterprise requirements within Germany. So focusing on the GDPR laws, focusing on German technology laws, which are very complex, very much focused on privacy. And there are a few unique companies like that across Europe, I know of one in Italy, there's a company that focuses on providing cloud services to the EU government themselves, who we've worked with in the past. So yeah, but as you say, it's the big three, they're growing, they're dealing with those challenges. We see them as resources, we see them as partners to what we're trying to achieve. We certainly not trying to compete with them at that level. >> Absolutely, all right, Shaun final question I have for you, tell us what your customers see as the real differentiation, what draws them to Mirantis and what we should expect to see over the coming months? >> So I think choice is a key differentiator. We're offering choice, we're not trying to tell you you can only use one cloud platform or one cloud provider. And that's extremely important as one of the key differentiators. I've mentioned this many times, simplicity, driving simplicity at all levels, from the operator through to the developer, to the consumer of the cloud, let's make it easy. Let's truly reduce the friction to getting started, all right that's one of the really key focus areas for us and that's something we talk about all the time in every meeting and we question ourselves constantly is, does this make it easier? And then security is a major component for us. We really focus on security as part of our tool sets, providing that standardized platform and that standardized security across all of these environments, and ultimately reducing the complexity. >> Shaun O'Meara, thank you so much. Great to hear that the real customer interaction and what they're dealing with today. >> Sure, thank you very much. >> Be sure to check out the tracks for developers, for infrastructure as well as all the rest theCUBE interviews on the Mirantis Launchpad site of course powered by CUBE365. I'm Stu Miniman and thank you for watching theCUBE. (upbeat music)

>> Announcer: From around the globe, it's theCUBE, with digital coverage of Mirantis Launchpad 2020, brought to you by Mirantis. >> Welcome back I'm Stu Miniman, and this is theCUBE's coverage of Mirantis Launchpad 2020. Big event, multiple tracks powered by theCUBE365. Happy to welcome you to the program. We have a first time guest, Willem du Plessis. He's the Director of Customer Success and Operations with Mirantis. Willem, thanks so much for joining us. >> Hi Stu, thanks for having me. >> So customer success, of course, a big topic in the industry last few years. CX a is so important. Employee success and enabling that, but what, give us a little bit, your background and the purview that you and your team cover. >> Exactly, yeah, so everything under my umbrella would be basically post-sales. The whole customer experience after the point of a sale's been made so the whole account management, thereafter, the success of the accounts, as well as the health of the account, thereafter, that will be anything basically post-sales would be under my umbrella. >> Wonderful, well, the big piece is the shift. As we know, software went from shrink wrapped, and hardware talking about CapX to the cloud really ushered in OpX we're touching more subscription managed services and the like, so Mirantis has a subscription offering. Why don't you lay out for us the new pieces of this and how Mirantis puts together its offerings? >> Yeah, absolutely. So with the launch of our new product, Docker Enterprise Container Cloud, we're making two subscriptions available as well, named ProdCare, which is a 24/7 mission critical support offering and OpsCare, being a fully managed platform as a service subscription. Now, these offerings have been available on the Mirantis Cloud platform side of our business for quite some time, we've been very successful with them, so it's really excited making them available to our Docker Enterprise customers. So what we're trying to achieve with these accounts or with these subscriptions, rather, you know, 30% of the Fortune 100 companies are Mirantis customers, so we work on a day to day basis with their container and Kubernetes initiatives. So when we speak to these customers, there are really two trends that are becoming very clear, the first being the requirements of service providers or vendors being able to provide a true 24/7 experience. What I mean by that is not the ability to just react to an incident on a 24/7 basis. That's what I mean, what I mean is all of these companies would have operation centers spread across the globe. So it is at every hour of the day, it would be business as usual. And what these companies require is a, a partner or a service provider that can match that level, that way of operating. That is the first trend that we're noting. The second piece is really the, the evolution of the dev environment. The dev environment is no longer really seen as a secondary or a lower class citizen, if you want to call it, it's really become part of the whole DevOps pipeline, so it is really part of a mission critical process so that what customers, what we hear from our customers is that they require a real enterprise-grade subscription that they can cover this whole pipeline under and, you know, have the same quality of service from whether that is a dev or a production environment. So if you have a failure on your dev environment and your developer cannot push code, that is, is the same level of criticality than there would then they would be on if the failure was on the production environment. So this whole pipeline is decidedly seen as a mission critical component. And that's a great, that's really where ProdCare comes in. It is really this 24/7 mission critical follow the sun, enterprise-grade subscription that provides our customers with enhanced SLAs that, like I said, we've been running on the Mirantis Cloud platform side for quite some time, we've had some significant success with some really large companies. The second offering that we're making available with, like I said, is OpsCare. Now OpsCare is an ITIL-based managed service subscription, where we provide a platform as a service experience to a customer on their infrastructure of choice. So it is really irrelevant for us what your infrastructure is, whether that is on-prem or in the public cloud, as long as the product can support the infrastructure, you know, the subscription would be available for you and the experience would be very much the same. So what OpsCare, like I said, entails is, is this whole ITIL framework that would include, you know, the monitoring and managing of your alerts, the incident management process, the problem management process, as well as change management that would include the lifecycle management of the whole environment. And that would just enable our customers to run on the latest and greatest offer of our product at all times. And same as with ProdCare that's been available for our brass cloud platform customers for quite a while, and have seen some significant success with that, as well. >> Well, we definitely have seen that growth of the managed care offerings like you're talking about with OpsCare, you know, shift left is so important for companies to be able to focus on what's critically important. As you said, developers need to be enabled, it can't just be waiting for things or be, you know, relegated to, you know, have to wait in line or use something that's not optimal. What are some of those outcomes? What can companies do that they weren't able before? What are some of those successes that you're seeing with the managed care OpsCare solution? >> Yeah, so the real way we OpsCare really comes to its own is allowing the customer ability to focus on what is important to their business and spend less time on what we call, keep the lights on. What I mean by that is they're solely focused on developing the application, developing the workload and spend basically no time on managing the infrastructure and, you know, maintaining it, or, you know, providing, do whatever to, to keep the platform stable, because that is done by Mirantis, already. So for example, if we take 2020 year to date, all the platforms running under OpsCare has an availability number of above four nines, and that is a significant number. So that really just sets such a strong foundation for a customer to just have that sole focus on, on what is important to them and, you know, just sets that foundation for them to develop their workload, to develop their business, and achieve their goals. >> Well, what about when it comes to the managing and monitoring of the environment? What kind of metrics are your customers having? Help us understand what the customer still does themselves or the reporting they're getting and what Mirantis, I'm assuming there's probably a Tam involved for at least some of the larger accounts there. Help us understand that shared responsibility, if you would for these type of environments. >> Yeah, exactly. So the whole ITIL framework, as I explained earlier, incident management, problem management, change, all of that, this is wrapped around why a customer success manager that is, you know, brings a single level of ownership on an accountability, and just have a customer direct for a single point of contact as a business partner. So all this is all our customers, their primary KPI or metric that we look at is just the availability of the platform. That is the primary SLA and thereafter, all of the other things happening, you know, the success of the workload and so on, because there's a lot of things that makes the result of the workload, not just the platform or the infrastructure, it's the quality of the workload, and so on, and so forth. But the main metric our customer would be looking at is that availability number, you know, how available and how stable and accessible is the environment, and, you know, like I said, just removing that requirement for them to spend, basically, no time on the platform or the infrastructure, and just focusing on the workload. >> Yeah, when it comes to in the field, your field, your partners, that line between ProdCare and OpsCare, obviously, the trend is going towards, you know, the fully managed option, but what guidance do you have out there, or what trends do you seeing? Is it a certain size company, that tends to be trending that way? Are there certain verticals that may be are further ahead? What's the reality, today? What do you expect to see over the next kind of six, 12 months? >> Yeah, so most of the companies that we see that as, that is engaging with us on an OpsCare, or managed service engagement, you know, they have the ambitions to go down the block model and build, operate, transfer, you know, to take the operations over themselves, at some point, and we have that option available to them, if they wish to choose it further along the line. What we do find is, is that they, that they don't really, you know, exercise that later on. It is, we do find it is such a smooth integration with our customers, that they tend to stay on OpsCare and see the value. This is actually a money saver for them, if they could, just focus their efforts on building, you know, focusing their time on the workload on top of the platform. From a vertical perspective, it's really anything and everything. We have customers in the science and research, we have TELCOs, large manufacturing, manufacturing, a lot of large organizations. There's really the breadth of the verticals that we see that are utilizing OpsCare and not even to mention ProdCare, that's really everything in there, as well. So it is not a really a subscription that is, that is custom for one vertical. It is basically something that we, that any vertical can actually utilize and find a significant amount of value in. >> All right, well, what final words do you have that you want to leave everyone with today? >> Yeah, so over the last six to nine months, you know, we've invested a significant amount of resources in the Docker Enterprise support business and we just with one focus, and that is just to take the support business to the next level and improve or give the customers an optimal customer experience. So with the availability of all these new subscriptions, I'm really excited to engage with our Docker Enterprise customers with these new, enhanced SLAs and just be able to work with them on these, like I said, enhanced subscriptions and just see, just give them a better customer experience. So, I'm really looking forward to working with them on the subscriptions. >> Willem, thank you so much for all the updates and want to welcome everyone to be sure to check out all the rest of the tracks on the Launchpad 2020 event. I'm Stu Miniman and thank you for watching theCUBE. (soft electronic music)

>> Narrator: From around the globe it's the CUBE with digital coverage of Mirantis Launchpad 2020, brought to you by Mirantis. >> Welcome back, I'm Stu Miniman, and this is the CUBE's coverage of Mirantis Launchpad 2020. And always love when we get to be able to talk to the practitioners that are using some of the technologies here. One of the interesting things we've been digging into is lens, the IDE in this space, as it's being referred to. So, happy to welcome to the program Matti Paksula. He is the founder and chief technology officer at supervisor.com. Matti, thanks so much for joining us. >> Thank you, thank you thank you for having me. >> So, if you could just, you help us understand, you know, your company as supervisor.com. What's the background as the founder? What was kind of the impetus to creating that business too? >> Sure, so, supervisor was this like super simple because we believe, and we know, that the only way to tests websites, if they can handle load, for example, eCommerce sites on black Friday, or when you, or, just about to make a product launch or that kind of stuff. Is just by sending real web browsers to the site. That's actually click and scroll and do it all the same things as a real users will do. But, and unlike, our secret thing is that we can do it, like before Black Friday. So, if somebody wants to simulate if they can handle like 2000 users or 5000 users, then they can use supervisor.com to make it happen like today. >> So, I'm just curious, you know, the concern always is about the DDoS attacks and the like. Do you help companies along that line too? Or is it more the, the testing for proper traffic and we leave the security aspect to somebody else? >> Yeah, well, like with any load testing tool, you have to verify yourself somehow. And with us, it's super easy because we integrated with Google analytics. And if you authorize us to read your Google Analytics Data, then we know that you are allowed to test your site. >> Wonderful, well, as I said in the lead, you're using lens, my understanding you've been using it since the early day, of course, a technology that closed source Mirantis has, has acquired that and the team, it's now also open source. So if you could bring us back to, you know, how did you get involved with lens? What was the, you know, the problem statement that it helped you resolve? >> Yeah, sure. So the (inaudible) super briefly is that Lens was developed by this startup called Condena, it's a finish startup, and they made a couple of attempts in container orchestration, like before Kubernetes and then Coobernetti's game. And they just felt like Kubernetes is super hard to kind of visualize or like, understand what's going on because you have these containers flying around, you have nodes going in going out. So they built this lens and then since I'd be working with those guys from 2015 or so, I was like one of the first outside users, or probably the first user outside of the company. >> So, that, pretty neat that you had that, you know, that project that they were doing. As an early user, you know, give us a little bit of that journey. What does it enable for your company? You know, how has it expanded from kind of the early use cases to where it is today. >> Yeah. So, if you're using Kubernetes traditionally, or like how most of the people who haven't yet heard about Lens use it is by or from the command line. So that's where you use keep CTL or cube control. You say cube CTL pod, and then you get the listing pod. But the problem is that, all that data is stale on the screen. So if you trend try to, for example, delete a port and you issue cutesy delete pod, blah, blah, blah, blah. And then you enter on the pod all ready, it might be gone. So Lens makes like everything real time. And like, if you try to delete something with lens, you move your mouse on top of the pod. And if it's getting deleted, you know, this, it, because it just disappears from your screen and like, it's not there anymore. And I think that's a huge a productivity boost in a way, that's how you can like get more and more stuff done every day as these kind of like, when you are a developer or CSI admin or whatever you need to kind of like, see what's happening in your cluster and house that note and pods are doing. And that. So back to your question, when you asked, like, how has the evolved lens it's like nowadays it's super stable. It handles big workloads very well. In the very, very early on, they had some performance issues with like, like large clusters, for example, when supervisor, when we run a load test with, for example, 10,000 concurrent web browsers. So basically what we have in Kubernetes is we have 10,000 pods. And then when you connect something like lens to it, it's just like started to spin up my fans until on the laptop, still about eating all the Ram. So I helped them a lot with my special use case of running like super big Ephemeral workloads there. >> Yeah. It's an interesting discussion. And in the whole, you know, container space, there's all that discussion of scale(chuckling). You know, of course everybody thinks back to Google and how they use it. So we know it can go really big, but, you know, environments, I needed to be able to work really small or youth cases like yours. I needed to be able to, you know, burst use that usage when you need it and go back on that a less density that we hope for in, in cloud. So I'm curious any, what's your expectation with it, you know, going open source, coming into Mirantis as a, as a longtime user of it, you know, what do you expect to see? >> Well, I think like Mirantis offers the right kind of home for the product, because they really get what's happening in the space. And I think they're like commercial offering on top of the open source will be around authentication. That's why, like, I kind of understood from the press release. And I think it makes sense because like, developers don't want to pay for these kinds of tools. And there are other tools that are commercial. And even if it's like just 100 bucks per year, I think that's still not going to work out with most of the developers and you kind of need this kind of long tail developer adoption for these kinds of products to succeed. And I think that, like, that's kind of like authentication, like centralized, like who can see what, and that kind of stuff. It doesn't like affect most of the startups or Indie Devs, but like for any company who was doing it like a real business, those are the features that are needed. And when you use that, the products for business, then I think it makes sense to pay also. >> Yeah, absolutely. There's always that, challenge developers of course love open source tools if they can use them. And, you know, the packaging, the monetization, isn't a question for you it's(chuckling), you know, for the Miranda's team. What would you say to your peers out there, people that are in this space, you know, what are the areas that they say, Oh, you know, if I have this type of environment, or if I have type, if I have this team, this is what lens will really be awesome for me. What are some of the things that you would recommend to your peers out there from, from all the usage that you've done? >> Yeah. So let's say three things. The first thing is what I already mentioned the real timeness that everything updates live, the second thing is the integrated metrics. So you cannot, for example, follow how much memory or CPU something is consuming. It's super helpful when you want to like, understand what's really going on and how much resources something is taken. And then the third thing is that Landis is great for debugging because once you have deployed something and something is off, and it's kind of hard to reproduce locally, especially with this kind of a microservice architecture, whatever, what you might have is that you can just like go inside at any part or note instantly from the UI. You don't have to, like, again, you don't have to use cubes sheets, the L blah, blah, blah, blah, blah. And, and you have just like in there also, because you are already in the. But its the fourth thing is that if you manage multiple Kubernetes clusters, it's super easy to accidentally connect to the wrong cluster. But like, if you have, some visual tool where you can see in I'm in this. I mean, my production cluster are I'm in my staging cluster and you make the selection like visually there, then all the cube sees and everything works against that's a cluster. So I think that's like very helpful so that you don't actually accidentally delete something from production, for example. >> Wonderful. Last question I have for you either blend specifically, or kind of the eco-system around it, what, would be on your wishlist for, as I said, either lance specifically, or to, you know, manage your environments surrounding that, you know, what, what would you be asking kind of Miranda and, the broader eco-system for? >> I know that, well, let me think. Yeah. Okay. First of all, I have like maybe 50, 60 issues still open a GitHub that I have opened there. So that's like my wish list, but like, if you, they got like longer term, I think it would just be great, if you could actually like start deployments from Lance, there are a bunch of deployment tools, like customize and help. But again, if you just wanted to get something running quickly, I think integrating that to Lance would be like, super good. Just you it's just like click like I want to deploy this app. That's, that's something I'm looking forward to. >> Yeah, absolutely. Everybody wants that simplicity. All right. Well, Hey, thank you so much. Great to hear the feedback. We always talk about the people that developed code, as well as, you know, the people that do the beta testing and the feedback. So critically important to the maturation development of everything that's based though. Thanks so much for joining us. >> Thank you. >> Stay tuned for more coverage from Mirantis Launchpad 2020 I'm Stu Miniman. And thank you for watching the cube. (upbeat music)

>> Hi, I'm Adrienne Davis, Customer Success Manager on the CFO-side of the house at Mirantis. With me today is Artem Andreev, Product Manager and expert, who's going to enlighten us today. >> Hello everyone. It's great to hear all of you listening to our discussion today. So my name is Artem Andreev. I'm a Product Manager for Mirantis OpenStack line of products. That includes the current product line that we have in the the next generation product line that we're about to launch quite soon. And actually this is going to be the topic of our presentation today. So the new product that we are very, very, very excited about, and that is going to be launched in a matter of several weeks, is called Mirantis OpenStack on Kubernetes. For those of you who have been in Mirantis quite a while already, Mirantis OpenStack on Kubernetes is essentially a reincarnation of our Miranti Cloud Platform version one, as we call it these days. So, and the theme has reincarnated into something more advanced, more robust, and altogether modern, that provides the same, if not more, value to our customers, but packaged in a different shape. And well, we're very excited about this new launch, and we would like to share this excitement with you Of course. As you might know, recently a few months ago, Mirantis acquired Docker Enterprise together with the advanced Kubernetes technology that Docker Enterprise provides. And we made this technology the piece and parcel of our product suite, and this naturally includes OpenStack Mirantis, OpenStack on Kubernetes as well, since this is a part of our product suite. And well, the Kubernetes technology in question, we call Docker Enterprise Container Cloud these days, I'm going to refer to this name a lot over the course of the presentation. So I would like to split today's discussions to several major parts. So for those of you who do not know what OpenStack is in general, a quick recap might be helpful to understand the value that it provides. I will discuss why someone still needs OpenStack in 2020. We will talk about what a modern OpenStack distribution is supposed to do to the expectation that is there. And of course, we will go into a bit of details of how exactly Mirantis OpenStack on Kubernetes works, how it helps to deploy and manage OpenStack clouds. >> So set the stage for me here. What's the base environment we were trying to get to? >> So what is OpenStack? One can think of OpenStack as a free and open source alternative to VMware, and it's a fair comparison. So OpenStack, just as VMware, operates primarily on Virtual Machines. So it gives you as a user, a clean and crispy interface to launch a virtual VM, to configure the virtual networking to plug this VM into it to configure and provision virtual storage, to attach to your VM, and do a lot of other things that actually a modern application requires to run. So the idea behind OpenStack is that you have a clean and crispy API exposed to you as a user, and alters little details and nuances of the physical infrastructure configuration provision that need to happen just for the virtual application to work are hidden, and spread across multiple components that comprise OpenStack per se. So as compared again, to a VMware, the functionality is pretty much similar, but actually OpenStack can do much more than just Vms, and it does that, at frankly speaking much less price, if we do the comparison. So what OpenStack has to offer. Naturally, the virtualization, networking, storage systems out there, it's just the basic entry level functionality. But of course, what comes with it is the identity and access management features, or practical user interface together with the CLI and command line tools to manage the cloud, orchestration functionality, to deploy your application in the form of templates, ability to manage bare metal machines, and of course, some nice and fancy extras like DNSaaS service, Metering, Secret Management, and Load Balancing. And frankly speaking, OpenStack can actually do even more, depending on the needs that you have. >> We hear so much about containers today. Do applications even need VMs anymore? Can't Kubernetes provide all these services? And even if IaaS is still needed, why would one bother with building their own private platform, if there's a wide choice of public solutions for virtualization, like Amazon web services, Microsoft Azure, and Google cloud platform? >> Well, that's a very fair question. And you're absolutely correct. So the whole trend (audio blurs) as the States. Everybody's talking about containers, everybody's doing containers, but to be realistic, yes, the market still needs VMs. There are certain use cases in the modern world. And actually these use cases are quite new, like 5G, where you require high performance in the networking for example. You might need high performance computing as well. So when this takes quite special hardware and configuration to be provided within your infrastructure, that is much more easily solved with the Vms, and not containers. Of course not to mention that, there are still legacy applications that you need to deal with, and that well, they have just switched from the server-based provision into VM-based provision, and they need to run somewhere. So they're not just ready for containers. And well, if we think about, okay, VMs are still needed, but why don't I just go to a public infrastructure as a service provider and run my workloads there? Now if you can do that, but well, you have to be prepared to pay a lot of money, once you start running your workloads at scale. So public IaaSes, they actually tend to hit your pockets heavily. And of course, if you're working in a highly regulated area, like enterprises cover (audio blurs) et cetera, so you have to comply with a lot of security regulations and data placement regulations. And well, public IaaSes, let's be frank, they're not good at providing you with this transparency. So you need to have full control over your whole stack, starting from the hardware to the very, very top. And this is why private infrastructure as a service is still a theme these days. And I believe that it's going to be a theme for at least five years more, if not more. >> So if private IaaSes are useful and demanded, why does Mirantis just stick to the OpenStack that we already have? Why did we decide to build a new product, rather than keep selling the current one? >> Well, to answer this question, first, we need to see what actually our customers believe more in infrastructure as a service platform should be able to provide. And we've compiled this list into like five criteria. Naturally, private IaaS needs to be reliable and robust, meaning that whatever happens on the underneath the API, that should not be impacting the business generated workloads, this is a must, or impacting them as little as possible, the platform needs to be secure and transparent, going back to the idea of working in the highly regulated areas. And this is again, a table stake to enter the enterprise market. The platform needs to be simple to deploy (audio blurs) 'cause well, you as an operator, you should not be thinking about the internals, but try to focus in on enabling your users with the best possible experience. Updates, updates are very important. So the platform needs to keep up with the latest software patches, bug fixes, and of course, features, and upgrading to a new version must not take weeks or months, and has as little impact on the running workloads as possible. And of course, to be able to run modern application, the platform needs to provide the comparable set of services, just as a public cloud so that you can move your application across your terms in the private or public cloud without having to change it severally, so-called the feature parity, it needs to be there. And if we look at the architecture of OpenStack, and we know OpenStack is powerful, it can do a lot. We've just discussed that, right? But the architecture of OpenStack is known to be complex. And well, tell me, how would you enable the robustness and robustness and reliability in this complex system? It's not easy, right? So, and actually this diagrams shelves, just like probably a third part of the modern update OpenStack cloud. So it's just a little illustration. It's not the whole picture. So imagine how hard it is to make a very solid platform out of this architecture. And well, naturally this also imposes some challenges to provide the transparency and security, 'cause well, the more complex the system is, the harder it is to manage, and well the harder it is to see what's on the inside, and well upgrades, yeah. One of the biggest challenges that we learned from our past previous history, well that many of our customers prefer to stay on the older version of OpenStack, just because, well, they were afraid of upgraded, cause they saw upgrades as time-consuming and risky and divorce. And well, instead of just switching to the latest and greatest software, they preferred reliability by sticking to the old stuff. Well, why? Well, 'cause potentially that meant implied certain impact on their workloads and well an upgrade required thorough planning and execution, just to be as as riskless as possible. And we are solving all of these challenges, of managing a system as complex as OpenStack is with Kubernetes. >> So how does Kubernetes solve these problems? >> Well, we look at OpenStack as a typical microservice architecture application, that is organized into multiple little moving parts, demons that are connected to each other and that talk to each other through the standard API. And altogether, that feels as very good feet to run on top of a Kubernetes cluster, because many of the modern applications, they fall exactly on the same pattern. >> How exactly did you put OpenStack on Kubernetes? >> Well, that's not easy. I'm going to be frank with you. And if you look at the architectural diagram, so this is a stack of Miranda's products represented with a focus of course, on the Mirantis OpenStack, as a central part. So what you see in the middle shelving pink, is Mirantis OpenStack on Kubernetes itself. And of course around that are supporting components that are needed to be there, to run OpenStack on Kubernetes successfully. So on the very bottom, there is hardware, networking, storage, computing, hardware that somebody needs to configure provision and manage, to be able to deploy the operating system on top of it. And this is just another layer of complexity that abstracts the Mirantis OpenStack on Kubernetes just from the under lake. So once we have operating system there, there needs to be a Kubernetes cluster, deployed and managed. And as I mentioned previously, we are using the capabilities that this Kuberenetes cluster provides to run OpenStack itself, the control plane that way, because everything in Mirantis OpenStack on Kuberentes is a container, or whatever you can think of. Of course naturally, it doesn't sound like an easy task to manage this multi-layered pie. And this is where Docker Enterprise Container Cloud comes into play, 'cause this is our single pane of glass into day one and day two operations for the hardware itself, for the operating system, and for Docker Enterprise Kubernetes. So it solves the need to have this underlay ready and prepared. And once the underlay is there, you go ahead, and deploy Mirantis OpenStack on Kubernetes, just as another Kubernetes application, application following the same practices and tools as you use with any other applications. So naturally of course, once you have OpenStack up and running, you can use it to create your own... To give your users ability to create their own private little Kubernetes clusters inside OpenStack projects. And this is one of the measure just cases for OpenStack these days, again, being an underlay for containers. So if you look at the operator experience, how does it look like for a human operator who is responsible for deployment the management of the cloud to deal with Mirantis OpenStack on Kubernetes? So first, you deploy Docker Enterprise Container Cloud, and you use the built-in capabilities that it provides to provision your physical infrastructure, that you discover the hardware nodes, you deploy operating system there, you do configuration of the network interfaces in storage devices there, and then you deploy Kubernetes cluster on top of that. This Kubernetes cluster is going to be dedicated to Mirantis OpenStack on Kuberenetes itself. So it's a special (indistinct) general purpose thing, that well is dedicated to OpenStack. And that means that inside of this cluster, there are a bunch of life cycle management modules, running as Kubernetes operators. So OpenStack itself has its own LCM module or operator. There is a dedicated operator for Ceph, cause Ceph is our major storage solution these days, that we integrate with. Naturally, there is a dedicated lifecycle management module for Stack Light. Stack Light is our operator, logging monitoring alerting solution for OpenStack on Kubernetes, that we bundle toegether with the whole product suite. So Kubernetes operators, directly through, it keeps the TL command or through the practical records that are provided by Docker Enterprise Container Cloud, as a part of it, to deploy the OpenStack staff and Stack Light clusters one by one, and connect them together. So instead of dealing with hundreds of YAML files, while it's five definitions, five specifications, that you're supposed to provide these days and that's safe. And although data management is performed through these APIs, just as the deployment as easily. >> All of this assumes that OpenStack has containers. Now, Mirantis was containerizing back long before Kubernetes even came along. Why did we think this would be important? >> That is true. Well, we've been containerizing OpenStack for quite a while already, it's not a new thing at all. However, is the way that we deploy OpenStack as a Kubernetes application that matters, 'cause Kubernetes solves a whole bunch of challenges that we have used to deal with, with MCP1, when deploying OpenStack on top of bare operating systems as packages. So, naturally Kubernetes provides us with... Allows us to achieve reliability through the self (audio blurs) auto-scaling mechanisms. So you define a bunch of policies that describe the behavior of OpenStack control plane. And Kubernetes follows these policies when things happen, and without actually any need for human interaction. So isolation of the dependencies or OpenStack services within Docker images is a good thing, 'cause previously we had to deal with packages and conflicts in between the versions of different libraries. So now we just ship everything together as a Docker image, and I think that early in updates is an advanced feature that Kubernetes provides natively. So updating OpenStack has never been as easy as with Kubernetes. Kubernetes also provides some fancy building blocks for network and like hold balancing, and of course, collegial tunnels, and service meshes. They're also quite helpful when dealing with such a complex application like OpenStack when things need to talk to each other and without any problem in the configuration. So Helm Reconciling is a place that also has a great deal of role. So it actually is our soul for Kubernetes. We're using Helm Bubbles, which are for opens, provide for OpenStack into upstream, as our low level layer of logic to deploy OpenStack app services and connect them to each other. And they'll naturally automatic scale-up of control plane. So adding in, YouNote is easy, you just add a new Kubernetes work up with a bunch of labels there and well, it handles the distribution of the necessary service automatically. Naturally, there are certain drawbacks. So there's fancy features come at a cost. Human operators, they need to understand Kubernetes and how it works. But this is also a good thing because everything is moving towards Kubernetes these days, so you would have to learn at some point anyway. So you can use this as a chance to bring yourself to the next level of knowledge. OpenStack is not 100% Cloud Native Application by itself. Unfortunately, there are certain components that are stateful like databases, or NOAA compute services, or open-the-switch demons, and that have to be dealt with very carefully when doing operates, updates, and all the whole deployment. So there's extra life cycle management logic build team that handles these components carefully for you. So, a bit of a complexity we had to have. And naturally, Kubernetes requires resources, and keeping the resources itself to run. So you need to have this resources available and dedicated to Kubernetes control plane, to be able to control your application, that is all OpenStack and stuff. So a bit of investment is required. >> Can anybody just containerize OpenStack services and get these benefits? >> Well, yes, the idea is not new, there's a bunch of OpStream open, sorry, community projects doing pretty much the same thing. So we are not inventing a rocket here, let's be fair. However, it's only the way that Kubernetes cooks OpenStack, gives you the robustness and reliability that enterprise and like big customers actually need. And we're doing a great deal of a job, ultimating all the possible day to work polls and all these caveats complexities of the OpenStack management inside our products. Okay, at this point, I believe we shall wrap this discussion a bit up. So let me conclude for you. So OpenStack is an opensource infrastructure as a service platform, that still has its niche in 2020th, and it's going to have it's niche for at least five years. OpenStack is a powerful but very complex tool. And the complexities of OpenStack and OpenStack life cycle management, are successfully solved by Mirantis, through the capabilities of Kubernetes distribution, that provides us with the old necessary primitives to run OpenStack, just as another containerized application these days.

>>thank you everyone for joining. I'm here today to talk about English controllers. AP Gateways and service mention communities three very hot topics that are also frequently confusing. So I'm Richard Lee, founder CEO of Ambassador Labs, formerly known as Data Wire. We sponsor a number of popular open source projects that are part of the Cloud Native Computing Foundation, including telepresence and Ambassador, which is a kubernetes native AP gateway. And most of what I'm going to talk about today is related to our work around ambassador. Uh huh. So I want to start by talking about application architecture, er and workflow on kubernetes and how applications that are being built on kubernetes really differ from how they used to be built. So when you're building applications on kubernetes, the traditional architectures is the very famous monolith, and the monolith is a central piece of software. It's one giant thing that you build, deployed run, and the value of a monolith is it's really simple. And if you think about the monolithic development process, more importantly, is the architecture er is really reflecting that workflow. So with the monolith, you have a very centralized development process. You tend not to release too frequently because you have all these different development teams that are working on different features, and then you decide in advance when you're going to release that particular pieces offering. Everyone works towards that release train, and you have specialized teams. You have a development team which has all your developers. You have a Q A team. You have a release team, you have an operations team, so that's your typical development organization and workflow with a monolithic application. As organization shift to micro >>services, they adopt a very different development paradigm. It's a decentralized development paradigm where you have lots of different independent teams that are simultaneously working on different parts of the application, and those application components are really shipped as independent services. And so you really have a continuous release cycle because instead of synchronizing all your teams around one particular vehicle, you have so many different release vehicles that each team is able to ship a soon as they're ready. And so we call this full cycle development because that team is >>really responsible, not just for the coding of that micro service, but also the testing and the release and operations of that service. Um, >>so this is a huge change, particularly with workflow. And there's a lot of implications for this, s o. I have a diagram here that just try to visualize a little bit more the difference in organization >>with the monolith. You have everyone who works on this monolith with micro services. You have the yellow folks work on the Yellow Micro Service, and the purple folks work on the Purple Micro Service and maybe just one person work on the Orange Micro Service and so forth. >>So there's a lot more diversity around your teams and your micro services, and it lets you really adjust the granularity of your development to your specific business need. So how do users actually access your micro services? Well, with the monolith, it's pretty straightforward. You have one big thing. So you just tell the Internet while I have this one big thing on the Internet, make sure you send all your travel to the big thing. But when you have micro services and you have a bunch of different micro services, how do users actually access these micro services? So the solution is an AP gateway, so the gateway consolidates all access to your micro services, so requests come from the Internet. They go to your AP gateway. The AP Gateway looks at these requests, and based on the nature of these requests, it routes them to the appropriate micro service. And because the AP gateway is centralizing thing access to all the micro services, it also really helps you simplify authentication, observe ability, routing all these different crosscutting concerns. Because instead of implementing authentication in each >>of your micro services, which would be a maintenance nightmare and a security nightmare, you put all your authentication in your AP gateway. So if you look at this world of micro services, AP gateways are really important part of your infrastructure, which are really necessary and pre micro services. Pre kubernetes Unhappy Gateway Well valuable was much more optional. So that's one of the really big things around. Recognizing with the micro services architecture er, you >>really need to start thinking much more about maybe a gateway. The other consideration within a P A gateway is around your management workflow because, as I mentioned, each team is actually response for their own micro service, which also means each team needs to be able to independently manage the gateway. So Team A working on that micro service needs to be able to tell the AP at Gateway. This this is >>how I want you to write. Request to my micro service, and the Purple team needs to be able to say something different for how purple requests get right into the Purple Micro Service. So that's also really important consideration as you think about AP gateways and how it fits in your architecture. Because it's not just about your architecture. It's also about your workflow. So let me talk about a PR gateways on kubernetes. I'm going to start by talking about ingress. So ingress is the process of getting traffic from the Internet to services inside the cluster kubernetes. From an architectural perspective, it actually has a requirement that all the different pods in a kubernetes cluster needs to communicate with each other. And as a consequence, what Kubernetes does is it creates its own private network space for all these pods, and each pod gets its own I p address. So this makes things very, very simple for inter pod communication. Cooper in any is, on the other hand, does not say very much around how traffic should actually get into the cluster. So there's a lot of detail around how traffic actually, once it's in the cluster, how you routed around the cluster and it's very opinionated about how this works but getting traffic into the cluster. There's a lot of different options on there's multiple strategies pot i p. There's ingress. There's low bounce of resource is there's no port. >>I'm not gonna go into exhaustive detail on all these different options on. I'm going to just talk about the most common approach that most organizations take today. So the most common strategy for routing is coupling an external load balancer with an ingress controller. And so an external load balancer can be >>ah, Harvard load balancer. It could be a virtual machine. It could be a cloud load balancer. But the key requirement for an external load balancer >>is to be able to attack to stable I people he address so that you can actually map a domain name and DNS to that particular external load balancer and that external load balancer, usually but not always well, then route traffic and pass that traffic straight through to your ingress controller, and then your English controller takes that traffic and then routes it internally inside >>kubernetes to the various pods that are running your micro services. There are >>other approaches, but this is the most common approach. And the reason for this is that the alternative approaches really required each of your micro services to be exposed outside of the cluster, which causes a lot of challenges around management and deployment and maintenance that you generally want to avoid. So I've been talking about in English controller. What exactly is an English controller? So in English controller is an application that can process rules according to the kubernetes English specifications. Strangely, Kubernetes is not actually ship with a built in English controller. Um, I say strangely because you think, well, getting traffic into a cluster is probably a pretty common requirement. And it is. It turns out that this is complex enough that there's no one size fits all English controller. And so there is a set of ingress >>rules that are part of the kubernetes English specifications at specified how traffic gets route into the cluster >>and then you need a proxy that can actually route this traffic to these different pods. And so an increase controller really translates between the kubernetes configuration and the >>proxy configuration and common proxies for ingress. Controllers include H a proxy envoy Proxy or Engine X. So >>let me talk a little bit more about these common proxies. So all these proxies and there >>are many other proxies I'm just highlighting what I consider to be probably the most three most well established proxies. Uh, h a proxy, uh, Engine X and envoy proxies. So H a proxy is managed by a plastic technology start in 2000 and one, um, the H a proxy organization actually creates an ingress controller. And before they kept created ingress controller, there was an open source project called Voyager, which built in ingress Controller on >>H a proxy engine X managed by engine. Xing, subsequently acquired by F five Also open source started a little bit later. The proxy in 2004. And there's the engine Xing breast, which is a community project. Um, that's the most popular a zwelling the engine Next Inc Kubernetes English project which is maintained by the company. This is a common source of confusion because sometimes people will think that they're using the ingress engine X ingress controller, and it's not clear if they're using this commercially supported version or the open source version, and they actually, although they have very similar names, uh, they actually have different functionality. Finally. Envoy Proxy, the newest entrant to the proxy market originally developed by engineers that lift the ride sharing company. They subsequently donated it to the cloud. Native Computing Foundation Envoy has become probably the most popular cloud native proxy. It's used by Ambassador uh, the A P a. Gateway. It's using the SDO service mash. It's using VM Ware Contour. It's been used by Amazon and at mesh. It's probably the most common proxy in the cloud native world. So, as I mentioned, there's a lot of different options for ingress. Controller is the most common. Is the engine X ingress controller, not the one maintained by Engine X Inc but the one that's part of the Cooper Nannies project? Um, ambassador is the most popular envoy based option. Another common option is the SDO Gateway, which is directly integrated with the SDO mesh, and that's >>actually part of Dr Enterprise. So with all these choices around English controller. How do you actually decide? Well, the reality is the ingress specifications very limited. >>And the reason for this is that getting traffic into the cluster there's a lot of nuance into how you want to do that. And it turns out it's very challenging to create a generic one size fits all specifications because of the vast diversity of implementations and choices that are available to end users. And so you don't see English specifying anything around resilience. So if >>you want to specify a time out or rate limiting, it's not possible in dresses really limited to support for http. So if you're using GSPC or Web sockets, you can't use the ingress specifications, um, different ways of routing >>authentication. The list goes on and on. And so what happens is that different English controllers extend the core ingress specifications to support these use cases in different ways. Yeah, so engine X ingress they actually use a combination of config maps and the English Resource is plus custom annotations that extend the ingress to really let you configure a lot of additional extensions. Um, that is exposing the engineers ingress with Ambassador. We actually use custom resource definitions different CRTs that extend kubernetes itself to configure ambassador. And one of the benefits of the CRD approach is that we can create a standard schema that's actually validated by kubernetes. So when you do a coup control apply of an ambassador CRD coop Control can immediately validate and tell >>you if you're actually applying a valid schema in format for your ambassador configuration on As I previously mentioned, ambassadors built on envoy proxy, >>it's the Gateway also uses C R D s they can to use a necks tension of the service match CRD s as opposed to dedicated Gateway C R D s on again sdo Gateway is built on envoy privacy. So I've been talking a lot about English controllers. But the title of my talk was really about AP gateways and English controllers and service smashed. So what's the difference between an English controller and an AP gateway? So to recap, an immigrant controller processes kubernetes English routing rules and a P I. G. Wave is a central point for managing all your traffic to community services. It typically has additional functionality such as authentication, observe, ability, a >>developer portal and so forth. So what you find Is that not all Ap gateways or English controllers? Because some MP gateways don't support kubernetes at all. S o eso you can't make the can't be ingress controllers and not all ingrates. Controllers support the functionality such as authentication, observe, ability, developer portal >>that you would typically associate with an AP gateway. So, generally speaking, um, AP gateways that run on kubernetes should be considered a super set oven ingress controller. But if the A p a gateway doesn't run on kubernetes, then it's an AP gateway and not an increase controller. Yeah, so what's the difference between a service Machin and AP Gateway? So an AP gateway is really >>focused on traffic into and out of a cluster, so the political term for this is North South traffic. A service mesh is focused on traffic between services in a cluster East West traffic. All service meshes need >>an AP gateway, so it's Theo includes a basic ingress or a P a gateway called the SDO gateway, because a service mention needs traffic from the Internet to be routed into the mesh >>before it can actually do anything Omelet. Proxy, as I mentioned, is the most common proxy for both mesh and gateways. Dr. Enterprise provides an envoy based solution out of the box. >>Uh, SDO Gateway. The reason Dr does this is because, as I mentioned, kubernetes doesn't come package with an ingress. Uh, it makes sense for Dr Enterprise to provide something that's easy to get going. No extra steps required because with Dr Enterprise, you can deploy it and get going. Get exposed on the Internet without any additional software. Dr. Enterprise can also be easily upgraded to ambassador because they're both built on envoy and interest. Consistent routing. Semantics. It also with Ambassador. You get >>greater security for for single sign on. There's a lot of security by default that's configured directly into Ambassador Better control over TLS. Things like that. Um And then finally, there's commercial support that's actually available for Ambassador. SDO is an open source project that has a has a very broad community but no commercial support options. So to recap, ingress controllers and AP gateways are critical pieces of your cloud native stack. So make sure that you choose something that works well for you. >>And I think a lot of times organizations don't think critically enough about the AP gateway until they're much further down the Cuban and a journey. Considerations around how to choose that a p a gateway include functionality such as How does it do with traffic management and >>observe ability? Doesn't support the protocols that you need also nonfunctional requirements such as Does it integrate with your workflow? Do you offer commercial support? Can you get commercial support for this on a P? A. Gateway is focused on north south traffic, so traffic into and out of your kubernetes cluster. A service match is focused on East West traffic, so traffic between different services inside the same cluster. Dr. Enterprise includes SDO Gateway out of the box easy to use but can also be extended with ambassador for enhanced functionality and security. So thank you for your time. Hope this was helpful in understanding the difference between a P gateways, English controllers and service meshes and how you should be thinking about that on your kubernetes deployment

>>from the Cube Studios in Palo Alto in Boston, connecting with thought leaders all around the world. This is a cube conversation. >>Hey, welcome back. You're ready, Jeffrey here with the Cuban Apollo Alto studios today, and we're excited. You know, we're slowly coming out of the, uh, out of the summer season. We're getting ready to jump back into the fall. Season, of course, is still covet. Everything is still digital. But you know, what we're seeing is a digital events allow a lot of things that you couldn't do in the physical space. Mainly get a lot more people to attend that don't have to get in airplanes and file over the country. So to preview this brand new inaugural event that's coming up in about a month, we have We have a new guest. He's Dave and Everen. He is the senior vice president of marketing. Former ran tous. Dave. Great to see you. >>Happy to be here today. Thank you. >>Yeah. So tell us about this inaugural event. You know, we did an event with Miranda's years ago. I had to look it up like 2014. 15. Open stack was hot and you guys sponsored a community event in the Bay Area because the open stack events used to move all over the country each and every year. But you guys said, and the top one here in the Bay Area. But now you're launching something brand new based on some new activity that you guys have been up to over the last several months. So let us give us give us the word. >>Yeah, absolutely. So we definitely have been organizing community events in a variety of open source communities over the years. And, you know, we saw really, really good success with with the Cube And are those events in opens tax Silicon Valley days? And, you know, with the way things have gone this year, we've really seen that virtual events could be very successful and provide a new, maybe slightly different form of engagement but still very high level of engagement for our guests and eso. We're excited to put this together and invite the entire cloud native industry to join us and learn about some of the things that Mantis has been working on in recent months. A zwelling as some of the interesting things that are going on in the Cloud native and kubernetes community >>Great. So it's the inaugural event is called Moran Sous launchpad 2020. The Wares and the Winds in September 16th. So we're about a month away and it's all online is their registration. Costars is free for the community. >>It's absolutely free. Eso everyone is welcome to attend You. Just visit Miranda's dot com and you'll see the info for registering for the event and we'd love it. We love to see you there. It's gonna be a fantastic event. We have multiple tracks catering to developers, operators, general industry. Um, you know, participants in the community and eso we'd be happy to see you on join us on and learn about some of the some of the things we're working on. >>That's awesome. So let's back up a step for people that have been paying as close attention as they might have. Right? So you guys purchase, um, assets from Docker at the end of last year, really taken over there, they're they're kind of enterprise solutions, and you've been doing some work with that. Now, what's interesting is we we cover docker con, um, A couple of months ago, a couple three months ago. Time time moves fast. They had a tremendously successful digital event. 70,000 registrants, people coming from all over the world. I think they're physical. Event used to be like four or 5000 people at the peak, maybe 6000 Really tremendous success. But a lot of that success was driven, really by the by the strength of the community. The docker community is so passionate. And what struck me about that event is this is not the first time these people get together. You know, this is not ah, once a year, kind of sharing of information and sharing ideas, but kind of the passion and and the friendships and the sharing of information is so, so good. You know, it's a super or, um, rich development community. You guys have really now taken advantage of that. But you're doing your Miranda's thing. You're bringing your own technology to it and really taking it to more of an enterprise solution. So I wonder if you can kind of walk people through the process of, you know, you have the acquisition late last year. You guys been hard at work. What are we gonna see on September 16. >>Sure, absolutely. And, you know, just thio Give credit Thio Docker for putting on an amazing event with Dr Khan this year. Uh, you know, you mentioned 70,000 registrants. That's an astounding number. And you know, it really is a testament thio. You know, the community that they've built over the years and continue to serve eso We're really, really happy for Docker as they kind of move into, you know, the next the next path in their journey and, you know, focus more on the developer oriented, um, solution and go to market. So, uh, they did a fantastic job with the event. And, you know, I think that they continue toe connect with their community throughout the year on That's part of what drives What drove so many attendees to the event assed faras our our history and progress with with Dr Enterprise eso. As you mentioned mid November last year, we did acquire Doctor Enterprise assets from Docker Inc and, um, right away we noticed tremendous synergy in our product road maps and even in the in the team's eso that came together really, really quickly and we started executing on a Siris of releases. Um that are starting Thio, you know, be introduced into the market. Um, you know, one was introduced in late May and that was the first major release of Dr Enterprise produced exclusively by more antis. And we're going to announce at the launch pad 2020 event. Our next major release of the Doctor Enterprise Technology, which will for the first time include kubernetes related in life cycle management related technology from Mirant is eso. It's a huge milestone for our company. Huge benefit Thio our customers on and the broader user community around Dr Enterprise. We're super excited. Thio provide a lot of a lot of compelling and detailed content around the new technology that will be announcing at the event. >>So I'm looking at the at the website with with the agenda and there's a little teaser here right in the middle of the spaceship Docker Enterprise Container Cloud. So, um, and I glanced into you got a great little layout, five tracks, keynote track D container track operations and I t developer track and keep track. But I did. I went ahead and clicked on the keynote track and I see the big reveal so I love the opening keynote at at 8 a.m. On the 76 on the September 16th is right. Um, I, Enel CEO who have had on many, many times, has the big reveal Docker Enterprise Container Cloud. So without stealing any thunder, uh, can you give us any any little inside inside baseball on on what people should expect or what they can get excited about for that big announcement? >>Sure, absolutely so I definitely don't want to steal any thunder from Adrian, our CEO. But you know, we did include a few Easter eggs, so to speak, in the website on Dr Enterprise. Container Cloud is absolutely the biggest story out of the bunch eso that's visible on the on the rocket ship as you noticed, and in the agenda it will be revealed during Adrian's keynote, and every every word in the product name is important, right? So Dr Enterprise, based on Dr Enterprise Platform Container Cloud and there's the new word in there really is Cloud eso. I think, um, people are going to be surprised at the groundbreaking territory that were forging with with this release along the lines of a cloud experience and what we are going to provide to not only I t operations and the Op Graders and Dev ops for cloud environment, but also for the developers and the experience that we could bring to developers As they become more dependent on kubernetes and get more hands on with kubernetes. We think that we're going thio provide ah lot of ways for them to be more empowered with kubernetes while at the same time lowering the bar, the bar or the barrier of entry for kubernetes. As many enterprises have have told us that you know kubernetes can be difficult for the broader developer community inside the organization Thio interact with right? So this is, uh, you know, a strategic underpinning of our our product strategy. And this is really the first step in a non going launch of technologies that we're going to make bigger netease easier for developing. >>I was gonna say the other Easter egg that's all over the agenda, as I'm just kind of looking through the agenda. It's kubernetes on 80 infrastructure multi cloud kubernetes Miranda's open stack on kubernetes. So Goober Netease plays a huge part and you know, we talk a lot about kubernetes at all the events that we cover. But as you said, kind of the new theme that we're hearing a little bit more Morris is the difficulty and actually managing it so looking, kind of beyond the actual technology to the operations and the execution in production. And it sounds like you guys might have a few things up your sleeve to help people be more successful in in and actually kubernetes in production. >>Yeah, absolutely. So, uh, kubernetes is the focus of most of the companies in our space. Obviously, we think that we have some ideas for how we can, you know, really begin thio enable enable it to fulfill its promise as the operating system for the cloud eso. If we think about the ecosystem that's formed around kubernetes, uh, you know, it's it's now really being held back on Lee by adoption user adoption. And so that's where our focus in our product strategy really lives is around. How can we accelerate the move to kubernetes and accelerate the move to cloud native applications on? But in order to provide that acceleration catalyst, you need to be able to address the needs of not only the operators and make their lives easier while still giving them the tools they need for things like policy enforcement and operational insights. At the same time, Foster, you know, a grassroots, um, upswell of developer adoption within their company on bond Really help the I t. Operations team serve their customers the developers more effectively. >>Well, Dave, it sounds like a great event. We we had a great time covering those open stack events with you guys. We've covered the doctor events for years and years and years. Eso super engaged community and and thanks for, you know, inviting us back Thio to cover this inaugural event as well. So it should be terrific. Everyone just go to Miranda's dot com. The big pop up Will will jump up. You just click on the button and you can see the full agenda on get ready for about a month from now. When when the big reveal, September 16th will happen. Well, Dave, thanks for sharing this quick update with us. And I'm sure we're talking a lot more between now in, uh, in the 16 because I know there's a cube track in there, so we look forward to interview in our are our guests is part of the part of the program. >>Absolutely. Eso welcome everyone. Join us at the event and, uh, you know, stay tuned for the big reveal. >>Everybody loves a big reveal. All right, well, thanks a lot, Dave. So he's Dave. I'm Jeff. You're watching the Cube. Thanks for watching. We'll see you next time.

(upbeat electronic music) >> Announcer: Live from Vancouver, Canada, it's The Cube, covering OpenStack Summit North America 2018. Brought to you by Red Hat, the OpenStack foundation, and its ecosystem partners. >> Welcome back to The Cube's coverage of OpenStack Summit 2018 here in beautiful Vancouver, British Columbia. I'm Stu Miniman, with my co-host John Troyer. Happy to welcome back to the program, it's been a couple of years, actually, Boris Renski, who is the co-founder and CMO of Merantis And also is on the keynote stage for the OpenDev part of this show here. Boris, great to see you, thanks for joining us. >> Good to see you guys, and great to be back. Thank you for having me back. >> Absolutely, so we're going to talk about OpenDev, we're going to talk about a few things, but let's start with Merantis, your company. I think back to some of my first experiences at the OpenStack show. First of all, Merantis always does great keynotes, I remember there was dancing on stage, there's fun T-shirts I actually coveted. I don't go after swag much, but it was like the Heisenburg 99.999%-- >> I remember that T-shirt, yeah. >> Pure T-shirt for the Breaking Bad fans out there, to date myself on this, but always bring some energy and excitement and Merantis was one of the companies really super glued to OpenStack, so bring us up to 2018. When I think of Merantis, what should I be thinking of and let's get into it from there. >> Yeah, so let me see. We are still super glued to OpenStack. We did go through some changes and some evolutions. I think given how long it's been since we've talked, the notable changes have been a change to our delivery approach and with it some of the changes to actually the underlying software stack, so the most common thing is that we've evolved Merantis OpenStack into what we now call Merantis Cloud Platform and the key difference is how we approach actually the life cycle management of the OpenStack itself. Before our tool for installing and basically updating OpenStack was Fuel which was very prescriptive and monolithic type of delivery method and what we realized is most of it, large customers that we have, they have a fairly heterogeneous reference architectures that you have to cater to and you have to be able to do that in such a way that it is cost effective, so we've rebuilt Fuel for to a new tool called DriveTrain which uses a continuous delivery pattern to manage and deliver updates to OpenStack and with that we've also tweaked out delivery model a little bit. Before we just followed traditional distro-model where we just throw out our software out there. You can download and play with it and call us and we'll support you. When it comes to complicated distributive systems like OpenStack, that are life-cycled following a continuous delivery pattern, most of the companies simply don't have the in-house talent and skills to just take it and start deriving value, so we've moved to what we refer to as a build, operate, transfer model where we actually come in and we set up the environment, we manage an environment to an SLA, give a customer four nines SLA on the up time of the OpenStack environment we're managing and after a period of a year, give the customer an opportunity to gradually take over the operations and by operations I mean, patches, updates, et cetera until after some time we just completely go away or we just take a role of a software support vendor, effectively. So that's on the core business side. Since we haven't talked in a while, so it's a little bit of a long update, sorry. >> Stu: Yeah, yeah, it's okay. >> The thing that we've been talking a lot about recently has been the new thing we launched in beta about a month and a half ago called Merantis application platform, so Merantis Cloud Platform is OpenStack, is our core business. Merantis Application Platform is a new thing that we have launched about month and a half ago that is based on Spinnaker and Spinnaker is this continuous delivery open source tool that's been built by Netflix, originally. >> Yeah, so before we get into the OpenDev and Spinnaker and all that stuff, want your viewpoint on the OpenStack piece, so really appreciate that update. There were years that we thought, oh, it's the battle for who's going to do distributions and as you said, it's not that easy and maybe we had poor expectations as an industry as to where we could take it and where it should be used, so how should people be thinking about OpenStack in general? Can you give us one or two of the key use cases you see in your customer base? >> Yeah, so, I think that what we realized is that when it comes to general purpose cloud, so to speak, there is not tremendous value, at least among the customers that we have the opportunity to interface with, to use OpenStack. You have something that's already in place and you don't touch it and that's usually VMware or you want something new general purpose, people go to public cloud, but there is an enormous opportunity for what we refer to as tuned stacks or clouds that are tuned to particular business use cases and this is where I think is an opportunity for OpenStack to excel and this is historically where we as Merantis been actually delivering value to our customers. So speaking of the use cases, our customer base is split, we split it into enterprise and telco. More than half of the customers, actually, are from the telco side. So telco clouds, there is a variety of use cases. Typically those use cases are function of the, and the overarching use case is NFE, virtually network function virtualization. The specificity and the reference architecture of the actual infrastructure environment is a function of the VNF that is running on that cloud and in some instances if you were to categorize this for telco space, you can think of it in terms of a big cloud for VNFs that don't need to be close to the edge and those that are stretching out to the smaller footprint all the way to the edge and those are vastly different reference architectures and you do different performance optimizations and tuning and this is something that you can only do with something like OpenStack. Now when it comes to the enterprise side, the actually emerging use case that we've been seeing quite a bit of is HPC, because, again, HPC is full of purpose-built equipment, you do networking differently, you do a lot of things differently and a lot of the times the general purpose public clouds don't work for it, so for HPC again, we have a set of reference architectures that are modeled within the Drivetrain that we can just deploy fairly easily out of the box that cater specifically to the HPC use case and the enterprise. >> Boris, do you think HPC then either includes now or evolves into ML and AI as well, again, bespoke hardware, very specific use case? >> Yes, eventually. I think that there is an opportunity there for some of the reference architectures and deployment topologies currently used for HPC to evolve towards some of the AI use cases. Again, I think that, when it comes to enterprise and AI, it's a bit early, so yeah. >> Boris, the tagline of the company is, The Managed Open Cloud Company, and you talked about managing, being a managed cloud. That's been a fascinating development over the last few years. We're seeing it at the OpenStack level and for instance at the kubernetes level as well. Can you talk a little bit about that approach and who are the customers that need that entry ramp or accelerator for these private cloud installations? >> Yeah, yeah, yeah. I think that... There are two types of ways to implement infrastructure, implement the cloud. There is those that are trying to, they are looking at public cloud and they are saying, okay, this is like, I see what Amazon's doing, what Google's doing is great. I want the same thing and I want it in-house, for security reasons, for whatever, compliance reasons, doesn't matter. So all of these guys that fall into this category, I think for them to become successful with the cloud on-prem, should follow the managed approach. Again, I'm a little bit biased on this in that I'm selling this-- >> That was always the hit against running your own private cloud is you didn't have, one did not have the expertise in-house-- >> Boris: Yeah, that's exactly correct. >> That's what we need. >> First of all, the whole evolution between Fuel to Drivetrain and using the CD pattern to life-cycling the infrastructure stack is something that there isn't talent out there, there isn't DNA out there and enterprises simply are not able to just go ahead and start doing it and the whole model that, when you go to Amazon, you just have this cloud that is continuously updated for you, you don't have to worry about anything, so this model implies that you focus on delivering the end service rather than delivering the software. When you go to Amazon, you don't get software, you don't get to pick and choose. You just get certain reference architecture that is delivered for you. The guys that want to replicate the Amazon on-premise effectively, in my view, have to be gradually on ramped onto that. You can't just grab the software, do DIY, and expect you'll have an Amazon. There's a second category and the second category is basically like the software guys, the guys that, they are not looking for Amazon, they are looking for cheaper VMware, which is a different experience. I have my own team, I have my opps guys, VMware is great, but it's too expensive, I don't want be locked into it, give me something that is different. So there is value in that, but this is not the segment of the market that we are going after and I don't think that cheaper VMware is what most people refer to when they talk about cloud. So I hope that answers the question. >> Absolutely, so you brought up Spinnaker before. Want to get your thoughts on the things usually, typically on top of OpenStack, but kubernetes, Spinnaker, containers in general. What's Merantis' position on this. What are you hearing from your customers and would love to tease out some of the Spinnaker stuff a bit more. >> Yeah, yeah. Spinnaker thing is fairly new for us. We've been tracking the space and Spinnaker in particular, probably for a year, although have come out publicly just recently about it. The reason why the space was interesting to us was because I think that everybody who is undergoing digital transformation and embracing cloud as a byproduct of it, is really after being able to run the company like a startup, being able to release faster, being able to release more often and in fact, when we'd come to our customers our opening pitch even for OpenStack has always been, buy OpenStack, that'll help you build software faster. On the one hand, it's kind of like a cool pitch, on the other hand, I think everybody in the company, including myself, we're not entirely comfortable with making that leap. OpenStack means I can have an API for my VM's and maybe containers, release software faster. How do you connect the two, right? So, we decided to, in trying to solve this problem of helping companies release software faster, for once rid ourselves of our existing business and our infrastructure centric views of the world and unpack the problem and see what are the real big issues with releasing software faster today. What we realized is that one of the biggest bottlenecks is actually the continuous delivery part because when it comes to continuous delivery or even not to use fancy terms just to, deploying anything to production in the enterprise. It's a very complicated process that requires coordination between multiple teams like the application team, the SRE team, the SEC opps team, all of these teams are using different tools and the handoff process and the handshakes between are very loose, generally so a developer can build something very quickly, but for it to hit production environment, and for the enterprise to actually get feedback from the customers on this, it takes a very long time. So we started thinking about how do you actually shorten that cycle? What can you do? With that kind of frame of mind, we've come across Spinnaker and what we realized is that Spinnaker is actually, in a sense, to continuous delivery what OpenStack is to infrastructure, because the reason why OpenStack became popular is because it's effectively, on one hand, has all these plugins for diverse infrastructure, and on the other hand you can automate the orchestration process of bringing up a VM, instead of having your server people come in, put in the server, your operating people come in and install operating system, the network people come in, configure the network, et cetera, it's actually built a workflow and orchestrated the whole thing automatically without necessarily requiring companies to throw away their existing infrastructure investment. And if you go to the CD space, the situation's kind of similar. You have all these different teams, you have all these different tools, and you need to find a way to automate and orchestrate this process so that you minimize the number of human steps and this is exactly the problem space that Spinnaker's been tackling, so it's a portent of this plugability and having a single API for the entire CD chain and the best implementation would be the one like Netflix has is where the actual developers are able to just deploy to production directly. All of this orchestration between all the testing and all the stuff is done by Spinnaker behind the scenes, so we feel that actually tackling that problem and bringing this innovation into the enterprise is going to be something very dramatic at producing something at an order of magnitude performance gains for our customers. >> Of course, one of the things the foundation announced was the Zule CI/CD. Can you help us reconcile Zule and Spinnaker? >> Zule is from what I would characterize it, primarily deals with VCI side of the spectrum and I mentioned this in my talk, so one of the things we learned as a company is if you unpack CI/CD, which most people, at least in the infrastructure space look at it like it's one thing, like oh CI/CD thing, it's like one thing, basically. In reality, it's not one thing, it's completely separate things, so CI primarily has to do with actually building the code into something that can be deployed, into some deployable artifact and CD takes on from there. So Zule deals primarily with the CI part and it deals with it in a particular way for a set of specific use cases, so Zule emerged as the CI infrastructure for OpenStack Project itself and OpenStack is a very peculiar project in that, there's thousands of developers with different viewpoints on the world that are highly distributed, building many different components that are loosely coupled that all need to come together somehow. So you need to have distributed CI systems that talk to each other and you can merge all of this code and test it all together, so that use case is very relevant for large open source projects and it's probably relevant for enterprises who want to adopt similar type of practices for software development internally, so if you want to some extent de-silo many distributed Dev teams that you have internally as an enterprise and overlay standard process for the CI piece of it for everybody, I think Zule is a good solution and Spinnaker then comes after that, as an additive that does the deployment part. >> John: Yep, that makes sense. >> Alright, for us unfortunately we're running low on time, not going to have much time to dig in to the OpenDev piece. Last question I actually wanted to ask you is what do you say to the naysayers out there. People that aren't here sometimes tend to throw stones at OpenStack failed, OpenStack is dead, all the VCs pulled out years ago. Merantis has been through it and you've got customers. We've had a good experience this week, but it's a different OpenStack than it was a few years ago, so just if you could give us the final word on that. >> Yeah, so, good question. I think that... Basically, OpenStack was at this insane hype back in the day and it's natural to expect that the higher the hype, the bigger going to be the drop, but I think that all technologies ultimately, they can not sustain the hype. You have to level out at a certain point that is equal to the true customer value that you are delivering. So I think that the naysaying is a function of very high hype that has now leveled to the... What it should be, really, in terms of the value being delivered by OpenStack. And there's this pool, it generated this big pool of the naysayers that are walking around and saying that it is dead and the reason why there's the pool is because indeed there is a lot of investment, there is enormous amount of startups that kind of like, ah, we are the cool guys, we are going to change the world, we are going to kill Amazon, whatever, that now are completely gone and now of course they are naysayers and saying that the whole thing's dead, but on the flip side of that, if you just walk around the summit, you can see that there's many more users, there's many more customers that are actually talking about real use cases and then the companies that did stay and stick around, like ourselves, like Red Hat, like Canonical and SUSE, actually, are seeing continued growth and increased usage, so just a nice closing comment is our biggest customer for OpenStack is AT&T. We've been with them for five years now and they've been very excited about it and then, no it's all going to be dead, it's going to be containers now, and nuh nuh nuh, but despite all of that, the usage is continuing to grow and there is 10,000 nodes plus now running physical servers with OpenStack and it continues to work and it just, workloads are moving to it and AT&T is not the only one. There is plenty more that are following this trend, so it's a very long answer to your question, but I remain optimistic. For us it's still very much core of our business and we're continuing to see growth and usage and we are sticking around and sticking to OpenStack. >> Alright, well Boris Renski, it's, as you know, one of our earliest taglines was helping to extract the signal from the noise. We appreciate you helping us to understand the reality outside the hype. So for John Troyer, I'm Stu Miniman, more coverage here from the OpenStack Summit 2018 in Vancouver. Thank you for watching The Cube. (upbeat electronic music) (soft piano music)

(upbeat music) >> Hello, brilliant humans and welcome back to theCUBE. We're live from Detroit, Michigan. My name is Savannah Peterson. Joined here with John Furrier, John, so exciting, day three. >> Day three, cranking along, doing great, final day of KubeCon, it wraps up. This next segment's going to be great. It's about WebAssembly, the hottest trend here, at KubeCon that nobody knows about cause they just got some funding and it's got some great traction. Multiple players in here. People are really interested in this and they're really discovering it. They're digging into it. So, we're going to hear from one of the founders of the company that's involved. So, it'll be great. >> Yeah, I think we're right at the tip of the iceberg really. We started off the show with Scott from Docker talking about this, but we have a thought leader in this space. Please welcome Matt Butcher the CEO and co-founder of Fermyon Thank you for being here. Welcome. >> Yeah, thanks so much for having me. Favorite thing to talk about is WebAssembly after that is coffee but WebAssembly first. >> Hey, it's the morning. We can talk about both those on the show. (all chuckles) >> It might get confusing, but I'm willing to try. >> If you can use coffee as a metaphor to teach everyone about WebAssembly throughout the rest of the show. >> All right. That would be awesome. >> All right I'll keep that in mind. >> So when we were talking before we got on here I thought it was really fun because I think the hype is just starting in the WebAssembly space. Very excited about it. Where do you think we're at, set the stage? >> Honestly, we were really excited to come here and see that kind of first wave of hype. We came here expecting to have to answer the question you know, what is WebAssembly and why is anybody looking at it in the cloud space, and instead people have been coming up to us and saying, you know this WebAssembly thing, we're hearing about it. What are the problems it's solving? >> Savannah: Yeah. >> We're really excited to hear about it. So, people literally have been stopping us in restaurants and walking down the street, hey, "You're at KubeCon, you're the WebAssembly people. Tell us more about what's going on." >> You're like awesome celeb. I love this. >> Yeah, and I, >> This is great >> You know the, the description I used was I expected to come here shouting into the void. Hey, you know anybody, somebody, let me tell you about WebAssembly. Instead it's been people coming to us and saying "We've heard about it. Get us excited about it," and I think that's a great place to be. >> You know, one of the things that's exciting too is that this kind of big trend with this whole extraction layer conversation, multicloud, it reminds me of the old app server days where, you know there was a separation between the back end and front end, and then we're kind of seeing that now with this WebAssembly Wasm trend where the developers just want to have the apps run everywhere and the coding to kind of fall in, take a minute to explain what this is, why it's important, why are people jazzed about there's other companies like Cosmonic is in there. There's a lot of open source movement behind it. You guys are out there, >> Savannah: Docker. >> 20 million in fresh funding. Why is this important? What is it and why is it relevant right now? Why are people talking about it? >> I mean, we can't... There is no penasia in the tech world much for the good of all of us, right? To keep us employed. But WebAssembly seems to be that technology that just sort of arose at the right time to solve a number of problems that were really feeling intractable not very long ago. You know, at the core of what is WebAssembly? Well it's a binary format, right? But there's, you know, built on the same, strain of development that Java was built on in the 90's and then the .net run time. But with a couple of little fundamental changes that are what have made it compelling today. So when we think about the cloud world, we think about, okay well security's a big deal to us. Virtual machines are a way for us to run other people's untrusted operating systems on our hardware. Containers come along, they're a... The virtual machine is really the heavyweight class. This is the big thing. The workhorse of the cloud. Then along come Containers, they're a little slimmer. They're kind of the middleweight class. They provide us this great way to sort of package up just the application, not the entire operating system just the application and the bits we care about and then be able to execute those in a trusted environment. Well you know, serverless was the buzzword a few years ago. But one thing that serverless really identified for us is that we didn't actually have the kind of cloud side architecture that was the compute layer that was going to be able to fulfill the promise of serverless. >> Yeah. >> And you know, at that time I was at Microsoft we got to see behind the curtain and see how Azure operates and see the frustration with going, okay how do we get this faster? How do we get this startup time down from seconds to hundreds of milliseconds, WebAssembly comes along and we're able to execute these things in sub one millisecond, which means there is almost no cost to starting up one of these. >> Sub one millisecond. I just want to let everyone rest on that for a second. We've talked a lot about velocity and scale on the show. I mean everyone here is trying to do things faster >> Yep >> Obviously, but that is a real linchpin that makes a very big difference when we're talking about deploying things. Yeah. >> Yeah, and I mean when you think about the ecological and the cost impact of what we're building with the cloud. When we leave a bunch of things running in idle we're consuming electricity if nothing else. The electricity bill keeps going up and we're paying for it via cloud service charges. If you can start something in sub one millisecond then there's no reason you have to leave it running when nobody's using it. >> Savannah: Doesn't need to be in the background. >> That's right. >> So the lightweight is awesome. So, this new class comes up. So, like Java was a great metaphor there. This is kind of like that for the modern era of apps. >> Yeah. >> Where is this going to apply most, do you think? Where's it going to impact most? >> Well, you know, I think there are really four big categories. I think there's the kind of thing I was just talking about I think serverless and edge computing and kind of the server class of problem space. I think IOT is going to benefit, Amazon, Disney Plus, >> Savannah: Yes, edge. >> And PBS, sorry BBC, they all use WebAssembly for the players because they need to run the same player on thousands of different devices. >> I didn't even think about that use case. What a good example. >> It's a brilliant way to apply it. IOT is a hard space period and to be able to have that kind of layer of abstraction. So, that's another good use case >> Savannah: Yeah. >> And then I think this kind of plugin model is another one. You see it was Envoy proxy using this as a way to extend the core features. And I think that one's going to be very, very promising as well. I'm forgetting one, but you know. (all chuckles) I think you end up with these kind of discreet compartments where you can easily fit WebAssembly in here and it's solving a problem that we didn't have the technology that was really adequately solving it before. >> No, I love that. One of the things I thought was interesting we were all at dinner, we were together on Tuesday. I was chatting with Paris who runs Deliveroo at Apple and I can't say I've heard this about too many tools but when we were talking about WebAssembly she said "This is good for everybody" And, it's really nice when technologies come along that will raise the water level across the board. And I love that you're leading this. Speaking of you just announced a huge series aid, 20 million dollars just a few days ago. What does that mean for you and the team? >> I mean there's a little bit of economic uncertainty and it's always nice, >> Savannah: Just a little bit. >> Little bit. >> Savannah: It's come up on the show a little bit this week >> Just smidge. and it's nice to know that we're at a critical time developing this kind of infrastructure layer developing this kind of developer experience where they can go from, you know, blinking cursor to deployed application in two minutes or less. It would be a tragedy if that got forestalled merely because you can't achieve the velocity you need to carry it out. So, what's very exciting about being able to raise around like that at this critical time is that gives us the ability to grow strategically, be able to continue releasing products, building a community around WebAssembly as a whole and of course around our products at Fermyon is a little smaller circle in the bigger circle, and that's why we are so excited about having closed around, that's the perfect one to extend a runway like that. >> Well I'm super excited by this because one I love the concept. I think it's very relevant, like how you progress heavyweight, middleweight, maybe this is lightweight class. >> I know, I'm here for the analogy. No, it's great, its great. >> Maybe it's a lightweight class. >> And we're slimming, which not many of us can say in these times so that's awesome. >> Maybe it's more like the tractor trailer, the van, now you got the sports car. >> Matt: Yeah, I can go.. >> Now you're getting Detroit on us. >> I was trying for a coffee, when I just couldn't figure it out. (all chuckles) >> So, you got 20 million. I noticed the investors amplify very good technical VC and early stage firm. >> Amazing, yeah. >> Insight, they do early stage, big early stage like this. Also they're on the board of Docker. Docker was intent to put a tool out there. There's other competition out there. Cosmonic is out there. They're funded. So you got VC funded companies like yourselves and Cosmonic and others. What's that mean? Different tool chains, is it going to create fragmentation? Is there a common mission? How do you look at the competition as you get into the market >> When you see an ecosystem form. So, here we are at KubeCon, the cloud native ecosystem at this point I like to think of them as like concentric rings. You have the kind of core and then networking and storage and you build these rings out and the farther out you get then the easier it is to begin talking about competition and differentiation. But, when you're looking at that core piece everybody's got to be in there together working on the same stuff, because we want interoperability, we want standards based solutions. We want common ways of building things. More than anything, we want the developers and operators and users who come into the ecosystem to be able to like instantly feel like, okay I don't have to learn. Like you said, you know, 50 different tools for 50 different companies. "I see how this works", and they're doing this and they're doing this. >> Are you guys all contributing into the same open source? >> Yep, yeah, so... >> All the funding happens. >> Both CNCF and the ByteCode Alliance are organizations that are really kind of pushing forward that core technology. You know, you mentioned Cosmonic, Microsoft, SOSA, Red Hat, VMware, they're all in here too. All contributing and again, with all of us knowing this is that nascent stage where we got to execute it. >> How? >> Do it together. >> How are you guys differentiating? Because you know, open source is a great thing. Rising Tide floats all boats. This is a hot area. Is there a differentiation discussion or is it more let's see how it goes, kind of thing? >> Well for us, we came into it knowing very specifically what the problem was we wanted to solve. We wanted this serverless architecture that executed in sub one millisecond to solve, to really create a new wave of microservices. >> KubeCon loves performance. They want to run their stuff on the fastest platform possible. >> Yeah, and it shouldn't be a roadblock, you know, yeah. >> And you look at someone like SingleStore who's a database company and they're in it because they want to be able to run web assemblies close to the data. Instead of doing a sequel select and pulling it way out here and munging it and then pushing it back in. They move the code in there and it's executing in there. So everybody's kind of finding a neat little niche. You know, Cosmonic has really gone more for an enterprise play where they're able to provide a lot of high level security guarantees. Whereas we've been more interested in saying, "Hey, this your first foray into WebAssembly and you're interested in serverless we'll get you going in like a couple of minutes". >> I want to ask you because we had Scott Johnston on earlier opening keynote so we kind of chatted one-on-one and I went off form cause I really wanted to talk to him because Docker is one of the most important companies since their pivot, when they did their little reset after the first Docker kind of then they sold the enterprise off to Mirantis they've been doing really, really well. What's your relationship to Docker? He was very bullish with you guys. Insights, joint investor. Is there a relationship? You guys talk, what's going on there? >> I mean, I'm going to have to admit a little bit of hero worship on my part. I think Scott is brilliant. I just do, and having come from the Kubernetes world the Fermyon team, we've always kind of kept an eye on Docker communicated with a lot of them. We've known Justin Cormack for years. Chris Cornett. (indistinct) I mean yeah, and so it has been a very natural >> Probably have been accused of every Docker Con and we've did the last three years on the virtual side with them. So, we know them really well. >> You've always got your finger on the pulse for them. >> Do you have a relationship besides a formal relationship or is it more of pass shoot score together in the industry? >> Yeah. No, I think it is kind of the multi-level one. You come in knowing people. You've worked together before and you like working with each other and then it sort of naturally extends onto saying, "Hey, what can we do together?" And also how do we start building this ecosystem around us with Docker? They've done an excellent job of articulating why WebAssembly is a complimentary technology with Containers. Which is something I believe very wholeheartedly. You need all three of the heavyweight, middleweight, lightweight. You can't do all the with just one, and to have someone like that sort of with a voice profoundly be able to express, look we're going to start integrating it to show you how it works this way and prevent this sort of like needless drama where people are going, oh Dockers dead, now everything's WebAssembly, and that's been a great.. >> This fight that's been going on. I mean, Docker, Kubernetes, WebAssembly, Containers. >> Yeah. >> We've seen on the show and we both know this hybrid is the future. We're all going to be using a variety of different tools to achieve our goals and I think that you are obviously one of them. I'm curious because just as we were going on you mentioned that you have a PhD in philosophy. (Matt chuckles) >> Matt: Yeah. >> Which is a wild card. You're actually our second PhD in philosophy working in a very technical role on the show this week, which is kind of cool. So, how does that translate into the culture at Fermyon? What's it like on the team? >> Well, you know, a philosophy degree if nothing else teaches you to think in systems and both human systems and formal systems. So that helps and when you approach the process of building a company, you need to be thinking both in terms of how are we organizing this? How are we organizing the product? How do we organize the team? We have really learned that culture is a major deal and culture philosophy, >> Savannah: Why I'm bringing it up. >> We like that, you know, we've been very forward. We have our chip values, curiosity, humility inclusivity and passion, and those are kind of the four things that we feel like that each of us every day should strive to be exhibiting these kinds of things. Curiosity, because you can't push the envelope if you don't ask the hard questions. Humility, because you know, it's easy to get cocky and talk about things as if you knew all the answers. We know we don't and that means we can learn from Docker and Microsoft >> Savannah: That's why you're curious. >> And the person who stops by the booth that we've never met before and says, "hey" and inclusivity, of course, building a community if you don't execute on that well you can't build a good community. The diversity of the community is what makes it stronger than a singular.. >> You have to come in and be cohesive with the community. >> Matt: Yeah. >> The app focus is a really, I think, relevant right now. The timing of this is right online. I think Scott had a good answer I thought on the relationship and how he sees it. I think it's going to be a nice extension to not a extension that way, but like. >> It probably will be as well. >> Almost a pun there John, almost a pun. >> There actually might be an extension, but evolution what we're going to get to which I think is going to be pure application server, like. >> Yep, yep. Like performance for new class of developer. Then now the question comes up and we've been watching developer productivity. That is a big theme and our belief is that if you take digital transformation to its conclusion IT and developers aren't a department serving the business they are the business. That means the developer workflows will have to be radically rebuilt to handle the velocity and new tech for just coding. I call it architectural list. >> I like that. I might steal that. >> It's a pun, but it's also brings up the provocative question. You shouldn't have to need an architecture to code. I mean, Java was great for that reason in many ways. So, if that happens if the developers are running the business that means more apps. The apps is the business. You got to have tool chains and productivity. You can't have fragmentation. Some people are saying WebAssembly might, fork tool chains, might challenge the developer productivity. what's your answer to that? How would you address that objection? >> I mean the threat of forking is always lurking in the corner in open source. In a way it's probably a positive threat because it keeps us honest it keeps us wanting to be inclusive again and keep people involved. Honestly though, I'm not particularly worried about it. I know that the W-3 as a standards body, of course, one of the most respected standards bodies on the planet. They do html, they do cascading style sheets. WebAssembly is in that camp and those of us in the core are really very interested in saying, you know, come on in, let's build something that's going to be where the core is solid and you know what you got and then you can go into the resurgence of the application server. I mean, I wholeheartedly agree with you on that, and we can only get there if we say, all right, here are the common paradigms that we're all going to agree to use, now let's go build stuff. >> And as we've been saying, developers are setting, I think are going to set the standards and they're going to vote with their code and their feet, if you will. >> Savannah: A hundred percent. >> They will decide if you're not aligning with what they want to do. okay. On how they want to self-serve and or work, you'll figure that out. >> Yep, yep. >> You'll get instant feedback. >> Yeah. >> Well, you know, again, I tell you a huge fan of Docker. One of the things that Docker understood at the very outset, is that they had an infrastructure tool and developers were the way to get adoption, and if you look at how fast they got adoption versus many, many other technologies that are profoundly impacted. >> Savannah: Wild. >> Yeah. >> Savannah: It's a cool story. >> It's because they got the developers to go, "This is amazing, hey infrastructure folks, here's an infrastructure tool that we like" and the infrastructure folks are used to code being tossed over the wall are going, "Are you for real?" I mean, and that was a brilliant way to do it and I think that what.. >> John: Yeah, yeah. >> We want to replay in the WebAssembly world is making it developer friendly and you know the kind of infrastructure that we can actually operate. >> Well congratulations to the entire community. We're huge fans of the concept. I kind of see where it's going with connect the dots. You guys getting a lot of buzz. I have to ask you, my final question is the hype is beyond all recognition at this point. People are super pumped and enthusiastic about it and people are looking at it maybe some challenging it, but that's all good things. How do you get to the next level where people are confident that this is actually going to go the next step? Hype to confidence. We've seen great hype. Envoy was hyped up big time before it came in, then it became great. That was one of my favorite examples. Hype is okay, but now you got to put some meat on the bone. The sizzle on the stake so to speak. So what's going to be the stake for you guys as you see this going forward? What's the need? >> Yeah, you know, I talk about our first guiding story was, you know, blinking cursor to deployed application in two minutes. That's what you need to win developers initially. So, what's the next story after that? It's got to be, Fermyon can run real world applications that solve real world problems. That's where hype often fails. If you can build something that's neat but nobody's quite sure what to do with it, to use it, maybe somebody will discover a good use. But, if you take that gambling asset, >> Savannah: It's that ending answer that makes the difference. >> Yeah, yeah. So we say, all right, what are developers trying to build with our platform and then relentlessly focus on making that easier and solving the real world problem that way. That's the crucial thing that's going to drive us out of that sort of early hype stage into a well adopted technology and I talk from Fermyon point of view but really that's for all of us in the WebAssembly. >> John: Absolutely. >> Very well stated Matt, just to wrap us up when we're interviewing you here on theCUBE next year, what do you hope to be able to say then that you can't say today? >> All this stuff about coffee we didn't cover today, but also.. (all chuckles) >> Savannah: Here for the coffee show. Only analogies, that's a great analogy. >> I want to walk here and say, you know last time we talked about being able to achieve density in servers that was, you know, 10 times Kubernetes. Next year I want to say no, we're actually thousands of times beyond Kubernetes that we're lowering people's electricity bill by making these servers more efficient and the developers love it. >> That your commitment to the environment is something I want to do an entirely different show on. We learned that 7-8% of all the world's powers actually used on data centers through the show this week which is jarring quite frankly. >> Yeah, yeah. Tragic would be a better way of saying that. >> Yeah, I'm holding back so that we don't go over time here quite frankly. But anyways, Matt Butcher thank you so much for being here with us. >> Thank you so much for having me it was pleasure.. >> You are worth the hype you are getting. I am grateful to have you as our WebAssembly thought leader. In addition to Scott today from Docker earlier in the show. John Furrier, thanks for being my co-host and thank all of you for tuning into theCUBE here, live from Detroit. I'm Savannah Peterson and we'll be back with more soon. (ambient music)

(upbeat music) >> Welcome back, everyone. Live coverage here at KubeCon + CloudNativeCon here in Detroit, Michigan. I'm John Furrier, your host of theCUBE for special one-on-one conversation with Scott Johnston, who's the CEO of Docker, CUBE alumni, been around the industry, multiple cycles of innovation, leading one of the most important companies in today's industry inflection point as Docker what they've done since they're, I would say restart from the old Docker to the new Docker, now modern, and the center of the conversation with containers driving the growth of Kubernetes. Scott, great to see you. Thanks for coming on theCUBE. >> John, thanks for the invite. Glad to be here. >> You guys have had great success this year with extensions. Docker as a business model's grown. Congratulations, you guys are monetizing well. Pushing up over 50 million. >> Thank you. >> I hear over pushing a hundred million maybe. What the year to the ground will tell me, but it's good sign. Plus you've got the community and nurturing of the ecosystem continuing to power away and open source is not stopping. It's thundering away growth. Younger generation coming in. >> That's right. >> Developer tool chain that you have has become consistent. Almost de facto standard. Others are coming in the market. A lot of competition emerging. You got a lot going on right now. What's going on? >> Well, I know it's fantastic time in our industry. Like all companies are becoming software companies. That means they need to build new applications. That means they need developers to be productive and to be safely productive. And we, and this wonderful CNCF ecosystem are right in the middle of that trend, so it's fantastic. >> So you have millions of developers using Docker. >> Tens of millions. >> Tens of millions of developed Docker and as the market's changing, I was commenting before we came on camera, and I'd love to get your reaction, comment on it. You guys represent the modernization of containers, open source. You haven't really changed how open source works, but you've kind of modernized it. You're starting to see developers at the front lines, more and more power going to developers. >> Scott: That's right. >> They want self-service. They vote with their code. >> That's right. >> They vote with their actions. >> Scott: That's right. >> And if you take digital transformation to its conclusion, it's not IT serves the business or it's a department, the company is IT. >> That's right. >> The company is the application, which means developers are running everything. >> Yes, yes. I mean, one of the jokes, not jokes in the valley is that Tesla is in a car company. Tesla is a computer company that happens to have wheels on the computer. And I think we can smile at that, but there's so many businesses, particularly during COVID, that realize that. What happened during COCID? If you're going to the movies, nope, you're now going to Netflix. If you're going to the gym, now you're doing Peloton. So this realization that like I have to have a digital game, not just on the side, but it has to be the forefront of my business and drive my business. That realization is now any industry, any company across the board. >> We've been reporting aggressively for past three years now. Even now we're calling some things supercloud. If companies, if they don't realize that IT is not a department, they will probably be out of business. >> That's a hundred percent. >> It's going to transform into full on invisible infrastructure. Infrastructure as code, whatever you want to call that going, configuration, operations, developers will set the pace. This has a lot to do with some of your success. You're at the beginning of it. This is just the beginning. What can you talk about that in your mind is contributing to the success of Docker? I know you're going to say team, everything, I get that, but like what specifically in the industry is driving Docker's success right now? >> Well, it did. We did have a fantastic team. We do have a fantastic team and that is one of the reasons, primary reasons our success. But what is also happening, John, is because there's a demand for applications, I'll just throw it out there. 750 million new applications are coming in the market in the next two years. That is more applications that have been developed in the entire 40 years history of IT. So just think about the productivity demands that are coming at developers. And then you also see the need to do so safely, meaning ship quickly, but ship safely. And yet 90 some percent of every application consists of open source components that are now on attack surface for criminals. And so typically our industry has had to say one or the other, okay, you can ship quickly but not safely, or you can ship safely, but it's not going to go fast. And one of the reasons I think Docker is where it is today is that we're able to offer both. We're able to unlock that you can ship quickly, safely using Docker, using the Docker toolchain, using integrations we have with all the wonderful partners here at CNCF that is unique. And that's a big reason why we're seeing the success we're seeing. >> And you're probably pleased with extensions this year. >> Yes. >> The performance of extensions that you launched at DockerCon '22. >> Yes. Well, extensions are part of that story and that developers have multiple tools. They want choice, developers like choice to be productive and Docker is part of that, but it's not the only solution. And so Docker extensions allow the monitoring providers and the observability and if you want a separate Kubernetes stack, like all of that flexibility, extensions allows. And again, offers the power and the innovation of this ecosystem to be used in a Docker development and context. >> Well, I want to get into some of the details of some of your products and how they're evolving. But first I want to get your thoughts on the trend line here that we reported at the opening segment. The hot story is WebAssembly, the Wasm, which really got a lot of traction or interest. People enthous about it. >> Interest, yeah. >> Lot of enthusiasm. Confidence we'll see how that evolves, but a lot of enthusiasm for sure. I've never seen something this hyped up since Envoy, in my opinion. So a lot of interest from developers. What is Wasm or WebAssembly is actually what it is, but Wasm is the codeword or nickname. What is Wasm? >> So in brief, WebAssembly is a new application type, full stop. And it's just enough of the components that you need and it's just a binary format that is very, very secure. And so it's lightweight, it's fast and secure. And so it opens up a lot of interesting use cases for developer, particularly on the edge. Another use case for Wasm is in the browser. Again, lightweight, fast, secure also. >> John: Sounds like an app server to me. >> And so we think it's a very, very interesting trend. And you ask, Okay, what's Docker's role in that? Well, Docker has been around eight years now, eight plus years, tens of millions developers using it. They've already made investments in skills, talent, automation, toolchains, pipelines. And Docker started with Linux containers as we know, then brought that same experience to Windows containers, then brought it to serverless functions. About 25% of Amazon Lambdas are OCI image containers. And so we were seeing that trend. We were also seeing the community actually without any prompting from us, start to fork and play with Docker and apply it to Wasm. And we're like, Huh, that's interesting. What if we helped get behind that trend, such that you changed just one line of a Docker file, now you're able to produce Wasm objects instead of Linux containers and just bring that same easy to use. >> So that's not a competition to Docker's? >> Not a competition at all. In fact, very complimentary. We showed off on Monday at the Wasm day, how in the same Docker compose application, multi-service application. One service is delivered via Linux container, Another service is delivered via Wasm. >> And Wasm is what? Multiple languages? 'Cause what is it? >> Yes. So the binary can be compiled from multiple languages. So RAS, JavaScript, on and on and on. At the end of the day, it's a smaller binary that provides a function, typically a single function that you can stand up and deploy on an edge. You can stand up and deploy on the server side or stand up and deploy on the browser. >> So from a container standpoint, from your customer standpoint, what a Linux container is is a similar thing to what a Wasm container is. >> They could implement the same function. That's right. Now a Linux container can have more capabilities that a function might not have, but that's. >> John: From a workflow standpoint. >> That's right. And that's more of a use case by use case standpoint. What we serve is we serve developers and we started out serving developers with Linux containers, then Windows containers, then Lambdas, now Wasm. Whatever other use case, what other application type comes along, we want to be there to serve developers. >> So one of the things I want to get your thoughts on, because this has come up in a couple CUBE interviews before, and we were talking before we came on camera, is developers want ease of use and simplicity. They don't want more steps to do things. They don't want things harder. >> That's right. So the classic innovation is reduce the time it takes to do something, reduce the steps, make it easier. That's a formula of success. >> Scott: That's right. >> When you start adding more toolchains into the mix, you get tool sprawl. So that's not really, that's antithesis to developer. So the argument is, okay, do I have to use a new tool chain for Wasm? Is that a fact or no? >> That's exactly right. That was what we were seeing and we thought, well, how can Docker help with this situation? And Docker can help by bringing the same existing toolchain that developers are already familiar with. The same automation, the same pipelines. And just by changing a line of Docker file, changing a single line of composed file, now they get the power of Wasm unlocked in the very same tools they were using before. >> So your position is, hey, don't adopt some toolchain for Wasm. You can just do it in line with Docker. >> No need to, no need to. We're providing it right there out of the box, ready for them. >> That's raise and extend, as they would say, build Microsoft strategy there. That's nice. Okay, so let's get back into like the secure trusted 'cause that was another theme at DockerCon. We covered that deeply. Software supply chain, I was commenting on my intro with Savannah and Lisa that at some point open source means so plentiful. You might not have to write code. You got to glue together. So as code proliferates, the question what's in there? >> That's right. This is what they call the software supply chain. You've been all over this. Where are we with this? Is it harder now? Is it easier? Was there progress? Take us through what's the state of the art. I think we're early on this one, John, in the industry because I think the realization of how much open source is inside a given app is just now hitting consciousness. And so the data we have is that for any given application, anywhere from 75 to 85% is actually not unique to the developer or the organization. It's open source components that they have put together. And it's really down to that last 15, 25%, which is their own unique code that they're adding on top of all this open source code. So right there, it's like, aha, that's a pretty interesting profile or distribution of value, which means those open source components, where are they finding them? How are they integrating them? How do they know those open source components are going to be supported and trusted and secured? And that's the challenge for us as an industry right now is to make it just obvious where to get the components, how safe they are, who's standing behind them, and how easy it is to assemble them into a working application. >> All right. So the question that I had specifically on security 'cause this had come up before. All good on the trusted and I think that message is evergreen. It's a north star. That's a north star for you. How are you making images more secure and how are you enabling organizations to identify security issues in containers? Can you share your strategy and thoughts on that particular point? >> Yes. So there's a range of things in the secure software supply chain and it starts with, are you starting with trusted open source components that you know have support, that you know are secured? So in Docker Hub today, we have 14 million applications, but a subset of that, we've worked with the upstream providers to basically designate as trusted open source content. So this is the Docker official images, Docker verified publisher images, Docker sponsored open source. And those different categories have levels of certification assurance that they must go through. Generate an SBOM, so you know what's inside that container. It has to be scanned by a scanning tool and those scanning results have to be made available. >> John: Are you guys scanning that? >> So we provide a scanner, they can use another scanner as long as they publish the results of that scan. And then the whole thing is signed. >> Are you publishing the results on your side too? >> Yeah, we published our results through an open database that's accessible to all. >> Free. >> Free, a hundred percent free. You come in and you can see every image on hub. >> So I'm a user, for free I can see security vulnerabilities that are out there that have been identified. >> By version, by layer, all the way through. And you can see tracking all the way back to the package that's upstream. So you know how to remediate and we provide recommendations on how to remediate that with the latest version. >> John: And you don't charge for that. >> We don't charge for that. We do not charge for that. And so that's the trusted upstream. >> So organization can look at the scan, they can look at the scan data and hopefully, what happens if they're not scanned? >> So we provide scanning tools both for the local environments for Docker Desktop, as well as for hub. So if you want to do your own scan, so for example, when you're that developer adding the 15, 25%, you got to scan your stuff as well. Not just leave it up to the already scanned components. And so we provide tools there. We also provide tools to track the packages that that developer might be including in their custom code, all the way back upstream to whatever MPM repo or what have you that they picked up. And then if there's a CVE 30 days later, we also track that as well. We say, Hey, that package was was safe 29 days ago, but today CVE just came out, better upgrade to the latest version and get that out there. So basically if you get down to it, it's like start with trusted components and then have observability not just on the moment. >> And scan all the time. >> Scan all the time and scanning gives you that observability and importantly not just at that moment, but through the lifecycle of the application, through lifecycle of the artifact. So end-to-end 24/7 observability of the state of your supply chain. That's what's key, John. >> That's the best practice. >> That's the key. That's the key. >> Awesome, I agree. That's great. Well, I'm glad we've dug into that's super important. Obviously organizations can get that scanning that's exceed the vulnerabilities, that can take action. That's going to be a big focus here for you, security. It's not going to stop, is it? >> It's never going to stop because criminals are incentive to keep attacking. And so it's the gift that keeps on giving, if you will. >> Okay, so let's get into some of the products. Docker Desktop seems to be doing well. Docker Hub has always been a staple of it. And how's that going? >> Yeah, Docker Hub has 18 million monthly actives hitting it and that's growing by double digits year over year. And what they're finding, going back to our previous thread, John, is that they're coming there for the trusted content. In fact, those three categories that I referenced earlier are about 2000 applications of the 14 million. And yet they represent 56% of the 15 billion downloads a month from Docker Hub. Meaning developers are identifying that, hey, I want trusted source. We raise those in the search results and we have a visual cue. And so that's the big driver of hub's growth right now, is I want trusted content, where do I go? I go to Hub, download that trusted open source and I'm ready to go. >> I have been seeing some chatter on the internet and some people's sharing that they're looking at other places, besides hub, to do some things. What's your message to folks out there around Docker Hub? Why Docker Hub and desktop together? 'Cause you mentioned the toolchain before, but those two areas, I know they've been around for a while, you continue to work on them. What's the message to the folks out there about stay with the hub? >> Sure. I mean the beauty of our ecosystem is that it's interoperable. The standards for build, share and run, we're all using them here at CNCF. So yes, there's other registries. What we would say is we have the 18 million monthly active that are pulling, we have the worldwide distribution that is 24/7 high, five nines reliability, and frankly, we're there to provide choice. And so yes, we have have our trusted content, but for example, the Tanzu apps, they also distribute through us. Red Hat applications also distribute through us because we have the reach and the distribution and offer developers choice of Dockers content, choice of Red Hats content, choice of VMware's, choice of Bitnami, so on so forth. So come to the hub for the distribution to reach and that the requirements we have for security that we put in place for our publishers, give users and publishers an extra degree of assurance. >> So the Docker Hub is an important part of the system? >> Scott: Yes, very much so. >> And desktop, what's new with desktop? >> So desktop of course is the other end of the spectrum. So if trusted components start up on Docker Hub, developers are pulling them down to the desktop to start assembling their application. And so the desktop gives that developer all the tools he or she needs to build that modern application. So you can have your build tooling, your debug tooling, your IDE sitting alongside there, your Docker run, your Docker compose up. And so the loop that we see happening is the dev will have a database they download from hub, a front-end, they'll add their code to it and they'll just rapidly iterate. They'll make a change, stand it up, do a unit test, and when they're satisfied do a git commit, off it goes into production. >> And your goal obviously is to have developers stay with Docker for their toolchain, their experience, make it their home base. >> And their trusted content. That's right. And the trusted content and the extensions are part of that. 'Cause the extensions provide complimentary tooling for that local experience. >> You guys have done an amazing job. I want to give you personal props. I've been following Docker from the beginning when they had the pivot, they sold the enterprise to Mirantis, went back to the roots, modernized, riding the wave. You guys are having a good time. I got to ask the question 'cause people always want to know 'cause open source is about transparency. How you guys making your money? Business is good. How's that work and what was the lucky, what was the not lucky strike, but what was the aha moment? What was the trigger that just made you just kick in this new monetization growth wave? >> So the monetization is per seat, per developer seat. And that changed in November 2019. We were pricing on the server side before, and as you said, we sold that off. And what changed is some of the trends we were talking about that the realization by all organizations that they had to become software companies. And Docker provided the productivity in an engineered desktop product and the trusted content, it provided the productivity safely to developers. And frankly then we priced it at a rate that is very reasonable from an economic standpoint. If you look at developer productivity, developers are paid anywhere from 150 to 300 to 400, 500,000 even higher. >> But when you're paying your developers that much, then productivity is a premium. And what we were asking for from companies from a licensing standpoint was really a modest relative to the making those developers product. >> It's not like Oracle. I mean talk about extracting the value out of the customer. But your point is your positioning is always stay quarter of the open source, but for companies that adopt the structural change to be developer first, a software company, there's a premium to pay because you devalue there. >> And need the tooling to roll it out at scales. So the companies are paying us. They're rolling it out to tens of thousand developers, John. So they need management, they need visibility, they need guardrails that are all around the desktop. So, but just to put a stat on it, so to your point about open source and the freemium wheel working, of our 13 million Docker accounts, 12 are free, about a million are paid for accounts. And that's by design because the open source. >> And you're not gouging developers per se, it's just, not gouging anyone, but you're not taking money out of their hands. It's the company. >> If the company is paying for their productivity so that they can build safely. >> More goodness more for the developer. >> That's right. That's right. >> Gouging would be more like the Oracle strategy. Don't comment. You don't need to comment. I keep saying that, but it's not like you're taxing. It's not a heavy. >> No, $5 a month, $9 a month, $24 a month depending on level. >> But I think the big aha to me and in my opinion is that you nailed the structural change culturally for a company. If they adopt the software ecosystem approach for transforming their business, they got to pay for it. So like a workflow, it's a developer. >> It's another tool. I mean, do they pay for their spreadsheet software? Do they pay for their back office ERP software? They do >> That's my point. >> to make those people popular or sorry, make those people successful, those employees successful. This is a developer tool to make developer successful. >> It's a great, great business model. Congratulations. What's next for you guys? What are you looking for? You just had your community events, you got DockerCon coming up next year. What's on the horizon for you? Put a plugin for the company. What are you looking for? Hiring? >> Yeah, so we're growing like gangbusters. We grew from 60 with the reset. We're now above 300 and we're continuing to grow despite this economic climate. Like our customers are very much investing in software capabilities. So that means they're investing in Docker. So we're looking for roles across the board, software engineers, product managers, designers, marketing, sales, customer success. So if you're interested, please reach out. The next year is going to be really interesting because we're bringing to market products that are doubling down on these areas, doubling down a developer productivity, doubling down on safety to make it even more just automatic that developers just build so they don't have to think about it. They don't need a new tool just to be safer. We hinted a bit about automating SBOM creation. You can see more of that pull through. And in particular, developers want to make the right decision. Everyone comes to work wanting to make the right decision. But what they often lack is context. They often lack like, well, is this bit of code safe or not? Or is this package that I just downloaded over here safe or not? And so you're going to see us roll out additional capabilities that give them very explicit contextual guidance of like, should you use this or not? Or here's a better version over here, a safer version over there. So stay tuned for some exciting stuff. >> It's going to be a massive developer growth wave coming even bigger we've ever seen. Final questions just while I got you here. Where do you see WebAssembly, Wasm going? If you had to throw a dart at the board out a couple years, what does it turn into? >> Yeah, so I think it's super exciting. Super exciting, John. And there's three use cases today. There's browser, there's edge, and there's service side in the data center of the cloud. We see the edge taking off in the next couple years. It's just such a straight line through from what they're doing today and the value that standing up a single service on the edge go. The service side needs some work on the Wasm runtime. The Wasm runtime is not multi-threaded today. And so there's some deep, deep technical work that's going on. The community's doing a fantastic job, but that'll take a while to play through. Browsers also making good progress. There's a component model that Wasm's working on that'll really ignite the industry. That is going to take another couple years as well. So I'd say let's start with the edge use case. Let's get everyone excited about that value proposition. And these other two use cases will come along. >> It'll all work itself out in the wash as open source always does. Scott Johnston, the Chief Executive Officer at Docker. Took over at the reset, kicking butt and taking names. Congratulations. You guys are doing great. Continue to power the developer movement. Thanks for coming on. >> John, thanks so much. Pleasure to be here. >> We're bringing you all the action here. Extracting the signal from the noise. I'm John Furrier, day one of three days of wall-to-wall live coverages. We'll be back for our next guest after this short break. (gentle music)

>> From theCUBE studios in Palo Alto, in Boston, bringing you data driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vollante. >> The rise of Kubernetes came about through a combination of forces that were, in hindsight, quite a long shot. Amazon's dominance created momentum for Cloud native application development, and the need for newer and simpler experiences, beyond just easily spinning up computer as a service. This wave crashed into innovations from a startup named Docker, and a reluctant competitor in Google, that needed a way to change the game on Amazon and the Cloud. Now, add in the effort of Red Hat, which needed a new path beyond Enterprise Linux, and oh, by the way, it was just about to commit to a path of a Kubernetes alternative for OpenShift and figure out a governance structure to hurt all the cats and the ecosystem and you get the remarkable ascendancy of Kubernetes. Hello and welcome to this week's Wikibon CUBE Insights powered by ETR. In this breaking analysis, we tapped the back stories of a new documentary that explains the improbable events that led to the creation of Kubernetes. We'll share some new survey data from ETR and commentary from the many early the innovators who came on theCUBE during the exciting period since the founding of Docker in 2013, which marked a new era in computing, because we're talking about Kubernetes and developers today, the hoodie is on. And there's a new two part documentary that I just referenced, it's out and it was produced by Honeypot on Kubernetes, part one and part two, tells a story of how Kubernetes came to prominence and many of the players that made it happen. Now, a lot of these players, including Tim Hawkin Kelsey Hightower, Craig McLuckie, Joe Beda, Brian Grant Solomon Hykes, Jerry Chen and others came on theCUBE during formative years of containers going mainstream and the rise of Kubernetes. John Furrier and Stu Miniman were at the many shows we covered back then and they unpacked what was happening at the time. We'll share the commentary from the guests that they interviewed and try to add some context. Now let's start with the concept of developer defined structure, DDI. Jerry Chen was at VMware and he could see the trends that were evolving. He left VMware to become a venture capitalist at Greylock. Docker was his first investment. And he saw the future this way. >> What happens is when you define infrastructure software you can program it. You make it portable. And that the beauty of this cloud wave what I call DDI's. Now, to your point is every piece of infrastructure from storage, networking, to compute has an API, right? And, and AWS there was an early trend where S3, EBS, EC2 had API. >> As building blocks too. >> As building blocks, exactly. >> Not monolithic. >> Monolithic building blocks every little building bone block has it own API and just like Docker really is the API for this unit of the cloud enables developers to define how they want to build their applications, how to network them know as Wills talked about, and how you want to secure them and how you want to store them. And so the beauty of this generation is now developers are determining how apps are built, not just at the, you know, end user, you know, iPhone app layer the data layer, the storage layer, the networking layer. So every single level is being disrupted by this concept of a DDI and where, how you build use and actually purchase IT has changed. And you're seeing the incumbent vendors like Oracle, VMware Microsoft try to react but you're seeing a whole new generation startup. >> Now what Jerry was explaining is that this new abstraction layer that was being built here's some ETR data that quantifies that and shows where we are today. The chart shows net score or spending momentum on the vertical axis and market share which represents the pervasiveness in the survey set. So as Jerry and the innovators who created Docker saw the cloud was becoming prominent and you can see it still has spending velocity that's elevated above that 40% red line which is kind of a magic mark of momentum. And of course, it's very prominent on the X axis as well. And you see the low level infrastructure virtualization and that even floats above servers and storage and networking right. Back in 2013 the conversation with VMware. And by the way, I remember having this conversation deeply at the time with Chad Sakac was we're going to make this low level infrastructure invisible, and we intend to make virtualization invisible, IE simplified. And so, you see above the two arrows there related to containers, container orchestration and container platforms, which are abstraction layers and services above the underlying VMs and hardware. And you can see the momentum that they have right there with the cloud and AI and RPA. So you had these forces that Jerry described that were taking shape, and this picture kind of summarizes how they came together to form Kubernetes. And the upper left, Of course you see AWS and we inserted a picture from a post we did, right after the first reinvent in 2012, it was obvious to us at the time that the cloud gorilla was AWS and had all this momentum. Now, Solomon Hykes, the founder of Docker, you see there in the upper right. He saw the need to simplify the packaging of applications for cloud developers. Here's how he described it. Back in 2014 in theCUBE with John Furrier >> Container is a unit of deployment, right? It's the format in which you package your application all the files, all the executables libraries all the dependencies in one thing that you can move to any server and deploy in a repeatable way. So it's similar to how you would run an iOS app on an iPhone, for example. >> A Docker at the time was a 30% company and it just changed its name from .cloud. And back to the diagram you have Google with a red question mark. So why would you need more than what Docker had created. Craig McLuckie, who was a product manager at Google back then explains the need for yet another abstraction. >> We created the strong separation between infrastructure operations and application operations. And so, Docker has created a portable framework to take it, basically a binary and run it anywhere which is an amazing capability, but that's not enough. You also need to be able to manage that with a framework that can run anywhere. And so, the union of Docker and Kubernetes provides this framework where you're completely abstracted from the underlying infrastructure. You could use VMware, you could use Red Hat open stack deployment. You could run on another major cloud provider like rec. >> Now Google had this huge cloud infrastructure but no commercial cloud business compete with AWS. At least not one that was taken seriously at the time. So it needed a way to change the game. And it had this thing called Google Borg, which is a container management system and scheduler and Google looked at what was happening with virtualization and said, you know, we obviously could do better Joe Beda, who was with Google at the time explains their mindset going back to the beginning. >> Craig and I started up Google compute engine VM as a service. And the odd thing to recognize is that, nobody who had been in Google for a long time thought that there was anything to this VM stuff, right? Cause Google had been on containers for so long. That was their mindset board was the way that stuff was actually deployed. So, you know, my boss at the time, who's now at Cloudera booted up a VM for the first time, and anybody in the outside world be like, Hey, that's really cool. And his response was like, well now what? Right. You're sitting at a prompt. Like that's not super interesting. How do I run my app? Right. Which is, that's what everybody's been struggling with, with cloud is not how do I get a VM up? How do I actually run my code? >> Okay. So Google never really did virtualization. They were looking at the market and said, okay what can we do to make Google relevant in cloud. Here's Eric Brewer from Google. Talking on theCUBE about Google's thought process at the time. >> One interest things about Google is it essentially makes no use of virtual machines internally. And that's because Google started in 1998 which is the same year that VMware started was kind of brought the modern virtual machine to bear. And so Google infrastructure tends to be built really on kind of classic Unix processes and communication. And so scaling that up, you get a system that works a lot with just processes and containers. So kind of when I saw containers come along with Docker, we said, well, that's a good model for us. And we can take what we know internally which was called Borg a big scheduler. And we can turn that into Kubernetes and we'll open source it. And suddenly we have kind of a cloud version of Google that works the way we would like it to work. >> Now, Eric Brewer gave us the bumper sticker version of the story there. What he reveals in the documentary that I referenced earlier is that initially Google was like, why would we open source our secret sauce to help competitors? So folks like Tim Hockin and Brian Grant who were on the original Kubernetes team, went to management and pressed hard to convince them to bless open sourcing Kubernetes. Here's Hockin's explanation. >> When Docker landed, we saw the community building and building and building. I mean, that was a snowball of its own, right? And as it caught on we realized we know what this is going to we know once you embrace the Docker mindset that you very quickly need something to manage all of your Docker nodes, once you get beyond two or three of them, and we know how to build that, right? We got a ton of experience here. Like we went to our leadership and said, you know, please this is going to happen with us or without us. And I think it, the world would be better if we helped. >> So the open source strategy became more compelling as they studied the problem because it gave Google a way to neutralize AWS's advantage because with containers you could develop on AWS for example, and then run the application anywhere like Google's cloud. So it not only gave developers a path off of AWS. If Google could develop a strong service on GCP they could monetize that play. Now, focus your attention back to the diagram which shows this smiling, Alex Polvi from Core OS which was acquired by Red Hat in 2018. And he saw the need to bring Linux into the cloud. I mean, after all Linux was powering the internet it was the OS for enterprise apps. And he saw the need to extend its path into the cloud. Now here's how he described it at an OpenStack event in 2015. >> Similar to what happened with Linux. Like yes, there is still need for Linux and Windows and other OSs out there. But by and large on production, web infrastructure it's all Linux now. And you were able to get onto one stack. And how were you able to do that? It was, it was by having a truly open consistent API and a commitment into not breaking APIs and, so on. That allowed Linux to really become ubiquitous in the data center. Yes, there are other OSs, but Linux buy in large for production infrastructure, what is being used. And I think you'll see a similar phenomenon happen for this next level up cause we're treating the whole data center as a computer instead of trading one in visual instance is just the computer. And that's the stuff that Kubernetes to me and someone is doing. And I think there will be one that shakes out over time and we believe that'll be Kubernetes. >> So Alex saw the need for a dominant container orchestration platform. And you heard him, they made the right bet. It would be Kubernetes. Now Red Hat, Red Hat is been around since 1993. So it has a lot of on-prem. So it needed a future path to the cloud. So they rang up Google and said, hey. What do you guys have going on in this space? So Google, was kind of non-committal, but it did expose that they were thinking about doing something that was you know, pre Kubernetes. It was before it was called Kubernetes. But hey, we have this thing and we're thinking about open sourcing it, but Google's internal debates, and you know, some of the arm twisting from the engine engineers, it was taking too long. So Red Hat said, well, screw it. We got to move forward with OpenShift. So we'll do what Apple and Airbnb and Heroku are doing and we'll build on an alternative. And so they were ready to go with Mesos which was very much more sophisticated than Kubernetes at the time and much more mature, but then Google the last minute said, hey, let's do this. So Clayton Coleman with Red Hat, he was an architect. And he leaned in right away. He was one of the first outside committers outside of Google. But you still led these competing forces in the market. And internally there were debates. Do we go with simplicity or do we go with system scale? And Hen Goldberg from Google explains why they focus first on simplicity in getting that right. >> We had to defend of why we are only supporting 100 nodes in the first release of Kubernetes. And they explained that they know how to build for scale. They've done that. They know how to do it, but realistically most of users don't need large clusters. So why create this complexity? >> So Goldberg explains that rather than competing right away with say Mesos or Docker swarm, which were far more baked they made the bet to keep it simple and go for adoption and ubiquity, which obviously turned out to be the right choice. But the last piece of the puzzle was governance. Now Google promised to open source Kubernetes but when it started to open up to contributors outside of Google, the code was still controlled by Google and developers had to sign Google paper that said Google could still do whatever it wanted. It could sub license, et cetera. So Google had to pass the Baton to an independent entity and that's how CNCF was started. Kubernetes was its first project. And let's listen to Chris Aniszczyk of the CNCF explain >> CNCF is all about providing a neutral home for cloud native technology. And, you know, it's been about almost two years since our first board meeting. And the idea was, you know there's a certain set of technology out there, you know that are essentially microservice based that like live in containers that are essentially orchestrated by some process, right? That's essentially what we mean when we say cloud native right. And CNCF was seated with Kubernetes as its first project. And you know, as, as we've seen over the last couple years Kubernetes has grown, you know, quite well they have a large community a diverse con you know, contributor base and have done, you know, kind of extremely well. They're one of actually the fastest, you know highest velocity, open source projects out there, maybe. >> Okay. So this is how we got to where we are today. This ETR data shows container orchestration offerings. It's the same X Y graph that we showed earlier. And you can see where Kubernetes lands not we're standing that Kubernetes not a company but respondents, you know, they doing Kubernetes. They maybe don't know, you know, whose platform and it's hard with the ETR taxon economy as a fuzzy and survey data because Kubernetes is increasingly becoming embedded into cloud platforms. And IT pros, they may not even know which one specifically. And so the reason we've linked these two platforms Kubernetes and Red Hat OpenShift is because OpenShift right now is a dominant revenue player in the space and is increasingly popular PaaS layer. Yeah. You could download Kubernetes and do what you want with it. But if you're really building enterprise apps you're going to need support. And that's where OpenShift comes in. And there's not much data on this but we did find this chart from AMDA which show was the container software market, whatever that really is. And Red Hat has got 50% of it. This is revenue. And, you know, we know the muscle of IBM is behind OpenShift. So there's really not hard to believe. Now we've got some other data points that show how Kubernetes is becoming less visible and more embedded under of the hood. If you will, as this chart shows this is data from CNCF's annual survey they had 1800 respondents here, and the data showed that 79% of respondents use certified Kubernetes hosted platforms. Amazon elastic container service for Kubernetes was the most prominent 39% followed by Azure Kubernetes service at 23% in Azure AKS engine at 17%. With Google's GKE, Google Kubernetes engine behind those three. Now. You have to ask, okay, Google. Google's management Initially they had concerns. You know, why are we open sourcing such a key technology? And the premise was, it would level the playing field. And for sure it has, but you have to ask has it driven the monetization Google was after? And I would've to say no, it probably didn't. But think about where Google would've been. If it hadn't open source Kubernetes how relevant would it be in the cloud discussion. Despite its distant third position behind AWS and Microsoft or even fourth, if you include Alibaba without Kubernetes Google probably would be much less prominent or possibly even irrelevant in cloud, enterprise cloud. Okay. Let's wrap up with some comments on the state of Kubernetes and maybe a thought or two about, you know, where we're headed. So look, no shocker Kubernetes for all its improbable beginning has gone mainstream in the past year or so. We're seeing much more maturity and support for state full workloads and big ecosystem support with respect to better security and continued simplification. But you know, it's still pretty complex. It's getting better, but it's not VMware level of maturity. For example, of course. Now adoption has always been strong for Kubernetes, for cloud native companies who start with containers on day one, but we're seeing many more. IT organizations adopting Kubernetes as it matures. It's interesting, you know, Docker set out to be the system of the cloud and Kubernetes has really kind of become that. Docker desktop is where Docker's action really is. That's where Docker is thriving. It sold off Docker swarm to Mirantis has made some tweaks. Docker has made some tweaks to its licensing model to be able to continue to evolve its its business. To hear more about that at DockerCon. And as we said, years ago we expected Kubernetes to become less visible Stu Miniman and I talked about this in one of our predictions post and really become more embedded into other platforms. And that's exactly what's happening here but it's still complicated. Remember, remember the... Go back to the early and mid cycle of VMware understanding things like application performance you needed folks in lab coats to really remediate problems and dig in and peel the onion and scale the system you know, and in some ways you're seeing that dynamic repeated with Kubernetes, security performance scale recovery, when something goes wrong all are made more difficult by the rapid pace at which the ecosystem is evolving Kubernetes. But it's definitely headed in the right direction. So what's next for Kubernetes we would expect further simplification and you're going to see more abstractions. We live in this world of almost perpetual abstractions. Now, as Kubernetes improves support from multi cluster it will be begin to treat those clusters as a unified group. So kind of abstracting multiple clusters and treating them as, as one to be managed together. And this is going to create a lot of ecosystem focus on scaling globally. Okay, once you do that, you're going to have to worry about latency and then you're going to have to keep pace with security as you expand the, the threat area. And then of course recovery what happens when something goes wrong, more complexity, the harder it is to recover and that's going to require new services to share resources across clusters. So look for that. You also should expect more automation. It's going to be driven by the host cloud providers as Kubernetes supports more state full applications and begins to extend its cluster management. Cloud providers will inject as much automation as possible into the system. Now and finally, as these capabilities mature we would expect to see better support for data intensive workloads like, AI and Machine learning and inference. Schedule with these workloads becomes harder because they're so resource intensive and performance management becomes more complex. So that's going to have to evolve. I mean, frankly, many of the things that Kubernetes team way back when, you know they back burn it early on, for example, you saw in Docker swarm or Mesos they're going to start to enter the scene now with Kubernetes as they start to sort of prioritize some of those more complex functions. Now, the last thing I'll ask you to think about is what's next beyond Kubernetes, you know this isn't it right with serverless and IOT in the edge and new data, heavy workloads there's something that's going to disrupt Kubernetes. So in that, by the way, in that CNCF survey nearly 40% of respondents were using serverless and that's going to keep growing. So how is that going to change the development model? You know, Andy Jassy once famously said that if they had to start over with Amazon retail, they'd start with serverless. So let's keep an eye on the horizon to see what's coming next. All right, that's it for now. I want to thank my colleagues, Stephanie Chan who helped research this week's topics and Alex Myerson on the production team, who also manages the breaking analysis podcast, Kristin Martin and Cheryl Knight help get the word out on socials, so thanks to all of you. Remember these episodes, they're all available as podcasts wherever you listen, just search breaking analysis podcast. Don't forget to check out ETR website @etr.ai. We'll also publish. We publish a full report every week on wikibon.com and Silicon angle.com. You can get in touch with me, email me directly david.villane@Siliconangle.com or DM me at D Vollante. You can comment on our LinkedIn post. This is Dave Vollante for theCUBE insights powered by ETR. Have a great week, everybody. Thanks for watching. Stay safe, be well. And we'll see you next time. (upbeat music)

>> In this session, we will be reviewing the power and benefits of implementing a secure software supply chain and how we can gain a cloud like experience with the flexibility, speed and security of modern software delivering. Hi, I'm Matt Bentley and I run our technical pre-sales team here at Mirantis. I spent the last six years working with customers on their containerization journey. One thing almost every one of my customers has focused on is how they can leverage the speed and agility benefits of containerizing their applications while continuing to apply the same security controls. One of the most important things to remember is that we are all doing this for one reason and that is for our applications. So now let's take a look at how we can provide flexibility to all layers of the stack from the infrastructure on up to the application layer. When building a secure supply chain for container focused platforms, I generally see two different mindsets in terms of where their responsibilities lie between the developers of the applications and the operations teams who run the middleware platforms. Most organizations are looking to build a secure, yet robust service that fits their organization's goals around how modern applications are built and delivered. First, let's take a look at the developer or application team approach. This approach falls more of the DevOps philosophy, where a developer and application teams are the owners of their applications from the development through their life cycle, all the way to production. I would refer to this more of a self service model of application delivery and promotion when deployed to a container platform. This is fairly common, organizations where full stack responsibilities have been delegated to the application teams. Even in organizations where full stack ownership doesn't exist, I see the self service application deployment model work very well in lab development or non production environments. This allows teams to experiment with newer technologies, which is one of the most effective benefits of utilizing containers. In other organizations, there is a strong separation between responsibilities for developers and IT operations. This is often due to the complex nature of controlled processes related to the compliance and regulatory needs. Developers are responsible for their application development. This can either include dock at the development layer or be more traditional, throw it over the wall approach to application development. There's also quite a common experience around building a center of excellence with this approach where we can take container platforms and be delivered as a service to other consumers inside of the IT organization. This is fairly prescriptive in the manner of which application teams would consume it. Yeah when examining the two approaches, there are pros and cons to each. Process, controls and compliance are often seen as inhibitors to speed. Self-service creation, starting with the infrastructure layer, leads to inconsistency, security and control concerns, which leads to compliance issues. While self-service is great, without visibility into the utilization and optimization of those environments, it continues the cycles of inefficient resource utilization. And a true infrastructure as a code experience, requires DevOps, related coding skills that teams often have in pockets, but maybe aren't ingrained in the company culture. Luckily for us, there is a middle ground for all of this. Docker Enterprise Container Cloud provide the foundation for the cloud like experience on any infrastructure without all of the out of the box security and controls that our professional services team and your operations teams spend their time designing and implementing. This removes much of the additional work and worry around ensuring that your clusters and experiences are consistent, while maintaining the ideal self service model. No matter if it is a full stack ownership or easing the needs of IT operations. We're also bringing the most natural Kubernetes experience today with Lens to allow for multi-cluster visibility that is both developer and operator friendly. Lens provide immediate feedback for the health of your applications, observability for your clusters, fast context switching between environments and allowing you to choose the best in tool for the task at hand, whether it is the graphic user interface or command line interface driven. Combining the cloud like experience with the efficiencies of a secure supply chain that meet your needs brings you the best of both worlds. You get DevOps speed with all the security and controls to meet the regulations your business lives by. We're talking about more frequent deployments, faster time to recover from application issues and better code quality. As you can see from our clusters we have worked with, we're able to tie these processes back to real cost savings, real efficiency and faster adoption. This all adds up to delivering business value to end users in the overall perceived value. Now let's look and see how we're able to actually build a secure supply chain to help deliver these sorts of initiatives. In our example secure supply chain, where utilizing Docker desktop to help with consistency of developer experience, GitHub for our source control, Jenkins for our CACD tooling, the Docker trusted registry for our secure container registry and the Universal Control Plane to provide us with our secure container runtime with Kubernetes and Swarm, providing a consistent experience, no matter where our clusters are deployed. You work with our teams of developers and operators to design a system that provides a fast, consistent and secure experience. For my developers, that works for any application, Brownfield or Greenfield, Monolith or Microservice. Onboarding teams can be simplified with integrations into enterprise authentication services, calls to GitHub repositories, Jenkins access and jobs, Universal Control Plan and Docker trusted registry teams and organizations, Kubernetes namespace with access control, creating Docker trusted registry namespaces with access control, image scanning and promotion policies. So, now let's take a look and see what it looks like from the CICD process, including Jenkins. So let's start with Docker desktop. From the Docker desktop standpoint, we'll actually be utilizing visual studio code and Docker desktop to provide a consistent developer experience. So no matter if we have one developer or a hundred, we're going to be able to walk through a consistent process through Docker container utilization at the development layer. Once we've made our changes to our code, we'll be able to check those into our source code repository. In this case, we'll be using GitHub. Then when Jenkins picks up, it will check out that code from our source code repository, build our Docker containers, test the application that will build the image, and then it will take the image and push it to our Docker trusted registry. From there, we can scan the image and then make sure it doesn't have any vulnerabilities. Then we can sign them. So once we've signed our images, we've deployed our application to dev, we can actually test our application deployed in our real environment. Jenkins will then test the deployed application. And if all tests show that as good, we'll promote our Docker image to production. So now, let's look at the process, beginning from the developer interaction. First of all, let's take a look at our application as it's deployed today. Here, we can see that we have a change that we want to make on our application. So our marketing team says we need to change containerize NGINX to something more Mirantis branded. So let's take a look at visual studio code, which we'll be using for our ID to change our application. So here's our application. We have our code loaded and we're going to be able to use Docker desktop on our local environment with our Docker desktop plugin for visual studio code, to be able to build our application inside of Docker, without needing to run any command line specific tools. Here with our code, we'll be able to interact with Docker maker changes, see it live and be able to quickly see if our changes actually made the impact that we're expecting our application. So let's find our updated tiles for application and let's go ahead and change that to our Mirantis sized NGINX instead of containerized NGINX. So we'll change it in a title and on the front page of the application. So now that we've saved that changed to our application, we can actually take a look at our code here in VS code. And as simple as this, we can right click on the Docker file and build our application. We give it a name for our Docker image and VS code will take care of the automatic building of our application. So now we have a Docker image that has everything we need in our application inside of that image. So, here we can actually just right click on that image tag that we just created and do run. This will interactively run the container for us. And then once our containers running, we can just right click and open it up in a browser. So here we can see the change to our application as it exists live. So, once we can actually verify that our applications working as expected, we can stop our container. And then from here, we can actually make that change live by pushing it to our source code repository. So here, we're going to go ahead and make a commit message to say that we updated to our Mirantis branding. We will commit that change and then we'll push it to our source code repository. Again, in this case, we're using GitHub to be able to use as our source code repository. So here in VS code, we'll have that pushed here to our source code repository. And then, we'll move on to our next environment, which is Jenkins. Jenkins is going to be picking up those changes for our application and it checked it out from our source code repository. So GitHub notifies Jenkins that there's a change. Checks out the code, builds our Docker image using the Docker file. So we're getting a consistent experience between the local development environment on our desktop and then in Jenkins where we're actually building our application, doing our tests, pushing it into our Docker trusted registry, scanning it and signing our image in our Docker trusted registry and then deploying to our development environment. So let's actually take a look at that development environment as it's been deployed. So, here we can see that our title has been updated on our application, so we can verify that it looks good in development. If we jump back here to Jenkins, we'll see that Jenkins go ahead and runs our integration tests for our development environment. Everything worked as expected, so it promoted that image for our production repository in our Docker trusted registry. We're then, we're going to also sign that image. So we're assigning that yes, we've signed off that has made it through our integration tests and it's deployed to production. So here in Jenkins, we can take a look at our deployed production environment where our application is live in production. We've made a change, automated and very secure manner. So now, let's take a look at our Docker trusted registry, where we can see our name space for our application and our simple NGINX repository. From here, we'll be able to see information about our application image that we've pushed into the registry, such as the image signature, when it was pushed by who and then, we'll also be able to see the results of our image. In this case, we can actually see that there are vulnerabilities for our image and we'll actually take a look at that. Docker trusted registry does binary level scanning. So we get detailed information about our individual image layers. From here, these image layers give us details about where the vulnerabilities were located and what those vulnerabilities actually are. So if we click on the vulnerability, we can see specific information about that vulnerability to give us details around the severity and more information about what exactly is vulnerable inside of our container. One of the challenges that you often face around vulnerabilities is how exactly we would remediate that in a secure supply chain. So let's take a look at that. In the example that we were looking at, the vulnerability is actually in the base layer of our image. In order to pull in a new base layer for our image, we need to actually find the source of that and update it. One of the ways that we can help secure that as a part of the supply chain is to actually take a look at where we get our base layers of our images. Docker hub really provides a great source of content to start from, but opening up Docker hub within your organization, opens up all sorts of security concerns around the origins of that content. Not all images are made equal when it comes to the security of those images. The official images from Docker hub are curated by Docker, open source projects and other vendors. One of the most important use cases is around how you get base images into your environment. It is much easier to consume the base operating system layer images than building your own and also trying to maintain them. Instead of just blindly trusting the content from Docker hub, we can take a set of content that we find useful such as those base image layers or content from vendors and pull that into our own Docker trusted registry, using our mirroring feature. Once the images have been mirrored into a staging area of our Docker trusted registry, we can then scan them to ensure that the images meet our security requirements. And then based off of the scan result, promote the image to a public repository where you can actually sign the images and make them available to our internal consumers to meet their needs. This allows us to provide a set of curated content that we know is secure and controlled within our environment. So from here, we can find our updated Docker image in our Docker trusted registry, where we can see that the vulnerabilities have been resolved. From a developer's point of view, that's about as smooth as the process gets. Now, let's take a look at how we can provide that secure content for our developers in our own Docker trusted registry. So in this case, we're taking a look at our Alpine image that we've mirrored into our Docker trusted registry. Here, we're looking at the staging area where the images get temporarily pulled because we have to pull them in order to actually be able to scan them. So here we set up mirroring and we can quickly turn it on by making it active. And then we can see that our image mirroring, we'll pull our content from Docker hub and then make it available in our Docker trusted registry in an automatic fashion. So from here, we can actually take a look at the promotions to be able to see how exactly we promote our images. In this case, we created a promotion policy within Docker trusted registry that makes it so that content gets promoted to a public repository for internal users to consume based off of the vulnerabilities that are found or not found inside of the Docker image. So our actual users, how they would consume this content is by taking a look at the public to them, official images that we've made available. Here again, looking at our Alpine image, we can take a look at the tags that exist and we can see that we have our content that has been made available. So we've pulled in all sorts of content from Docker hub. In this case, we've even pulled in the multi architecture images, which we can scan due to the binary level nature of our scanning solution. Now let's take a look at Lens. Lens provides capabilities to be able to give developers a quick opinionated view that focuses around how they would want to view, manage and inspect applications deployed to a Kubernetes cluster. Lens integrates natively out of the box with Universal Control Plane clam bundles. So you're automatically generated TLS certificates from UCP, just work. Inside our organization, we want to give our developers the ability to see their applications in a very easy to view manner. So in this case, let's actually filter down to the application that we just employed to our development environment. Here, we can see the pod for application. And when we click on that, we get instant detailed feedback about the components and information that this pod is utilizing. We can also see here in Lens that it gives us the ability to quickly switch contexts between different clusters that we have access to. With that, we also have capabilities to be able to quickly deploy other types of components. One of those is helm charts. Helm charts are a great way to package up applications, especially those that may be more complex to make it much simpler to be able to consume and inversion our applications. In this case, let's take a look at the application that we just built and deployed. In this case, our simple NGINX application has been bundled up as a helm chart and is made available through Lens. Here, we can just click on that description of our application to be able to see more information about the helm chart. So we can publish whatever information may be relevant about our application. And through one click, we can install our helm chart. Here, it will show us the actual details of the helm charts. So before we install it, we can actually look at those individual components. So in this case, we can see this created an ingress rule. And then this will tell Kubernetes how did it create this specific components of our application. We'd just have to pick a namespace to deploy it to and in this case, we're actually going to do a quick test here because in this case, we're trying to deploy the application from Docker hub. In our Universal Control Plane, we've turned on Docker content trust policy enforcement. So this is actually going to fail to deploy. Because we're trying to employ our application from Docker hub, the image hasn't been properly signed in our environment. So the Docker content trust policy enforcement prevents us from deploying our Docker image from Docker hub. In this case, we have to go through our approved process through our secure supply chain to be able to ensure that we know where our image came from and that meets our quality standards. So if we comment out the Docker hub repository and comment in our Docker trusted registry repository and click install, it will then install the helm chart with our Docker image being pulled from our DTR, which then it has a proper signature. We can see that our application has been successfully deployed through our home chart releases view. From here, we can see that simple NGINX application and in this case, we'll get details around the actual deployed helm chart. The nice thing is, is that Lens provides us this capability here with helm to be able to see all of the components that make up our application. From this view, it's giving us that single pane of glass into that specific application, so that we know all of the components that is created inside of Kubernetes. There are specific details that can help us access the applications such as that ingress rule that we just talked about, gives us the details of that, but it also gives us the resources such as the service, the deployment and ingress that has been created within Kubernetes to be able to actually have the application exist. So to recap, we've covered how we can offer all the benefits of a cloud like experience and offer flexibility around DevOps and operations control processes through the use of a secure supply chain, allowing our developers to spend more time developing and our operators, more time designing systems that meet our security and compliance concerns.

>> So, hi, my name is Daniel Terry, I work as Lead Designer at SEB. So, today we will go through why we are why we are Mirantis' customer, why we choose Docker Enterprise, and mainly what challenges we were facing before we chose to work with Docker, and where we are today, and our keys to success. >> Hi, my name is Johan, I'm a senior developer and a Tech Lead at SEB. I was in the beginning with Docker for like, four years ago. And as Daniel was saying here, we are going to present to you our journey with Docker and the answers. >> Yeah, who are we? We are SEB group. So we are a classic, financial large institutions. So, classic and traditional banking services. In Sweden, we are quite a big bank, one of the largest. And we are on a journey of transforming the bank so it has to be online 24-seven. People can do their banking business every day, whenever they want, nothing should stop them to be online. So this is putting a lot of pressure on us on infrastructure to be able to give them that service. (drum fill) >> So our timeline here. Is look, we started out with how to facilitate the container technology it has to be. 2016. And, in 2018, we had the first Docker running in SEB in a standalone mode. You need that. We didn't have any swarm, or given up this cluster since a while. For 2019, we have our first Docker-prise enterprise cluster at SEB. And today, 2020, we have the latest and greatest version of Docker installed. We are running around approximately two and a fifth at 450 specs. Around a thousand services and around 1500 containers. So, developer challenges. As for me as a developer, previous to Docker was really, really hard to get things in production. Times. It took big things and ordering services and infrastructures was a pain in the... yeah, you know what I mean? So for me, it was all about processes. We use natural processes and meaning that I wasn't able to, to see maintaining my system in production. I was handing that over to our operations teams and operation teams in that time, they didn't know how the application works. They didn't know how to troubleshoot it and see, well, what's going wrong. They were experts on the infrastructure and the platforms, but not on our applications. We were working in silos, meaning that I as a developer, only did developing things. The operations side did their things, and the security side did their things. But we didn't work as a team. I mean, today we have a completely different way of working. We will not see shapes. I mean, we have persons that were really good in maybe MQ technologies, or in some programming language and so on, but we didn't have the knowledge in the team techs to solve things, as we should have. Long lead times. I mean, everything we were trying to do had to follow the processes as we had. I mean that we should fill in some forms, send it away, hopefully someone was getting, getting back to us and saying, yeah guys, we can help you out with these services or this infrastructure, but it takes a really long time to do that. I mean, ordering infrastructure is when you're not an expert on that really hard to do. And often the orders we made or placed were wrong. When we have forms to fill in, it wasn't possible for us to do things automatically. Meaning that we didn't have the code, or the infrastructure as code. Meaning that if we didn't get the right persons into the meetings the first time, we didn't have the possibility to do it the right way, meaning that we had to redo and redo, and hopefully sometimes we got the right. We didn't have consistent set ups between the environments. When we order, as for example, a test environment, we could maybe order it with some minor resources, less CPU, so less memory, less disc or whatever. Or actually less performance on the hardware, but then we moved up to production. We realized that we have different hardware, different discs, different memories, and that could actually cause some serious problems in applications, access-wise. I mean, everyone likes to have exercise, especially if you are the maintainer of the system. That was really, really hard to get. I mean, every system has their own services, their own service, and therefore they need to apply for access to those other services. But today there's a complete difference since we only have one class to produce. Since we don't have infrastructure as a code back then, there were really lots of human errors. I mean, everyone was doing things manually. When you're coming from the Windows perspective, everything is a UI. You tend to prefer that way of working, meaning that if you used to click something in between the environments, the environments will not look the same. Life cycles. I mean, just imagine. When we have the server installed, it's like a pet. You have everything configured all from certificates to port openings, cartels, install patches, you name it. And then imagine that Windows are terminating a version and you need to reinstall that. Everything needs to be redone from the beginning. So there was a really long time taking to, to do the LCM activities, General lack of support of Microservice architecture was really also, a thing that are driving us forward with the containers technology, since we can't scale our applications in the same way as for containers. We, for example, couldn't have two applications or two processes using the same TCP port. For example, if you'd like to scale a web server, you can't do that on the same hardware. You need to have two different servers. And just imagine replacing all the excesses, replacing all the orders again for more hardware, and then manually a setting up there. The low balancer in front is a really huge task to do. And necessarily if you don't have the knowledge how the infrastructure is where you're working, then it's also really hard for you as a developer to do things right. Traditionalist. I mean, the services for us are like pets. They were really, really hard to set up. It'd take maybe a week or so. And if something was wrong with them, we will try to fix them as a pet. I mean, we couldn't just kill them and throw them away. It will actually destroy the application as this, our, like a unit box where all our things are installed. >> So, coming in from the infrastructure part of this, we've also seen challenges. For my team, we're coming from a Windows environment. So doing like a DevOps journey, which we want to do, makes it harder due to our nature in our environments. We are not used to, maybe use API, so we are not used to giving open APIs to our developers to do changes on the servers. Since we are a bank, we don't allow users to log into the servers, which means we have to do things for them all the time. This was very time consuming. And a lot of the challenges we actually still are seeing is the existing infrastructure. You can't just put that container platform on it, and thinking you're sold and everything. One of the biggest issues for us is, has been to getting servers. Windows servers usually takes like 15 minutes, Linux servers can takes up to two week in a bad day. So we really lack like, infrastructure as code. If we want a low balancer, that is also an order form. If we want the firewall opening, that's an order form. Hopefully they will not deny it. So it will go faster. So it's a lot of old processes that we need to go through. So what we wanted to do is that we want to move all of these things to the developers, so they can do it. They can own up their problems, but with our old infrastructure, that wasn't possible. We are a heavily ITIL-based organization, meaning that everything went from a cab. Still does in some way, we have one major service window every month where we take everything down. There is a lot of people involved in everything. So it's quite hard to know what will be done during the maintenance window. We lack supporting tools, or we lacked supporting tools, like log-in, good log-in tools. We have a bunch of CI/CD tools, but the maturity level of the infrastructure team wasn't that good. Again, order form and processes. If we want to, like, procure, do our procurement on a new like, storage system, or a backup system, we talk about here. So to do it is, for us, with containers, it would solve a lot of problems, because we cause we would then move the problems, not maybe move the problems to the developer, but we would make it able for them to own their own problems. So everything that we have talked about up till now boils down to business drivers. So the management's gave- gave us some policies to, or what they, how they want to change the company, so we can be this agile and fast moving bank. So one of the biggest drivers are cloud readiness, where Containers comes in perfectly. So we can build it on premises, and then we can move it to the cloud when we are ready but we can't, but we also need an exit strategy to move it back on premises if we need, due to hard regulations. Maybe you can throw it in the air. >> Absolutely. I definitely can. You're absolutely right. We need to develop things in a certain way. So we can move from infrastructure to infrastructure depending, or regardless of the vendor. Meaning that if we are able to run it on-prem, we should be able to run it in cloud or vice versa. We should also be able to move between clouds, and not be forced into one cloud provider. So that's really important for us at SEB. Short time to market is also a thing here. I mean, we are working with the huge customers. I can't name them, but they're really huge. And they need to have us being moving forward. I mean, able to really fast switch from one technology, maybe to another, we are here for them. And it's really important to us to be really fast for us to get new things out in production. All right, maybe. Nothing else? >> I don't, don't really. From the upside, we are in a huge staff DevOps transition. So, or a forced DevOps transition, which means we need to start looking at new infrastructure solutions, maybe deploy our infrastructure parts inside of containers to be able to use it the same way in the cloud. That's what we do prior, do here on premises, we have private clouds which are built on techno- technology, container technology today. So this fits quite good to have the Docker platform being one part of that one. >> Yeah. And this is solid, we are also working really, really actively on open source platforms and open source drivers. We can see that we have a huge amount of vendors in SEB, really huge ones, but we can also see that we can, facilitate open source platforms, and open source technology as well. So container technology will bring that for us. I mean, instead of having a SaaS platform and SaaS services, we can actually instantiate our own with containers and stuff. >> Also we are, since we are quite heavily regulated, the process of going through to you as like a SaaS service can take up to two years for us to go through, and then maybe the SaaS service, is it, is it what we want to use anymore? So, also we want to develop the things in our own premises and maybe, and scale it to the cloud if we need. And also we want to be an attractive employer, where maybe it's not that, the coolest thing for a young student to work in mainframe, we have a mainframe it's, it's not going anywhere, but it's hard to get people, and we want to be an attractive employer, and everyone is talking Kubernetics and containers or, and clouds. So we need to transition into those technologies. >> Yeah, we need to be open minded and necessarily facilitate the new technologies. So we can actually attract new employees. So it's really important to us to have an open mind. Our experience with Docker Containers. I mean, as I said before, scalability is a really important thing for us today. When we are using a more microservice architecture, we need to be able to Skype. We need to be scaling horizontally instead of vertically. So for that, containers are perfect storage. As we said before, we have a huge problem with environments being differently set up, since it was often manually done. Today, as we have a infrastructure as a code, it's really, really nice to have the same things exactly configured, the same in all environments. And we also have the same tooling, meaning that if I can run it on my machine, it's the same tooling I will be using to run it for test purposes or in production. That's a huge benefit for us as a developer. Time to market. I mean, today, we don't have to order service, we are using the service approach here. So we have a container cluster that are actually just sitting there waiting for our services to be hosted. So no more forms, no more calls, no more meetings before we can set up anything. We also own our problems. I mean, before, as I said, we have the processes, meaning that we ship our applications to any server. And then the operation sites take over. That's not the case now. We are actually using this as we should in DevOps. Meaning the other teams are actually responsible for all their errors as well. Even if it's on the infrastructure part, it's completely different if it's a platform's problem, because then it's the platform's team, and we can use different windows. We can try stuff out, we have an open mind. And that says that I can download and try any container image I would like on my developer machine. It's not maybe, okay to run it in production without having the security people look at it. But normally it's really, really much faster instead of waiting maybe six months, we can maybe wait one week or so. And of course less to none LCM activities. I mean, as I said before, it will take months, maybe, to do an LCM activity on multiple servers. Today, our LCM activities more or less are just switching to a new version of the image from Docker hub. That's all we have to do. So that's actually maintained during the processes we have in CI/CD pipelines. >> And the last one. So our keys to success: you should get demanded from the managers and management that everything should be a container. All the new development has to go through a container before you start ordering servers. Everything shall go through a CI/CD pipeline. We don't actually, here at SEB. Our developers build their own CI/CD pipeline. We just provide a platform for them to use it against, and the CI/CD to systems, but they build everything for themselves. Cause they know how their application works, how it should be deployed, with what tools. We just provide them with a tool set. Build a Cross Team. So you should incorporate all the processes that you need, but you should focus on the developer part, because you are building a platform for the developers, not for operations or security. >> And then maybe >> A lot of... >> you'll be able to take flight >> Yeah. Luck has nothing to do with it? Yes, it has. Of course, luck has something to do with it, even if you're really passionate, even if you're really good at some things. I mean, we got some really nice help from Dr. Inc. We were really... Came in with the technology in the right time for us to be, and we had really engaged people with these projects and that's a really luck for us to have. >> Yeah. And also we... I want to thank our colleagues, because we have another container team who started before us. And they have actually run into a lot of organizational problems, which they have sold, so we could piggyback on that, on those solutions. Also, start small and scale it. This is where Docker swarm comes, fits perfectly. So we have actually, we started with swarm. We are moving into Kubernetics in this platform. We will not force-move anything. The developers just should show us, what their- fits their needs. Thank you! >> Thank you very much.

>> Announcer: From theCUBE studios (upbeat music) in Palo Alto and Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. >> Everyone, welcome to this CUBE Conversation. I'm John Furrier, host of theCUBE here in Palo Alto, California during the COVID-19 current situation. We're here with a skeleton crew, getting the content out there. Wanted to bring a special remote interview to you with two great remote guests, talking about how the digital events, and how the digital interactions are evolving, and how our community's reacting. Got two great guests, John Kreisa, a senior vice president of marketing at Docker, and Jenny Burcio, who's the advocate, community and DockerCon content lead at Docker. Jenny and John, thanks for joining me today. >> Great to be here, thank you. >> Thanks, John. >> So you guys, Docker has been one of the most popular container platforms from the beginning of this cloud native movement. You have over millions and millions of developers out there. DockerCon is going virtual. It's an event that you guys had physically over the years, now it's going to go virtual, but this is not new to the developer world. I want to get into that in the conversation, but first I want to give you guys a chance to take a minute and explain, John Kreisa, if you take a minute to explain the new Docker because there were some changes over the past year. Take a quick minute to explain that. >> Sure thanks John, and hello everybody. So, we went through a change in November of last year to refocus Docker on, I'll say, what was the roots and the foundations of the company, around developers and developer teams. And so, at that time we took the action to split off the enterprise-focused component of the business, sold it to a company called Mirantis. Since that time, we've been working very diligently around refocusing Docker on developer tooling, developer chains, and really developer productivity, individuals and teams, and that's something that has really revitalized our community, I'll say. The community's been strong and has come with us, and I think is reacting very, very positively to this change. So that's something that we've been going on, we're about five months into that change, and that's been positive so far. >> So it's a startup, kind of a reset, kind of a start up again, get the startup roots, but with a huge community, millions of developers. >> Massive community, that's right. Millions of developers, more than two million Docker desktop downloads installed on developer machines. Huge community around Docker Hub, using that as their essential collaboration point for developers for developing applications as they move those applications to the web, and to the cloud infrastructure. So, really just a tremendous community. It is a refocused company, but one that really is starting with a phenomenal foundation, as you mentioned, in terms of the community that we have with us. >> And it's a second chance to ride the big wave. Certainly the waves are bigger now. I don't want to make this a real commercial about Docker, or DockerCon. We're going to do a special video promo reel on that event, which we're kind of co-producing with you guys on a new collaboration. So look for, the folks watching, look for a nice promo intro video on what's going to happen at DockerCon, which will be a whole nother track. The reason why I wanted to bring you guys here, is this highlights to me the core impact of part of this crisis and current situation around Coronavirus, COVID-19, people are working at home more, so the mainstream world is seeing what it's like to work at home. People are understanding some of the pressures and the dynamics around how people communicate and work. And we, Jenny, were talking about this from a community standpoint. Open source community, they've been working at home (laughs) for a long time. It's been one of the most biggest success stories that hasn't been written is the success of how software developers have been productive in working in these groups on big projects with people from around the world. This isn't new. I'd love to get your perspective on how, what's your reaction to everyone else's reaction of the whole work-at-home digital world? >> Yeah, so, I mean, if you look at what open source, and what engineers have done, generally. You know, innovation doesn't happen within an office from nine to five, in whatever time zone you're in. And so, there's been, with Docker, GitHub, Zoom, a number of tools in place, and not just the ones I named, that really allow anyone, anywhere in the world, to contribute their ideas, and respond real time. We're not going through a huge change, even within Docker or in tech, of having to work from home. Maybe kids in the calls is a little bit different, but for many of us, we're lucky to continue marching on during this time. >> What do you guys see as best practices of the work-at-home crisis, or some of the collaboration techniques? I mean, everyone knows the online troll. I mean, trolls just get booted out, or moderated out of groups. Is there a certain best practice that you could share with folks that aren't, that are learning this for the first time? >> Sure, so, highly recommend having a code of conduct, and living by that code of conduct. So making it very visible to whomever you're working with, both internally at the company, and in open source, externally to anyone wanting to contribute to a project. Giving grace in this time. As we all know there's stress much beyond what's happening in our day-to-day work for all the community right now. And writing things as much as possible. And I think, particularly as in the last couple of weeks, there's been a real need to keep the written record of decisions and conversations, and make it out there and open so anyone can kind of participate. And even to that end, Docker announced a public roadmap earlier this month. So now our entire community can jump on and vote for what they want to see, or provide input and ideas on what we would do next. >> John, I want to ask you around DockerCon coming up, as you guys look to this being a first virtual event, digital event we call it. It's more digital than virtual, but I guess people use the word virtual more now, but it's really digital. Content value has always been king on physical events, but as you move over to virtual events, you just can't make the same people make the same decisions around a breakout room, or what assignment on the calendar and just ship it over to digital is a whole nother roles. New rules, new roles, new dynamics. What's your view on this as a marketer, because you've been on both sides, successful on both sides of the table there? >> Yeah, it is a, in a way, whole new world. I've participated in virtual events in the past, but I think this, the kind of scenario that we're in, puts a whole new impetus on making sure that these events, as much as you can, emulate the in-person experience. I think it's important that the experience you provide to your audience allows them to interact in a number of different ways, above and beyond just simply watching and consuming content, but really allows them to interact with each other that makes it so they can interact with speakers, and other users, and the kinds of people that they want to have. One of the things that we're thinking about, for example, for DockerCon coming up is, how do we emulate that hallway experience, right? The you're walking down the hall, you see somebody, you've been wanting to talk to them, and you have a quick five, or 10, or 20-minute conversation that allows you to have a really good, rich exchange. And that's something that we're working hard, Jenny's working hard on, and that the team's really working hard to provide. So, you know, in this new world, it's how do we bring some of those things that make a great in-person event to the virtual world? And you know, there's fortunately a lot of great tools out there now that do make that possible, you just have to bring them together in the right way. >> Yeah, I know that's something that we've been working on together with you guys, and you know, everyone knows my rant. I think that the format's going to be multiple different types of formats. Chats are different. We were chatting around the different, you know, there's a streamed chat, like on YouTube and Twitch, versus threaded like Reddit. And the hallway grabs, those hallway tracks, it's all about the content of the people, and I want to get your thoughts on, as you guys look to take this asynchronous approach, try to make it synchronous with DockerCon, has it changed some of your thinking around call for papers? I mean, call for papers is almost like an editorial call for a blog post now. So is it changing how you guys are thinking? Is there any insight that you could share as you guys are preparing? Also, you still got to get sponsors. You still got to get some funding. Maybe not huge amounts 'cause the physical space, venue's not there, it's digital now. So, can you guys just share your thinking, your reaction, and any insights you can glean from those two dynamics, the format, the call for papers, and the sponsors, and things of that nature that were proven methods the old way? I mean, just like, call the papers, line up the schedule, there it is, and everyone shows up, but not anymore. What's different? >> So with virtual we really have the opportunity to take the serendipity out of the conversations and the learning that happens at an in-person event. We ran a traditional call for papers. It closed on Friday, we got a number of responses and great, great content that came in. But we're not going to set a speaker up to deliver that live in a session at DockerCon. We're going to pre-record their talks, and have the speaker there live to actually chat with anyone in the audience. So, answer questions, so you'll have, actually, a much greater opportunity to talk to that expert via this virtual event than you would in person, listening to that person speak. I think it really helps first time speakers, and speakers who aren't as confident to get up in a huge room, to have the opportunity to pre-record their talk. So it adds to kind of the diversity and inclusion of the event to bring on some new speakers, for sure. And from a location standpoint, right, now you don't have to give up a whole week to show up somewhere. You can spend that time working on your talk, or whatever else, to kind of share your knowledge. And then the conversation doesn't have to end there. You really, everyone has a way to connect with each other after the fact, which as event marketers, you're always looking for what is that way that you continue the wonderful connections and learning that happens at a live event, beyond. And by having it all happen virtually, you're setting yourself up for success in that area. >> It actually makes it more interesting, because you think about it, you give your talk, and you're there after either giving people high fives, or signing autographs, or getting tomatoes thrown at you. So it's there, right? I mean, it is what's the product, it's the content product. You can engage with the audience after to take that followup, that side bar, maybe the conversations. How about, John, sponsors? I mean, obviously, we have to include sponsors into these events. You know, I've seen some software out there that's pretty old school. It's like, "Oh, here's the digital rendering of our booth." I mean, I personally think that's horrible. I think that's the wrong direction, but the content value of a booth is an event within the event. So there is a way to weave this in. What's your vision of that? How do you see the inclusion of a sponsor, and how is it more intimate and more authentic for them? >> Yeah, I think there's multiple aspects in terms of benefits for a sponsor that we are thinking about. Certainly, as you said, you don't really get that walk into the booth kind of experience, but given that it's all digital, you actually have a much more scalable way to enable sponsors to interact. Firstly, just with how we're promoting the event going into it, and the fact that as they create an asset, it can live in perpetuity, that we can continue to push out there to viewers. And we know that people can come and look at that content afterwards, and that gives yet another opportunity for those sponsors to interact with the people who are consuming it. So everybody has to really think a little bit differently. Both the sponsors of these events, and the hosts, as Docker is doing now, to how and what kinds of interactions. So we're thinking, how do we allow them to capture an interaction? What kinds of calls to action can they include within their digital content? And so everybody's got to think a little bit more digitally and more forward than just, "Hey, let me have people walk "into my booth and pick up some swag." >> You know, it's interesting, we have this conversation that's like an angle on theCUBE all the time, if you think about the end user, the consumer of the content, if you work on the strive for the content value, everybody wins. So, it's like an upstream project in open source. If done well, everyone can reap the benefits. If the shared mission is audience satisfaction around the content, that's contextually relevant to the people at any given time, which is what digital is beautiful for, and you can really create an environment for great activation, and full-on demand, consumer experience advantage, either learning or engaging, or whatever. If you do that, if everyone shares in that mission, that's a success formula. Whether you're a sponsor, or an attendee, or a producer. Do you agree with that? >> And John, we were saying earlier today, this format makes content even more of the king, right? The way that you're going to get attention is by delivering value through that content, and you will probably have a better result of someone stopping by to learn what your offering is, or what knowledge you're bringing to the table, versus what that piece of swag was that they're getting scanned for. >> And there's a role for everybody. I remember when, back in the glory days when I used to develop code, I used to go show my peers my software, they're like, "Yeah, John, that code's just not good." "Well, no, no." But there's a role for me. I wasn't the best coder, but if you have good code, you rise right to the top of the pecking order and people recognize your software in open source, and content's kind of the same way. Everyone can produce content, and some will be better than others, but it doesn't mean that it's just about the content produced, or the curation, there's other roles. Do you guys see some parallels between content development in this kind of way, in a similar fashion as, say, software? I'm just making that metaphor up, it's just riffing out loud. It's a similar construct. Good software wins the day. Good community makes it all work. >> Sure, if your end goal is to educate others and share something that is of value, then it's going to be picked up. And of course creating content takes practice, just like becoming an excellent coder. And so, the stakes aren't as high in a virtual event, especially with pre-recording and some of the other things that you're doing. You know, blog about it. Do a video, do a session, right? Take that content, deliver it different ways, and practice. Particular to DockerCon, both at our live events, and what we will do moving forward, we have an extensive support system for all of our speakers. We assign a number of people internally to review outline, review talk tracks, review slides, and run through actual practices, so that our speakers are very attuned to what our audience is going to be expecting, and feel very comfortable delivering their session, because their success is our success, and ultimately, we're looking for delivering that value to Docker's builders. >> I love the format you mentioned earlier, pre-record, but also there's a new format emerging that's very popular in the Twitch world which is streaming your video game. I still predict that people will be streaming their coding sessions, but you guys have a Docker captain in Brett, who has his own streaming rig and he does the Docker birthday party, recently. I think that's going to be a future format, streaming to an end point, not just for gaming, but for just life, life casting as some people call it. But that's a good format. It fits perfectly into these digital events to host and emcee these sessions. So you can do the record on-demand, record in advance, but there's also a role for streaming, doing the demos, doing the tech talks. >> I mean, think about your audience. They need something both in the moment, and after the fact. And sessions are something that you can watch now, or later, but running through an event with our captain, like Brett Fisher, you want to be there to see what's going on. We did a birthday live stream on Thursday, to celebrate Docker's seventh birthday, and it was amazing because we had so many members of our community come on. They can't go to meet-ups anymore with everything that's happening, but we found a way to all connect, all chat, have a great time, and have this group experience, both fun and learning. And I think we will continue to see that, not just in the conference form, but increasingly now with COVID, people can't get together. People are Zooming with their high school friends to make up for time lost. So I think beyond our industry, the world is going to get very used to connecting virtually. >> I'm going to have a Zoom session tonight, seven o'clock on my Facebook page. It's going to be interesting to see all my high school friends come out, and who knows those words, but there's kind of no moderator button on Facebook. I got to figure out, make sure they're all there. Final question on this whole event thing, and then we can get to this last section around DockerCon. John and Jenny, we both have friends that are in digital, have done events. I'm hearing a lot of pressure is on these digital teams, because the physical events have proven a lot of great business value. Most companies know the economic value of physical event. Again, it's been standardized over decades, but now all of the sudden these new teams, digital teams, are being asked to provide the same business value that these physical events have provided, and these teams aren't equipped for it. So I'm getting a lot of phone calls, and a lot of outreach to theCUBE saying, "We need help." That's the event digital team, and the demand generation marketing teams. They're under a lot of pressure. Are you guys seeing the same thing, and if you are, what advice would you give the people out there, because they're under a massive amount of pressure to deliver? >> Yeah, it's a new world in that regard. And yeah, there are a few platforms out there, but in terms of something for demand marketers that emulates that live event, there's really not. I mean, as you know, we're innovating in multiple ways with you to bring a different kind of experience, but we're also having to think about how do we convert that into some kind of economic value? I mean, for example, DockerCon is a free event this year. A lot of the costs are lower, but it's a free event. That sort of changes that aspect of it. But the other part is, how do we make sure that we connect with that audience, so that we have an ongoing relationship? The way we're looking at it, and I think one recommendation for other companies, is it is a component in a series of engagements. It's a very big one, one that we're investing quite a bit in, in terms of resources, but it's really just a series of, one component of a series of engagements that we have digitally. And there's lot of other ways that you can do it, and fortunately, like Jenny has online meetups, or already has virtual meetups as a component of our virtual experience. This is one that we're sliding in with that, and based on how we're expecting it to go, we'll continue to invest in it in the future. >> Jenny, 365 days in the year, that's digital, it's aways on, right? It's like you got to think holistically, not just have an event, stand it up, tear it down, move to the next one. You activate and you got to keep it always on, you have to keep a pulse. Keep the community rolling. >> Yes, and whether it was a physical event, or a virtual event, that's your goal anyways, is to continue that momentum and keep the community going. We are innovating on that with you for DockerCon, but we're also very much listening to our community, and what their needs are, and trying to figure out how to support their connections with their local community. Docker has a pretty extensive meetup network all around the world, and the rise of virtual really allows us to take the physical limitations of local meetups out, and if they want to run virtual events, then great, how can we support them as well? >> That's awesome. And you know our mission from this area for the folks watching, is to create the best experience possible for audiences, and that means putting the right content in front of them that matters, or having them choose their own content, meet the right people, find if their friends are there, make it a great engaging experience. Because if that happens, everybody wins. So, we're looking forward to DockerCon. If you guys could just give a highlight, quick teaser. John, give a quick teaser on DockerCon, and then Jenny, give the community update of what do you guys expect to have happen? What are you hoping for? What are you nervous about? What's the excitement? What's going on? John, we'll start with you. >> Yeah, thanks John. So just a brief on DockerCon. It's May 28th, of this year. It is a free event that is going to run for, I think it's eight hours during the day. There's multimodal, kind of consumption models. So we're thinking in terms of different channels that people can come and consume. We talked a little bit about the live channel with our captains. There's a live channel with theCUBE, with you guys. There's also the pre-recorded track content. So, there's a way for people to come and interact, come and participate in the chats, and consume content that should be highly educational and focused, and we hope that it'll be a great experience. We're really focused on the content, making sure that it's a great experience for our users and our audience. >> Jenny, how about the community? What's your take, and what's your goal and aspirations? What are you hoping for? >> Hoping for the community to be able to connect, both with the speakers, experts, captains, get their questions answered, have conversations with people on stage, if you will, but also with each other. And just kind of strengthen the bonds of the community, and getting everybody to a better place with developing with Docker and DevOps, and kind of create those pathways beyond May 28th. >> Yeah, it's a DevOps world. We're going to do our best. Hope we put a kick ass program together. It's going to be fun, (laughs) and we hope we have good bandwidth. John went out a couple times there, one time, but we're going to have some good time, and hopefully learn a lot and iterate, and just raise the bar on it and just get it going. So really appreciate collaborating with you guys, and really thank you for your insight on this real, I think, a clear vision on how digital's going to shape how people engage and how events will go, even when they come back. I think this point in time, this current situation's going to emphasize the role of digital isn't just about marketing to people and getting them to come to an event. I think it's going to be a real productive network effect, where there's value created. And I think the silver lining in all this is, this is going to be now the new path for us. So thank you for sharing your cutting edge insights. I appreciate your time, thank you. >> Thanks so much for having us. >> Thank you, John. >> Okay, this is a CUBE Conversation. I'm John Furrier here in the CUBE studios in Palo Alto, with the remote interviews during this time of crisis, of COVID-19 current situation. I'm John Furrier, theCUBE, thanks for watching. (upbeat music)

(vibrant music) >> Everyone, welcome to our Palo Alto studio. I'm John Furrier host of theCUBE. We're here for a digital conversation. Part of our new digital events, part of our new structure of bringing people into the studio and also doing remotes. We'd love to do that in the era of the travel bans, but it's always great to have local Silicon Valley executives and startups here. Milin Desai, CEO of Sentry IO is here with me. Former VM-ware industry executive, CEO of Sentry IO hot startup. Thanks for coming in. >> Thank you for having me. >> So you can drive in. You don't have to fly anywhere. It's all good. No wearing masks. The coronavirus is crazy. I'm so glad we have you at this studio and get this content acquisition. Thanks for coming in. I want to get your take on your company before we get into the industry thing. I think you look at some of the most successful categories that just came out of nowhere. You know, you look at AIOps for instance in driving, you know, observability. But what is observability? That beginning, that comes with public page or do the list just goes on and on. The cloud has created this agile market where real time and then a lot of automation is going on so whether it's error logs like a Splunk does and that's scaled up. You get to doing something variation with software code that's not just something breaks, a phone rings. There's a lot a going on. You're this really kind of the tailwind here for you with cloud scale. What does Sentry doing? What's their secret sauce? >> So, the simplest way I would put it is we help you measure and monitor your code in production in close to real time. So what does that mean? You look at all, all of the companies that we talk about, whether it's a John Deere on one end or a Spotify on the other. They're all getting more digital in nature, which means they all trying to interact with their customers more often, building apps with an interface with an API. And as we all know, through our own personal experiences, if you don't get a great experience, you simply move on. So, you pull up your app, you pull up Uber, it's not working, let me look at Lyft. Right? That's the kind of consumer behavior that's starting to take in. >> So-- >> Meaning you don't really know as the owner of the app if they're abandoning or not, it's just down sales or? >> Correct. And so, what we do is we help developers monitor how the usages of their code in production. So, as users hit editors, a checkout button is not working or a user is having a bad experience on a mobile phone, whereas the same application on a browser looks fine. We in real time giving notification saying X number of users on this type of device, on this type of interface are having issues. And not just that, it's an alert, it's an alert that says this is the issue, this is the line of code where the issue's taking place, this is the potential commit that you did in your getRepository, which is causing it. So, it's the full kind of metadata around the issue. Which typically would be, what, two days? I take it as filed. Support me, look at it. Hey, customer has an issue, let's reproduce it. Well the customer is gone. So this is all done in real-- >> Or it could be a complete blindspot too. You don't know, right? This is the thing. This is why I love this whole digital transformation role where instrumentation is re-imagining how everything's being done. So for instance, you could see a code push and you go, okay, it's in production. And then why are sales down? Why is usage down? And then you've got to do a postmortem. >> Correct. >> No one called, just going what the hell happened? Fingers are blaming. He did it! Here you're trying to get to the point where you can see that error earlier or before or after, during as it work. >> It's almost in real time. Close to real time. As the user has the error immediately through either PagerDuty, Slack, email, whichever your communication medium is. You get to know a user or a set of users are having an issue. You click it, you go to this portal. All the metadata is right there. So, it's in real time. And so to exactly your point, it's not after the fact. >> Yeah. >> Right, it's happening. And so, the CTO of tackled.io, said it best, it's a startup that helps companies get on to marketplaces. He said, "Hey, we found issues before our customers even filed a issue against us." So, you know, this helps us deliver true customer experience, as a development team. >> So, on the developers that target profile get that and they're coding away. They don't have time to do research. They'll be like, "Oh, I better bolt on some instrumentation here." That's been the successful move. Look at like what Datadog has done in DevOps. Just the easy onboarding, free use it. Is that the same model you guys are taking this free land, adopt then expand. So, is it a freemium, could you explain the business model? >> Yeah, so, a Sentry is a open source. And so customers can take the piece of software that we have as is, fully functional and run it themselves on their data center on their cloud, or they can choose a SaaS version from us and we offer kind of like a free version and then you pay for the plan. So, what we typically see is customers turn it on, developers turn it on and they like it. And then, the best score I got recently was, one CEO who said, "Hey, you know, I don't send you that many events, but I see the value of what you do, so I decided to pay you." Right, so, they went from free to paid. And that's kind of typical pattern that we see. And the best thing about this is, it takes you approximately four lines of code to get started. Four lines of code in your code and you get started getting the benefits of Sentry. >> What's good sign for monetization when you got the paying it forward literally with cash. I want to ask you the difference between the open source version because I saw in the origination story it's really interesting. They were at jobs and they saw this side project grow into a real opportunity. And it's always good to see the open source not die, right. So, this been maintain the project. When would someone use the open sources? Is that the hardcore folks or, so SaaS, obviously makes sense. It's easier if you're doing a lot of the extra support and whatnot on top of it. But what's the use case for the folks who are going to bring it in house loaded on their cloud? >> I think we'll leave it to our customers to decide that. And we've seen, folks who say, "Hey, you know, we have, we're going to try it out, it's a small, we have got a good DevOps practice. We're going to get it up and running." Here's what happened with one of my teams at VMware. The engineer in charge looked at it and said, "It's not worth my time given what the price on SaaS is." Right, so, like our smallest plan is $29, which satisfies most startups or small software projects. And his point was like, "Hey, you know, it's almost better for me to start and using that versus--" >> Well they weren't using NSX. I'm sure Pat Gels would be like, "Get shipped the next product." Well this is the trade off, right? I mean, so that's what's beautiful of open source. You want to bring it in and make it work for yourself. That trade off has to be economically there. >> Correct. >> So you have a nice balance of if you're hardcore, no problem. >> Please use-- >> Use it, contribute, be part of the team. But if you want ease of use and all the bells and whistles and the speed. >> I think it comes down to what we are starting to see, which is, how much do you care about getting to value faster and where is your value? Is it in kind of running and operating all these pieces of software or is it in, you know, getting value to your end customer? So, if you are focused on building your business, we are this value add that kind of gets you there faster. So, stop focusing on kind of building the infrastructure. Start delivering kind of the value to the business. >> So I'm going to ask you, so, are you the CEO? So the founders who I've not met. I look forward to interviewing them. They seem pretty cool. I'm sure they probably say, "Oh this guy from VMware, he's probably the big company guy." 'Cause they were like, we're going to Dropbox now. Engineers, I could almost imagine their, what they're like. Probably skeptical, this is VMware guy. How did you get through the interview process? Obviously, you're the CEO, you made it. Were they skeptical ? What worked? Why you, why'd you go there? >> You know, the best thing about this transition is Chris and David. So, David was the CEO. He is now the CTO. He's the founder creator along with Chris. And it was his decision, to bring someone into the company, given that we are seeing this, you know, we are now at 20000 plus customers and he felt like he wanted to kind of go back to building and creating and bring a partner in crime. So, that was the good part. I would say like, we started talking and we are at the same energy level, you know? So, I think it just worked out in the way we communicated. And you've known me for a bit. I'm kind of hands on. I like, you know, to kind of get into things and build businesses. So, I think the profile matched out and both of us took our time. So it was, a long dating process, where we got to know each other. Not just as, you know, what we do for work. But, you know, how we operate and had coffee and lunch and dinner and--- >> Well, it is a dating, dating and marriage is always thinking, but the founders are, it's a tough move to make. I mean, for founders to be self-aware, to bring in someone else. But also the fit has to be there. And a lot of entrepreneurs just check the box and try to hire someone too fast that could fail or gets jammed down by the VCs, you know. So, the founders are pretty kind of reluctant. So, that's interesting that you did that. >> Yeah, he's been thinking. You know, the thing about David is he's super thoughtful and hopefully you'll get to see him soon. He's been thinking about this for a bit. And he took his time. And he worked through the process and that's why I said it felt like we were not just talking about, me joining as a CEO, as much as us getting to know each other and building this for the long run. And so we really took our time on both ends--- >> And he want to to get back on the engine of the business? He's a developer, right? He's like the code. >> Just don't want to, >> It was-- >> 20000 customers, you going to get hiring people. It's HR issues. This probably, I don't want to do that. >> That and you know it was kind of the personality thing, right? Grit and grind, you know. We kind of, can somebody come in and have the passion, the same that he believes in what we do. And he saw that and I saw that in him and I'm like, this is a great opportunity that I cannot forego. >> So talk about the, I say love modern, the modern startups because, you know, you're on the right side of history when you got cloud at your tailwind and kind of DevOps, like vibe you get going on with, I know it's not DevOps, but it's common like cloud scale and the agility. How are you guys organized? You guys have virtual teams. You have a central office. Is there a physical place? Do people come in? What's the, how is the company's philosophy on work environment? >> So, we actually have three locations. One in San Francisco, which is the headquarters, where we are located. And then in Vienna, Austria, where one of the early engineers and pioneers live. And so we built around that person and that location. >> No one's complaining about that. >> No. >> Vienna's not a bad place there-- >> Not a bad place. I haven't visited yet. (laughs) I am looking forward to it. I was supposed to be there in April, but, given the circumstances, I'm postponing it. And we recently started this past year in Toronto. And so, we are--- >> So three strong areas for tech talent for sure. >> And then we do have some employees working from home. So, we try and hire the best, and then we accommodate. But we do try to kind of cluster around these three locations. >> So, I got to get your take as the CEO, obviously we're all grappling with this, work at home, Covid 19, the coronavirus, is impacting. Everything's being canceled here in Silicon Valley. I would say Seattle has more of a hotspot than our area. Mostly China as China. What's the view that you guys are taking right now? You're telling people who work at home. Obviously, events are being canceled. Places where people doing Biz Dev, KubeCon was canceled, Dell Technology World is can-- I mean everything's being canceled. How's that affecting your business and what's your philosophy? How are you guys are executing through this tough time? >> I think as a company we've kind of taken the step for having people work from home and we did it on a location by location basis. So, for folks in San Francisco, especially because folks who are commuting on public transportation and other things. We wanted to make our team feel comfortable. And so we've instituted a work from home policy, for, I think we said two weeks, but I think it's going to keep going until we get a clear signal from the government, both locally and at the federal level. So that's kind of where we are as a team. And then what we noticed was the Austrian government kind of had similar regulations of everyone's working from home. Slack, you know, Google Hangouts. We spending a lot of time on video, making sure we are connected as a team. And you know, just that spirit of how we operate and talk to each other continues. As a business, we are a bottoms up business. So, what I mean by that is folks sign up, they use the product. And developers are right now globally still fully functional. The only difference being they're now working from home. So we feel like as a business, we'll be fine. And we are ensuring that our customers through this transition and through this period of kind of unknowns are able to continue to be successful for their customers. >> It's funny, I was talking with someone, it's like there's going to be some, obviously, sectors, like events are going to take a big hit. South by got canceled, Coachella's being canceled. All the tech events are being canceled. That's why we're going to be doing our stuff at the studio with virtual events, for theCUBE. But certain things are going to be different. You going to see pregnancy, boom. You know, nine months later, people are going to be having kids cause they're home alone or divorces depending on how you look at it. But productivity, developer wise has been talked about as actually developers want to just crank out some code. They don't have to come into the office. You can be more, I mean you can still be productive. Developers have been doing this for decades. >> I think-- >> At least if they are more. >> You know, I think you, you know, I think there might be a scenarios of adjustment, a period of adjustment. And then folks will get comfortable. So, it's super important to create that engagement model. Whether, do you have the tooling to keep the team engaged. And there companies that are completely remote. And so we're making sure we learn from their best practices around that. But I do believe that, for tech companies or even for manufacturing companies focused on building software, developers are going to be productive. >> Okay, so a baby boom's coming, divorce rate's going to go up and productivity is skyrocketing. (both laugh) >> For developers. >> For developers. Well, I mean it's a good time. Okay, can I get your take on the industry now. Honestly, putting all the coronavirus aside, we saw a surge in public cloud check. Done. And ask you when your VMware with NSX coming in and becoming the engine with software defined networking as part of the Series piece. You're starting to see hybrid clear as day. It's going to happen. Multi clouds on the horizon. So, you now have a three wave cloud game going on. Wave one, done. Wave two is hybrid. Wave three maybe bigger than them all with multicloud. Do you agree with that trend analysis and what's your take on that? >> So, this is where I'll probably kind of look back at my time at VMware. I think, you know, definitely see the multicloud wave catching on. But I would use the word multicloud as in, not a app spread across three clouds as much as, you know, a company choosing to have a certain assets in AWS, certain assets in Azure, certain in Google. So, I don't see yet this idea of an app being stretched across the three clouds but definitely, while I was-- >> VMware tried that. (both laugh) >> While I was at VMware and in talking to customers, we definitely saw adoption of multiple clouds. And that's where when I was working with the cloud health team, this idea of managing cost and security across three clouds became very common as a pattern that came up. You definitely see that as a kind of directional thing that a lot of organizations are doing. >> Yeah, the idea of just rapidly shifting up workloads based on pricing, all that stuff. I think it's aspirational at best because development teams are now just getting their groove on with hybrid and operation, cloud operations. So, I can see a day where if you can manage the latency network issues, maybe some day, but I mean, come on, really? I think about how hard that is, just latency alone. >> And the issue is like, architecturally you have to make really good choices to get there. So, I think you might see that in like kind of tech software firms. We're thinking about, how do I stay cloud neutral? But for the most part, if you want to take the full value of AWS or full value of GCP, you want to go deeper in there. And use all their services. >> Yeah, I think that's great insight. Let's riff on that a little bit because one of the things I was talking to Dave Alante and Stu Miniman about was, if you look at the multicloud, I don't think it's going to come from a vendor. I think if you look at the success of the Facebooks of the world, even Dropbox where your founders came from, early on, they had to just basically build it from cloud native, from ground up. And all the hyper scalers use open source. They built all their stuff. No one was selling them anything. They just did it. So, I think you'll see smart architectural moves, but that'll be the unicorn. That'll not be the standard. That'll be the exception, not the rule. I don't think you can sell multicloud, in my opinion, yet, or I don't think that'll even be possible. But I think someone will come out and say, make those architectural decisions saying, "I have an architecture that works multicloud because we architect it that way." >> Yup, yup. And I think that's kind of the more, kind of from an engineering standpoint, I think you'll see more of that. I think from a, you know, from a kind of solution standpoint, you will see folks saying, "I will help you manage or secure or build into each of the clouds and give you kind of common pattern versus the latter of it." And engineering team says, "Here's a way to architect for multicloud." >> You know, we pay a lot of attention to the next gen kind of psychologies. Obviously, we do a lot of coding on with our cube cloud that's coming out now. But, how do you see the founders you're working with and that in this new peer group that's developing. I call it, the next gen entrepreneur, technical entrepreneur. As they look at the vast resources of cloud and all of the data opportunities there and mobility, internet things and all this stuff going on. What is the general mindset right now of these kinds of entrepreneurs from a technology perspective? How are they looking at the problem space? What's your take on this new landscape as an entrepreneur? >> Yeah, I'll give you kind of what got me super excited about Sentry. Like how, why did I think about that? Which is if you look at 2000 to 2010, we did software defined infrastructure. Things started moving into software. 2010 to 2020 was, as you correctly wanted a cloud, hybrid, everything became kind of as a service. I think this next decade will be about data. So, companies using the data to get a competitive advantage or figuring out, you know, how to stay ahead, whether it's competitively or even to win a market. And the other aspect of this is because everything is so, as a service, API centric, I think it's going to explode how we develop things. And I think this is going to be truly now the decade for the developer, who's going to make deeper choices, greater choices, buying decisions. And so, with data kind of exploding, and the management of it and getting insights out of it is one aspect of it. And, you know, as somebody who's looking at Sentry, we do a lot of that, right? Which is how are customers using it? What are they using? What languages? And everything else that goes with that. But on the other end, developers are going to start kind of using things and create a whole new set of use cases that's going to change the way we think about it. So I think there's a whole set of elements around how to use this infrastructure to build new applications, creative products, that is going to be a massive boom. >> I think that's a great point. I think that's great insight. Because you think about observability, which I was just joking earlier on about, but I think the relevance observability is network management applied to value real time, right? Because if you can instrument everything, the smart people are going to saying, "Hey, I can just instrument this and get the data I need rather than dealing with this hassle process we had before." So, it brings up that kind of philosophy of kill the old to bring in the new or something new that kills the old. So, it's an interesting phenomenon. I think it's very relevant. But I want to get your, question as a CEO now, you've got, you're at the helm, helm of a company is technical. And talking about architecture, what's your architecture for the venture? What's your plans? How do you see the, you said you're going to come and build this next level growth. What's your architecture look like? Are you going to, do more of the same? Any new things that we see? What are you going to... What's your plan? >> Fundamentally, you know, we as a kind of set of users in the world today, have spent a lot of time monitoring, as I told you earlier, machines, systems and applications, right? And so there's a lot of successful companies doing that. But if you fundamentally believe that this is the decade where you're going to write more code than we've ever before or refresh more applications than we've ever before. Our focus is code and how it does whether it's in a staging environment, in a canary deployment, or in production. How do we measure code and monitor code in production. And the impact of that code to the end users. So it could be errors and now increasingly code performance. So you will see us kind of venture into this idea of helping developers. Not only find issues that they run into production like we talked about before, but also be able to say, looks like over the past three releases, our logins per second have gone down progressively by 10%. Why is that happening? Where is that happening? Which team made that change? So, you will see us kind of really double down on this idea of measuring and monitoring code going forward, complimenting how we measure monitor systems, machines and applications today. >> Yeah, I mean, code has got to be managed, as people more, people contribute. It's like a compiler for the compiler. (laughs) >> It's like if code fails, your business-- >> Code for the code. >> Yeah. >> Meta three meta meta as they say, but code for the code. But that's, it's basically code management in a way, right? It's the code data. You're leveraging that code relationship to the application. >> And so we talk about applications a lot. And so we write code, we store code, you know, in a getRepository. Now there's a whole set of elements around securing it. We deploy it. What about measuring and monitoring it? That is the element where we focus and kind of bring that whole cycle together. Helping that application developer be successful. >> What's it like for you going from VMware to the startup? What's the biggest, coolest thing that's happened? >> It's been a great transition. You know, and I always say this to folks who ask me for career advice. They say, always choose the people you work with and the people you work for. And I've been fortunate enough to do that and I think this transition has been great for that reason alone. Which is I've had the time to get to know the team at Sentry. They got to know me and it's just been, it's been fantastic. I think the velocity of and the pace at which I can make changes, has been the most fun part of it. >> And you've got like 25, 20000 paying customers 50000 total customers roughly in that range. Pretty sizeable. Employee count, how many employees do you have? >> 100 plus employees and-- >> Still small, still small. >> Yeah, still small. And we're going to probably double this year, give or take. And you know, it's 20000 customers from every startup. I've spoken to a startups, over 100 startups in two months. And it's amazing to see their reaction and their love for Sentry. >> And funding, how many rounds of funding have you guys done? >> We just finished Series C, in September of last year. 40 million, any Accel growth. So, we feel really good about where we are. With the revenue ramp that we've seen, we're in great shape. >> And pretty good numbers in terms of a head count too, very leveraged SaaS model. Get the developers. >> Yes. >> Great. Well, we're going to be entertaining a lot of developers at DockerCon this year. DockerCon used to be an event for Docker. Now they sold half the business to Mirantis. They're focusing on Docker developers. We have an event here. We're doing a virtual event. So, a lot more developer action coming. We'll talk more about that. Love to meet your founders, have them come in too. We want to thank you for coming on. >> Thank you. >> Milin Desai, CEO of sentry.io, former VMware executive with a great hot startup, Series C funded, growing here in Silicon Valley, San Francisco and in Austria. I'm John Furrier with theCUBE. Thanks for watching. (vibrant music)