(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)

>>Hey, welcome to the live panel. My name is Brett. I am your host, and indeed we are live. In fact, if you're curious about that, if you don't believe us, um, let's just show a little bit of the browser real quick to see. Yup. There you go. We're live. So, all right. So how this is going to work is I'm going to bring in some guests and, uh, in one second, and we're going to basically take your questions on the topic designer of the day, that continuous integration testing. Uh, thank you so much to my guests welcoming into the panel. I've got Carlos, Nico and Mandy. Hello everyone. >>Hello? All right, >>Let's go. Let's go around the room and all pretend we don't know each other and that the internet didn't read below the video who we are. Uh, hi, my name is Brett. I am a Docker captain, which means I'm supposed to know something about Docker. I'm coming from Virginia Beach. I'm streaming here from Virginia Beach, Virginia, and, uh, I make videos on the internet and courses on you to me, Carlos. Hey, >>Hey, what's up? I'm Carlos Nunez. I am a solutions architect, VMware. I do solution things with computers. It's fun. I live in Dallas when I'm moving to Houston in a month, which is where I'm currently streaming. I've been all over the Northeast this whole week. So, um, it's been fun and I'm excited to meet with all of you and talk about CIA and Docker. Sure. >>Yeah. Hey everyone. Uh, Nico, Khobar here. I'm a solution engineer at HashiCorp. Uh, I am streaming to you from, uh, the beautiful Austin, Texas. Uh, ignore, ignore the golden gate bridge here. This is from my old apartment in San Francisco. Uh, just, uh, you know, keeping that, to remember all the good days, um, that that lived at. But, uh, anyway, I work at Patrick Corp and I work on all things, automation, um, and cloud and dev ops. Um, and I'm excited to be here and Mandy, >>Hi. Yeah, Mandy Hubbard. I am streaming from Austin, Texas. I am, uh, currently a DX engineer at ship engine. Um, I've worked in QA and that's kind of where I got my, uh, my Docker experience and, um, uh, moving into DX to try and help developers better understand and use our products and be an advocate for them. >>Nice. Well, thank you all for joining me. Uh, I really appreciate you taking the time out of your busy schedule to be here. And so for those of you in chat, the reason we're doing this live, because it's always harder to do things live. The reason we're here is to answer a question. So we didn't come with a bunch of slides and demos or anything like that. We're here to talk amongst ourselves about ideas and really here for you. So we've, we obviously, this is about easy CII, so we're, we're going to try to keep the conversation around testing and continuous integration and all the things that that entails with containers. But we may, we may go down rabbit holes. We may go veer off and start talking about other things, and that's totally fine if it's in the realm of dev ops and containers and developer and ops workflows, like, Hey, it's, it's kinda game. >>And, uh, these people have a wide variety of expertise. They haven't done just testing, right? We, we live in a world where you all kind of have to wear many hats. So feel free to, um, ask what you think is on the top of your mind. And we'll do our best to answer. It may, might not be the best answer or the correct answer, but we're going to do our best. Um, well, let's get it start off. Uh, let's, let's get a couple of topics to start off with. Uh, th the, the easy CGI was my, one of my three ideas. Cause he's the, one of the things that I'm most excited about is the innovation we're seeing around easier testing, faster testing, automated testing, uh, because as much as we've all been doing this stuff for, you know, 15 years, since 20 years since the sort of Jenkins early days, um, it it's, it seems like it's still really hard and it's still a lot of work. >>So, um, let's go around the room real quick, and everybody can just kind of talk for a minute about like your experience with testing and maybe some of your pain points, like what you don't like about our testing world. Um, and we can talk about some pains, cause I think that will lead us to kind of talk about what, what are the things we're seeing now that might be better, uh, ideas about how to do this. I know for me, uh, testing, obviously there's the code part, but just getting it automated, but mostly getting it in the hands of developers so that they can control their own testing. And don't have to go talk to a person to run that test again, or the mysterious Jenkins platform somewhere. I keep mentioning Jenkins cause it's, it is still the dominant player out there. Um, so for me, I'm, I'm, I, I don't like it when I'm walking into a room and there's, there's only one or two people that know how the testing works or know how to make the new tests go into the testing platform and stuff like that. So I'm always trying to free those things so that any of the developers are enabled and empowered to do that stuff. So someone else, Carlos, anybody, um, >>Oh, I have a lot of opinions on that. Having been a QA engineer for most of my career. Um, the shift that we're saying is everyone is dev ops and everyone is QA. Th the issue I see is no one asked developers if they wanted to be QA. Um, and so being the former QA on the team, when there's a problem, even though I'm a developer and we're all running QA, they always tend to come to the one of the former QA engineers. And they're not really owning that responsibility and, um, and digging in. So that's kind of what I'm saying is that we're all expected to test now. And some people, well, some people don't know how it's, uh, for me it was kind of an intuitive skill. It just kind of fit with my personality, but not knowing what to look for, not knowing what to automate, not even understanding how your API end points are used by your front end to know what to test when a change is made. It's really overwhelming for developers. And, um, we're going to need to streamline that and, and hold their hands a little bit until they get their feet wet with also being QA. >>Right. Right. So, um, uh, Carlos, >>Yeah, uh, testing is like, Tesla is one of my favorite subjects to talk about when I'm baring with developers. And a lot of it is because of what Mandy said, right? Like a lot of developers now who used to write a test and say, Hey, QA, go. Um, I wrote my unit tests. Now write the rest of the test. Essentially. Now developers are expected to be able to understand how testing, uh, testing methodologies work, um, in their local environments, right? Like they're supposed to understand how to write an integration tasks federate into and tasks, a component test. And of course, how to write unit tests that aren't just, you know, assert true is true, right? Like more comprehensive, more comprehensive, um, more high touch unit tests, which include things like mocking and stubbing and spine and all that stuff. And, you know, it's not so much getting those tests. Well, I've had a lot of challenges with developers getting those tests to run in Docker because of usually because of dependency hell, but, um, getting developers to understand how to write tests that matter and mean something. Um, it's, it's, it can be difficult, but it's also where I find a lot of the enjoyment of my work comes into play. So yeah. I mean, that's the difficulty I've seen around testing. Um, big subject though. Lots to talk about there. >>Yeah. We've got, we've already got so many questions coming in. You already got an hour's worth of stuff. So, uh, Nico 81st thoughts on that? >>Yeah, I think I definitely agree with, with other folks here on the panel, I think from a, um, the shift from a skillset perspective that's needed to adopt the new technologies, but I think from even from, uh, aside from the organizational, um, and kind of key responsibilities that, that the new developers have to kinda adapt to and, and kind of inherit now, um, there's also from a technical perspective as there's, you know, um, more developers are owning the full stack, including the infrastructure piece. So that adds a lot more to the plate in Tim's oaf, also testing that component that they were not even, uh, responsible for before. Um, and, um, also the second challenge that, you know, I'm seeing is that on, you know, the long list of added, um, uh, tooling and, you know, there's new tool every other day. Um, and, um, that kind of requires more customization to the testing, uh, that each individual team, um, any individual developer Y by extension has to learn. Uh, so the customization, uh, as well as the, kind of the scope that had, uh, you know, now in conferences, the infrastructure piece, um, uh, both of act to the, to the challenges that we're seeing right now for, um, for CGI and overall testing, um, uh, the developers are saying, uh, in, in the market today. >>Yeah. We've got a lot of questions, um, about all the, all the different parts of this. So, uh, let me just go straight to them. Cause that's why we're here is for the people, uh, a lot of people asking about your favorite tools and in one of this is one of the challenges with integration, right? Is, um, there is no, there are dominant players, but there, there is such a variety. I mean, every one of my customers seems like they're using a different workflow and a different set of tools. So, and Hey, we're all here to just talk about what we're, what we're using, uh, you know, whether your favorite tools. So like a lot of the repeated questions are, what are your favorite tools? Like if you could create it from scratch, uh, what would you use? Pierre's asking, you know, GitHub actions sounds like they're a fan of GitHub actions, uh, w you know, mentioning, pushing the ECR and Docker hub and, uh, using vs code pipeline, I guess there may be talking about Azure pipelines. Um, what, what's your preferred way? So, does anyone have any, uh, thoughts on that anyone want to throw out there? Their preferred pipeline of tooling? >>Well, I have to throw out mine. I might as Jenkins, um, like kind of a honorary cloud be at this point, having spoken a couple of times there, um, all of the plugins just make the functionality. I don't love the UI, but I love that it's been around so long. It has so much community support, and there are so many plugins so that if you want to do something, you don't have to write the code it's already been tested. Um, unfortunately I haven't been able to use Jenkins in, uh, since I joined ship engine, we, most of our, um, our, our monolithic core application is, is team city. It's a dotnet application and TeamCity plays really well with.net. Um, didn't love it, uh, Ms. Jenkins. And I'm just, we're just starting some new initiatives that are using GitHub actions, and I'm really excited to learn, to learn those. I think they have a lot of the same functionality that you're looking for, but, um, much more simplified in is right there and get hubs. So, um, the integration is a lot more seamless, but I do have to go on record that my favorite CICT tools Jenkins. >>All right. You heard it here first people. All right. Anyone else? You're muted? I'm muted. Carlin says muted. Oh, Carla says, guest has muted themselves to Carlos. You got to unmute. >>Yes. I did mute myself because I was typing a lot, trying to, you know, try to answer stuff in the chat. And there's a lot of really dark stuff in there. That's okay. Two more times today. So yeah, it's fine. Yeah, no problem. So totally. And it's the best way to start a play more. So I'm just going to go ahead and light it up. Um, for enterprise environments, I actually am a huge fan of Jenkins. Um, it's a tool that people really understand. Um, it has stood the test of time, right? I mean, people were using Hudson, but 15 years ago, maybe longer. And, you know, the way it works, hasn't really changed very much. I mean, Jenkins X is a little different, but, um, the UI and the way it works internally is pretty familiar to a lot of enterprise environments, which is great. >>And also in me, the plugin ecosystem is amazing. There's so many plugins for everything, and you can make your own if you know, Java groovy. I'm sure there's a perfect Kotlin in there, but I haven't tried myself, but it's really great. It's also really easy to write, um, CIS code, which is something I'm a big fan of. So Jenkins files have been, have worked really well for me. I, I know that I can get a little bit more complex as you start to build your own models and such, but, you know, for enterprise enterprise CIO CD, if you want, especially if you want to roll your own or own it yourself, um, Jenkins is the bellwether and for very good reason now for my personal projects. And I see a lot on the chat here, I think y'all, y'all been agreed with me get hub actions 100%, my favorite tool right now. >>Um, I love GitHub actions. It's, it's customizable, it's modular. There's a lot of plugins already. I started using getting that back maybe a week after when GA and there was no documentation or anything. And I still, it was still my favorite CIA tool even then. Um, and you know, the API is really great. There's a lot to love about GitHub actions and, um, and I, and I use it as much as I can from my personal project. So I still have a soft spot for Travis CAI. Um, you know, they got acquired and they're a little different now trying to see, I, I can't, I can't let it go. I just love it. But, um, yeah, I mean, when it comes to Seattle, those are my tools. So light me up in the comments I will respond. Yeah. >>I mean, I, I feel with you on the Travis, the, I think, cause I think that was my first time experiencing, you know, early days get hub open source and like a free CIA tool that I could describe. I think it was the ammo back then. I don't actually remember, but yeah, it was kind of an exciting time from my experience. There was like, oh, this is, this is just there as a service. And I could just use it. It doesn't, it's like get hub it's free from my open source stuff. And so it does have a soft spot in my heart too. So yeah. >>All right. We've got questions around, um, cam, so I'm going to ask some questions. We don't have to have these answers because sometimes they're going to be specific, but I want to call them out because people in chat may have missed that question. And there's probably, you know, that we have smart people in chat too. So there's probably someone that knows the answer to these things. If, if it's not us, um, they're asking about building Docker images in Kubernetes, which to me is always a sore spot because it's Kubernetes does not build images by default. It's not meant for that out of the gate. And, uh, what is the best way to do this without having to use privileged containers, which privileged containers just implying that yeah, you, you, it probably has more privileges than by default as a container in Kubernetes. And that is a hard thing because, uh, I don't, I think Docker doesn't lie to do that out of the gate. So I don't know if anyone has an immediate answer to that. That's a pretty technical one, but if you, if you know the answer to that in chat, call it out. >>Um, >>I had done this, uh, but I'm pretty sure I had to use a privileged, um, container and install the Docker Damon on the Kubernetes cluster. And I CA I can't give you a better solution. Um, I've done the same. So, >>Yeah, uh, Chavonne asks, um, back to the Jenkins thing, what's the easiest way to integrate Docker into a Jenkins CICB pipeline. And that's one of the challenges I find with Jenkins because I don't claim to be the expert on Jenkins. Is there are so many plugins because of this, of this such a huge ecosystem. Um, when you go searching for Docker, there's a lot that comes back, right. So I, I don't actually have a preferred way because every team I find uses it differently. Um, I don't know, is there a, do you know if there's a Jenkins preferred, a default plugin? I don't even know for Docker. Oh, go ahead. Yeah. Sorry for Docker. And jacon sorry, Docker plugins for Jenkins. Uh, as someone's asking like the preferred or easy way to do that. Um, and I don't, I don't know the back into Jenkins that well, so, >>Well, th the new, the new way that they're doing, uh, Docker builds with the pipeline, which is more declarative versus the groovy. It's really simple, and their documentation is really good. They, um, they make it really easy to say, run this in this image. So you can pull down, you know, public images and add your own layers. Um, so I don't know the name of that plugin, uh, but I can certainly take a minute after this session and going and get that. Um, but if you really are overwhelmed by the plugins, you can just write your, you know, your shell command in Jenkins. You could just by, you know, doing everything in bash, calling the Docker, um, Damon directly, and then getting it working just to see that end to end, and then start browsing for plugins to see if you even want to use those. >>The plugins will allow more integration from end to end. Some of the things that you input might be available later on in the process for having to manage that yourself. But, you know, you don't have to use any of the plugins. You can literally just, you know, do a block where you write your shell command and get it working, and then decide if, for plugins for you. Um, I think it's always under important to understand what is going on under the hood before you, before you adopt the magic of a plugin, because, um, once you have a problem, if you're, if it's all a lockbox to you, it's going to be more difficult to troubleshoot. It's kind of like learning, get command line versus like get cracking or something. Once, once you get in a bind, if you don't understand the underlying steps, it's really hard to get yourself out of a bind, versus if you understand what the plugin or the app is doing, then, um, you can get out of situations a lot easier. That's a good place. That's, that's where I'd start. >>Yeah. Thank you. Um, Camden asks better to build test environment images, every commit in CII. So this is like one of those opinions of we're all gonna have some different, uh, or build on build images on every commit, leveraging the cash, or build them once outside the test pile pipeline. Um, what say you people? >>Uh, well, I I've seen both and generally speaking, my preference is, um, I guess the ant, the it's a consultant answer, right? I think it depends on what you're trying to do, right. So if you have a lot of small changes that are being made and you're creating images for each of those commits, you're going to have a lot of images in your, in your registry, right? And on top of that, if you're building those images, uh, through CAI frequently, if you're using Docker hub or something like that, you might run into rate limiting issues because of Docker's new rate, limiting, uh, rate limits that they put in place. Um, but that might be beneficial if the, if being able to roll back between those small changes while you're testing is important to you. Uh, however, if all you care about is being able to use Docker images, um, or being able to correlate versions to your Docker images, or if you're the type of team that doesn't even use him, uh, does he even use, uh, virgins in your image tags? Then I would think that that might be a little, much you might want to just have in your CIO. You might want to have a stage that builds your Docker images and Docker image and pushes it into your registry, being done first particular branches instead of having to be done on every commit regardless of branch. But again, it really depends on the team. It really depends on what you're building. It really depends on your workflow. It can depend on a number of things like a curse sometimes too. Yeah. Yeah. >>Once had two points here, you know, I've seen, you know, the pattern has been at every, with every, uh, uh, commit, assuming that you have the right set of tests that would kind of, uh, you would benefit from actually seeing, um, the, the, the, the testing workflow go through and can detect any issue within, within the build or whatever you're trying to test against. But if you're just a building without the appropriate set of tests, then you're just basically consuming almond, adding time, as well as all the, the image, uh, stories associated with it without treaty reaping the benefit of, of, of this pattern. Uh, and the second point is, again, I think if you're, if you're going to end up doing a per commit, uh, definitely recommend having some type of, uh, uh, image purging, um, uh, and, and, and garbage collection process to ensure that you're not just wasting, um, all the stories needed and also, um, uh, optimizing your, your bill process, because that will end up being the most time-consuming, um, um, you know, within, within your pipeline. So this is my 2 cents on this. >>Yeah, that's good stuff. I mean, those are both of those are conversations that could lead us into the rabbit hole for the rest of the day on storage management, uh, you know, CP CPU minutes for, uh, you know, your build stuff. I mean, if you're in any size team, more than one or two people, you immediately run into headaches with cost of CIA, because we have now the problem of tools, right? We have so many tools. We can have the CIS system burning CPU cycles all day, every day, if we really wanted to. And so you re very quickly, I think, especially if you're on every commit on every branch, like that gets you into a world of cost mitigation, and you probably are going to have to settle somewhere in the middle on, uh, between the budget, people that are saying you're spending way too much money on the CII platform, uh, because of all these CPU cycles, and then the developers who would love to have everything now, you know, as fast as possible and the biggest, biggest CPU's, and the biggest servers, and have the bills, because the bills can never go fast enough, right. >>There's no end to optimizing your build workflow. Um, we have another question on that. This is another topic that we'll all probably have different takes on is, uh, basically, uh, version tags, right? So on images, we, we have a very established workflow in get for how we make commits. We have commit shots. We have, uh, you know, we know get tags and there's all these things there. And then we go into images and it's just this whole new world that's opened up. Like there's no real consensus. Um, so what, what are your thoughts on the strategy for teams in their image tag? Again, another, another culture thing. Um, commander, >>I mean, I'm a fan of silver when we have no other option. Um, it's just clean and I like the timestamp, you know, exactly when it was built. Um, I don't really see any reason to use another, uh, there's just normal, incremental, um, you know, numbering, but I love the fact that you can pull any tag and know exactly when it was created. So I'm a big fan of bar, if you can make that work for your organization. >>Yep. People are mentioned that in chat, >>So I like as well. Uh, I'm a big fan of it. I think it's easy to be able to just be as easy to be able to signify what a major changes versus a minor change versus just a hot fix or, you know, some or some kind of a bad fix. The problem that I've found with having teams adopt San Bernardo becomes answering these questions and being able to really define what is a major change, what is a minor change? What is a patch, right? And this becomes a bit of an overhead or not so much of an overhead, but, uh, uh, uh, a large concern for teams who have never done versioning before, or they never been responsible for their own versioning. Um, in fact, you know, I'm running into that right now, uh, with, with a client that I'm working with, where a lot, I'm working with a lot of teams, helping them move their applications from a legacy production environment into a new one. >>And in doing so, uh, versioning comes up because Docker images, uh, have tags and usually the tax correlate to versions, but some teams over there, some teams that I'm working with are only maintaining a script and others are maintaining a fully fledged JAK, three tier application, you know, with lots of dependencies. So telling the script, telling the team that maintains a script, Hey, you know, you should use somber and you should start thinking about, you know, what's major, what's my number what's patch. That might be a lot for them. And for someone or a team like that, I might just suggest using commit shots as your versions until you figure that out, or maybe using, um, dates as your version, but for the more for the team, with the larger application, they probably already know the answers to those questions. In which case they're either already using Sember or they, um, or they may be using some other version of the strategy and might be in December, might suit them better. So, um, you're going to hear me say, it depends a lot, and I'm just going to say here, it depends. Cause it really does. Carlos. >>I think you hit on something interesting beyond just how to version, but, um, when to consider it a major release and who makes those decisions, and if you leave it to engineers to version, you're kind of pushing business decisions down the pipe. Um, I think when it's a minor or a major should be a business decision and someone else needs to make that call someone closer to the business should be making that call as to when we want to call it major. >>That's a really good point. And I add some, I actually agree. Um, I absolutely agree with that. And again, it really depends on the team that on the team and the scope of it, it depends on the scope that they're maintaining, right? And so it's a business application. Of course, you're going to have a product manager and you're going to have, you're going to have a product manager who's going to want to make that call because that version is going to be out in marketing. People are going to use it. They're going to refer to and support calls. They're going to need to make those decisions. Sember again, works really, really well for that. Um, but for a team that's maintaining the scripts, you know, I don't know, having them say, okay, you must tell me what a major version is. It's >>A lot, but >>If they want it to use some birds great too, which is why I think going back to what you originally said, Sember in the absence of other options. I think that's a good strategy. >>Yeah. There's a, there's a, um, catching up on chat. I'm not sure if I'm ever going to catch up, but there's a lot of people commenting on their favorite CII systems and it's, and it, it just goes to show for the, the testing and deployment community. Like how many tools there are out there, how many tools there are to support the tools that you're using. Like, uh, it can be a crazy wilderness. And I think that's, that's part of the art of it, uh, is that these things are allowing us to build our workflows to the team's culture. Um, and, uh, but I do think that, you know, getting into like maybe what we hope to be at what's next is I do hope that we get to, to try to figure out some of these harder problems of consistency. Uh, one of the things that led me to Docker at the beginning to begin with was the fact that it wa it created a consistent packaging solution for me to get my code, you know, off of, off of my site of my local system, really, and into the server. >>And that whole workflow would at least the thing that I was making at each step was going to be the same thing used. Right. And that, that was huge. Uh, it was also, it also took us a long time to get there. Right. We all had to, like Docker was one of those ones that decade kind of ideas of let's solidify the, enter, get the consensus of the community around this idea. And we, and it's not perfect. Uh, you know, the Docker Docker file is not the most perfect way to describe how to make your app, but it is there and we're all using it. And now I'm looking for that next piece, right. Then hopefully the next step in that, um, that where we can all arrive at a consensus so that once you hop teams, you know, okay. We all knew Docker. We now, now we're all starting to get to know the manifests, but then there's this big gap in the middle where it's like, it might be one of a dozen things. Um, you know, so >>Yeah, yeah. To that, to that, Brett, um, you know, uh, just maybe more of a shameless plug here and wanting to kind of talk about one of the things that I'm on. So excited, but I work, I work at Tasha Corp. I don't know anyone, or I don't know if many people have heard of, um, you know, we tend to focus a lot on workflows versus technologies, right. Because, you know, as you can see, even just looking at the chat, there's, you know, ton of opinions on the different tooling, right. And, uh, imagine having, you know, I'm working with clients that have 10,000 developers. So imagine taking the folks in the chat and being partnered with one organization or one company and having to make decisions on how to build software. Um, but there's no way you can conversion one or, or one way or one tool, uh, and that's where we're facing in the industry. >>So one of the things that, uh, I'm pretty excited about, and I don't know if it's getting as much traction as you know, we've been focused on it. This is way point, which is a project, an open source project. I believe we got at least, uh, last year, um, which is, it's more of, uh, it's, it is aim to address that really, uh, uh, Brad set on, you know, to come to tool to, uh, make it extremely easy and simple. And, you know, to describe how you want to build, uh, deploy or release your application, uh, in, in a consistent way, regardless of the tools. So similar to how you can think of Terraform and having that pluggability to say Terraform apply or plan against any cloud infrastructure, uh, without really having to know exactly the details of how to do it, uh, this is what wave one is doing. Um, and it can be applied with, you know, for the CIA, uh, framework. So, you know, task plugability into, uh, you know, circle CEI tests to Docker helm, uh, Kubernetes. So that's the, you know, it's, it's a hard problem to solve, but, um, I'm hopeful that that's the path that we're, you know, we'll, we'll eventually get to. So, um, hope, you know, you can, you can, uh, see some of the, you know, information, data on it, on, on HashiCorp site, but I mean, I'm personally excited about it. >>Yeah. Uh I'm to gonna have to check that out. And, um, I told you on my live show, man, we'll talk about it, but talk about it for a whole hour. Uh, so there's another question here around, uh, this, this is actually a little bit more detailed, but it is one that I think a lot of people deal with and I deal with a lot too, is essentially the question is from Cameron, uh, D essentially, do you use compose in your CIO or not Docker compose? Uh, because yes I do. Yeah. Cause it, it, it, it solves so many problems am and not every CGI can, I don't know, there's some problems with a CIO is trying to do it for me. So there are pros and cons and I feel like I'm still on the fence about it because I use it all the time, but also it's not perfect. It's not always meant for CIA. And CIA sometimes tries to do things for you, like starting things up before you start other parts and having that whole order, uh, ordering problem of things anyway. W thoughts and when have thoughts. >>Yes. I love compose. It's one of my favorite tools of all time. Um, and the reason why it's, because what I often find I'm working with teams trying to actually let me walk that back, because Jack on the chat asked a really interesting question about what, what, what the hardest thing about CIS for a lot of teams. And in my experience, the hardest thing is getting teams to build an app that is the same app as what's built in production. A lot of CGI does things that are totally different than what you would do in your local, in your local dev. And as a result of that, you get, you got this application that either doesn't work locally, or it does work, but it's a completely different animal than what you would get in production. Right? So what I've found in trying to get teams to bridge that gap by basically taking their CGI, shifting the CII left, I hate the shift left turn, but I'll use it. >>I'm shifting the CIO left to your local development is trying to say, okay, how do we build an app? How do we, how do we build mot dependencies of that app so that we can build so that we can test our app? How do we run tests, right? How do we build, how do we get test data? And what I found is that trying to get teams to do all this in Docker, which is normally a first for a lot of teams that I'm working with, trying to get them all to do all of this. And Docker means you're running Docker, build a lot running Docker, run a lot. You're running Docker, RM a lot. You ran a lot of Docker, disparate Docker commands. And then on top of that, trying to bridge all of those containers together into a single network can be challenging without compose. >>So I like using a, to be able to really easily categorize and compartmentalize a lot of the things that are going to be done in CII, like building a Docker image, running tests, which is you're, you're going to do it in CII anyway. So running tests, building the image, pushing it to the registry. Well, I wouldn't say pushing it to the registry, but doing all the things that you would do in local dev, but in the same network that you might have a mock database or a mock S3 instance or some of something else. Um, so it's just easy to take all those Docker compose commands and move them into your Yammel file using the hub actions or your dankest Bob using Jenkins, or what have you. Right. It's really, it's really portable that way, but it doesn't work for every team. You know, for example, if you're just a team that, you know, going back to my script example, if it's a really simple script that does one thing on a somewhat routine basis, then that might be a lot of overhead. Um, in that case, you know, you can get away with just Docker commands. It's not a big deal, but the way I looked at it is if I'm, if I'm building, if I build something that's similar to a make bile or rate file, or what have you, then I'm probably gonna want to use Docker compose. If I'm working with Docker, that's, that's a philosophy of values, right? >>So I'm also a fan of Docker compose. And, um, you know, to your point, Carlos, the whole, I mean, I'm also a fan of shifting CEI lift and testing lift, but if you put all that logic in your CTI, um, it changes the L the local development experience from the CGI experience. Versus if you put everything in a compose file so that what you build locally is the same as what you build in CGI. Um, you're going to have a better experience because you're going to be testing something more, that's closer to what you're going to be releasing. And it's also very easy to look at a compose file and kind of, um, understand what the dependencies are and what's happening is very readable. And once you move that stuff to CGI, I think a lot of developers, you know, they're going to be intimidated by the CGI, um, whatever the scripting language is, it's going to be something they're going to have to wrap their head around. >>Um, but they're not gonna be able to use it locally. You're going to have to have another local solution. So I love the idea of a composed file use locally, um, especially if he can Mount the local workspace so that they can do real time development and see their changes in the exact same way as it's going to be built and tested in CGI. It gives developers a high level of confidence. And then, you know, you're less likely to have issues because of discrepancies between how it was built in your local test environment versus how it's built in NCI. And so Docker compose really lets you do all of that in a way that makes your solution more portable, portable between local dev and CGI and reduces the number of CGI cycles to get, you know, the test, the test data that you need. So that's why I like it for really, for local dev. >>It'll be interesting. Um, I don't know if you all were able to see the keynote, but there was a, there was a little bit, not a whole lot, but a little bit talk of the Docker, compose V two, which has now built into the Docker command line. And so now we're shifting from the Python built compose, which was a separate package. You could that one of the challenges was getting it into your CA solution because if you don't have PIP and you got down on the binary and the binary wasn't available for every platform and, uh, it was a PI installer. It gets a little nerdy into how that works, but, uh, and the team is now getting, be able to get unified with it. Now that it's in Golang and it's, and it's plugged right into the Docker command line, it hopefully will be easier to distribute, easier to, to use. >>And you won't have to necessarily have dependencies inside of where you're running it because there'll be a statically compiled binary. Um, so I've been playing with that, uh, this year. And so like training myself to do Docker going from Docker dash compose to Docker space, compose. It is a thing I I'm almost to the point of having to write a shell replacement. Yeah. Alias that thing. Um, but, um, I'm excited to see what that's going, cause there's already new features in it. And it, these built kit by default, like there's all these things. And I, I love build kit. We could make a whole session on build kit. Um, in fact there's actually, um, maybe going on right now, or right around this time, there is a session on, uh, from Solomon hikes, the seat, uh, co-founder of Docker, former CTO, uh, on build kit using, uh, using some other tool on top of build kit or whatever. >>So that, that would be interesting for those of you that are not watching that one. Cause you're here, uh, to do a check that one out later. Um, all right. So another good question was caching. So another one, another area where there is no wrong answers probably, and everyone has a different story. So the question is, what are your thoughts on CII build caching? There's often a debate between security. This is from Quentin. Thank you for this great question. There's often a debate between security reproducibility and build speeds. I haven't found a good answer so far. I will just throw my hat in the ring and say that the more times you want to build, like if you're trying to build every commit or every commit, if you're building many times a day, the more caching you need. So like the more times you're building, the more caching you're gonna likely want. And in most cases caching doesn't bite you in the butt, but that could be, yeah, we, can we get the bit about that? So, yeah. Yeah. >>I'm going to quote Carlos again and say, it depends on, on, you know, how you're talking, you know, what you're trying to build and I'm quoting your colors. Um, yeah, it's, it's got, it's gonna depend because, you know, there are some instances where you definitely want to use, you know, depends on the frequency that you're building and how you're building. Um, it's you would want to actually take advantage of cashing functionalities, um, for the build, uh, itself. Um, but if, um, you know, as you mentioned, there could be some instances where you would want to disable, um, any caching because you actually want to either pull a new packages or, um, you know, there could be some security, um, uh, disadvantages related to security aspects that would, you know, you know, using a cache version of, uh, image layer, for example, could be a problem. And you, you know, if you have a fleet of build, uh, engines, you don't have a good grasp of where they're being cashed. We would have to, um, disable caching in that, in that, um, in those instances. So it, it would depend. >>Yeah, it's, it's funny you have that problem on both sides of cashing. Like there are things that, especially in Docker world, they will cash automatically. And, and then, and then you maybe don't realize that some of that caching could be bad. It's, it's actually using old, uh, old assets, old artifacts, and then there's times where you would expect it to cash, that it doesn't cash. And then you have to do something extra to enable that caching, especially when you're dealing with that cluster of, of CIS servers. Right. And the cloud, the whole clustering problem with caching is even more complex, but yeah, >>But that's, that's when, >>Uh, you know, ever since I asked you to start using build kits and able to build kit, you know, between it's it's it's reader of Boston in, in detecting word, you know, where in, in the bill process needs to cash, as well as, uh, the, the, um, you know, the process. I don't think I've seen any other, uh, approach there that comes close to how efficient, uh, that process can become how much time it can actually save. Uh, but again, I think, I think that's, for me that had been my default approach, unless I actually need something that I would intentionally to disable caching for that purpose, but the benefits, at least for me, the benefits of, um, how bill kit actually been processing my bills, um, from the builds as well as, you know, using the cash up until, you know, how it detects the, the difference in, in, in the assets within the Docker file had been, um, you know, uh, pretty, you know, outweigh the disadvantages that it brings in. So it, you know, take it each case by case. And based on that, determine if you want to use it, but definitely recommend those enabling >>In the absence of a reason not to, um, I definitely think that it's a good approach in terms of speed. Um, yeah, I say you cash until you have a good reason not to personally >>Catch by default. There you go. I think you catch by default. Yeah. Yeah. And, uh, the trick is, well, one, it's not always enabled by default, especially when you're talking about cross server. So that's a, that's a complexity for your SIS admins, or if you're on the cloud, you know, it's usually just an option. Um, I think it also is this, this veers into a little bit of, uh, the more you cash the in a lot of cases with Docker, like the, from like, if you're from images and checked every single time, if you're not pinning every single thing, if you're not painting your app version, you're at your MPN versions to the exact lock file definition. Like there's a lot of these things where I'm I get, I get sort of, I get very grouchy with teams that sort of let it, just let it all be like, yeah, we'll just build two images and they're totally going to have different dependencies because someone happened to update that thing and after whatever or MPM or, or, and so I get grouchy about that, cause I want to lock it all down, but I also know that that's going to create administrative burden. >>Like the team is now going to have to manage versions in a very much more granular way. Like, do we need to version two? Do we need to care about curl? You know, all that stuff. Um, so that's, that's kind of tricky, but when you get to, when you get to certain version problems, uh, sorry, uh, cashing problems, you, you, you don't want those set those caches to happen because it, if you're from image changes and you're not constantly checking for a new image, and if you're not pinning that V that version, then now you, you don't know whether you're getting the latest version of Davion or whatever. Um, so I think that there's, there's an art form to the more you pen, the less you have, the less, you have to be worried about things changing, but the more you pen, the, uh, all your versions of everything all the way down the stack, the more administrative stuff, because you're gonna have to manually change every one of those. >>So I think it's a balancing act for teams. And as you mature, I to find teams, they tend to pin more until they get to a point of being more comfortable with their testing. So the other side of this argument is if you trust your testing, then you, and you have better testing to me, the less likely to the subtle little differences in versions have to be penned because you can get away with those minor or patch level version changes. If you're thoroughly testing your app, because you're trusting your testing. And this gets us into a whole nother rant, but, uh, yeah, but talking >>About penny versions, if you've got a lot of dependencies isn't that when you would want to use the cash the most and not have to rebuild all those layers. Yeah. >>But if you're not, but if you're not painting to the exact patch version and you are caching, then you're not technically getting the latest versions because it's not checking for all the time. It's a weird, there's a lot of this subtle nuance that people don't realize until it's a problem. And that's part of the, the tricky part of allow this stuff, is it, sometimes the Docker can be almost so much magic out of the box that you, you, you get this all and it all works. And then day two happens and you built it a second time and you've got a new version of open SSL in there and suddenly it doesn't work. Um, so anyway, uh, that was a great question. I've done the question on this, on, uh, from heavy. What do you put, where do you put testing in your pipeline? Like, so testing the code cause there's lots of types of testing, uh, because this pipeline gets longer and longer and Docker building images as part of it. And so he says, um, before staging or after staging, but before production, where do you put it? >>Oh man. Okay. So, um, my, my main thought on this is, and of course this is kind of religious flame bait, so sure. You know, people are going to go into the compensation wrong. Carlos, the boy is how I like to think about it. So pretty much in every stage or every environment that you're going to be deploying your app into, or that your application is going to touch. My idea is that there should be a build of a Docker image that has all your applications coded in, along with its dependencies, there's testing that tests your application, and then there's a deployment that happens into whatever infrastructure there is. Right. So the testing, they can get tricky though. And the type of testing you do, I think depends on the environment that you're in. So if you're, let's say for example, your team and you have, you have a main branch and then you have feature branches that merged into the main branch. >>You don't have like a pre-production branch or anything like that. So in those feature branches, whenever I'm doing CGI that way, I know when I freak, when I cut my poll request, that I'm going to merge into main and everything's going to work in my feature branches, I'm going to want to probably just run unit tests and maybe some component tests, which really, which are just, you know, testing that your app can talk to another component or another part, another dependency, like maybe a database doing tests like that, that don't take a lot of time that are fascinating and right. A lot of would be done at the beach branch level and in my opinion, but when you're going to merge that beach branch into main, as part of a release in that activity, you're going to want to be able to do an integration tasks, to make sure that your app can actually talk to all the other dependencies that it talked to. >>You're going to want to do an end to end test or a smoke test, just to make sure that, you know, someone that actually touches the application, if it's like a website can actually use the website as intended and it meets the business cases and all that, and you might even have testing like performance testing, low performance load testing, or security testing, compliance testing that would want to happen in my opinion, when you're about to go into production with a release, because those are gonna take a long time. Those are very expensive. You're going to have to cut new infrastructure, run those tests, and it can become quite arduous. And you're not going to want to run those all the time. You'll have the resources, uh, builds will be slower. Uh, release will be slower. It will just become a mess. So I would want to save those for when I'm about to go into production. Instead of doing those every time I make a commit or every time I'm merging a feature ranch into a non main branch, that's the way I look at it, but everything does a different, um, there's other philosophies around it. Yeah. >>Well, I don't disagree with your build test deploy. I think if you're going to deploy the code, it needs to be tested. Um, at some level, I mean less the same. You've got, I hate the term smoke tests, cause it gives a false sense of security, but you have some mental minimum minimal amount of tests. And I would expect the developer on the feature branch to add new tests that tested that feature. And that would be part of the PR why those tests would need to pass before you can merge it, merge it to master. So I agree that there are tests that you, you want to run at different stages, but the earlier you can run the test before going to production. Um, the fewer issues you have, the easier it is to troubleshoot it. And I kind of agree with what you said, Carlos, about the longer running tests like performance tests and things like that, waiting to the end. >>The only problem is when you wait until the end to run those performance tests, you kind of end up deploying with whatever performance you have. It's, it's almost just an information gathering. So if you don't run your performance test early on, um, and I don't want to go down a rabbit hole, but performance tests can be really useless if you don't have a goal where it's just information gap, uh, this is, this is the performance. Well, what did you expect it to be? Is it good? Is it bad? They can get really nebulous. So if performance is really important, um, you you're gonna need to come up with some expectations, preferably, you know, set up the business level, like what our SLA is, what our response times and have something to shoot for. And then before you're getting to production. If you have targets, you can test before staging and you can tweak the code before staging and move that performance initiative. Sorry, Carlos, a little to the left. Um, but if you don't have a performance targets, then it's just a check box. So those are my thoughts. I like to test before every deployment. Right? >>Yeah. And you know what, I'm glad that you, I'm glad that you brought, I'm glad that you brought up Escalades and performance because, and you know, the definition of performance says to me, because one of the things that I've seen when I work with teams is that oftentimes another team runs a P and L tests and they ended, and the development team doesn't really have too much insight into what's going on there. And usually when I go to the performance team and say, Hey, how do you run your performance test? It's usually just a generic solution for every single application that they support, which may or may not be applicable to the application team that I'm working with specifically. So I think it's a good, I'm not going to dig into it. I'm not going to dig into the rabbit hole SRE, but it is a good bridge into SRE when you start trying to define what does reliability mean, right? >>Because the reason why you test performance, it's test reliability to make sure that when you cut that release, that customers would go to your site or use your application. Aren't going to see regressions in performance and are not going to either go to another website or, you know, lodge in SLA violation or something like that. Um, it does, it does bridge really well with defining reliability and what SRE means. And when you have, when you start talking about that, that's when you started talking about how often do I run? How often do I test my reliability, the reliability of my application, right? Like, do I have nightly tasks in CGI that ensure that my main branch or, you know, some important branch I does not mean is meeting SLA is meeting SLR. So service level objectives, um, or, you know, do I run tasks that ensure that my SLA is being met in production? >>Like whenever, like do I use, do I do things like game days where I test, Hey, if I turn something off or, you know, if I deploy this small broken code to production and like what happens to my performance? What happens to my security and compliance? Um, you can, that you can go really deep into and take creating, um, into creating really robust tests that cover a lot of different domains. But I liked just using build test deploy is the overall answer to that because I find that you're going to have to build your application first. You're going to have to test it out there and build it, and then you're going to want to deploy it after you test it. And that order generally ensures that you're releasing software. That works. >>Right. Right. Um, I was going to ask one last question. Um, it's going to have to be like a sentence answer though, for each one of you. Uh, this is, uh, do you lint? And if you lint, do you lent all the things, if you do, do you fail the linters during your testing? Yes or no? I think it's going to depend on the culture. I really do. Sorry about it. If we >>Have a, you know, a hook, uh, you know, on the get commit, then theoretically the developer can't get code there without running Melinta anyway, >>So, right, right. True. Anyone else? Anyone thoughts on that? Linting >>Nice. I saw an additional question online thing. And in the chat, if you would introduce it in a multi-stage build, um, you know, I was wondering also what others think about that, like typically I've seen, you know, with multi-stage it's the most common use case is just to produce the final, like to minimize the, the, the, the, the, the image size and produce a final, you know, thin, uh, layout or thin, uh, image. Uh, so if it's not for that, like, I, I don't, I haven't seen a lot of, you know, um, teams or individuals who are actually within a multi-stage build. There's nothing really against that, but they think the number one purpose of doing multi-stage had been just producing the minimalist image. Um, so just wanted to kind of combine those two answers in one, uh, for sure. >>Yeah, yeah, sure. Um, and with that, um, thank you all for the great questions. We are going to have to wrap this up and we could go for another hour if we all had the time. And if Dr. Khan was a 24 hour long event and it didn't sadly, it's not. So we've got to make room for the next live panel, which will be Peter coming on and talking about security with some developer ex security experts. And I wanted to thank again, thank you all three of you for being here real quick, go around the room. Um, uh, where can people reach out to you? I am, uh, at Bret Fisher on Twitter. You can find me there. Carlos. >>I'm at dev Mandy with a Y D E N D Y that's me, um, >>Easiest name ever on Twitter, Carlos and DFW on LinkedIn. And I also have a LinkedIn learning course. So if you check me out on my LinkedIn learning, >>Yeah. I'm at Nicola Quebec. Um, one word, I'll put it in the chat as well on, on LinkedIn, as well as, uh, uh, as well as Twitter. Thanks for having us, Brett. Yeah. Thanks for being here. >>Um, and, and you all stay around. So if you're in the room with us chatting, you're gonna, you're gonna, if you want to go to see the next live panel, I've got to go back to the beginning and do that whole thing, uh, and find the next, because this one will end, but we'll still be in chat for a few minutes. I think the chat keeps going. I don't actually know. I haven't tried it yet. So we'll find out here in a minute. Um, but thanks you all for being here, I will be back a little bit later, but, uh, coming up next on the live stuff is Peter Wood security. Ciao. Bye.

>>Welcome back to the cubes coverage of dr khan 2021 virtual. I'm john for a host of the cube. Got a great cube segment here at Donnie Bergholz, VP of products at Docker Industry veterans, seeing all the ways of innovation now uh had a product that dr dani great to see you. >>It's great to see you again to john >>hey, great program this year, Dr khan almost pushing the envelope again. Just the world's changed significantly over the past few years in this past year has been pretty crazy last year were virtual at the beginning of the pandemic, the watershed moment. Dr khan 2020 you know, with virtual event and then share action packed keynote track, uh four tracks run share build accelerate, you got a cube track, you've got live hits. Uh, community rooms global, huge growth in the developer community around Docker Kubernetes is now well understood by everyone and the general consensus is everyone's in production with it moving like a fast train cloud natives at the center of the action coupons, very operational operators. Dr khan's very development focus. So this is a key developer event really in the CNC F cloud native world. What's going on the process? Give us the update? >>Yeah. And I think you made a fantastic point there, john which is the developer focus. Uh, I joined dr back in october of last year and one of the first things that I did was make sure that we were going out there listening to our customers, having a lot of fresh conversations with them and using those as the core product strategy as we were talking to customers. What we learned fell into three big buckets around building sharing and running modern applications. So we've used those to create our product strategy which is based on solving problems that our customers and developers using Docker care about rather than lot of product strategies that I've come across as an analyst and as a leader on the enterprise side, which are very much feature factory driven of like here's the thing we can ship it, what kind of shove it in your face and try and sell it to you. So I'm really excited about what we're doing a doctor by delivering things that are developers really care about based on problems that they have told us are really valuable to solve problems that when we win, we went together and so we're focused on helping developers really accelerate their application delivery. So what are we doing? There's so much stuff and you know, if you've seen the keynote already, you'll see more and more of that. We announced for really big things and a lot of smaller things as well, um things like uh doctor verified publisher program which brings more trusted content. Um the doctor deV environments that help teams collaborate more effectively, um dr desktop on apple silicon bringing environments to the latest and greatest of machines that everybody is trying to get ahold of. Especially now that cps are harder to come by. Uh uh as well as uh some of those little things like scoped personal access tokens, which makes it easier for people to use a Ci pipeline without having to give it full right privileges and be concerned that if they get hacked, if the sea acrobatic it's hacked, then they get hacked to we're trying to help them defend against those kinds of cases. >>It's funny you made me think of the eye with the apple silicon comment, the supply chain threats that you've seen in hardware. And even here I'm hearing the word kicked around just in the CTO of doctor used the word supply chain, software supply chain. So again, you bring up this idea of supply chain, you mentioned trust. I can almost see the dots connecting, you know, in real time out in the audience out there saying, okay, you've got trust supply chain hardware, software, containers, there's no perimeter and clouds. You have to have a kind of unit level security. This is kind of a big deal. Can you just unpack this trend? Because this is a security kind of anywhere kind of not going to use a buzzword, but like supply chain actually hits home here. Like talk about that. What? All wise all this means? >>Yeah, I think Doctor is in a really interesting position in terms of how development teams and enterprises are adopting it, because it's been around for long enough that enterprises have come to trust Docker and it's really gotten in there in a way that a lot of brand new technologies have not. And yet we're still pushing the boundaries of innovation at the same time. So when when we think about where dr fits in for developers, we've got dr official images, which are probably adopted the default for anything you're going to do in a container. You go and get a doctor official image and start doing it. But then what Right? You pulling a bunch of those, you start building applications, you start pulling other libraries, you build your own code on top, um, on your DEV environment where you're probably running doctor desktop to do so. And so we've got content coming from a trusted source, we've got dr running on the developer laptop and then we've got everything else like where else does it go from there? Uh, and so there's a ton of um, both problem and opportunity to help bring all that complex kind of spaghetti pipeline mess together and help provide people with the path of they can have confidence in while they're doing so. It's interesting because it's different for developers than it is for option. Security teams very, very different in terms of what they care about. >>So talk about the automation impact because I can see two things happening. One is the trusted environment, more containers everywhere. And then you have more developers coming on board. Right? So actually more people writing code, not just bots, machines and humans. So you have more people flooding in writing code, more containers everywhere that need to be trusted? What's the impact to the environment? What's the but how do you, how does develop experience get easier and simpler when that's happening? >>We see that as you get more and more content, The tail, the long tail continues to extend, right, more and more community generated third party content. People publishing their own applications on Docker hub and all across the Internet. And that makes the importance of being able to discover things that you can trust that you can incorporate without worrying about what might be there all the more important. So we've got dr official images today, we announced the doctor verified publisher program. All these are things that we're doing to try and make it easier for developers to find the good stuff to use it and not worry about it and just move on with their lives. >>What's your vision and what's your, what stalkers take on the collaboration aspect of coding? I think it's one of the key themes here. Where does that fit in? What's the story with collaboration? >>Yeah, we see this as an area that really has been left behind around the adoption of containers, the adoption of kubernetes, the focus has been so much on that pipeline and that path and production and production container orchestration where we watched the generation of kubernetes arise and most of the vendors in the space, we're doing some kind of top down infrastructure deal right selling to the VP of Ops or something along those lines. Um and so the development of those applications really was left by the wayside because that's not a problem that the VP of us cares about, but it's a very interesting problem as we think about dr being focused on developers now to help those teams collaborate because no application is built in a closet. Every single application that is built is built in partnership with other developers, with product managers, with designers, all these people who need to somehow work together to review not only the source code, but the application as a whole. >>What does the product? Um, Evolution looked like as Justin Cormack and I were talking about, you know, developer productivity, the simplification containers as a P. I. S. What is the, what is the priority? How, how do you look at that? Because the securities front and center and a variety of security partners here in the ecosystem. Where's the priorities on the road map? You can, if someone asked you, hey Donnie, what's the bottom line? What's the product strategy? >>Yeah, our priority is the team. First and foremost, it is not optimizing for the single developer, it is optimizing for that team working together effectively. We feel that that is a very underserved audience of that developer team as a unit. Um, if you look at everybody in the container space, like I said, they're all kind of focused on operations, production, cloud environments, not on that team. And so we see that as a great opportunity to solve really important problems that nobody else is doing a great job of solving today. >>I gotta ask you on the team formation is the general consensus. Also in a lot of my interviews here at dr khan and outside in the industry, is that the, the monolithic organization building monolithic applications certainly has been disrupted. Certainly the engineering teams now look like they're going to be into end workloads, full visibility and to end with an s sorry, on the team, everyone kind of built in these teams. We kind of platform engineering flexing in between. So you don't have that kind of like silent organization certainly has been discussed for well, but this seems to be the standard. Now, what's your take on this and is that what you mean by teams that could you share your view on how people are organizing teams? Because certainly get hub and a lot of other leaders are saying, yeah, we see the same way these teams have, you know, threaded leaders and or fully baked team members inside these teams. >>Yeah, we definitely see that team as a cross functional team. It's not, you know, your your old world, we might have been like, you've got the development team here, you've got the QA team here, you've got the operations team there. It's completely not that it's that team is it's got developers on it. If there are dedicated testers or software engineers and test their on it, if they need to have a devops person or an SRE there on it as well, it's all part of the same team and that team is building on top of the platforms that are exposed by other teams. And that's the big shift that I think has been in the works for probably a decade at this point has been that kind of rotation of responsibilities that you used to be, that DEV's owned the DEV environment and DEV test and ops owned Prod and everything about PROd and now it's much more that there are platforms that span every environment and there's a platform team responsible for each one of those components that delivers it in a self service way. And then there are teams that build on top of that that own their application all the way from development through to production, they support it there on call for it. This is how we work internally, our development teams in our product development teams, I should say, because they're cross functional, really take ownership for their applications and it's it's a super powerful imperative. It gives people the ability to iterate much more quickly by taking away a lot of those gatekeepers. And it's it's the same thing as a matter of fact, when I was at an enterprise before I joined dr it's the same thing we did. A big part of our strategy was creating these self service platforms so that product teams could move quickly. >>Remember I interviewed during the QB was awesome. Great concept. Go back to look at that tape. That's not exactly not tape, it's on disk, but Great. Great concept. Let me ask you one more question on that because one of the things that's clear that's coming out even in the university areas Engineering DeVOPS has now brought in much more of a focus of the SRE that used to be an ops role but now becomes becoming developer. I mean it's DEVOPS, as you said, it's been going on for a while over a decade now it's much more clear that this s. R. Re engineering role is key. So with that I've always thought Doctor and containers is a perfect integration tool capability. I mean why not? I mean that's one of the benefits of containers as you allow, you can contain arise things. So if you play out what you just said about the team's integration is huge. Talk about how you see that evolving as a product person. >>Yeah. I think as you say, the integration is huge. Um You know, one way that I look at it is that the application itself or the service itself is defined by either a container or a set of containers. Um And the product development team cares about what's inside of that set of containers up and to that container layer or that group of containers layer. Whether that's the doctor file with its containers. Docker compose those kinds of things and then there might be a platform team responsible for running a great kubernetes environment, whether they're using a cloud platform or in house and they care about everything outside of the containers, up to the containers as that interface. Uh So when we think about those focuses, like Docker is all about that application in words. Um And a lot of the more production oriented containers vendors are container outwards. So it's very different when we think about the kinds of problems we want to solve. It's about making that application definition really easy and portable and enabling a clean handoff to SRE teams who may be responsible for running that Apple product. >>You brought up trusted content, trusted containers, modern applications earlier. What does trusted containers mean to you? I mean that's I mean obviously means security built in but there's a lot of migration there with containers, containers coming in and out of clusters all the time. They're being orchestrated. They're being used with state and state stateless data. What does trusted content mean? >>No. Really, for us, the focus is an interesting one because when we think about building, sharing and running applications for developers, our run means we want to give developers are great interface into the production environment. We don't want to provide the production environment. And so some of those problems are ones we deeply care about where the developers are making sure that they've got a trusted, secure, verifiable path to get the content that they are incorporating into their app all the way to production or to a point of hand off. If there is a point of hand off, once it gets to production, it becomes the problem of different products and different vendors to make it really easy for those same enterprises to effectively secure that application and project. >>What does containers is as an A P. I mean that's just docker reference classic approach or is there a new definition to containers as a piece? Our container ap >>Yeah, I think the question becomes really interesting when you start thinking about what's inside of each one of those containers and how you might be able to use those as building blocks. Even thinking about trends that are on the rise, like Loco Noko development, how could you imagine incorporating containers or a service composed of a group of containers um, into one of those kinds of contexts to do so you have to have a clean ap that you can define and published in support of how a different component would interface with every one of those containers. What are the ports? What are the protocols? What are the formats? Every one of those things is important to creating an API >>So I gotta ask you don? T put you on the spot because you've been on many, many sides of the table, analyst Docker, you've been at an enterprise doing some hardcore devops. If I'm a customer out there and say I'm a classic main street enterprise. Hey Donnie, I'm putting my teams, we're kicking ass. We've been kicking the tires, been in the cloud pandemics, giving us a little lift, we know it to double down on, we feel good about where we're going. Um, but I got a couple clouds out there. I'm all in on one. I got another one going, but I'm going hybrid all the way. I don't even know what multi cloud is yet, but hybrid means edge and ultimately distributed computing. What do I do? What's the doctor Playbook, What do you, what do you say to me? How do you keep me calm and motivated? Yeah, >>I think, you know, the reality is like you say every company is going to be running in multiple different environments. Um It's probably not the same application in multiple environments and different apps and they've gotten to a place maybe accidentally as different business units are different functions started picking different clouds of their choice and getting them there. But in the end of it, like the company as a whole has to figure out how do I support that and how do I make it all work together effectively and deal with all the different, not just levels of expertise in these different environments, but the different levels of performance and latency to expect as you have applications that may need to run across all those, um you know, I used to work in the travel industry and you might have somebody trying to book a flight and that's but you know, bouncing across a cloud to a data center, to a different cloud, to a service provider and on back and you can imagine very quickly, how do you solve for those latency problems that we know are correlated to user experience and in an e commerce kind of context correlated with revenue because people balance if they can't get a good response, it's complicated. The fact is it's just it's a hard problem to solve. Um containers can definitely help solve part of that by providing a consistent platform that lets you take your applications from place to place. That lets you build a consistent set of expertise so that, you know, a container here is like a container, there is like a container over there um And work with those in a fairly consistent way. But there's always going to be differences. I think it's very dangerous to assume that because you have a container in multiple places, it's going to provide the same levels of guarantees. And we had a lot of these conversations back in the early 2010s when private cloud was really starting to pick up steam and we said Oh let's make compatible storage layers. Uh And it was true to a point you could provide api compatibility but you had to run as hard as you could to keep up with the changes and you couldn't provide the same level of resiliency, You couldn't provide the same level of data protection, you couldn't provide the same level of performance and global footprint and all those provide what what does the A. P. I mean to a developer using it. It's all of those things regardless of whether they're in an api spec somewhere. >>That's a great call out looking at the how things are moving so fast and you just got to keep up. It's almost like you want some peace, peace time kind of philosophy. So I gotta ask you as you look at the landscape again, you've got a unique perspective running product over a docker which puts you at the front lines and looking at the whole marketplace as as a whole cloud native. But you also been an analyst. I got to ask you what does success look like because as the world changes that it's not always obvious until you see it. And then you know that success and then some people are trying different approaches. How do you tell the winners from the losers or the better approaches versus the ones that struggle? Is there a pattern that you're seeing emerge from the pandemic as a team is a tech? What's the, what's the pattern of success that you see? Development teams and organizations deploying that's working and what's a sign of bad things? >>Yeah, I think, you know, one of the biggest patterns is the ability to iterate quickly and learn fast. You know, if there's nothing else that you can do, you just think about what are those basic principles that let you be Agile? Not as a development team. Agile is a company getting from those ideas and that customer feedback all the way through the loop. To build that thing, tested with your customers before you ship it, get it out there. Maybe you do some kind of a modern deployment practice to decrease your risk as you're doing so right. It's Canary, it's rolling, releases its blue green, all those things Right? How do you d risk, how do you experiment while you're doing so and how do you stay agile so that you're able to provide customer value as fast as possible? Almost every failure pattern that you see is one that happens because you're not listening to your customers effectively and often enough and you're not iterating quickly enough so you're building in a direction that is not what they wanted or needed, >>you know, looking at Dr khan 2021 this year, look at the calendar, the cube tracks in there, which I'm excited to do a bunch of coverage on. It's always fun. But you got the classic build share run, which is the ethos of Doctor, but you get a new track called accelerate, there is an acceleration coming out of the pandemic more than ever. Um it's been pretty cool. I mean you're seeing a lot more action in all areas but talk about the acceleration with containers and what you what you're seeing on the landscape side of the industry and how that's impacting customers. What specifically is this acceleration really all about? >>Yeah, when I think about what acceleration means to me, it's about how do you avoid building things, avoid finding things that you don't need to spend your time on? How can you pick things up? Incorporate those into your workflows, incorporate those into your applications that you don't have to build it yourself right, you can accelerate every time you want to accelerate. Its because somebody else built something that you can then reuse and build on top of whether its application components, whether that's SAs or apps, developer services, whether that's pre integrated pipelines. So you've already got plug ins and tools that work every one of those things as an accelerator, A lot of them are delivered by all kinds of different vendors all over the map. And so if they don't integrate well together, if there aren't open A. P. S, if there aren't pre integrated offerings, it's not gonna be an accelerator is gonna be exactly the opposite. It's going to be I want to get this thing in, let me bring in five or six different consulting teams to start trying to piece all this stuff together. Big, big slow down. So the pretty integrated solutions, the open A. P. S. Those are the kinds of things that really are going to accelerate people. >>I can't I can't agree with you more on this whole slowdown thing. And one of the hardest things to do is insert new team members are new kind of rules and process into kind of already accelerated momentum, which is hard. This is a hard new kind of a cloud native dynamic, which is scale and speed are critical, right? So it's one of those things that's actually benefit. But if you don't rein it in a little bit, how do you balance that? What's your advice to folks? This is, this is a common problem. I mean, it could get away from you. It's on one hand, but if you slow down too much, it's a gridlock and you, you misfire. What's your thoughts on this? >>Yeah, that, that balance of scale and speed. Um, and it definitely is a balance there. You know, I think there's always a danger of over architect ng for your current state of reality. Um, and you know, one of the things that I've learned over the years is, you've got to, you got to scale your process and scale your architecture to where you're at and where you're going to be soon, if you start Designing for five years, 10 years down the road, um it's going to slow you down in the short term and you might never get to where you thought you were going to be in five or 10 years. You've got to build for where you're at, built for where you're going soon, you're not gonna go for the future. And this is, it ties into these ideas like evolutionary architecture, like how do you build in a way that makes change easy because, you know, things are always going to change. Um, you know, some of the recent trends around things like project product playing so well to this, right? It's not like a project team comes together and builds the solution and then walks away and the solution works untouched for years or decades. Instead, it's it's that agile approach of is a product team there long lived. They own what they're building and they support it and they continue to enhance it, going forward to improve their ability to meet their customers needs over time. >>Yeah, and I think that's a super important point. The magical product team that just scales infinitely by itself while you're sleeping is different. Again, the team formation is an indicator of that. So, I think this whole agility going to the next level really is all about, you know, a series of these teams. Micro micro teams. Microservices, I mean, again, monolithic applications yielded monolithic organizations. >>Microservices >>brings in kind of this open source ethos, this new hate to use the term to Pizza team because it's an Amazonian thing, but it kind of applies here, Right? So you got to have these teams. I had to focus and to end and take ownership of that, whether it's product, platform or project at the end of the day, you're still serving customers. Final question for you on. Well, I got you here. I know end user experience you brought this up earlier. This is a huge important piece. I think last year, you and I talked about this briefly in our interview as developers come to the front lines of the business, some of them all don't have M B A. S and that always, you know, going to business school and some of the best engineers shouldn't go to business school in my opinion, But but you know, they have to learn the vernacular of complex topics, understand quality, get bring craft into the software more and more developers on the front lines closer and closer to the customer as they go direct. This is a huge change from just 5, 10 years ago. What's your thoughts on this? And what do you tell people when when they say hey donnie what how should I ah posture to the customer? What can I do to get better? What do you say to that? >>Yeah it's a great question. Um and it's one that I think a lot of companies are struggling to solve. How do we bring developers closer to the customers? And what does that mean? One of the things that we do regularly at Dr is we bring our developers along on customer interviews. So our product managers are constantly out there, you know kind of beating the virtual street, talking to developers talking to customers. Um and regularly they'll bring developers on the same team along. This is super valuable in helping our developers really build an understanding of the customers are building for, right. It may not even be about that specific thing that they're building on that one day. Um but it's about understanding the customer's needs and really making that something that is internalized in the way they think about how do they solve problems? How do they design solutions? How do they do? So in a way that is much more likely to resonate with the customers. Um Do they have an NBA? No, but where do you start? You gotta start somewhere? You start by bringing people into the conversation, so we don't expect them to lead an interview. We expect them to come along, learn and ask questions. And what happens so often is that people with, you know, the business in other companies might say yeah, developers, they're just these tech people will just like give him a set of requirements and they'll deliver stuff. Um but bring them along for the ride and letting them interact with the customers that are using their product is an amazing and exciting experience for developers. We hear consistently just super excited, treat back. >>It's clearly the trend. I mean one of the best, the best performing teams have the business and developers working together. It's really interesting phenomenon. I think it's going to change the makeup of taking that and to end approach to a whole nother level dani. Great to have you on. Great to see you final question. Um take a minute to put a plug in for the product team over there. What are you working on? What are you most excited about? Give a quick plug? >>You know, I am super excited about what we're doing in both trusted content and around team collaboration. Um I think both of those are just going to be amazing. Amazing opportunities to improve how developers are working on their microservices. It's so fragmented, it's so complicated that helping make that easier is going to be really important and valuable an area for development teams to focus on. >>Uh, Dr khan 2021 Virtual, Donnie Bergholz, VP of products and Dakar, good friend of the CUBA and the industry as well. Dani, thanks for that. Great insight and sharing some gems you drop there. Thanks. >>All right. Thank you. All >>right. Dr khan coverage I'm john for your host of the cube, The Cube track here at Dakar 2021 virtual. Thanks for watching. Mhm.

(upbeat music) >> Okay, welcome back to theCUBES's coverage of Dockercon 2021. I'm John Furrier, your host of theCUBE. We have Justin Cormack, CTO of Docker. Was also involved in the CNCF technical oversight and variety of other technical activities. Justin, great to see you. Thanks for coming on theCUBE Virtual this year, again, twice in a row and maybe next year will be in person but certainly hybrid, great to see you. >> Yeah, great to see you too. Yeah, in person would be nice one of these days, yes. >> Yeah, when we get real life back. It's almost there, I can feel it, but there's so much activity. One of the things that we've been talking about, certainly in theCUBE and even here at DockerCon, same story. The pandemic really hasn't truly impacted developer community, because most of the people have been working remotely and virtually for many, many decades. And if you think about just in the past 10 years, all the innovation in cloud has come from virtual teams, open-source softwares, always had good kind of governance and a democratization of kind of how it becomes built. So not a bit's been skipped during the pandemic. In fact, if anything supply chain of software development has increased. So- >> Yeah, I think that it's definitely true that open-source was really the place that pioneered remote working. And a lot of the work methods the people worked out to do open-source as in communication and things like that, were things that people have adopted. It's a slightly different community. I'd say open-source projects like meetings less than some other organizations, but there was definitely that pioneering thing. And a lot of the companies that started off remote first, were in open-source software, and they started off for those reasons as well because developers were already working like that, and they could just hire them and they could continue to work like that. >> Yeah, one of the upsides of all this is that people won't tolerate even zoom or in person meetings that just go on, 15, 30 minutes good call. Why do we have a meeting? What's the purpose? (faintly speaking) the way to go. Let's get into the developer community. One of the things I love about DockerCon this year 2021 is the envelopes being pushed again almost to another level, it's almost a new level, this next level of containers is bringing more innovation to the table and productivity and simplicity. Some of the same messages last year but now more than ever, stuff's going on. What are you hearing directly from the community? You talk to a lot of the developers out of the millions of developers in the Docker ecosystem. What are they saying now in 2021? What's going on in their mind? >> Yeah, I think it's an area... More and more people are using Docker, and they're using it every day and it's a change that's been going on, obviously for a while, but it begins to sort of, as it spreads, the kind of developers using Docker, so different from... When I started at Docker, coming up for six years ago, it was a very bleeding edge type thing for early adopters. Now it's everywhere, millions and millions of ordinary developers are using Docker every day. And the kinds of things that's telling us is, well, some of this stuff that we thought, well, five years ago was an amazing breakthrough and simplicity. Now that's on its own still too hard. One of the things I mentioned in my keynote was that, we're talking to developers who just primarily have been working windows all their life but more and more applications being shipped on Linux. And they using Linux containers, but they find Docker files really hard because they have really, Linux shell scrapes and not a windows developer doesn't know how to use a Linux shell script. And it's bringing it down to that next level of use where you can adopt these things more easily, the pitched to the kind of level of developer who is just thinking about their language, their APIs and they don't want to have to learn kind of lots of new things to do Docker. They'll learn some, but they really wanted to kind of integrate better into the environments they work in and help them more. We've been working on a lot of detailed instructions about like how to use Docker better with JavaScript and Python, because people have told us, be specific about these things, tell us exactly how I do make things work well with the way I'm doing things now. >> What is the big upside for containers for the folks watching? And last year, one of the most popular sessions was the one-on-one Peter McKay did, which was fascinating, packed with people. And the adoption of containers is going everywhere and enabling a lot of growth. What's the main message to these new developers that are coming on board to ecosystem. >> I think what's happening is that people are gradually, very slowly starting to think about containers in a different way. When we started, the question everyone kept asking was about containers and VMS, what's the difference? That question didn't really, kind of really address what the big fundamental changes that containers made to how people work was. I'd like to think about it in terms of the physical shipping containers, like people are concerned about like, can you escape from the box? Can I get out of a container? These kinds of questions. This is not really the important question about containers is kind of escape from the box. The question is, what does it enable you to build? The shipping container let us build the supply chains that let people build products and factories and things that would never have been possible without the ability to actually just ship things in a routine and predictable and reliable and secure way, getting that content and the things that come in the container and you actually work more effectively. And, so I think that now we're talking about like what's the effect of containers on the industry as a whole? What are the things that we can learn about repeatability and documentation and metadata and reliability, that we kind of talked about a little bit before, but these are becoming the important use cases for containers. Containers are really about, they're not about that kind of security and escape piece, there're about the content, the supply chain and your actual process of working. >> What do you, first of all, great call out on the security piece. I want to get that in a second. I think that's a killer one. You've mentioned supply chain, can you define software supply chain, and is that where the automation value comes in? Because a lot of people are talking about automation is improving the developer experience. So can you clarify quickly, what do you mean by the software supply chain? And is that where automation comes in? Am I getting that right? >> Yeah, so the software supply chain is really that process by which you get components of software to build your applications. Around 99% of companies are using open-source software to build applications. And the vast majority of the pieces of any modern application art consists mainly of open-source software and some tries source software, and some software that people are writing themselves. But you've got to get these components in, you've got to make sure that they're updated and scanned and they're reliable. And that's the software supply chain is that process for bringing in components that you're using to build your applications. And so, the way automation comes in, is just because there's so much of the software dealing with it manually is just difficult, and it's an ongoing process of build and test and CI and all those scanning and all those processes. And I think as software developers, we fundamentally know that the most valuable things are the things that we automate. They're the things that we do all the time and they're important. And that a lot of building a software is about building repeatable processes, rather than just doing things one by one, because we know that we have to keep updating software, we have to keep fixing bags, we have to keep improving software. And so you've got to be able to keep doing these things, and automation is what helps us do that. >> I was talking to Dana Lawson the VP of Engineering at GitHub, and she and I were chatting about this one topic. I want to get your thoughts on it, because she was definitely of the camp of automation helps with productivity. No doubt, check, double check there. The question I have for you is how do you see the impact on say the developer experience and innovation specifically? Because, okay, I can see the productivity, okay, something happens a bunch of times automated. Then you start thinking about supply chain, then you thought about developer experience and ultimately with Kubernetes around the corner, with the relationship with containers, you can see the cloud-native benefits from an innovation standpoint. Can you share your thoughts on the automation impact to experience for the developer and the innovation strategies they need? >> Well, I think that one of the ways we're trying to think about everything we do at Docker is that we should be helping build processes rather than helping you do something once, because, if you do something three times, you want to automate it, but what if the first time you did it, that could also build that automated process. And if it was, why isn't it as easy to make something automated as it is to do it once? There's no real reason why it shouldn't be. And I think that kind of... I was having a conversation with someone the other day about how they would... They had kind of reversed their thinking and they found that often it was easier to start with automation and harder to do things manually. And that's a kind of real reversal of that kind of role between automation and doing stuff run, so, and it's not how we think about it, but I think it's really interesting to think about that kind of thing, and how could we make automation really, really simple. >> Well, that's a great example when you have that kind of environment, and certainly the psychology is better to have automation but if everyone's saying it's hard to do manual, that means they're at some sort of scale, right? So scale matters, right? So as you start getting the SRE vibes going, and you start getting Cloud Scale in cloud-native apps, that's going to be cool. Now, the question I want to ask you, because while the other thing that's happening is more people are coming into open-source than ever before, not just young developers, but also end users. Not like the hardcore-end users, looking like classic enterprises are coming in. So as more developers come in and increase over the year, what does that mean for the experience for developers? Now you have, does that change it? How do you view that? Because as more developers come in, you have institutional knowledge, you have scale, you have learnings, what's your thoughts on on the impact as the population of developers increase? How does Docker view that? >> Yeah, now, I think it's really interesting trend. It's been very visible in CNCF for the last few years. We've been seeing a lot more active end-user, company's doing open-source. Spotify has been one of the examples with a backstage project they brought into CNCF and other areas where they work. And I think it's part of this growing trend that's really important to Docker, Docker is a bottom up technology adoption company. Developers are using Docker because it works for them and they love it. And developers are doing open-source in their companies because open-source works for them and they love it. And it works for their business as well. And whereas historically like the the model was, you would buy kind of large enterprise products, with big procurement deals that were often not what the developers wanted, but now you're getting developers saying, what we want to do is adopt these open-source projects, because we know how they work, we already understand that we know how to integrate them better into our processes. And I think it's that developer lad demand that's really important, and it's the kind of integration that developers want to do, the kind of products that they want to work with, because they understand them and love them, and they had targeted at developers and that's incredibly important. And I think that's very much where Docker's focused and we really want to... Open-source is of the core of everything we've always done. We've built with the open-source community, and we've kind of come from that kind of environment. And we built things that we love as developers and that other developers love. >> Talk about your thoughts on security. Obviously it's always built in from the beginning, Shift-Left is the ethos, day two operations, AI apps, whatever people want to call that. Post-deployment mode, security has to be at the center of this, containers can be a great solution and give some great flexibility for developers. Can you talk about your view and Docker view on the security posture and situation? >> Yeah, I think Shift-Left is incredibly important because just doing things late, everyone knows is the wrong thing from the point of view of productivity. But I think Shift-Left can just mean, ask the developers to do everything, which is really a bit too much. I think that sometimes things need to be shifted even further left than people have actually thought. So like, why are you expecting developers to scan components to see if they're allowed to use? If they should be using them or they should be updated, why hasn't that happened before the developer even gets there? I think there's a, I sorted my keynote about this whole piece, about trusted content. And it's really important that we really shift that even further left, so it's long before it gets to the developer, those things that are happening. Security, it's a huge area, of course, but it's very much, we need to help developers because security is non-obvious. I think the more you understand about security, the more you understand that it doesn't come naturally to people and they need to be helped with it, and they need to learn a lot about things in a way to, I found myself that, learning how to think like an attacker is a really important way of thinking about how to secure softwares, like what what would they do rather than just thinking about the normal kind of, oh, this works in the (faintly speaking) What happens if things go wrong? That you have to think about as well. So there's a lot of work to do to educate and help and build tools that help developers there. And it's been really good working with Snyk, cause they're a very developer focused security company, that's why we chose to work with them. Whereas historically, security companies have been very oriented towards kind of the operator side of it, not the development side, not the developer experience. And the other piece is really around supply chain security. That's just kind of a new security area. And it's very important from the container point of view, because one of the things containers let you do is really control the components that you're using to build applications and manage them better. And so we can really build tooling that helps you manage, that helps you understand what's in a container, helps you understand where it came from, how it was built and automate those processes and sign and authenticate them as well. And we've been working with CNCF on Nature V2, which is for signing revamp of the container signing process, because people really want to know who originated this container? Where did it come from? What did they say is in it? There's a lot of work about build up materials and composition analysis and all those things that you need to know about. What's in a container, and the... >> Everyone wants to know what's in a container. If you've got a Kubernetes cluster for instance, that's all highly secure and in comes a container, how do you know what the... There's no perimeter, right? So again, as you said, thinking like an attack vector there, you got to understand that, this is where the action is, right? This is where a lot of work's being done on this idea of always on security. You don't know when the container's coming in. during the run stage, you're running a business now, it's not just build and share, your running infrastructure. >> Absolutely, you really want full control about everything that goes into it, and you want to know where everything that you're running in production came from, and you pretty tired of this, and that's your end to end supply chain. It's everything from developer inputs through the build process and grow to production. And in production, understanding whether it needs to be updated and whether there's new discover vulnerabilities and whether it's being attacked and how that relates back to what came into it in the first place. >> Lot more intelligence, lot more monitoring. You guys are enabling all that I know it's cool. Great stuff. Hey, I want to get your thoughts on just what got you here on the calendar, looking at the DockerCon '21 event, and we're having a fun time here with, we're on theCUBE track, get the keynote track. But if you look at the sessions that's going on, you got, and I'll get your comment on this, cause it's really interesting how it's cleverly laid out this is. You've got the classic run share build and then you've got a track called accelerate, interesting metadata around these labels. Take us through, because this basically shows the maturation of containers. We already talked about the relationship, somewhat with Kubernetes, everyone kind of sees that direction clearly, but you got acceleration, which is a key new track, but run, share, build, what's your reaction to that? Share your observations of what the layout of those names and what it means to an enterprise and people building. >> Yeah, (faintly speaking) has been Docker's kind of motto for a long time. It kind of encapsulates that kind of process of like, the developer building application, the collaborative piece that's really important about sharing content in containers and then obviously putting into production because that's the aim. But, accelerate is incredibly important too. Developers are just being asked to do a lot. Everything is software, there's a lot of software, and a lot of software has to be created and we've got to make it easier to do this. And that kind of getting quickly from idea to business outcomes and results is what modern software teams are really driving at. And, I think we've really been focused this last year on what the team needs to succeed, and especially, small focused teams delivering business value. It's how we're structured internally as well and is how our customers, to a large extent are structured. And there's that kind of focus on accelerating those business outcomes and the feedback loops from your ideas to what the feedback that your customers give you at helping you understand that it's really important. >> Talk about final question for you in terms of the topic here, cloud, hybrid cloud, multicloud, this is, put multicloud asides more hype. Everyone has multiple clouds, but it speaks to the general distributed computing architecture when you talk about public cloud and on-premises cloud operations. So modern developers looking at that as, okay, distributed environment, edge, whatever you're going to call it. What's your view of Docker as it goes forward for the folks watching, who have experience with Docker, loved the vibe, loved the open-source, but now I've got to start thinking about putting the containers everywhere. What's the Docker pitch, so to speak, with a tech story that they should walk away with from you? What's the story, what's the pitch? >> Yeah, so containers everywhere has been a sort of emerging trend for a while, the last year or so. The whole Kubernetes at the edge thing has really exploded with people experimenting with lots and lots of different architectures for different kinds of environments at the edge. What's totally clear is that people want to be able to update software really easily at the edge the way you can in the cloud. We can't have the sort of, there's no point in shipping a modern piece of manufacturing equipment that you can't update the software on, because the software is how it works, more and more equipment is becoming very general purpose, people making general purpose robots, general purpose factories, general purpose everything which need to be specialized into the application they're going to run that week. And also people are getting more and more feedback and data and feedback from the data. So if you're building something that runs on a farm, you're getting permanent feedback about how well it's doing and how well the crops are growing was coming back. And so everywhere you've got this, we need to update. And everywhere you need to update, you want containers because containers are the simple reliable way to update software. >> I know you talked about CNCF and your role there. Also the CTO of Docker, I have to ask cause we were just covered Coop con and cloud-native con just last month and this month. And it's clear that Kubernetes is becoming boringly good in a way that's good to be boring, right? It means it's working. And it's becoming more cloud-native con than Coop-con. That has been kind of editorial observation, which speaks to what we feel is a trend towards more cloud-native discussions, less about Kubernetes. So, it's still Kubernetes stuff going on, don't get me wrong, just saying it's not as controversial in the sense that people kind of clearly understand why that's important, and all the discussions now seem to be on cloud-native modern developer workflows. What's your reaction to that? Do you agree, if not, what's your take? >> Yeah, I think that's definitely true. Kubernetes is definitely much more boring. Everyone is using it. They're using it in production now vastly more than they were a few years ago, when it was just experiment, experiment, experiment, now it's production scale out. The ecosystem in CNCF is kind of huge. There's so many little bits that have to be filled in storage and networking and all that. So there's actually a lot of pieces that are around Kubernetes, but, there's definitely more of a focus coming on the developer experience there. Compared to DockerCon, the audience at Coop Con is incarnated kind of still much more operator focused rather than developer focused. And it's very nice coming to DockerCon, just to feel like being amongst that developer community, Coop Con still has a way to gauge to have more of a real developer audience, but the project is starting to pair with a more developer focused kind of aim or things like backstage from Spotify is a really interesting one where it's about operations, but it's a developer portal focused things. So, I think it's happening, and there's a lot more talk about that. There's a whole bunch of infrastructure, there's a lot more security projects in CNCF than they were before. And we're doing a lot of work on supply chain security and CNCF just released a white paper on that few days ago. So there's a lot of work there that touches on developer needs. I still think that audience (faintly speaking) that much different from DockerCon which is I think 80% developers and maybe 10% infrastructure rather than the other way round. >> I think if you're going to get operators it can be SRE/platformleads. The platform leads are definitely inside DockerCon now than they've ever been before from my observation. So, but that speaks to the sign of the times. Most development teams have an SRE in the team, not an SRE team. They're just starting to see much more integration amongst the kind of a threaded or threaded teams or whatnot. So... >> Yeah. (faintly speaking) Operate your apps is the model. And I think that it's going to lead to more and more crossover between these communities. It's what DevOps was supposed to be about, somehow got diverted into building DevOps teams instead of working together, but we'll get there. >> It's clear from my standpoint, at least from reporting here is that, from the DockerCon and community at large, cloud-native community, having end-to-end work-load visibility on developer test run, everything seems to be the consensus, without a doubt. And then having multiple teams, and then having some platform, have some flexing people moving between teams for the most part, but built insecurity, built in SRE, built in DevOps, DevSecOps, all the way from end-to-end. >> Absolutely, we know that that's what does work best, it's where most organizations are heading at different speeds, because it's very different from the traditional architecture. It takes time to get there, but that's the model that has come out of microservices that really containers enabled and allow that model to happen. And it's the team architecture of containers. >> Hey, monolithic applications have monolithic organizations, microservices have microservices teams. Justin, great to have you on theCUBE for this conversation. If folks watching this interview, check out Justin's keynote, came from the main stage, great stuff. Justin, thanks for coming on theCUBE, we really appreciate your time and insight. >> Thank you, good to see you again. >> Okay, this is theCUBES's coverage of DockerCon 2021 Virtual. I'm John Furrier, your host. Thanks for watching. (upbeat music)

>>all right, We're five minutes after the hour. That's all aboard. Who's coming aboard? Welcome everyone to the tutorial track for our launchpad of them. So for the next couple of hours, we've got a SYRIZA videos and experts on hand to answer questions about our new product, Doctor Enterprise Container Cloud. Before we jump into the videos and the technology, I just want to introduce myself and my other emcee for the session. I'm Bill Milks. I run curriculum development for Mirant us on. And >>I'm Bruce Basil Matthews. I'm the Western regional Solutions architect for Moran Tissue esa and welcome to everyone to this lovely launchpad oven event. >>We're lucky to have you with us proof. At least somebody on the call knows something about your enterprise Computer club. Um, speaking of people that know about Dr Enterprise Container Cloud, make sure that you've got a window open to the chat for this session. We've got a number of our engineers available and on hand to answer your questions live as we go through these videos and disgusting problem. So that's us, I guess, for Dr Enterprise Container Cloud, this is Mirant asses brand new product for bootstrapping Doctor Enterprise Kubernetes clusters at scale Anything. The airport Abu's? >>No, just that I think that we're trying Thio. Uh, let's see. Hold on. I think that we're trying Teoh give you a foundation against which to give this stuff a go yourself. And that's really the key to this thing is to provide some, you know, many training and education in a very condensed period. So, >>yeah, that's exactly what you're going to see. The SYRIZA videos we have today. We're going to focus on your first steps with Dr Enterprise Container Cloud from installing it to bootstrapping your regional child clusters so that by the end of the tutorial content today, you're gonna be prepared to spin up your first documentary prize clusters using documented prize container class. So just a little bit of logistics for the session. We're going to run through these tutorials twice. We're gonna do one run through starting seven minutes ago up until I guess it will be ten fifteen Pacific time. Then we're gonna run through the whole thing again. So if you've got other colleagues that weren't able to join right at the top of the hour and would like to jump in from the beginning, ten. Fifteen Pacific time. We're gonna do the whole thing over again. So if you want to see the videos twice, you got public friends and colleagues that, you know you wanna pull in for a second chance to see this stuff, we're gonna do it all. All twice. Yeah, this session. Any any logistics I should add, Bruce that No, >>I think that's that's pretty much what we had to nail down here. But let's zoom dash into those, uh, feature films. >>Let's do Edmonds. And like I said, don't be shy. Feel free to ask questions in the chat or engineers and boosting myself are standing by to answer your questions. So let me just tee up the first video here and walk their cost. Yeah. Mhm. Yes. Sorry. And here we go. So our first video here is gonna be about installing the Doctor Enterprise Container Club Management cluster. So I like to think of the management cluster as like your mothership, right? This is what you're gonna use to deploy all those little child clusters that you're gonna use is like, Come on it as clusters downstream. So the management costs was always our first step. Let's jump in there >>now. We have to give this brief little pause >>with no good day video. Focus for this demo will be the initial bootstrap of the management cluster in the first regional clusters to support AWS deployments. The management cluster provides the core functionality, including identity management, authentication, infantry release version. The regional cluster provides the specific architecture provided in this case, eight of us and the Elsie um, components on the UCP Cluster Child cluster is the cluster or clusters being deployed and managed. The deployment is broken up into five phases. The first phase is preparing a big strap note on this dependencies on handling with download of the bridge struck tools. The second phase is obtaining America's license file. Third phase. Prepare the AWS credentials instead of the adduce environment. The fourth configuring the deployment, defining things like the machine types on the fifth phase. Run the bootstrap script and wait for the deployment to complete. Okay, so here we're sitting up the strap node, just checking that it's clean and clear and ready to go there. No credentials already set up on that particular note. Now we're just checking through AWS to make sure that the account we want to use we have the correct credentials on the correct roles set up and validating that there are no instances currently set up in easy to instance, not completely necessary, but just helps keep things clean and tidy when I am perspective. Right. So next step, we're just going to check that we can, from the bootstrap note, reach more antis, get to the repositories where the various components of the system are available. They're good. No areas here. Yeah, right now we're going to start sitting at the bootstrap note itself. So we're downloading the cars release, get get cars, script, and then next, we're going to run it. I'm in. Deploy it. Changing into that big struck folder. Just making see what's there. Right now we have no license file, so we're gonna get the license filed. Oh, okay. Get the license file through the more antis downloads site, signing up here, downloading that license file and putting it into the Carisbrook struck folder. Okay, Once we've done that, we can now go ahead with the rest of the deployment. See that the follow is there. Uh, huh? That's again checking that we can now reach E C two, which is extremely important for the deployment. Just validation steps as we move through the process. All right, The next big step is valid in all of our AWS credentials. So the first thing is, we need those route credentials which we're going to export on the command line. This is to create the necessary bootstrap user on AWS credentials for the completion off the deployment we're now running an AWS policy create. So it is part of that is creating our Food trucks script, creating the mystery policy files on top of AWS, Just generally preparing the environment using a cloud formation script you'll see in a second will give a new policy confirmations just waiting for it to complete. Yeah, and there is done. It's gonna have a look at the AWS console. You can see that we're creative completed. Now we can go and get the credentials that we created Today I am console. Go to that new user that's being created. We'll go to the section on security credentials and creating new keys. Download that information media Access key I D and the secret access key. We went, Yeah, usually then exported on the command line. Okay. Couple of things to Notre. Ensure that you're using the correct AWS region on ensure that in the conflict file you put the correct Am I in for that region? I'm sure you have it together in a second. Yes. Okay, that's the key. Secret X key. Right on. Let's kick it off. Yeah, So this process takes between thirty and forty five minutes. Handles all the AWS dependencies for you, and as we go through, the process will show you how you can track it. Andi will start to see things like the running instances being created on the west side. The first phase off this whole process happening in the background is the creation of a local kind based bootstrapped cluster on the bootstrap node that clusters then used to deploy and manage all the various instances and configurations within AWS. At the end of the process, that cluster is copied into the new cluster on AWS and then shut down that local cluster essentially moving itself over. Okay. Local clusters boat just waiting for the various objects to get ready. Standard communities objects here Okay, so we speed up this process a little bit just for demonstration purposes. Yeah. There we go. So first note is being built the best in host. Just jump box that will allow us access to the entire environment. Yeah, In a few seconds, we'll see those instances here in the US console on the right. Um, the failures that you're seeing around failed to get the I. P for Bastian is just the weight state while we wait for a W s to create the instance. Okay. Yes. Here, beauty there. Okay. Mhm. Okay. Yeah, yeah. Okay. On there. We got question. Host has been built on three instances for the management clusters have now been created. We're going through the process of preparing. Those nodes were now copying everything over. See that? The scaling up of controllers in the big Strap cluster? It's indicating that we're starting all of the controllers in the new question. Almost there. Yeah. Yeah, just waiting for key. Clark. Uh huh. Start to finish up. Yeah. No. What? Now we're shutting down control this on the local bootstrap node on preparing our I. D. C. Configuration. Fourth indication, soon as this is completed. Last phase will be to deploy stack light into the new cluster the last time Monitoring tool set way Go stack like to plan It has started. Mhm coming to the end of the deployment Mountain. Yeah, America. Final phase of the deployment. Onda, We are done. Okay, You'll see. At the end they're providing us the details of you. I log in so there's a keeper clogging. You can modify that initial default password is part of the configuration set up with one documentation way. Go Councils up way can log in. Yeah, yeah, thank you very much for watching. >>Excellent. So in that video are wonderful field CTO Shauna Vera bootstrapped up management costume for Dr Enterprise Container Cloud Bruce, where exactly does that leave us? So now we've got this management costume installed like what's next? >>So primarily the foundation for being able to deploy either regional clusters that will then allow you to support child clusters. Uh, comes into play the next piece of what we're going to show, I think with Sean O'Mara doing this is the child cluster capability, which allows you to then deploy your application services on the local cluster. That's being managed by the ah ah management cluster that we just created with the bootstrap. >>Right? So this cluster isn't yet for workloads. This is just for bootstrapping up the downstream clusters. Those or what we're gonna use for workings. >>Exactly. Yeah. And I just wanted to point out, since Sean O'Mara isn't around, toe, actually answer questions. I could listen to that guy. Read the phone book, and it would be interesting, but anyway, you can tell him I said that >>he's watching right now, Crusoe. Good. Um, cool. So and just to make sure I understood what Sean was describing their that bootstrap er knows that you, like, ran document fresh pretender Cloud from to begin with. That's actually creating a kind kubernetes deployment kubernetes and Docker deployment locally. That then hits the AWS a p i in this example that make those e c two instances, and it makes like a three manager kubernetes cluster there, and then it, like, copies itself over toe those communities managers. >>Yeah, and and that's sort of where the transition happens. You can actually see it. The output that when it says I'm pivoting, I'm pivoting from my local kind deployment of cluster AP, I toothy, uh, cluster, that's that's being created inside of AWS or, quite frankly, inside of open stack or inside of bare metal or inside of it. The targeting is, uh, abstracted. Yeah, but >>those air three environments that we're looking at right now, right? Us bare metal in open staff environments. So does that kind cluster on the bootstrap er go away afterwards. You don't need that afterwards. Yeah, that is just temporary. To get things bootstrapped, then you manage things from management cluster on aws in this example? >>Yeah. Yeah. The seed, uh, cloud that post the bootstrap is not required anymore. And there's no, uh, interplay between them after that. So that there's no dependencies on any of the clouds that get created thereafter. >>Yeah, that actually reminds me of how we bootstrapped doctor enterprise back in the day, be a temporary container that would bootstrap all the other containers. Go away. It's, uh, so sort of a similar, similar temporary transient bootstrapping model. Cool. Excellent. What will convict there? It looked like there wasn't a ton, right? It looked like you had to, like, set up some AWS parameters like credentials and region and stuff like that. But other than that, that looked like heavily script herbal like there wasn't a ton of point and click there. >>Yeah, very much so. It's pretty straightforward from a bootstrapping standpoint, The config file that that's generated the template is fairly straightforward and targeted towards of a small medium or large, um, deployment. And by editing that single file and then gathering license file and all of the things that Sean went through, um, that that it makes it fairly easy to script >>this. And if I understood correctly as well that three manager footprint for your management cluster, that's the minimum, right. We always insist on high availability for this management cluster because boy do not wanna see oh, >>right, right. And you know, there's all kinds of persistent data that needs to be available, regardless of whether one of the notes goes down or not. So we're taking care of all of that for you behind the scenes without you having toe worry about it as a developer. >>No, I think there's that's a theme that I think will come back to throughout the rest of this tutorial session today is there's a lot of there's a lot of expertise baked him to Dr Enterprise Container Cloud in terms of implementing best practices for you like the defaulter, just the best practices of how you should be managing these clusters, Miss Seymour. Examples of that is the day goes on. Any interesting questions you want to call out from the chap who's >>well, there was. Yeah, yeah, there was one that we had responded to earlier about the fact that it's a management cluster that then conduce oh, either the the regional cluster or a local child molester. The child clusters, in each case host the application services, >>right? So at this point, we've got, in some sense, like the simplest architectures for our documentary prize Container Cloud. We've got the management cluster, and we're gonna go straight with child cluster. In the next video, there's a more sophisticated architecture, which will also proper today that inserts another layer between those two regional clusters. If you need to manage regions like across a BS, reads across with these documents anything, >>yeah, that that local support for the child cluster makes it a lot easier for you to manage the individual clusters themselves and to take advantage of our observation. I'll support systems a stack light and things like that for each one of clusters locally, as opposed to having to centralize thumb >>eso. It's a couple of good questions. In the chat here, someone was asking for the instructions to do this themselves. I strongly encourage you to do so. That should be in the docks, which I think Dale helpfully thank you. Dale provided links for that's all publicly available right now. So just head on in, head on into the docks like the Dale provided here. You can follow this example yourself. All you need is a Mirante license for this and your AWS credentials. There was a question from many a hear about deploying this toe azure. Not at G. Not at this time. >>Yeah, although that is coming. That's going to be in a very near term release. >>I didn't wanna make promises for product, but I'm not too surprised that she's gonna be targeted. Very bracing. Cool. Okay. Any other thoughts on this one does. >>No, just that the fact that we're running through these individual pieces of the steps Well, I'm sure help you folks. If you go to the link that, uh, the gentleman had put into the chat, um, giving you the step by staff. Um, it makes it fairly straightforward to try this yourselves. >>E strongly encourage that, right? That's when you really start to internalize this stuff. OK, but before we move on to the next video, let's just make sure everyone has a clear picture in your mind of, like, where we are in the life cycle here creating this management cluster. Just stop me if I'm wrong. Who's creating this management cluster is like, you do that once, right? That's when your first setting up your doctor enterprise container cloud environment of system. What we're going to start seeing next is creating child clusters and this is what you're gonna be doing over and over and over again. When you need to create a cluster for this Deb team or, you know, this other team river it is that needs commodity. Doctor Enterprise clusters create these easy on half will. So this was once to set up Dr Enterprise Container Cloud Child clusters, which we're going to see next. We're gonna do over and over and over again. So let's go to that video and see just how straightforward it is to spin up a doctor enterprise cluster for work clothes as a child cluster. Undocumented brands contain >>Hello. In this demo, we will cover the deployment experience of creating a new child cluster, the scaling of the cluster and how to update the cluster. When a new version is available, we begin the process by logging onto the you I as a normal user called Mary. Let's go through the navigation of the U I so you can switch. Project Mary only has access to development. Get a list of the available projects that you have access to. What clusters have been deployed at the moment there. Nan Yes, this H Keys Associate ID for Mary into her team on the cloud credentials that allow you to create access the various clouds that you can deploy clusters to finally different releases that are available to us. We can switch from dark mode to light mode, depending on your preferences, Right? Let's now set up semester search keys for Mary so she can access the notes and machines again. Very simply, had Mississippi key give it a name, we copy and paste our public key into the upload key block. Or we can upload the key if we have the file available on our local machine. A simple process. So to create a new cluster, we define the cluster ad management nodes and add worker nodes to the cluster. Yeah, again, very simply, you go to the clusters tab. We hit the create cluster button. Give the cluster name. Yeah, Andi, select the provider. We only have access to AWS in this particular deployment, so we'll stick to AWS. What's like the region in this case? US West one release version five point seven is the current release Onda Attach. Mary's Key is necessary Key. We can then check the rest of the settings, confirming the provider Any kubernetes c r D r I p address information. We can change this. Should we wish to? We'll leave it default for now on. Then what components? A stack light I would like to deploy into my Custer. For this. I'm enabling stack light on logging on Aiken. Sit up the retention sizes Attention times on. Even at this stage, at any customer alerts for the watchdogs. E consider email alerting which I will need my smart host details and authentication details. Andi Slack Alerts. Now I'm defining the cluster. All that's happened is the cluster's been defined. I now need to add machines to that cluster. I'll begin by clicking the create machine button within the cluster definition. Oh, select manager, Select the number of machines. Three is the minimum. Select the instant size that I'd like to use from AWS and very importantly, ensure correct. Use the correct Am I for the region. I commend side on the route device size. There we go, my three machines obviously creating. I now need to add some workers to this custom. So I go through the same process this time once again, just selecting worker. I'll just add to once again, the AM is extremely important. Will fail if we don't pick the right, Am I for a boon to machine in this case and the deployment has started. We can go and check on the bold status are going back to the clusters screen on clicking on the little three dots on the right. We get the cluster info and the events, so the basic cluster info you'll see pending their listen cluster is still in the process of being built. We kick on, the events will get a list of actions that have been completed This part of the set up of the cluster. So you can see here we've created the VPC. We've created the sub nets on We've created the Internet gateway. It's unnecessary made of us and we have no warnings of the stage. Yeah, this will then run for a while. We have one minute past waken click through. We can check the status of the machine bulls as individuals so we can check the machine info, details of the machines that we've assigned, right? Mhm Onda. See any events pertaining to the machine areas like this one on normal? Yeah. Just watch asked. The community's components are waiting for the machines to start. Go back to Custer's. Okay, right. Because we're moving ahead now. We can see we have it in progress. Five minutes in new Matt Gateway on the stage. The machines have been built on assigned. I pick up the U. S. Thank you. Yeah. There we go. Machine has been created. See the event detail and the AWS. I'd for that machine. Mhm. No speeding things up a little bit. This whole process and to end takes about fifteen minutes. Run the clock forward, you'll notice is the machines continue to bold the in progress. We'll go from in progress to ready. A soon as we got ready on all three machines, the managers on both workers way could go on and we could see that now we reached the point where the cluster itself is being configured. Mhm, mhm. And then we go. Cluster has been deployed. So once the classes deployed, we can now never get around our environment. Okay, Are cooking into configure cluster We could modify their cluster. We could get the end points for alert alert manager on See here The griffon occupying and Prometheus are still building in the background but the cluster is available on you would be able to put workloads on it the stretch to download the cube conflict so that I can put workloads on it. It's again three little dots in the right for that particular cluster. If the download cube conflict give it my password, I now have the Q conflict file necessary so that I can access that cluster Mhm all right Now that the build is fully completed, we can check out cluster info on. We can see that Allow the satellite components have been built. All the storage is there, and we have access to the CPU. I So if we click into the cluster, we can access the UCP dashboard, right? Shit. Click the signing with Detroit button to use the SSO on. We give Mary's possible to use the name once again. Thing is, an unlicensed cluster way could license at this point. Or just skip it on. There. We have the UCP dashboard. You can see that has been up for a little while. We have some data on the dashboard going back to the console. We can now go to the griffon, a data just being automatically pre configured for us. We can switch and utilized a number of different dashboards that have already been instrumented within the cluster. So, for example, communities cluster information, the name spaces, deployments, nodes. Mhm. So we look at nodes. If we could get a view of the resource is utilization of Mrs Custer is very little running in it. Yeah. General dashboard of Cuba navies cluster one of this is configurable. You can modify these for your own needs, or add your own dashboards on de scoped to the cluster. So it is available to all users who have access to this specific cluster, all right to scale the cluster on to add a notice. A simple is the process of adding a mode to the cluster, assuming we've done that in the first place. So we go to the cluster, go into the details for the cluster we select, create machine. Once again, we need to be ensure that we put the correct am I in and any other functions we like. You can create different sized machines so it could be a larger node. Could be bigger disks and you'll see that worker has been added from the provisioning state on shortly. We will see the detail off that worker as a complete to remove a note from a cluster. Once again, we're going to the cluster. We select the node would like to remove. Okay, I just hit delete On that note. Worker nodes will be removed from the cluster using according and drawing method to ensure that your workouts are not affected. Updating a cluster. When an update is available in the menu for that particular cluster, the update button will become available. And it's a simple as clicking the button, validating which release you would like to update to. In this case, the next available releases five point seven point one. Here I'm kicking the update by in the background We will coordinate. Drain each node slowly go through the process of updating it. Andi update will complete depending on what the update is as quickly as possible. Girl, we go. The notes being rebuilt in this case impacted the manager node. So one of the manager nodes is in the process of being rebuilt. In fact, to in this case, one has completed already on In a few minutes we'll see that there are great has been completed. There we go. Great. Done. Yeah. If you work loads of both using proper cloud native community standards, there will be no impact. >>Excellent. So at this point, we've now got a cluster ready to start taking our communities of workloads. He started playing or APs to that costume. So watching that video, the thing that jumped out to me at first Waas like the inputs that go into defining this workload cost of it. All right, so we have to make sure we were using on appropriate am I for that kind of defines the substrate about what we're gonna be deploying our cluster on top of. But there's very little requirements. A so far as I could tell on top of that, am I? Because Docker enterprise Container Cloud is gonna bootstrap all the components that you need. That s all we have is kind of kind of really simple bunch box that we were deploying these things on top of so one thing that didn't get dug into too much in the video. But it's just sort of implied. Bruce, maybe you can comment on this is that release that Shawn had to choose for his, uh, for his cluster in creating it. And that release was also the thing we had to touch. Wanted to upgrade part cluster. So you have really sharp eyes. You could see at the end there that when you're doing the release upgrade enlisted out a stack of components docker, engine, kubernetes, calico, aled, different bits and pieces that go into, uh, go into one of these commodity clusters that deploy. And so, as far as I can tell in that case, that's what we mean by a release. In this sense, right? It's the validated stack off container ization and orchestration components that you know we've tested out and make sure it works well, introduction environments. >>Yeah, and and And that's really the focus of our effort is to ensure that any CVS in any of the stack are taken care of that there is a fixes air documented and up streamed to the open stack community source community, um, and and that, you know, then we test for the scaling ability and the reliability in high availability configuration for the clusters themselves. The hosts of your containers. Right. And I think one of the key, uh, you know, benefits that we provide is that ability to let you know, online, high. We've got an update for you, and it's fixes something that maybe you had asked us to fix. Uh, that all comes to you online as your managing your clusters, so you don't have to think about it. It just comes as part of the product. >>You just have to click on Yes. Please give me that update. Uh, not just the individual components, but again. It's that it's that validated stack, right? Not just, you know, component X, y and Z work. But they all work together effectively Scalable security, reliably cool. Um, yeah. So at that point, once we started creating that workload child cluster, of course, we bootstrapped good old universal control plane. Doctor Enterprise. On top of that, Sean had the classic comment there, you know? Yeah. Yeah. You'll see a little warnings and errors or whatever. When you're setting up, UCP don't handle, right, Just let it do its job, and it will converge all its components, you know, after just just a minute or two. But we saw in that video, we sped things up a little bit there just we didn't wait for, you know, progress fighters to complete. But really, in real life, that whole process is that anything so spend up one of those one of those fosters so quite quite quick. >>Yeah, and and I think the the thoroughness with which it goes through its process and re tries and re tries, uh, as you know, and it was evident when we went through the initial ah video of the bootstrapping as well that the processes themselves are self healing, as they are going through. So they will try and retry and wait for the event to complete properly on. And once it's completed properly, then it will go to the next step. >>Absolutely. And the worst thing you could do is panic at the first warning and start tearing things that don't don't do that. Just don't let it let it heal. Let take care of itself. And that's the beauty of these manage solutions is that they bake in a lot of subject matter expertise, right? The decisions that are getting made by those containers is they're bootstrapping themselves, reflect the expertise of the Mirant ISS crew that has been developing this content in these two is free for years and years now, over recognizing humanities. One cool thing there that I really appreciate it actually that it adds on top of Dr Enterprise is that automatic griffon a deployment as well. So, Dr Enterprises, I think everyone knows has had, like, some very high level of statistics baked into its dashboard for years and years now. But you know our customers always wanted a double click on that right to be able to go a little bit deeper. And Griffon are really addresses that it's built in dashboards. That's what's really nice to see. >>Yeah, uh, and all of the alerts and, uh, data are actually captured in a Prometheus database underlying that you have access to so that you are allowed to add new alerts that then go out to touch slack and say hi, You need to watch your disk space on this machine or those kinds of things. Um, and and this is especially helpful for folks who you know, want to manage the application service layer but don't necessarily want to manage the operations side of the house. So it gives them a tool set that they can easily say here, Can you watch these for us? And Miran tas can actually help do that with you, So >>yeah, yeah, I mean, that's just another example of baking in that expert knowledge, right? So you can leverage that without tons and tons of a long ah, long runway of learning about how to do that sort of thing. Just get out of the box right away. There was the other thing, actually, that you could sleep by really quickly if you weren't paying close attention. But Sean mentioned it on the video. And that was how When you use dark enterprise container cloud to scale your cluster, particularly pulling a worker out, it doesn't just like Territo worker down and forget about it. Right? Is using good communities best practices to cordon and drain the No. So you aren't gonna disrupt your workloads? You're going to just have a bunch of containers instantly. Excellent crash. You could really carefully manage the migration of workloads off that cluster has baked right in tow. How? How? Document? The brass container cloud is his handling cluster scale. >>Right? And And the kubernetes, uh, scaling methodology is is he adhered to with all of the proper techniques that ensure that it will tell you. Wait, you've got a container that actually needs three, uh, three, uh, instances of itself. And you don't want to take that out, because that node, it means you'll only be able to have to. And we can't do that. We can't allow that. >>Okay, Very cool. Further thoughts on this video. So should we go to the questions. >>Let's let's go to the questions >>that people have. Uh, there's one good one here, down near the bottom regarding whether an a p I is available to do this. So in all these demos were clicking through this web. You I Yes, this is all a p. I driven. You could do all of this. You know, automate all this away is part of the CSC change. Absolutely. Um, that's kind of the point, right? We want you to be ableto spin up. Come on. I keep calling them commodity clusters. What I mean by that is clusters that you can create and throw away. You know, easily and automatically. So everything you see in these demos eyes exposed to FBI? >>Yeah. In addition, through the standard Cube cuddle, Uh, cli as well. So if you're not a programmer, but you still want to do some scripting Thio, you know, set up things and deploy your applications and things. You can use this standard tool sets that are available to accomplish that. >>There is a good question on scale here. So, like, just how many clusters and what sort of scale of deployments come this kind of support our engineers report back here that we've done in practice up to a Zeman ia's like two hundred clusters. We've deployed on this with two hundred fifty nodes in a cluster. So were, you know, like like I said, hundreds, hundreds of notes, hundreds of clusters managed by documented press container fall and then those downstream clusters, of course, subject to the usual constraints for kubernetes, right? Like default constraints with something like one hundred pods for no or something like that. There's a few different limitations of how many pods you can run on a given cluster that comes to us not from Dr Enterprise Container Cloud, but just from the underlying kubernetes distribution. >>Yeah, E. I mean, I don't think that we constrain any of the capabilities that are available in the, uh, infrastructure deliveries, uh, service within the goober Netease framework. So were, you know, But we are, uh, adhering to the standards that we would want to set to make sure that we're not overloading a node or those kinds of things, >>right. Absolutely cool. Alright. So at this point, we've got kind of a two layered our protection when we are management cluster, but we deployed in the first video. Then we use that to deploy one child clustering work, classroom, uh, for more sophisticated deployments where we might want to manage child clusters across multiple regions. We're gonna add another layer into our architectural we're gonna add in regional cluster management. So this idea you're gonna have the single management cluster that we started within the first video. On the next video, we're gonna learn how to spin up a regional clusters, each one of which would manage, for example, a different AWS uh, US region. So let me just pull out the video for that bill. We'll check it out for me. Mhm. >>Hello. In this demo, we will cover the deployment of additional regional management. Cluster will include a brief architectures of you how to set up the management environment, prepare for the deployment deployment overview and then just to prove it, to play a regional child cluster. So, looking at the overall architecture, the management cluster provides all the core functionality, including identity management, authentication, inventory and release version. ING Regional Cluster provides the specific architecture provider in this case AWS on the LCN components on the D you speak Cluster for child cluster is the cluster or clusters being deployed and managed? Okay, so why do you need a regional cluster? Different platform architectures, for example aws who have been stack even bare metal to simplify connectivity across multiple regions handle complexities like VPNs or one way connectivity through firewalls, but also help clarify availability zones. Yeah. Here we have a view of the regional cluster and how it connects to the management cluster on their components, including items like the LCN cluster Manager we also Machine Manager were held. Mandel are managed as well as the actual provider logic. Mhm. Okay, we'll begin by logging on Is the default administrative user writer. Okay, once we're in there, we'll have a look at the available clusters making sure we switch to the default project which contains the administration clusters. Here we can see the cars management cluster, which is the master controller. And you see, it only has three nodes, three managers, no workers. Okay, if we look at another regional cluster similar to what we're going to deploy now, also only has three managers once again, no workers. But as a comparison, here's a child cluster This one has three managers, but also has additional workers associate it to the cluster. All right, we need to connect. Tell bootstrap note. Preferably the same note that used to create the original management plaster. It's just on AWS, but I still want to machine. All right. A few things we have to do to make sure the environment is ready. First thing we're going to see go into route. We'll go into our releases folder where we have the kozberg struck on. This was the original bootstrap used to build the original management cluster. Yeah, we're going to double check to make sure our cube con figures there once again, the one created after the original customers created just double check. That cute conflict is the correct one. Does point to the management cluster. We're just checking to make sure that we can reach the images that everything is working. A condom. No damages waken access to a swell. Yeah. Next we're gonna edit the machine definitions. What we're doing here is ensuring that for this cluster we have the right machine definitions, including items like the am I. So that's found under the templates AWS directory. We don't need to edit anything else here. But we could change items like the size of the machines attempts. We want to use that The key items to ensure where you changed the am I reference for the junta image is the one for the region in this case AWS region for utilizing this was no construct deployment. We have to make sure we're pointing in the correct open stack images. Yeah, okay. Set the correct and my save file. Now we need to get up credentials again. When we originally created the bootstrap cluster, we got credentials from eight of the U. S. If we hadn't done this, we would need to go through the u A. W s set up. So we're just exporting the AWS access key and I d. What's important is CAAs aws enabled equals. True. Now we're sitting the region for the new regional cluster. In this case, it's Frankfurt on exporting our cube conflict that we want to use for the management cluster. When we looked at earlier Yeah, now we're exporting that. Want to call the cluster region Is Frank Foods Socrates Frankfurt yet trying to use something descriptive It's easy to identify. Yeah, and then after this, we'll just run the bootstrap script, which will complete the deployment for us. Bootstrap of the regional cluster is quite a bit quicker than the initial management clusters. There are fewer components to be deployed. Um, but to make it watchable, we've spent it up. So we're preparing our bootstrap cluster on the local bootstrap node. Almost ready on. We started preparing the instances at W s and waiting for that bastard and no to get started. Please. The best you nerd Onda. We're also starting to build the actual management machines they're now provisioning on. We've reached the point where they're actually starting to deploy. Dr. Enterprise, this is probably the longest face. Yeah, seeing the second that all the nerds will go from the player deployed. Prepare, prepare. Yeah, You'll see their status changes updates. He was the first night ready. Second, just applying second already. Both my time. No waiting from home control. Let's become ready. Removing cluster the management cluster from the bootstrap instance into the new cluster running the date of the U. S. All my stay. Ah, now we're playing Stockland. Switch over is done on. Done. Now I will build a child cluster in the new region very, very quickly to find the cluster will pick. Our new credential has shown up. We'll just call it Frankfurt for simplicity a key and customs to find. That's the machine. That cluster stop with three managers. Set the correct Am I for the region? Yeah, Do the same to add workers. There we go test the building. Yeah. Total bill of time Should be about fifteen minutes. Concedes in progress. It's going to expect this up a little bit. Check the events. We've created all the dependencies, machine instances, machines, a boat shortly. We should have a working cluster in Frankfurt region. Now almost a one note is ready from management. Two in progress. Yeah, on we're done. Clusters up and running. Yeah. >>Excellent. So at this point, we've now got that three tier structure that we talked about before the video. We got that management cluster that we do strapped in the first video. Now we have in this example to different regional clustering one in Frankfurt, one of one management was two different aws regions. And sitting on that you can do Strap up all those Doctor enterprise costumes that we want for our work clothes. >>Yeah, that's the key to this is to be able to have co resident with your actual application service enabled clusters the management co resident with it so that you can, you know, quickly access that he observation Elson Surfboard services like the graph, Ana and that sort of thing for your particular region. A supposed to having to lug back into the home. What did you call it when we started >>the mothership? >>The mothership. Right. So we don't have to go back to the mother ship. We could get >>it locally. Yeah, when, like to that point of aggregating things under a single pane of glass? That's one thing that again kind of sailed by in the demo really quickly. But you'll notice all your different clusters were on that same cluster. Your pain on your doctor Enterprise Container Cloud management. Uh, court. Right. So both your child clusters for running workload and your regional clusters for bootstrapping. Those child clusters were all listed in the same place there. So it's just one pane of glass to go look for, for all of your clusters, >>right? And, uh, this is kind of an important point. I was, I was realizing, as we were going through this. All of the mechanics are actually identical between the bootstrapped cluster of the original services and the bootstrapped cluster of the regional services. It's the management layer of everything so that you only have managers, you don't have workers and that at the child cluster layer below the regional or the management cluster itself, that's where you have the worker nodes. And those are the ones that host the application services in that three tiered architecture that we've now defined >>and another, you know, detail for those that have sharp eyes. In that video, you'll notice when deploying a child clusters. There's not on Lee. A minimum of three managers for high availability management cluster. You must have at least two workers that's just required for workload failure. It's one of those down get out of work. They could potentially step in there, so your minimum foot point one of these child clusters is fine. Violence and scalable, obviously, from a >>That's right. >>Let's take a quick peek of the questions here, see if there's anything we want to call out, then we move on to our last want to my last video. There's another question here about, like where these clusters can live. So again, I know these examples are very aws heavy. Honestly, it's just easy to set up down on the other us. We could do things on bare metal and, uh, open stack departments on Prem. That's what all of this still works in exactly the same way. >>Yeah, the, uh, key to this, especially for the the, uh, child clusters, is the provision hers? Right? See you establish on AWS provision or you establish a bare metal provision or you establish a open stack provision. Or and eventually that list will include all of the other major players in the cloud arena. But you, by selecting the provision or within your management interface, that's where you decide where it's going to be hosted, where the child cluster is to be hosted. >>Speaking off all through a child clusters. Let's jump into our last video in the Siri's, where we'll see how to spin up a child cluster on bare metal. >>Hello. This demo will cover the process of defining bare metal hosts and then review the steps of defining and deploying a bare metal based doctor enterprise cluster. So why bare metal? Firstly, it eliminates hyper visor overhead with performance boost of up to thirty percent. Provides direct access to GP use, prioritize for high performance wear clothes like machine learning and AI, and supports high performance workloads like network functions, virtualization. It also provides a focus on on Prem workloads, simplifying and ensuring we don't need to create the complexity of adding another opera visor. Lay it between so continue on the theme Why Communities and bare metal again Hyper visor overhead. Well, no virtualization overhead. Direct access to hardware items like F p G A s G p us. We can be much more specific about resource is required on the nodes. No need to cater for additional overhead. Uh, we can handle utilization in the scheduling. Better Onda we increase the performances and simplicity of the entire environment as we don't need another virtualization layer. Yeah, In this section will define the BM hosts will create a new project will add the bare metal hosts, including the host name. I put my credentials I pay my address the Mac address on then provide a machine type label to determine what type of machine it is for later use. Okay, let's get started. So well again. Was the operator thing. We'll go and we'll create a project for our machines to be a member off helps with scoping for later on for security. I begin the process of adding machines to that project. Yeah. So the first thing we had to be in post, Yeah, many of the machine A name. Anything you want, que experimental zero one. Provide the IAP my user name type my password. Okay. On the Mac address for the common interface with the boot interface and then the i p m I i p address These machines will be at the time storage worker manager. He's a manager. Yeah, we're gonna add a number of other machines on will. Speed this up just so you could see what the process looks like in the future. Better discovery will be added to the product. Okay. Okay. Getting back there we have it are Six machines have been added, are busy being inspected, being added to the system. Let's have a look at the details of a single note. Yeah, you can see information on the set up of the node. Its capabilities? Yeah. As well as the inventory information about that particular machine. I see. Okay, let's go and create the cluster. Yeah, So we're going to deploy a bare metal child cluster. The process we're going to go through is pretty much the same as any other child cluster. So we'll credit custom. We'll give it a name, but if it were selecting bare metal on the region, we're going to select the version we want to apply. No way. We're going to add this search keys. If we hope we're going to give the load. Balancer host I p that we'd like to use out of dress range on update the address range that we want to use for the cluster. Check that the sea ideal blocks for the Cuban ladies and tunnels are what we want them to be. Enable disabled stack light. Yeah, and soothe stack light settings to find the cluster. And then, as for any other machine, we need to add machines to the cluster. Here. We're focused on building communities clusters, so we're gonna put the count of machines. You want managers? We're gonna pick the label type manager and create three machines is the manager for the Cuban eighties. Casting Okay thing. We're having workers to the same. It's a process. Just making sure that the worker label host level are I'm sorry. On when Wait for the machines to deploy. Let's go through the process of putting the operating system on the notes validating and operating system deploying doctor identifies Make sure that the cluster is up and running and ready to go. Okay, let's review the bold events waken See the machine info now populated with more information about the specifics of things like storage and of course, details of a cluster etcetera. Yeah, yeah, well, now watch the machines go through the various stages from prepared to deploy on what's the cluster build? And that brings us to the end of this particular demo. You can see the process is identical to that of building a normal child cluster we got our complaint is complete. >>All right, so there we have it, deploying a cluster to bare metal. Much the same is how we did for AWS. I guess maybe the biggest different stepwise there is there is that registration face first, right? So rather than just using AWS financials toe magically create PM's in the cloud. You got a point out all your bare metal servers to Dr Enterprise between the cloud and they really come in, I guess three profiles, right? You got your manager profile with a profile storage profile which has been labeled as allocate. Um, crossword cluster has appropriate, >>right? And And I think that the you know, the key differentiator here is that you have more physical control over what, uh, attributes that love your cat, by the way, uh, where you have the different attributes of a server of physical server. So you can, uh, ensure that the SSD configuration on the storage nodes is gonna be taken advantage of in the best way the GP use on the worker nodes and and that the management layer is going to have sufficient horsepower to, um, spin up to to scale up the the environments, as required. One of the things I wanted to mention, though, um, if I could get this out without the choking much better. Um, is that Ah, hey, mentioned the load balancer and I wanted to make sure in defining the load balancer and the load balancer ranges. Um, that is for the top of the the cluster itself. That's the operations of the management, uh, layer integrating with your systems internally to be able to access the the Cube Can figs. I I p address the, uh, in a centralized way. It's not the load balancer that's working within the kubernetes cluster that you are deploying. That's still cube proxy or service mesh, or however you're intending to do it. So, um, it's kind of an interesting step that your initial step in building this, um and we typically use things like metal L B or in gen X or that kind of thing is to establish that before we deploy this bear mental cluster so that it can ride on top of that for the tips and things. >>Very cool. So any other thoughts on what we've seen so far today? Bruce, we've gone through all the different layers. Doctor enterprise container clouds in these videos from our management are regional to our clusters on aws hand bear amount, Of course, with his dad is still available. Closing thoughts before we take just a very short break and run through these demos again. >>You know, I've been very exciting. Ah, doing the presentation with you. I'm really looking forward to doing it the second time, so that we because we've got a good rhythm going about this kind of thing. So I'm looking forward to doing that. But I think that the key elements of what we're trying to convey to the folks out there in the audience that I hope you've gotten out of it is that will that this is an easy enough process that if you follow the step by steps going through the documentation that's been put out in the chat, um, that you'll be able to give this a go yourself, Um, and you don't have to limit yourself toe having physical hardware on prim to try it. You could do it in a ws as we've shown you today. And if you've got some fancy use cases like, uh, you you need a Hadoop And and, uh, you know, cloud oriented ai stuff that providing a bare metal service helps you to get there very fast. So right. Thank you. It's been a pleasure. >>Yeah, thanks everyone for coming out. So, like I said we're going to take a very short, like, three minute break here. Uh, take the opportunity to let your colleagues know if they were in another session or they didn't quite make it to the beginning of this session. Or if you just want to see these demos again, we're going to kick off this demo. Siri's again in just three minutes at ten. Twenty five a. M. Pacific time where we will see all this great stuff again. Let's take a three minute break. I'll see you all back here in just two minutes now, you know. Okay, folks, that's the end of our extremely short break. We'll give people just maybe, like one more minute to trickle in if folks are interested in coming on in and jumping into our demo. Siri's again. Eso For those of you that are just joining us now I'm Bill Mills. I head up curriculum development for the training team here. Moran Tous on Joining me for this session of demos is Bruce. Don't you go ahead and introduce yourself doors, who is still on break? That's cool. We'll give Bruce a minute or two to get back while everyone else trickles back in. There he is. Hello, Bruce. >>How'd that go for you? Okay, >>Very well. So let's kick off our second session here. I e just interest will feel for you. Thio. Let it run over here. >>Alright. Hi. Bruce Matthews here. I'm the Western Regional Solutions architect for Marantz. Use A I'm the one with the gray hair and the glasses. Uh, the handsome one is Bill. So, uh, Bill, take it away. >>Excellent. So over the next hour or so, we've got a Siris of demos that's gonna walk you through your first steps with Dr Enterprise Container Cloud Doctor Enterprise Container Cloud is, of course, Miranda's brand new offering from bootstrapping kubernetes clusters in AWS bare metal open stack. And for the providers in the very near future. So we we've got, you know, just just over an hour left together on this session, uh, if you joined us at the top of the hour back at nine. A. M. Pacific, we went through these demos once already. Let's do them again for everyone else that was only able to jump in right now. Let's go. Our first video where we're gonna install Dr Enterprise container cloud for the very first time and use it to bootstrap management. Cluster Management Cluster, as I like to describe it, is our mother ship that's going to spin up all the other kubernetes clusters, Doctor Enterprise clusters that we're gonna run our workloads on. So I'm gonna do >>I'm so excited. I can hardly wait. >>Let's do it all right to share my video out here. Yeah, let's do it. >>Good day. The focus for this demo will be the initial bootstrap of the management cluster on the first regional clusters. To support AWS deployments, the management cluster provides the core functionality, including identity management, authentication, infantry release version. The regional cluster provides the specific architecture provided in this case AWS and the Elsom components on the UCP cluster Child cluster is the cluster or clusters being deployed and managed. The deployment is broken up into five phases. The first phase is preparing a bootstrap note on its dependencies on handling the download of the bridge struck tools. The second phase is obtaining America's license file. Third phase. Prepare the AWS credentials instead of the ideas environment, the fourth configuring the deployment, defining things like the machine types on the fifth phase, Run the bootstrap script and wait for the deployment to complete. Okay, so here we're sitting up the strap node. Just checking that it's clean and clear and ready to go there. No credentials already set up on that particular note. Now, we're just checking through aws to make sure that the account we want to use we have the correct credentials on the correct roles set up on validating that there are no instances currently set up in easy to instance, not completely necessary, but just helps keep things clean and tidy when I am perspective. Right. So next step, we're just gonna check that we can from the bootstrap note, reach more antis, get to the repositories where the various components of the system are available. They're good. No areas here. Yeah, right now we're going to start sitting at the bootstrap note itself. So we're downloading the cars release, get get cars, script, and then next we're going to run it. Yeah, I've been deployed changing into that big struck folder, just making see what's there right now we have no license file, so we're gonna get the license filed. Okay? Get the license file through more antis downloads site signing up here, downloading that license file and putting it into the Carisbrook struck folder. Okay, since we've done that, we can now go ahead with the rest of the deployment. Yeah, see what the follow is there? Uh huh. Once again, checking that we can now reach E C two, which is extremely important for the deployment. Just validation steps as we move through the process. Alright. Next big step is violating all of our AWS credentials. So the first thing is, we need those route credentials which we're going to export on the command line. This is to create the necessary bootstrap user on AWS credentials for the completion off the deployment we're now running in AWS policy create. So it is part of that is creating our food trucks script. Creating this through policy files onto the AWS, just generally preparing the environment using a cloud formation script, you'll see in a second, I'll give a new policy confirmations just waiting for it to complete. And there is done. It's gonna have a look at the AWS console. You can see that we're creative completed. Now we can go and get the credentials that we created. Good day. I am console. Go to the new user that's being created. We'll go to the section on security credentials and creating new keys. Download that information media access Key I. D and the secret access key, but usually then exported on the command line. Okay, Couple of things to Notre. Ensure that you're using the correct AWS region on ensure that in the conflict file you put the correct Am I in for that region? I'm sure you have it together in a second. Okay, thanks. Is key. So you could X key Right on. Let's kick it off. So this process takes between thirty and forty five minutes. Handles all the AWS dependencies for you. Um, as we go through, the process will show you how you can track it. Andi will start to see things like the running instances being created on the AWS side. The first phase off this whole process happening in the background is the creation of a local kind based bootstrapped cluster on the bootstrap node that clusters then used to deploy and manage all the various instances and configurations within AWS at the end of the process. That cluster is copied into the new cluster on AWS and then shut down that local cluster essentially moving itself over. Yeah, okay. Local clusters boat. Just waiting for the various objects to get ready. Standard communities objects here. Yeah, you mentioned Yeah. So we've speed up this process a little bit just for demonstration purposes. Okay, there we go. So first note is being built the bastion host just jump box that will allow us access to the entire environment. Yeah, In a few seconds, we'll see those instances here in the US console on the right. Um, the failures that you're seeing around failed to get the I. P for Bastian is just the weight state while we wait for AWS to create the instance. Okay. Yeah. Beauty there. Movies. Okay, sketch. Hello? Yeah, Okay. Okay. On. There we go. Question host has been built on three instances for the management clusters have now been created. Okay, We're going through the process of preparing. Those nodes were now copying everything over. See that scaling up of controllers in the big strapped cluster? It's indicating that we're starting all of the controllers in the new question. Almost there. Right? Okay. Just waiting for key. Clark. Uh huh. So finish up. Yeah. No. Now we're shutting down. Control this on the local bootstrap node on preparing our I. D. C configuration, fourth indication. So once this is completed, the last phase will be to deploy stack light into the new cluster, that glass on monitoring tool set, Then we go stack like deployment has started. Mhm. Coming to the end of the deployment mountain. Yeah, they were cut final phase of the deployment. And we are done. Yeah, you'll see. At the end, they're providing us the details of you. I log in. So there's a key Clark log in. Uh, you can modify that initial default possible is part of the configuration set up where they were in the documentation way. Go Councils up way can log in. Yeah. Yeah. Thank you very much for watching. >>All right, so at this point, what we have we got our management cluster spun up, ready to start creating work clusters. So just a couple of points to clarify there to make sure everyone caught that, uh, as advertised. That's darker. Enterprise container cloud management cluster. That's not rework loans. are gonna go right? That is the tool and you're gonna use to start spinning up downstream commodity documentary prize clusters for bootstrapping record too. >>And the seed host that were, uh, talking about the kind cluster dingy actually doesn't have to exist after the bootstrap succeeds eso It's sort of like, uh, copies head from the seed host Toothy targets in AWS spins it up it then boots the the actual clusters and then it goes away too, because it's no longer necessary >>so that bootstrapping know that there's not really any requirements, Hardly on that, right. It just has to be able to reach aws hit that Hit that a p I to spin up those easy to instances because, as you just said, it's just a kubernetes in docker cluster on that piece. Drop note is just gonna get torn down after the set up finishes on. You no longer need that. Everything you're gonna do, you're gonna drive from the single pane of glass provided to you by your management cluster Doctor enterprise Continue cloud. Another thing that I think is sort of interesting their eyes that the convict is fairly minimal. Really? You just need to provide it like aws regions. Um, am I? And that's what is going to spin up that spending that matter faster. >>Right? There is a mammal file in the bootstrap directory itself, and all of the necessary parameters that you would fill in have default set. But you have the option then of going in and defining a different Am I different for a different region, for example? Oh, are different. Size of instance from AWS. >>One thing that people often ask about is the cluster footprint. And so that example you saw they were spitting up a three manager, um, managing cluster as mandatory, right? No single manager set up at all. We want high availability for doctrine Enterprise Container Cloud management. Like so again, just to make sure everyone sort of on board with the life cycle stage that we're at right now. That's the very first thing you're going to do to set up Dr Enterprise Container Cloud. You're going to do it. Hopefully exactly once. Right now, you've got your management cluster running, and they're gonna use that to spend up all your other work clusters Day today has has needed How do we just have a quick look at the questions and then lets take a look at spinning up some of those child clusters. >>Okay, e think they've actually been answered? >>Yeah, for the most part. One thing I'll point out that came up again in the Dail, helpfully pointed out earlier in surgery, pointed out again, is that if you want to try any of the stuff yourself, it's all of the dogs. And so have a look at the chat. There's a links to instructions, so step by step instructions to do each and every thing we're doing here today yourself. I really encourage you to do that. Taking this out for a drive on your own really helps internalizing communicate these ideas after the after launch pad today, Please give this stuff try on your machines. Okay, So at this point, like I said, we've got our management cluster. We're not gonna run workloads there that we're going to start creating child clusters. That's where all of our work and we're gonna go. That's what we're gonna learn how to do in our next video. Cue that up for us. >>I so love Shawn's voice. >>Wasn't that all day? >>Yeah, I watched him read the phone book. >>All right, here we go. Let's now that we have our management cluster set up, let's create a first child work cluster. >>Hello. In this demo, we will cover the deployment experience of creating a new child cluster the scaling of the cluster on how to update the cluster. When a new version is available, we begin the process by logging onto the you I as a normal user called Mary. Let's go through the navigation of the u I. So you can switch Project Mary only has access to development. Uh huh. Get a list of the available projects that you have access to. What clusters have been deployed at the moment there. Man. Yes, this H keys, Associate ID for Mary into her team on the cloud credentials that allow you to create or access the various clouds that you can deploy clusters to finally different releases that are available to us. We can switch from dark mode to light mode, depending on your preferences. Right. Let's now set up some ssh keys for Mary so she can access the notes and machines again. Very simply, had Mississippi key give it a name. We copy and paste our public key into the upload key block. Or we can upload the key if we have the file available on our machine. A very simple process. So to create a new cluster, we define the cluster ad management nodes and add worker nodes to the cluster. Yeah, again, very simply, we got the clusters tab we had to create cluster button. Give the cluster name. Yeah, Andi, select the provider. We only have access to AWS in this particular deployment, so we'll stick to AWS. What's like the region in this case? US West one released version five point seven is the current release Onda Attach. Mary's Key is necessary key. We can then check the rest of the settings, confirming the provider any kubernetes c r D a r i p address information. We can change this. Should we wish to? We'll leave it default for now and then what components of stack light? I would like to deploy into my custom for this. I'm enabling stack light on logging, and I consider the retention sizes attention times on. Even at this stage, add any custom alerts for the watchdogs. Consider email alerting which I will need my smart host. Details and authentication details. Andi Slack Alerts. Now I'm defining the cluster. All that's happened is the cluster's been defined. I now need to add machines to that cluster. I'll begin by clicking the create machine button within the cluster definition. Oh, select manager, Select the number of machines. Three is the minimum. Select the instant size that I'd like to use from AWS and very importantly, ensure correct. Use the correct Am I for the region. I convinced side on the route. Device size. There we go. My three machines are busy creating. I now need to add some workers to this cluster. So I go through the same process this time once again, just selecting worker. I'll just add to once again the am I is extremely important. Will fail if we don't pick the right. Am I for a Clinton machine? In this case and the deployment has started, we can go and check on the bold status are going back to the clusters screen on clicking on the little three dots on the right. We get the cluster info and the events, so the basic cluster info you'll see pending their listen. Cluster is still in the process of being built. We kick on, the events will get a list of actions that have been completed This part of the set up of the cluster. So you can see here. We've created the VPC. We've created the sub nets on. We've created the Internet Gateway. It's unnecessary made of us. And we have no warnings of the stage. Okay, this will then run for a while. We have one minute past. We can click through. We can check the status of the machine balls as individuals so we can check the machine info, details of the machines that we've assigned mhm and see any events pertaining to the machine areas like this one on normal. Yeah. Just last. The community's components are waiting for the machines to start. Go back to customers. Okay, right. Because we're moving ahead now. We can see we have it in progress. Five minutes in new Matt Gateway. And at this stage, the machines have been built on assigned. I pick up the U S. Yeah, yeah, yeah. There we go. Machine has been created. See the event detail and the AWS. I'd for that machine. No speeding things up a little bit this whole process and to end takes about fifteen minutes. Run the clock forward, you'll notice is the machines continue to bold the in progress. We'll go from in progress to ready. A soon as we got ready on all three machines, the managers on both workers way could go on and we could see that now we reached the point where the cluster itself is being configured mhm and then we go. Cluster has been deployed. So once the classes deployed, we can now never get around. Our environment are looking into configure cluster. We could modify their cluster. We could get the end points for alert Alert Manager See here the griffon occupying and Prometheus are still building in the background but the cluster is available on You would be able to put workloads on it at this stage to download the cube conflict so that I can put workloads on it. It's again the three little dots in the right for that particular cluster. If the download cube conflict give it my password, I now have the Q conflict file necessary so that I can access that cluster. All right, Now that the build is fully completed, we can check out cluster info on. We can see that all the satellite components have been built. All the storage is there, and we have access to the CPU. I. So if we click into the cluster, we can access the UCP dashboard, click the signing with the clock button to use the SSO. We give Mary's possible to use the name once again. Thing is an unlicensed cluster way could license at this point. Or just skip it on. Do we have the UCP dashboard? You could see that has been up for a little while. We have some data on the dashboard going back to the console. We can now go to the griffon. A data just been automatically pre configured for us. We can switch and utilized a number of different dashboards that have already been instrumented within the cluster. So, for example, communities cluster information, the name spaces, deployments, nodes. Um, so we look at nodes. If we could get a view of the resource is utilization of Mrs Custer is very little running in it. Yeah, a general dashboard of Cuba Navies cluster. What If this is configurable, you can modify these for your own needs, or add your own dashboards on de scoped to the cluster. So it is available to all users who have access to this specific cluster. All right to scale the cluster on to add a No. This is simple. Is the process of adding a mode to the cluster, assuming we've done that in the first place. So we go to the cluster, go into the details for the cluster we select, create machine. Once again, we need to be ensure that we put the correct am I in and any other functions we like. You can create different sized machines so it could be a larger node. Could be bigger group disks and you'll see that worker has been added in the provisioning state. On shortly, we will see the detail off that worker as a complete to remove a note from a cluster. Once again, we're going to the cluster. We select the node we would like to remove. Okay, I just hit delete On that note. Worker nodes will be removed from the cluster using according and drawing method to ensure that your workloads are not affected. Updating a cluster. When an update is available in the menu for that particular cluster, the update button will become available. And it's a simple as clicking the button validating which release you would like to update to this case. This available releases five point seven point one give you I'm kicking the update back in the background. We will coordinate. Drain each node slowly, go through the process of updating it. Andi update will complete depending on what the update is as quickly as possible. Who we go. The notes being rebuilt in this case impacted the manager node. So one of the manager nodes is in the process of being rebuilt. In fact, to in this case, one has completed already. Yeah, and in a few minutes, we'll see that the upgrade has been completed. There we go. Great. Done. If you work loads of both using proper cloud native community standards, there will be no impact. >>All right, there. We haven't. We got our first workload cluster spun up and managed by Dr Enterprise Container Cloud. So I I loved Shawn's classic warning there. When you're spinning up an actual doctor enterprise deployment, you see little errors and warnings popping up. Just don't touch it. Just leave it alone and let Dr Enterprises self healing properties take care of all those very transient temporary glitches, resolve themselves and leave you with a functioning workload cluster within victims. >>And now, if you think about it that that video was not very long at all. And that's how long it would take you if someone came into you and said, Hey, can you spend up a kubernetes cluster for development development A. Over here, um, it literally would take you a few minutes to thio Accomplish that. And that was with a W s. Obviously, which is sort of, ah, transient resource in the cloud. But you could do exactly the same thing with resource is on Prem or resource is, um physical resource is and will be going through that later in the process. >>Yeah, absolutely one thing that is present in that demo, but that I like to highlight a little bit more because it just kind of glides by Is this notion of, ah, cluster release? So when Sean was creating that cluster, and also when when he was upgrading that cluster, he had to choose a release. What does that didn't really explain? What does that mean? Well, in Dr Enterprise Container Cloud, we have released numbers that capture the entire staff of container ization tools that will be deploying to that workload costume. So that's your version of kubernetes sed cor DNs calico. Doctor Engineer. All the different bits and pieces that not only work independently but are validated toe work together as a staff appropriate for production, humanities, adopted enterprise environments. >>Yep. From the bottom of the stack to the top, we actually test it for scale. Test it for CVS, test it for all of the various things that would, you know, result in issues with you running the application services. And I've got to tell you from having, you know, managed kubernetes deployments and things like that that if you're the one doing it yourself, it can get rather messy. Eso This makes it easy. >>Bruce, you were staying a second ago. They I'll take you at least fifteen minutes to install your release. Custer. Well, sure, but what would all the other bits and pieces you need toe? Not just It's not just about pressing the button to install it, right? It's making the right decision. About what components work? Well, our best tested toe be successful working together has a staff? Absolutely. We this release mechanism and Dr Enterprise Container Cloud. Let's just kind of package up that expert knowledge and make it available in a really straightforward, fashionable species. Uh, pre Confederate release numbers and Bruce is you're pointing out earlier. He's got delivered to us is updates kind of transparent period. When when? When Sean wanted toe update that cluster, he created little update. Custer Button appeared when an update was available. All you gotta do is click. It tells you what Here's your new stack of communities components. It goes ahead. And the straps those components for you? >>Yeah, it actually even displays at the top of the screen. Ah, little header That says you've got an update available. Do you want me to apply? It s o >>Absolutely. Another couple of cool things. I think that are easy to miss in that demo was I really like the on board Bafana that comes along with this stack. So we've been Prometheus Metrics and Dr Enterprise for years and years now. They're very high level. Maybe in in previous versions of Dr Enterprise having those detailed dashboards that Ravana provides, I think that's a great value out there. People always wanted to be ableto zoom in a little bit on that, uh, on those cluster metrics, you're gonna provides them out of the box for us. Yeah, >>that was Ah, really, uh, you know, the joining of the Miranda's and Dr teams together actually spawned us to be able to take the best of what Morantes had in the open stack environment for monitoring and logging and alerting and to do that integration in in a very short period of time so that now we've got it straight across the board for both the kubernetes world and the open stack world. Using the same tool sets >>warm. One other thing I wanna point out about that demo that I think there was some questions about our last go around was that demo was all about creating a managed workplace cluster. So the doctor enterprise Container Cloud managers were using those aws credentials provisioned it toe actually create new e c two instances installed Docker engine stalled. Doctor Enterprise. Remember all that stuff on top of those fresh new VM created and managed by Dr Enterprise contain the cloud. Nothing unique about that. AWS deployments do that on open staff doing on Parramatta stuff as well. Um, there's another flavor here, though in a way to do this for all of our long time doctor Enterprise customers that have been running Doctor Enterprise for years and years. Now, if you got existing UCP points existing doctor enterprise deployments, you plug those in to Dr Enterprise Container Cloud, uh, and use darker enterprise between the cloud to manage those pre existing Oh, working clusters. You don't always have to be strapping straight from Dr Enterprises. Plug in external clusters is bad. >>Yep, the the Cube config elements of the UCP environment. The bundling capability actually gives us a very straightforward methodology. And there's instructions on our website for exactly how thio, uh, bring in import and you see p cluster. Um so it it makes very convenient for our existing customers to take advantage of this new release. >>Absolutely cool. More thoughts on this wonders if we jump onto the next video. >>I think we should move press on >>time marches on here. So let's Let's carry on. So just to recap where we are right now, first video, we create a management cluster. That's what we're gonna use to create All our downstream were closed clusters, which is what we did in this video. Let's maybe the simplest architectures, because that's doing everything in one region on AWS pretty common use case because we want to be able to spin up workload clusters across many regions. And so to do that, we're gonna add a third layer in between the management and work cluster layers. That's gonna be our regional cluster managers. So this is gonna be, uh, our regional management cluster that exists per region that we're going to manage those regional managers will be than the ones responsible for spending part clusters across all these different regions. Let's see it in action in our next video. >>Hello. In this demo, we will cover the deployment of additional regional management. Cluster will include a brief architectural overview, how to set up the management environment, prepare for the deployment deployment overview, and then just to prove it, to play a regional child cluster. So looking at the overall architecture, the management cluster provides all the core functionality, including identity management, authentication, inventory and release version. ING Regional Cluster provides the specific architecture provider in this case, AWS on the L C M components on the d you speak cluster for child cluster is the cluster or clusters being deployed and managed? Okay, so why do you need original cluster? Different platform architectures, for example AWS open stack, even bare metal to simplify connectivity across multiple regions handle complexities like VPNs or one way connectivity through firewalls, but also help clarify availability zones. Yeah. Here we have a view of the regional cluster and how it connects to the management cluster on their components, including items like the LCN cluster Manager. We also machine manager. We're hell Mandel are managed as well as the actual provider logic. Okay, we'll begin by logging on Is the default administrative user writer. Okay, once we're in there, we'll have a look at the available clusters making sure we switch to the default project which contains the administration clusters. Here we can see the cars management cluster, which is the master controller. When you see it only has three nodes, three managers, no workers. Okay, if we look at another regional cluster, similar to what we're going to deploy now. Also only has three managers once again, no workers. But as a comparison is a child cluster. This one has three managers, but also has additional workers associate it to the cluster. Yeah, all right, we need to connect. Tell bootstrap note, preferably the same note that used to create the original management plaster. It's just on AWS, but I still want to machine Mhm. All right, A few things we have to do to make sure the environment is ready. First thing we're gonna pseudo into route. I mean, we'll go into our releases folder where we have the car's boot strap on. This was the original bootstrap used to build the original management cluster. We're going to double check to make sure our cube con figures there It's again. The one created after the original customers created just double check. That cute conflict is the correct one. Does point to the management cluster. We're just checking to make sure that we can reach the images that everything's working, condone, load our images waken access to a swell. Yeah, Next, we're gonna edit the machine definitions what we're doing here is ensuring that for this cluster we have the right machine definitions, including items like the am I So that's found under the templates AWS directory. We don't need to edit anything else here, but we could change items like the size of the machines attempts we want to use but the key items to ensure where changed the am I reference for the junta image is the one for the region in this case aws region of re utilizing. This was an open stack deployment. We have to make sure we're pointing in the correct open stack images. Yeah, yeah. Okay. Sit the correct Am I save the file? Yeah. We need to get up credentials again. When we originally created the bootstrap cluster, we got credentials made of the U. S. If we hadn't done this, we would need to go through the u A. W s set up. So we just exporting AWS access key and I d. What's important is Kaz aws enabled equals. True. Now we're sitting the region for the new regional cluster. In this case, it's Frankfurt on exporting our Q conflict that we want to use for the management cluster when we looked at earlier. Yeah, now we're exporting that. Want to call? The cluster region is Frankfurt's Socrates Frankfurt yet trying to use something descriptive? It's easy to identify. Yeah, and then after this, we'll just run the bootstrap script, which will complete the deployment for us. Bootstrap of the regional cluster is quite a bit quicker than the initial management clusters. There are fewer components to be deployed, but to make it watchable, we've spent it up. So we're preparing our bootstrap cluster on the local bootstrap node. Almost ready on. We started preparing the instances at us and waiting for the past, you know, to get started. Please the best your node, onda. We're also starting to build the actual management machines they're now provisioning on. We've reached the point where they're actually starting to deploy Dr Enterprise, he says. Probably the longest face we'll see in a second that all the nodes will go from the player deployed. Prepare, prepare Mhm. We'll see. Their status changes updates. It was the first word ready. Second, just applying second. Grady, both my time away from home control that's become ready. Removing cluster the management cluster from the bootstrap instance into the new cluster running a data for us? Yeah, almost a on. Now we're playing Stockland. Thanks. Whichever is done on Done. Now we'll build a child cluster in the new region very, very quickly. Find the cluster will pick our new credential have shown up. We'll just call it Frankfurt for simplicity. A key on customers to find. That's the machine. That cluster stop with three manages set the correct Am I for the region? Yeah, Same to add workers. There we go. That's the building. Yeah. Total bill of time. Should be about fifteen minutes. Concedes in progress. Can we expect this up a little bit? Check the events. We've created all the dependencies, machine instances, machines. A boat? Yeah. Shortly. We should have a working caster in the Frankfurt region. Now almost a one note is ready from management. Two in progress. On we're done. Trust us up and running. >>Excellent. There we have it. We've got our three layered doctor enterprise container cloud structure in place now with our management cluster in which we scrap everything else. Our regional clusters which manage individual aws regions and child clusters sitting over depends. >>Yeah, you can. You know you can actually see in the hierarchy the advantages that that presents for folks who have multiple locations where they'd like a geographic locations where they'd like to distribute their clusters so that you can access them or readily co resident with your development teams. Um and, uh, one of the other things I think that's really unique about it is that we provide that same operational support system capability throughout. So you've got stack light monitoring the stack light that's monitoring the stack light down to the actual child clusters that they have >>all through that single pane of glass that shows you all your different clusters, whether their workload cluster like what the child clusters or usual clusters from managing different regions. Cool. Alright, well, time marches on your folks. We've only got a few minutes left and I got one more video in our last video for the session. We're gonna walk through standing up a child cluster on bare metal. So so far, everything we've seen so far has been aws focus. Just because it's kind of easy to make that was on AWS. We don't want to leave you with the impression that that's all we do, we're covering AWS bare metal and open step deployments as well documented Craftsman Cloud. Let's see it in action with a bare metal child cluster. >>We are on the home stretch, >>right. >>Hello. This demo will cover the process of defining bare metal hosts and then review the steps of defining and deploying a bare metal based doctor enterprise cluster. Yeah, so why bare metal? Firstly, it eliminates hyper visor overhead with performance boost of up to thirty percent provides direct access to GP use, prioritize for high performance wear clothes like machine learning and AI, and support high performance workouts like network functions, virtualization. It also provides a focus on on Prem workloads, simplifying and ensuring we don't need to create the complexity of adding another hyper visor layer in between. So continuing on the theme Why communities and bare metal again Hyper visor overhead. Well, no virtualization overhead. Direct access to hardware items like F p g A s G p, us. We can be much more specific about resource is required on the nodes. No need to cater for additional overhead. We can handle utilization in the scheduling better Onda. We increase the performance and simplicity of the entire environment as we don't need another virtualization layer. Yeah, In this section will define the BM hosts will create a new project. Will add the bare metal hosts, including the host name. I put my credentials. I pay my address, Mac address on, then provide a machine type label to determine what type of machine it is. Related use. Okay, let's get started Certain Blufgan was the operator thing. We'll go and we'll create a project for our machines to be a member off. Helps with scoping for later on for security. I begin the process of adding machines to that project. Yeah. Yeah. So the first thing we had to be in post many of the machine a name. Anything you want? Yeah, in this case by mental zero one. Provide the IAP My user name. Type my password? Yeah. On the Mac address for the active, my interface with boot interface and then the i p m i P address. Yeah, these machines. We have the time storage worker manager. He's a manager. We're gonna add a number of other machines on will speed this up just so you could see what the process. Looks like in the future, better discovery will be added to the product. Okay, Okay. Getting back there. We haven't Are Six machines have been added. Are busy being inspected, being added to the system. Let's have a look at the details of a single note. Mhm. We can see information on the set up of the node. Its capabilities? Yeah. As well as the inventory information about that particular machine. Okay, it's going to create the cluster. Mhm. Okay, so we're going to deploy a bare metal child cluster. The process we're going to go through is pretty much the same as any other child cluster. So credit custom. We'll give it a name. Thank you. But he thought were selecting bare metal on the region. We're going to select the version we want to apply on. We're going to add this search keys. If we hope we're going to give the load. Balancer host I p that we'd like to use out of the dress range update the address range that we want to use for the cluster. Check that the sea idea blocks for the communities and tunnels are what we want them to be. Enable disabled stack light and said the stack light settings to find the cluster. And then, as for any other machine, we need to add machines to the cluster. Here we're focused on building communities clusters. So we're gonna put the count of machines. You want managers? We're gonna pick the label type manager on create three machines. Is a manager for the Cuban a disgusting? Yeah, they were having workers to the same. It's a process. Just making sure that the worker label host like you are so yes, on Duin wait for the machines to deploy. Let's go through the process of putting the operating system on the notes, validating that operating system. Deploying Docker enterprise on making sure that the cluster is up and running ready to go. Okay, let's review the bold events. We can see the machine info now populated with more information about the specifics of things like storage. Yeah, of course. Details of a cluster, etcetera. Yeah, Yeah. Okay. Well, now watch the machines go through the various stages from prepared to deploy on what's the cluster build, and that brings us to the end of this particular do my as you can see the process is identical to that of building a normal child cluster we got our complaint is complete. >>Here we have a child cluster on bare metal for folks that wanted to play the stuff on Prem. >>It's ah been an interesting journey taken from the mothership as we started out building ah management cluster and then populating it with a child cluster and then finally creating a regional cluster to spread the geographically the management of our clusters and finally to provide a platform for supporting, you know, ai needs and and big Data needs, uh, you know, thank goodness we're now able to put things like Hadoop on, uh, bare metal thio in containers were pretty exciting. >>Yeah, absolutely. So with this Doctor Enterprise container cloud platform. Hopefully this commoditized scooping clusters, doctor enterprise clusters that could be spun up and use quickly taking provisioning times. You know, from however many months to get new clusters spun up for our teams. Two minutes, right. We saw those clusters gets better. Just a couple of minutes. Excellent. All right, well, thank you, everyone, for joining us for our demo session for Dr Enterprise Container Cloud. Of course, there's many many more things to discuss about this and all of Miranda's products. If you'd like to learn more, if you'd like to get your hands dirty with all of this content, police see us a training don Miranda's dot com, where we can offer you workshops and a number of different formats on our entire line of products and hands on interactive fashion. Thanks, everyone. Enjoy the rest of the launchpad of that >>thank you all enjoy.

>>Hello, My name is John John Sheikh from Iran Tous. Welcome to our session on new extensions for doctors CLI as we all know, containers air everywhere. Kubernetes is coming on strong and the CNC F cloud landscape slide has become a marvel to behold its complexities about to surpass that of the photo. Letha dies used to fabricate the old intel to 86 and future generations of the diagram will be built out and up into multiple dimensions using extreme ultraviolet lithography. Meanwhile, complexity is exploding and uncertainty about tools, platform details, processes and the economic viability of our companies in changing and challenging times is also increasing. Mirant ous, as you've already heard today, believes that achieving speed is critical and that speed results from balancing choice with simplicity and security. You've heard about Dr Enterprise Container Cloud, a new framework built on kubernetes, the less you deploy compliant, secure by default. Cooper nineties clusters on any infrastructure, providing a seamless self service capable cloud experience to developers. Get clusters fast, Justus, you need them, Update them seamlessly. Scale them is needed all while keeping workloads running smoothly. And you've heard how Dr Enterprise Container Cloud also provides all the day one and Day two and observe ability, tools, the integration AP ICE and Top Down Security, Identity and Secrets management to run operations efficiently. You've also heard about Lens, an open source i D for kubernetes. Aimed at speeding up the most banding, tightest inner loop of kubernetes application development. Lens beautifully meets the needs of a new class of developers who need to deal with multiple kubernetes clusters. Multiple absent project sufficiently developers who find themselves getting bogged down and seal I only coop CTL work flows and context switches into and out of them. But what about Dr Developers? They're working with the same core technologies all the time. They're accessing many of the same amenities, including Docker, engine Enterprise, Docker, Trusted registry and so on. Sure, their outer loop might be different. For example, they might be orchestrating on swarm. Many companies are our future of Swarm session talks about the ongoing appeal of swarm and Miranda's commitment to maintaining and extending the capabilities of swarm Going forward. Dr Enterprise Container Cloud can, of course, deployed doctor enterprise clusters with 100% swarm orchestration on computes just Aziza Leah's. It can provide kubernetes orchestration or mixed swarming kubernetes clusters. The problem for Dr Dev's is that nobody's given them an easy way to use kubernetes without a learning curve and without getting familiar with new tools and work flows, many of which involved buoys and are somewhat tedious for people who live on the command line and like it that way until now. In a few moments you'll meet my colleagues Chris Price and Laura Powell, who enact a little skit to introduce and demonstrate our new extended docker CLI plug in for kubernetes. That plug in offers seamless new functionality, enabling easy context management between the doctor Command Line and Dr Enterprise Clusters deployed by Dr Enterprise Container Cloud. We hope it will help Dev's work faster, help them adapt decay. TSA's they and their organizations manage platform coexistence or transition. Here's Chris and Laura, or, as we like to call them, developer A and B. >>Have you seen the new release of Docker Enterprise Container Cloud? I'm already finding it easier to manage my collection of UCP clusters. >>I'm glad it's helping you. It's great we can manage multiple clusters, but the user interface is a little bit cumbersome. >>Why is that? >>Well, if I want to use docker cli with a cluster, I need to download a client bundle from UCP and use it to create a contact. I like that. I can see what's going on, but it takes a lot of steps. >>Let me guess. Are these the steps? First you have to navigate to the web. You i for docker Enterprise Container Cloud. You need to enter your user name and password. And since the cluster you want to access is part of the demo project, you need to change projects. Then you have to choose a cluster. So you choose the first demo cluster here. Now you need to visit the U C p u I for that cluster. You can use the link in the top right corner of the page. Is that about right? >>Uh yep. >>And this takes you to the UCP you. I log in page now you can enter your user name and password again, but since you've already signed in with key cloak, you can use that instead. So that's good. Finally, you've made it to the landing page. Now you want to download a client bundle what you can do by visiting your user profile, you'll generate a new bundle called Demo and download it. Now that you have the bundle on your local machine, you can import it to create a doctor context. First, let's take a look at the context already on your machine. I can see you have the default context here. Let's import the bundle and call it demo. If we look at our context again, you can see that the demo context has been created. Now you can use the context and you'll be able to interact with your UCP cluster. Let's take a look to see if any stacks are running in the cluster. I can see you have a stack called my stack >>in >>the default name space running on Kubernetes. We can verify that by checking the UCP you I and there it iss my stack in the default name space running on Kubernetes. Let's try removing the stack just so we could be sure we're dealing with the right cluster and it disappears. As you can see. It's easy to use the Docker cli once you've created a context, but it takes quite a bit of effort to create one in the first place. Imagine? >>Yes. Imagine if you had 10 or 20 or 50 clusters toe work with. It's a management nightmare. >>Haven't you heard of the doctor Enterprise Container Cloud cli Plug in? >>No, >>I think you're going to like it. Let me show you how it works. It's already integrated with the docker cli You start off by setting it up with your container cloud Instance, all you need to get started is the base. You are all of your container cloud Instance and your user name and password. I'll set up my clothes right now. I have to enter my user name and password this one time only. And now I'm all set up. >>But what does it actually dio? >>Well, we can list all of our clusters. And as you can see, I've got the cluster demo one in the demo project and the cluster demo to in the Demo project Taking a look at the web. You I These were the same clusters we're seeing there. >>Let me check. Looks good to me. >>Now we can select one of these clusters, but let's take a look at our context before and after so we can understand how the plug in manages a context for us. As you can see, I just have my default contact stored right now, but I can easily get a context for one of our clusters. Let's try demo to the plug in says it's created a context called Container Cloud for me and it's pointing at the demo to cluster. Let's see what our context look like now and there's the container cloud context ready to go. >>That's great. But are you saying once you've run the plug in the doctor, cli just works with that cluster? >>Sure. Let me show you. I've got a doctor stack right here and it deploys WordPress. Well, the play it to kubernetes for you. Head over to the U C P u I for the cluster so you can verify for yourself. Are you ready? >>Yes. >>First I need to make sure I'm using the context >>and >>then I can deploy. And now we just have to wait for the deployment to complete. It's as easy as ever. >>You weren't lying. Can you deploy the same stack to swarm on my other clusters? >>Of course. And that should also show you how easy it is to switch between clusters. First, let's just confirm that our stack has reported as running. I've got a stack called WordPress demo in the default name space running on Kubernetes to deploy to the other cluster. First I need to select it that updates the container cloud context so I don't even need to switch contexts, since I'm already using that one. If I check again for running stacks, you can see that our WordPress stack is gone. Bring up the UCP you I on your other cluster so you can verify the deployment. >>I'm ready. >>I'll start the deployment now. It should be appearing any moment. >>I see the services starting up. That's great. It seems a lot easier than managing context manually. But how do I know which cluster I'm currently using? >>Well, you could just list your clusters like So do you see how this one has an asterisk next to its name? That means it's the currently selected cluster >>I'm sold. Where can I get the plug in? >>Just go to get hub dot com slash miran tous slash container dash cloud dash cli and follow the instructions

>> Announcer: From around the globe, it's theCUBE. With digital coverage of Dockercon live 2020. Brought to you by, Docker, and its ecosystem partners. >> Hey, welcome back everyone to the DockerCon 2020, #DockerCon20. This is The Cube virtual coverage with Docker on their event here. And we're in the studio in Palo Alto, I'm John Furrier your host of theCUBE, we're here with a great guest to talk about Docker Desktop, the Microsoft relationship, and the key news that's coming out. Ben De St Paer-Gotch is the product manager for Docker Desktop. Ben, great for coming on, thanks for spending the time with me. >> Thanks for having me, I really appreciate it. >> So obviously, this is a virtual conference, we wish we could be in person, but given the state of affairs we're going to do remotely, but the momentum Docker has is phenomenal, it's always been great with containers. It's the number one downloaded app around for developers. Microsoft just had their Build conference, which was again virtual as well, or digital, as they say, it's interchangeable. But clear momentum now with Docker as containers actually is the standard, you guys are doing great. What's the key news out of the Microsoft world for people who missed it last week with MS Build? >> Yeah, so last year at Build, Microsoft announced WSO2 to the Windows subsystem with Linux two. (mumbles) The mapping between the windows (mumbles) Which, went really well but it just didn't provide the same centered needed Linux experience. Last year, they announced Windows subsystem Linux two, (Provides an actual Linux one on windows machine, and we've been working hard with Microsoft over the last year to integrate proper desktop as a main desktop application for working with containers with WSO2. A build this year, Microsoft has gone on and announced that WSO2 is going to have a few new features, and it's going to have new features. (mumbles) Mention Linux graphical, Linux applications, you can access the file system, the installation is going to become a slicker which I guess I'm the most excited about that pitch. But the most exciting announcement is, they will be bringing GPU support to WSO2 which means that we will be able to provide and give you support through Docker desktop or container workloads that peoples are working on. And now we're launching Gray and Agua through containers and docks and desktops and Windows which is really cool because we haven't been able to do that before. >> So is this the first GPU support on Microsoft Windows for Docker, with Docker? >> It's, yeah, it's the first GPU Support for Docker Desktop or Mac or Windows. So, previously the hypervisor hasn't passed through the GPU, pretty much, which meant that we couldn't access it from Docker desktop. So Docker desktop isn't about a lightweight VM we sorts of plumb all that in for you. But we're limited about what we could get access to from the hypervisor, Microsoft putting this through and giving us access for the first time, we can actually, we can go. >> Not to go on a side tangent here, but you know, all these virtual events, and I was watching some of the build stuff as well, as well as us immediate streamers and doing stuff, you can see people's home rigs. And you talk to any Developer, video streamer, or anyone who is working remotely, if you don't have the best GPU's in there, I mean, this has just become, I mean, quite frankly, you need the GPU's. So this is important, it's not only from a vanity standpoint performance. Having that support, I'm going to want the best GPU's, I'm always going to be upgrading my machine for that extra power. What's the impact? What does it mean for me as a Developer? Does it increase stuff? What's the bottom line? >> As a Developer, it means you actually have access to it. So, especially when you're doing workloads on the CPU, you've got minimum amounts of power utilization you can do. When you're running workloads for an L Development, you have a lot of power up process you've got to log, to do your mobile training. So, in an element cycle, you're likely to have your application which you're going to use to produce a modeling, you're going to have training data. Taking that training data and producing a model requires lots of panel processing which is an enormous calculations in producing with finer waitings. Doing that on a CPU has to be done on a serial fashion rather than parallel, which is huge and intensive and takes a really long time. Whereas on a GPU, you can do all of that in parallel which massively reduces the amount of time it will take to run those training functions. Either just straight up in Linux or running them in a container, which as the more of people are looking at running container with workloads, it's how I first, the first team that I was on actually used Docker. I was working in Amazon Alexa, and my team picked up the opportunity to run our workload in container. And that was my first experience, so even though my team backed down, so I could see the system. >> Yeah, ML workloads automations could be critical of that performance. Okay, let's get into some of the momentum with Microsoft, you guys have obviously, builds over, we're here now at DockerCon, there's news. Could you share some of the tidbits for what's being talked about now with Docker and DockerCon. >> Yeah, absolutely, so, along with everything else we've been doing, we've been partnering with Microsoft trying to make the best experience generally with Docker desktop, and with WSO2 and with the VSCO. I've been working closely with Microsoft guys to actually try and improve our experience in Windows as it is today, and to improve some of those integrations with VSCO, and also working with the VSCO team on the Docker plugin for VSCO to give our feedback, and to hear feedback from those guys on the errors and issues they're seeing with Docker desktop and to really try to produce the best experience we can on Windows. End to end, from very front end running all the way through that first push, that first run on the cloud using Docker. >> So what is some of the new product management processes and customer support things that you guys are doing? This comes up a lot, obviously, we had a great conversation around shift left with security. That's great news there. You start to see a lot of this added value for Developers, wanted their support right? So how do I get things I need, and from a customer standpoint? It's kind of a moving train this world and it's only getting better and better from a Developer standpoint. But there's more complexity, it's got to be abstract the way you've got, you know, this new abstraction layers developing. You've got a lot of automation. How does the customer get the support they need in the same agile way that Developers are cranking out code? >> It's a really good question, it's something I think we're still working on as well. So, we're trying to working out and one of the big things I'm trying to work out is, how to make it easier for people to get started with Docker, and how do we also make sure with the things we build, we don't leave a cliff edge instead of a lining path. You don't get to a certain point in an easy process, and then the next step, takes you straight off a cliff, so that's not useful for anyone. So, producing those parts and those ways for people to learn and actually progress is something we're really trying to work out. How to make it natural from the first experience all the way through. From an actual support perspective, the other thing we're looking at, is we're trying to do more things in the open. We're really trying at Docker to bring as many of the new features and pieces we're developing which we have to do that in the open with community visibility, so that if people really want it fixed, they can open the PR and they can help us out. And then the last thing that my team really stood out was our Docker of having actions. As creators, someone already finished, could you do this? Someone else had a PR and emerged it. So, to a certain extent, you've got your one side which had you on board and this ever growth spiral and you keep learning. The other side is how'd you fix the board when you find an issue? In that one, we're really trying to work with the community, a lot more than we have in the last couple of years. >> Awesome, some folks watching, hit him up on Twitter, he's the Product Manager for Docker Desktop among other things. You guys are very transparent, you've got your Twitter handle on the lower third. People can chime in or just jump on the chat, we'll follow up and get you the info. Final question for you Ben, as you look at this reality we're in, there's kind of a holistic kind of moment now where people kind of realizing the new realities here. You're looking at the.. you get the keys to the kingdom with Docker Desktop, okay. You got some momentum with Microsoft, the developer role is moving fast and fast as the head room increases for capabilities with automation. And I know you mentioned a few of those things. GPU is now available. What's the future look like for these Developers? The next short, medium and long term? What's your view as you look out over the landscape because you've got to look at the product roadmap, your engagement with the community. Can you share some insight into how you're thinking about Docker Desktop going forward? >> Yeah, absolutely. So, I think what really interesting point as you say, which is that, if you look at sort of a lot of the Developer side of things that have sort of come out in the last like six months, six to eighteen months. The things I see, I see daily like you mention, things like orchestrating for containers gaining momentum. If you think about crossing the Kaizen model, we're just passed the early Dockers now. We're kind of into the early majority, but we're going to start to move over the next few years into the late majority. What that really means is that people here have been using one of two of these technologies. Maybe you've been using cloud, maybe you've been using Edge, maybe you've been using containers, maybe you've been using CICD, maybe you are using Expiration, maybe you're not. Maybe you've got a Microservice application, maybe it's a little bit of a mole rat. What we're really going to see is, you're going to start to see, all of these changes intersecting and overlapping. And people who have started to pick up model two of these will start to pick up all of them. And that's probably going to happen as we move into the majority of users. So from a what's coming instead of a lot of those thing that you see in best practice in the ideal Developer setup, so a beautiful CICD, a more of an orchestrated environment, Microservice architecture, we're going to see a lot more of that becoming the norm. But I think along with that, we'll also see a level of recognition coming along that a single Microservice alone doesn't provide value. And that's it's going to be some of those groups of services that will provide the user outcome. And that's where my focus is at the end which is you know, an authentication service is great but it doesn't provide value unless you give access to something as authentic. >> It's been issued that the new Docker is all about Developer experience. This is really the core mission. I mean, since the sale of the piece of morantis, Docker has retrenched and reinvented, but stayed core to its principles. Just share with the Developers who've been watching that are coming back into the ecosystem, what is this new Docker vibe? Share your thoughts. >> The new Docker vibe is about working in the open, and it's about solving problems for Developments. The original goal of Docker was to make it easy to pack and ship. It was to reduce Developer friction. As we move more into, sort of, the enterprise space, we worry more about Ops and DevOps. We're not trying to re-focus on Developer and if you sort of think there's two parts to the Developer life cycle, where you've got your work, where you're doing your creative work, where you're writing code. And then you've sort of got your part of the inner loop. And then you've got your part where you're trying to get that code out to production, you're trying to get your value to someone else. Instead of your outer loop, we're really trying to focus on the inner loop And sort of our mantra is that any bit for a Developer should spend as much as their time as possible creating new and exciting things and we're onto those holes that reduce those boring, Monday, repetitive tasks, that we're really trying to work out how we take those boring repetitive pieces and how do we make them just vanish like magic from new users or how do we reduce the friction for the experience from users? From both desktop and hub, we're really trying to bring those two together to achieve that. >> You know what's great about folks who have been in the class since day one. All of us have scar tissue experiences, you know the one thing that's constant is constant change. And one of the things that you guys have done at Docker, and hats off to the whole, you know, original team, is that brand of Docker has symbolized quality openness, and set the standard, I mean, if you look back and containers were really coming around, it's not a new concept. But Docker really set the industry on this path and it's been great to follow every DockerCon at TheCube coverage, but more importantly, as the demand for Developers to build these next wave of Cambrian explosion of applications. It's going to be more important than ever to have more of these abstractions, more of these tools in this real time, more Developers experience because there's more building going on. And it's not just one cloud, it's all clouds, it's all things. >> Yeah, I think it was like when IDC analyzed the future report a couple years ago, I think it was maybe the 2018 one. They said that maybe 2017. They said to date, we've built 500 millions applications worldwide and by 2023, we'll build another 500 million. The rate of creation is just insane, it's exponential growth of us producing more and more applications and connecting more and more devices to do them. The sheer volume of creation and the rate of new technology supporting, even with the rate of companies adopting, I guess more of a warm cloud. I think it's like 60 percent of companies are now more than one cloud provider. Maybe even more, maybe it's like 80 percent. It's ridiculous. >> I was just having this debate on Twitter about this multi-cloud. Someone tried to call us out saying, "Oh you guys were pooing on multi-cloud in 2016 and 18." I go "Look at, no one was Pooping on multi-cloud, it didn't exist." I had multiple clouds but there was no real use case. Now you're starting to see the use cases, where yeah, I had multiple clouds and I got Azure here, I got this over here. But no one wakes up and spreads their workloads wrong. This is going back a few years. Certainly the hybrid was developing, but I think now you're starting to see with networking and some of these inter-operable dynamics, you start to see innovation pockets in wide spaces in large market opportunities for start-ups and companies to thread the clouds together at the right place. So I think multi-cloud is becoming apparent from a use case stand point. Still a ton of work to do, I mean direct connects, got SLA's, I mean all kinds of stuff at the networking level but it is real. It's going to be one of those realities that everyone has, at least one or two, if not three. It could be optimization, this is what Developers do right? Solve problems. >> Yeah, absolutely, I mean if nothing else, I've encounter a couple of companies even just where redundancy is handled by multi-cloud strategy. If you want to achieve more nines and you're just balancing workloads between two clouds. >> I mean, the Zoom news was really a testament to that because everyone got into a twist over that. Oh Zoom moves off Amazon, no they didn't move off Amazon, they went to Oracle, they got Adge, they're everywhere. Why wouldn't they be? They need to pass it, they fail over, they need fall tolerance, I mean, these are basic distributing computing concepts that is one on one. You've got to have these co-locations. And optimization for those clouds and the apps on Microsoft as well, so why wouldn't you do it? >> Exactly. And that's that hybrid, that multi-cloud, compounding that some of which you said earlier, that over changes when you're looking at how you go to CICD, how you're bundling these applications, creating more applications than ever. Coming back, sort of, with more AI workloads, much like GPU and you combine that with, sort of, last in the growth of age devices as well. It sort of makes for a really interesting future. And Docker is sort of, that summation SOV, what we're using to frame how we're thinking about our product and what we should be building. >> Great, for the audience out there, hit him up on Twitter, Ben's available, they're out in the open, if you're interested in how Docker makes life easier on the Windows platform, with the GPU support, they've got security now built in, shifting left. Give these guys a call and of course, we love the mission, out in the open. It's theCUBE's mission as well and great to chat with you. Ben, thanks for spending the time with me today. >> Been an absolute pleasure, thank you for having me. >> Okay, just TheCube's coverage, the virtual Cube with DockerCon co-creating together out in the open. DockerCon20, #Docker20, I'm John Fer with TheCube, stay tuned for our next segment, and thanks for watching. (ambient music)

(upbeat music) >> Narrator: From around the globe, It's theCUBE with digital coverage of DockerCon live 2020 brought to you by Docker and its ecosystem partners. >> Hello, welcome back to our DockerCon 2020 DockerCon 20 coverage this is theCUBE virtual here in the Palo Alto studios with our quarantine crew, I'm John Furrier your host, got two great guests here. Scott Johnson is the CEO of Docker and Peter McKay CEO of Snyk hot security startup with some big news, you guys have rolled out, but really it's got an impact to developers. Scott and Peter great to see you guys again. >> Great to see John. >> Good to see you John. I'm glad we can at least talk remotely. I wish we were face to face, but obviously we're living in a time of crisis were you starting to see a Cambrian explosion starting to emerge where all people are recognizing that a lot is going to come out of this. You guys have announced a strategic alliance. Can you guys take a minute to explain what is this alliance and what does it mean ? Scott, we'll start with you. >> Absolutely, and thank you, Peter, thank you, John, for this chance to share with you all that's going on it's very exciting. Look, what we saw together as teams, both, both Peter's and ours was the developer experience is getting better and better in terms of faster and faster iterations but we weren't in the world of the Docker Desktop and Docker Hub experience having kind of scary as a first pass citizen that was really right in front and center with developer workflow. And so in working with Peter's team, we realized that the two companies had the same vision of like, let's bring that developer for security just right in center, in the user experience in the command line, in the tooling and just make it natural. So that developers could continue to iterate rapidly, continue to ship value, ship features fast. But in addition to doing that, do so in a secure fashion and in a secure manner. And really that's what this partnership is about is making security just kind of built in natural developer friendly developer first. We're very very excited to partner with Snyk and then bring this to development community. >> Peter, you guys have a unique business model, you're developer first security. What does this mean to you? Docker has got millions of developers out there who know containers, there's certainly developer first. What does this alliance mean to you guys as Snyk? >> Yeah, when you think of the developer community, you think of Docker, I mean, that's when we looked at the front end of our funnel, the people who we go after and our users, it's developers, and when you think developers, you think Docker and so we've got... Scott and I got together I'd say four or five months ago where we started talking about building a tighter relationship together the synergies between what he was doing and the team was doing, we're doing at Docker. And what we were trying to do is kind of embed the developer experience and develope and integrate security into that really made a very compelling value proposition together for developers and embedding that security into that application development into your containers and your image and your application development life cycle just made it a better developer experience overall. >> We've been talking to a lot of developers, certainly for DockerCon and just outside of the industry anecdotally, is that Docker really revolutionized, container ideas has been such a great win for developers. Containerizing applications really has changed the game, has spawned the generation of Kubernetes and cloud native microservices. What specifically is going on with you guys in this partnership? Where's the security fit in because can I just do a scan and scan the vulnerabilities? I mean, what's unique here? What does this mean for developers? What's going on with the alliance? >> Yeah, I'll take it first, Peter, but then jump in. So John, in the history of application development, so often security is not addressed until the end. And so developers they're shipping rapidly. They're they're iterating quickly, but then it gets, right before production and the alarm goes off and security team swoops in and security is often seen as a point of friction or a way to delay applications from getting the market and delivering value quickly. And this partnership completely reverses that where instead of having security be further down the stream of the tool chain or the application development life cycle, we're pulling it right up in front and having it be right alongside all the other activities that a developer is doing around building their code around, testing their code around, running their code locally. And it's the whole shift left I'm mean I'm sure you've seen out there and we are shifting this as far left it can be where it's right there on the local Docker Desktop in the command line as a primary emotion and its primary tool to building a great secure application as any other aspect of the tool chain. And that was really the focus of the partnership, which is like, make this just native and as far left as possible and not make security an afterthought or something that gets taken place by other Ops people downstream. >> Peter. >> If you think can about... That's the whole concept of how Snyk was founded. We all came from an application security background where it was security tools for security people, and it really... The whole industry needed this fundamental shift in the approach. And as Scott said that whole shifting left concept to really scale security in the right way and is to embed it into that application development life cycle into embedded into the tools that developers use each and every day. So they wanted to be a security expert, a developer doesn't need to be someone who knows all the vulnerabilities, they just need to know how to develop the most creative, indeed the most agile organization to develop, much better applications. And if they can do it in a more secure way they would obviously do it, but don't make them do something dramatically different and don't ask them to be security experts. And that's what we've tried to do in the partnership with Docker allows us to embed that continuous security insights into that whole development loop to when they develop these applications, they're secure when they're done and all the way through that development life cycle, you're testing for vulnerabilities in auto remediating along the way. So it allows them to develop very creative at the pace in which they want to develop. And it makes them more secure by doing it. >> Yeah, let me pick up on Peter's point there, which is so often security has been something that's discovered late in the process, right? Either just before production or sometimes even in production. And then just think about that feedback loop. It's got to go all the way back upstream all the way to the element team developers got to go find what they're working on. Well, maybe not hours ago, it could have been days ago could even be weeks ago and then both figure out how to remediate, get it all the way through the inner loop and the outer loop. We're completely blowing that up and disrupting that by bringing it all the way forward such that the feedback is right then and there with the developer in the moment on the laptop, in their inner loop and giving them the immediate response that they need and the single they need to take action remediate and then move on to the next creative thing they can do is they're just thinking about shortening that whole feedback loop. And really as Peter said, building security in from the get go because the signal is there to give them a indication of what they need to do right then and there. >> Great, I want to get into the... I mean, I can see the workflow advantage, so I totally get that. I've heard on theCUBE many times that security has got to be built in from the beginning. We've heard that before many times, I don't think I've heard security discussed this way, combined with the trends arounds automation. So can you guys talk about how that fits in? Because I get shifting left all that workflow, all goodness. But now I'm assuming there's a whole op side of security. And then if I'm trying to automate things and that's the real trend we're seeing here, how does that all work? Does that all come together? And it's this kind of unique that you guys are doing? Can you unpack that a little bit and clarify? >> Yeah, I mean, this has been something that we've been focused on quite a bit. I mean, the first it's... Used to be that you used to find a lot of vulnerability and yes we find a lot of vulnerabilities. And what we tried to do is focused on the prioritization and really hear the critical ones that developers need to fix first, second, third, and fourth based on severity. And we build that all in and that's something that we learned that we built into the process. And then last phase is this auto remediation. To the extent we can auto correct and auto fix, which is becoming increasingly a bigger part because the more you learn about the vulnerabilities in some of the fixes, the more you can automate and remediate that just makes the whole development process that much more productive and efficient. And that's really what we're trying to do, not only just find vulnerabilities, prioritize them, what are the ones that are what the team feels as severity one twos and threes embed that into the process. So you fix these are the ones you're fixing first, second, and third, into the extent they could be auto remediated, then fix them automatically. So we're trying to build that increasingly into the application. >> So, is this the first secure containerization deployment model? I mean, have other people have been doing this? I mean, is this new to Docker new to the industry? What's what's going on? >> Well, so we're here to talk about the partnership and of course there's a wealth of a very active ecosystem in and around security and other spaces. But we think this is the first that brings it this close to the developer in the moment in the command line on the desktop. And thus we think it has a lot of value to offer development team. >> I'll put my developer hat on. I'm one of the millions of developers, containers are part of my daily design coding, What's in it for me? Why does it matter to me as a developer? What does it do for me? Save time? What's the impact for the developer? >> Well, you think about... I mean, just look at the old model, right? The old model is you develop an application, you send it to the security team and they'll audit it. They'll tell you all the vulnerabilities and then they'll ship it back to you. You fix it, then they'll check it again. And they were waiting in the queue and then they'll tell you what's wrong and they'll send it back and think of that long. It's just like... Can you remember in the early day, when they a quality issue, fix it earlier in the life cycle of an application, don't wait till the end where the quality is embedded into the process. And so what you find is, the developers are embracing this and we have our like Docker, you have a freemium where developers can try it and realize that look, and I'm going to have to do security anyway, I mean, I have to develop secure application. If I can use a tool that's built for me and embedded into my development life cycle so I don't have to be a security expert and I don't have to wait for the security teams, to tell me what's wrong. And I can embed this all the way through and then not have to go through that painful step at the very end, to go through that security audit. I would do that any day of the week-- >> (mumbles) it back to you, do the scans, "Hey, you got to fix this." And then developer Scott your point moves on. They're coding, right? I mean, that's a problem. >> Developers want to ship, right? I mean, going back to your point, John, like one of the revolutions of Docker is that it is given the expectation that developers can ship faster. And right now in much of the state of the state, because security is important, like it can serve as a gate. And as Peter just walked you through it can slow down developer shipping and having impact. And so for you, the developer, John, like this gives you freedom to ship early often, high-frequency everything the promise of the container development model. This really unleashes that. >> Yeah 'cause that rails around the security policies too allows them to be projected in as syntax, if you will, or as part of the coding environment so I don't have to worry about it. I mean, at the end of the day, it's peace of mind, more than anything, time is certainly a pain in the butt, but yeah, as a developer, the creativity we needed more than ever. Okay, so with the COVID crisis-- >> One last point I want to make on that, sorry, it's also the security teams want it to because they don't want to be the bottleneck. They don't want to be doing this at the last minute and having all the pressure on them. I mean, they know that a big chunk of their business is going through these applications. So a lot of the budget dollars that come from people buying Snyk and embedding it into the process is from security because they can't keep up this digital transformation and what companies are going through. They don't want to be, there's one of two things. Either they're going to be the bottleneck or the developers are going to go around them and just put an application in the cloud in it and ship the container, put it anywhere then going around security. So they don't want that either. So there's just a very tight alignment between developers want to ship fast and security teams want to do the same. >> I hate to say it, but the whole agility is now not only just normal for us insiders in the industry. It's proven now with this COVID crisis that you have to be fast, you have to be at scale. And I think this speaks to some of the experiences you guys had in the industry, you were talking earlier. If you're not moving at the pace that you need to move at the scale you need the automation it's proven cloud native is going is completely ratified in my mind. There's no doubt, that means microservices is front and center and this change that's happening right now. And when we come out of this pandemic, there's going to be growth winners and not growth winners. We flat line to decline or winners, and it's all going to be based on microservices. So for the developers out there going to be called into the office as someday or in a Zoom, let's get these apps double down on this, kill that project. There's going to be those conversations >> It's happening right now, John. So look, what's happening, as a result of COVID an entire bodies of human activity are shifting from offline online. Like social, consumer, B2B, healthcare going down the list, finance, commerce, retail, like massive tectonic shift going from offline online. That means massive demand for new applications, new application development, and quickly, some this shift is happening and there's a bunch of businesses that didn't have exposure to digital they're like, "Oh my goodness, I need a digital strategy. "I need a digital channel. "I need a digital revenue stream." And so the demand for new applications quickly is exploding through the roof. And we see this across the board in our industry right now which is very, very fortunate given the other circumstances and other industries, but you're absolutely right. Like this lets them ship faster. And now is the time when they need to ship and ship fast. >> And the budgets are going to be allocated on these new projects was just a nuance in your point, it's new projects and then there's fixing modernizing the old stuff. Because look at Walmart, Walmart got hamstrung on the eCommerce side, they just killed their jet acquisition. They spent $3 billion on, this is the reality. This is not like just a strategy to do innovation, innovation strategy or some walk down, digital transformation lane. This is happening, it has to be done. What do they do? >> Its interesting and it starts, we always say, we start with the new and replaced the old. We start with a new application, it usually is always the case where we usually start with a lot of the companies is a new (mumbles) on application. And then it expands from there. And so know you look at what you used to be the best practices were tech companies, and then it moved to financial services, industries and insurance and then in retail, now you look at manufacturing, you look across the board, as Scott said, this offline to online, is driving so much of the empowering developers to take on more responsibility and to own more of it, but to be faster and to be more agile. And that's really, what's driving this big shifts in the market. And like you said earlier, if they're not there, they're in trouble because this market is driving that direction. >> I want to get both of your comments on this final question, because even with the progression of the developers from the Steve bomber developer development developers, speech on YouTube to developers on the front lines, cloud native, and now today it's been a progression. And I think it's always been the developers on the front lines are getting closer to the front lines. I think now it's even more compelling because there's a scale and agility speed game going on. So I think it's just another step function, developer relevance. It's not so much, they've never been close to, they have been getting closer they're in the business conversation and the ones that could move fast are the ones going to deliver the value. So if automation is in the playbook, if cloud need is not in the playbook, this is going to be the new developer equation, the ones that meet that will be successful. Can you guys react to that and your thoughts? >> Go ahead Peter. >> I mean, I think what we're trying to do is make that developer experience just one from just the partnership with Docker and is a key, just making it really easy, do the integration, do a lot of the work, make the developer experience as seamless as possible, make it very efficient for them, make it easy for them to try and buy, make it just a great experience and allow them to, or empower them to take on more of the responsibility of getting that App published and in the containers out the door. And that's what we're excited about with the partnership with Docker is that with the number of developers that they have, the work that we do together, and the roadmap that we have is really making that experience just an incredible journey for our developer and that's what we want to continue to make sure we foster. >> Scott, the new relevance of developers, your thoughts. >> Yeah, I would only--building on Peter's point, observed that a lot of the developer expectations are informed by the stack and what's possible. And to your points earlier about the previous waves, John, like, developers are important, but their full potential if you will was perhaps muted or gated because there was not a clean abstraction between the application on the underlying infrastructure. And now, as we know, Dockerization and the surrounding ecosystem of Kubernetes and other tools, we have a much cleaner separation between the Application and the infrastructure, and that allows and set expectations for a much higher cadence of release much faster, time to value, much more agile operations in terms of responding to competitors and the market and your customers. And so with that expectation, how do you unleash that? And this partnership is really key to that, by taking the friction out. As we talked about kind of historical security models and bringing a new model that bring the security way left right into the developers around that experience. And then in some sense, really fulfills that ability to move quickly, react in an agile fashion and have an impact as quickly as possible. >> That's awesome security built into the workflow, automated industry first, guys thanks so much for a great partnership, but the final work at the plugin for the relationship going forward, how's that work is going to be available is integration code is it development? Give a quick plug for what's happening, the relationship and what's happening going forward? >> Look, Docker only succeeds if the ecosystem succeeds. and we're very very proud and humbled to join arms with Peter and the Snyk team as a partner in the security ecosystem. And so you'll see us not only in this integrated developer experience on the command line, which is going to be very, very valuable to developers that we've been talking about, but you'll see us out there promoting the solution in different forms and community groups. And so it doesn't stop and end with the DockerCon experience, look for us in the year ahead to do more and more together. >> Awesome. >> I agree and I think that just culturally and the way the organizations work really well together, I think this is a beginning of a longer journey and a longer partnership we're going to have together with Scott and the team, so we're excited. I think the validation, the early validation we've got from the development teams that we've been talking to around the world, I think there's tremendous desire for this to happen, and we're excited to launch the journey together, with Scott and team. >> It's been a lot of fun watching this progression, like you said, create that headroom, the developable, we'll take it right up and there'll be another step function, more progression. Great job guys. Congratulations on the great partnership >> We need to security built in, we need more creativity. We need that, we need this new modern era to be flourishing. Thanks for your time, appreciate it. >> Thanks John. >> Thank you. >> theCUBE coverage, virtual CUBE coverage of DockerCon 20. I'm John Furrier your host, along with Docker for DockerCon 20 #Docker 20. Thanks for watching and stay tuned for our next segment of DockerCon 20 virtual. (upbeat music)

>> Narrator: From around the globe, it's theCUBE with digital coverage of Dockercon Live 2020, brought to you by Docker and it's ecosystem partners. >> Everyone welcome back to Dockercon 2020, #Docker20. This is theCUBE and Docker's coverage of Dockercon 20. I'm John Furrier in the Palo Alto studios with our quarantine crew, we got a great interview segment here and big news around developer workflow code to cloud. We've got Amanda Silver, Corporate Vice President, product for developer tools at Microsoft and Scott Johnson, the CEO of Docker. Scott had a great Keynote talking about this relationship news has hit about the extension of the Microsoft partnership. So congratulations, Amanda, welcome to theCUBE. >> Thanks for having me. >> Amanda, tell us about what your role is at Microsoft. You guys are well known in the developer community. You had to develop a ecosystem even when I was in college going way back. Very modern now, the cloud is the key, code to cloud, that's the theme. Tell us about your role at Microsoft. >> Yeah, so I basically run the product, Product Design and User Research team that works on our developer tools at Microsoft. And so that includes the Visual Studio product as well as Visual Studio code that's become pretty popular in the last few years but it also includes things like the dotNET runtime and the TypeScript programming language, as well as all of our Azure tooling. >> What's your thoughts on the relationship with Docker? Obviously the news extension of an existing relationship, Microsoft's got a lot of tools, you got a lot of things you guys are doing, bringing the cloud to every business. Tell us about your thoughts on this relationship with Docker? >> Yeah well, we're very excited about the partnership for sure. Our goal is really to make sure that Azure is a fantastic place where all developers can kind of bring their code and they feel welcome. They feel natural. We really see a unique opportunity to make the experience really great for the Docker community by creating more integrated and seamless experience across Docker desktop, Windows and Visual Studio and we really appreciate how Docker has kind of, supported our Windows ecosystem to run in Docker as well. >> Scott, this relationship and an extension with Microsoft is really, I think, impressive and also notable because Microsoft's got so many tools out there and they have so successful with Azure. You guys have been so successful with your developer community but this also is a reflective of the new Docker. Can you share your thoughts on how this partnership with Microsoft, extending the way it is, with the growth of the cloud is a reflection of the new Docker? >> Yeah, absolutely John, it's a great question. One of the things that we've really been focused on since November is fully embracing the ecosystem and all the partnerships and all the possibilities of that ecosystem and part of that is just reality that we're a smaller company now and we can't do it all, nor should we do it all. Part of it's the reality that developers love choice and no one's going to change their minds on choice, and third is just acknowledging that there's so much creativity and so much energy outside the four walls of Docker that we'd be silly not to take advantage of that and welcome it and embrace it and provide that as a phenomenal experience for our developers. So this is a great example of that. The Snyk partnership we announced last week is a great example of that and you're going to see many more partnerships like this going forward that are reflective of exactly this point. >> You've been a visionary on the product side, interviewed before. Also deploying is more important than ever, that whole workflow simplifying, it's not getting complex, people want choice, building code, managing code, deploying code. This has been a big focus of yours. Can you just share your thoughts on where Microsoft comes in? Because they got stuff too, you've got stuff, it all works together. What's your thoughts? >> Right, so it needs to work together because developers want to focus on their app. They don't want to focus on duct taping and stringing together different siloed pools. So you can see in the demo and you'll see in demonstrations later throughout the conference, just the seamless experience that a developer gets in the Docker command line inner operating with Visual Studio Code, with the Docker command line and then deploying to Azure and what's wonderful about the partnership is that both parties put real engineering effort and design effort into making it a great experience. So a lot of the complexities around configuration, around default settings, around security, user management, all of that is abstracted out and taken away from the developers so they can focus on applications and getting those applications deployed to the cloud as quickly as possible. Getting their apps from code to cloud is the watchword or the call to action for this partnership and we think we've really hit it out of the park with the integration that you saw. >> Great validation in the critical part of the workflow you guys been part of. Amanda, we're living in a time we're doing these remote interviews. The COVID crisis has shown the productivity gains of working at home and working, sheltering in place but it also has highlighted the focus of developers, mainly who have also worked at home. They're been kind of used to this, you see the rigs. I saw at Microsoft build some amazing rigs from the studio, so these guys streaming their code demos. This is a Cambrian explosion of new kinds of productivity. You got the world's getting more complex at scale. This is what cloud does. What's your thoughts on this? 'Cause the tooling, there's more tools than ever, right? >> Yeah. >> I still got to deploy code. It's got to be more agile, it's got to be faster, it's got to be at scale. This is what you guys believe in. What's your thinking on all these tooling and abstraction layers? And the end of the day, developers still got to do their job. >> Yeah, well, absolutely. And now even more than ever, I think we've certainly seen over the past few months, a more rapid acceleration of digital transformation that has really happened in the past few years. Paper processes are now becoming digital processes all of a sudden. Everybody needs to work and learn from home and so there's just this rapid acceleration to kind of move everything to support our new remote first lifestyle. But even more so, we now have remote development teams actually working from home as well in a variety of different kinds of environments, whether they're using their own personal machine to connect to their infrastructure or they're using a work issued machine. It's more important than ever that developers are productive but they are productive as a team. Software is a team sport, we all need to be able to work together and to be able to collaborate. And one of the most important aspects of agility for developers is consistency. And what Docker really enables with containerization, is to make the infrastructure consistent and repeatable so that as developers are moving through the lifecycle from their local desktop and developing on their local desktop, to a test environment and to staging and to production, it's really, it's infrastructure for developers as well as operations. And so, that infrastructure, that's completely customizable for what the developers operating system of choice is, what their app stack is, all of those dependencies kind of running together. And so that's what really enables developers to be really agile and have a really fast iteration cycle but also to have that consistency across all of their development team. And we now need to think about things like, how are we actually going to bring on interns for the summer and make sure that they can actually set up their developer boxes in a consistent way that we can actually support them and things like Docker really help with that. >> As your container instances and Visual Studio cloud that you guys have has had great success. There's a mix and match formula here and the other day, developers want to ship the code. What's the message that you guys are sending here with this because I think productivity is one, simplification is the other but as developers, we're on the front lines and they're shipping in real time. This is a big part of the value proposition that you guys bringing to the table. >> Yeah, the core message is that any developer and their code is welcome (laughs) and that we really want to support them, empower them and increase their velocity and the impact that they can have. And so, having things like the fact that the Docker CLI is natively integrated into the Azure experience is a really important aspect of making sure that developers are feeling welcome and feeling comfortable. And now that the Docker CLI tools that are part of Docker desktop have access to native commands that work well with Azure container instances, Azure container instances, if anybody is unfamiliar with that, is the simplest and fastest way to kind of set up containers in Azure and so we believe that developers have really been looking for a really simple way to kind of get containers on Azure and now we have that really consistent experience across our servers, services and our tools. Visual Studio code and Visual Studio extensions make full use of Docker desktop and the Docker CLI so that they can get that combination of the productivity and the power that they're looking for. And in fact, we've integrated these as a design point since very early on in our partnership when we've been partnering with Docker for quite a while. >> Amanda, I want to ask you about the tool chain. We've heard about workflows, making it simpler. Bottom line from a developer standpoint, what's the bottom line for me? What does this mean to me, everyday developer out there? >> I really think it means, your productivity on your terms. And so, Microsoft has been a developer company since the very beginning with Bill Gates and GW Basic. And it's actually similar for Docker. They really have a developer first point of view, which certainly speaks to my heart and so one of the things that we're really trying to do with Docker is to make sure that we can create a workflow that's super productive at every stage of the developer experience, no matter which stack they're actually targeting, whether there's targeting Node or Python, or dotNET and C Sharp or Java, we really want to make sure that we have a super simple experience that you can actually initiate all of these commands, create Docker container images and use the Docker compose files. And then, just kind of do that consistently, as you're deploying it all the way up into your infrastructure in Azure. And the other thing that we really want to make sure is that that even post deployment, you can actually inspect and diagnose these containers and images without having to leave the tool. So we also think about the process of writing the code but also the process of kind of managing the code and remediating issues that might come up in production. And so we really want you to be able to look at containers up in the Azure, that are deployed into Azure and make sure that they're running and healthy and that if something's wrong, that you can actually open up a shell and be in an interactive mode and be able to look at the logs from those containers and even inspect one to see environment variables or other details. >> Yeah, that's awesome. Writing code, managing code and then you got to deploy, right? So what I've been loving about the past generation of Agile is deployment's been faster to play off all the time. Scott, this brings up that the ease of use but you'll want to actually leverage automation. This is the trend that you want to get into. You want to make it easy to write code, manage code but during the deployment phase, that's a big innovation. That's the last point, making that better and stronger. What's your thoughts on simplifying that? >> Well, as a big part of this partnership, John, that Docker and Microsoft embarked on, as you saw from the demo in the keynote, all within the Docker command line, the developer's able to do it in two simple commands, deploy an app, define and compose from their desktop to Azure. And there's a whole slew of automation and pre-configured smart defaults or sane defaults that have gone on behind the scenes and it a lot of hardcore engineering work on part of Docker-Microsoft together to simplify that and make that easy. And that goes exactly to your point, which is, the simpler you can make it, make an abstract way to kind of underline plumbing and infrastructure, the faster Devs can get their application from code to cloud. >> Scott, you've been a product CEO, you've been a product person now you're the CEO but you have a product back when you've been involved with a relationship with Microsoft for a long time. What's the state of the market right now? I see Microsoft has evolved because just the performance, corporate performance, the shift to the cloud has been phenomenal. Now developers getting more empowered, there's more demand for the pressure to put developers to do more and more creativity. So you've seen this evolve, this relationship, what does it mean? >> Yeah, it's honestly a wonderful question, John and I want to thank Amanda and the entire Microsoft team for being long standing partners with us on this journey. So it might not be known to everyone on today's day's event but Microsoft came to the very first Dockercon event way back in June 2014 and I had the privilege of greeting them and welcoming them and then they were full on, ready to see what all the excitement about Docker was about and really embraced it. And you mentioned kind of openness in Microsoft's growth over time in that dimension and we think Docker, together with Microsoft have really shown what an open developer community can do. That started back in 2014 and then we embarked on an open source collaboration around the Docker command line of the Docker engine, bringing that Docker engine from Linux and now moving it to Windows applications. And so all the sudden the promise of write once and use the same primitives, the same formats, the same command lines, as you can with Linux onto Windows applications, we brought that promise to the market. And it's been an ongoing journey together with Microsoft on open standards base, developer facing friendliness, ease of use, fast time to deploy and this partnership that we announced yesterday and we highlighted at the keynote is just another example of that ongoing relationship, laser-like focused on developer productivity and helping teams build great apps. >> Why do you like Azure in the cloud for Docker? Can you share why? >> Well, as Amanda has been sharing, it's super focused on, what are the needs of developers to help them continue to stay focused on their apps and not have their cognitive load burdened by other aspects of getting their apps to the cloud and Azure does a phenomenal job of simplifying and providing sane defaults out of the box. And as we've been talking about, it's also very open to partner integrations like the one we've announced yesterday and highlighted that make it just easy for development teams to choose their tools and build their apps and deploy them onto Azure as quickly as possible. So it's a phenomenal platform for developers and we're very excited and proud to partner with Microsoft on it. >> Amanda on your side, I see Docker's got millions of developers. you guys got millions of developers even more. How do you see the developers in Microsoft's side engaging with Docker desktop and Docker hub? Where does it all fit? I mentioned earlier how I see Docker context really improving the way that individuals and teams work with their environments in making sure that they're consistent but I think this really comes together as we work with Docker desktop and Docker Hub. When developers sign in to Docker Hub from Docker desktop, everything kind of lights up and so they can see all of the images in their repositories and they can also see the cloud environments that they're running them in. And so, once you sign into the Hub, you can see all the contexts that map to the logical environments they have access to, like Dev, NQA and maybe staging. And another use case that's really important is that we can access the same integration environment. So, I can have microservices that I've been working on but I can also see microservices that my teammates and their logs from the services that they've been working on, which I think is really great and certainly helps with team productivity. The other thing too, is that this also really helps with hybrid cloud deployments, where, you might have some on-premises hosted containers and you might have some that's hosted in a public cloud. And so you can see all of those things through your Docker Hub. >> Well, I got to say, I love the code to cloud tagline, I think that's very relevant and catchy. And I think, I guess to me what I'm seeing and I'd love to get your thoughts, Amanda on this is you oversee a key part of Microsoft's business that's important for developers, just the vibe and people are amped up right now. I know people are tensed, anxiety with the COVID-19 crisis but I think people are generally agreeing that this is going to be a massive inflection point for just more headroom needed for developers to accelerate their value on the front lines. What's your personal take on this? You've seen these waves before but now in this time, what are you most excited about? What are you optimistic about? What's your view on the opportunities? Can you share your thoughts, because people are going to get back to work. They're working now remotely but if we go back to hybrid world, they're going to be jamming on projects. >> Yeah, for sure but people are jamming on projects right now and I think that in a lot of ways, developers are first responders in that they are... Developers are always trying to support somebody else. We're trying to support somebody else's workflow and so we have examples of people who are creating new remote systems to be able to schedule meetings in hospitals for the doctors who are actually the first responders taking care of patients but at the end of the day, it's the developer who's actually creating that solution. And so we're being called to duty right now and so we need to make sure that we're actually there to support the needs of our users and that we're basically cranking on code as fast as we can. And to be able to do that, we have to make sure that every developer is empowered and they can move quickly but also that they can collaborate really quickly. And so I think that Docker Hub, Docker kind of helps you ensure that you have that consistency but you also have that connection to the infrastructure that's hosted by your your organization. >> I think you nailed, that's amazing insight. I think that's... The current situation in the community matters because there's a lot of frontline work being done to your point but then we got to rebuild, the modernization is happening as well coming out of this so there's going to be that. And there's a lot of camaraderie going on and massive community involvement I'm seeing more of. The empathy but also now there's going to be the building, the creation, the new creation. So, Scott, this is going to call for more simplicity and to abstract away the complexities. This is the core issue. >> Well, that's exactly right. And it is time to build and we're going to build our way out of this and it is the community that's responding. And so in some sense, Microsoft and Docker are there to support that moory energy and give them the tools to go and identify and have an impact as quickly as possible. I referenced in the keynote, completely bottoms up organic adoption of Docker desktop and Docker Hub in racing to provide solutions against the COVID-19 virus. It's a war against this pandemic that is heavily dependent on applications and data. And there's over 200 projects, community projects on Docker Hub today, where you've got tools and containers and data analysis all in service to the COVID-19 battle that's being fought. And then as you said, John, as we get through the other side, there's entire industries that are completely rethinking their approach that were largely offline before but now see the imperative and the importance of going online. And that tectonic shift, nearly overnight of offline to online behavior and commerce and social and going down the list, that requires new application development. And I'm very pleased about this partnership is that together, we're giving developers the tools to really take advantage of that opportunity and go and build our way out of it. >> Well, Scott, congratulations on a great extended partnership with Microsoft and the Docker brand. I'm a big fan from day one. I know you guys have pivoted on a new trajectory, which is phenomenal, very community oriented, very open source, very open. So congratulations on that. Amanda, thanks for spending the time to come on. I'll give you the final word. Take a minute to talk about what's new at Microsoft for the folks that know Microsoft, know they have a developer mindset from day one. Cloud is exploding, code to cloud. What's the update? What's the new narrative? What should people know about Microsoft with developer community? Can you share some data for the folks that aren't in the community or might want to join or the folks in the community who want to get an update? >> Yeah, it's a great kind of question. Right now, I think we are all really focused on making sure that we can empower developers throughout the world and that includes both those who are building solutions for their organizations today but also, I think we're going to end up with a ton of new developers over this next period, who are really entering the workforce and learning to create digital solutions. Overall, there's a massive developer shortage across the world. There's so much opportunity for developers to kind of address a lot of the needs that we're seeing out of organizations, again, across the world. And so I think it's just a really exciting time to be a developer and my only hope is that basically we're building tools that actually enable them to solve the problem. >> Awesome insight, and thank you so much for your time. Code to cloud developers are cranking away, they're the first responders, going to take care of business and then continue to build out the modern applications. And when you have a crisis like this, people cut right through the noise and get right to the tools that matter. So thanks for sharing the Microsoft-Docker partnership and the things that you guys are working on together. Thanks for your time. >> Thank you. >> Thank you. >> Okay, this is theCUBE's coverage. We are at Dockercon 2020 Digital. This is theCUBE Virtual. I'm John Furrier, bringing all the action, more coverage. Stay with us for more Dockercon Virtual after this short break. (gentle music)

>> announcer: From around the globe. It's the theCUBE with digital coverage of DockerCon live 2020. Brought to you by Docker and its ecosystem partners. >> Welcome back to theCUBE coverage here at the DockerCon virtual headquarters, anchor desks here in the Palo Alto Studios were quarantined in this virtual event of DockerCon. I'm John Furrier, host along with Jenny Bertuccio, John Kreisa, Peter McKee, other folks who are moderating and weaving in and out of the sessions. But here we have a live sessions with Justin Graham, Vice President of the Products group at Docker. Justin, thanks for coming in DockerCon virtual '20. >> Absolutely, happy to be here from my home office in Seattle, Washington where it is almost sunny. >> You had a great backdrop traveler saying in the chat you got a bandwidth, a lot of bandwidth there. Looking good, some island. What a day for Docker global event. 77,000 people registered. It's just been an awesome party. >> It's been great, I could hardly sleep last night. I was up at 5:00 this morning. I was telling my son about it at breakfast. I interrupted his Zoom school. And he talked a little bit about it, so it's been awesome. I've been waiting for this interview slot for the most of the day. >> So yeah, I got to tell the kids to get off, download those gigabytes of new game updates and get off Netflix, I hear you. But you got good bandwidth. Let's get into it, I love your position. VP of Product at a company that's super technical, a lot of software, a lot of cloud. You've got a good view of the landscape of what the current situation is relative to the product, the deals that are going on with this new announced here, sneak Microsoft expansion, multiple clouds as well as the roadmap and community interaction. So you got a lot going on, you've got your fingers in all the action. When you get the keys to the kingdom, as we say in the product side of things, what's the story today from your perspective around DockerCon? What's the most important thing people should know about of what's going on with this new Docker? Obviously, ease of use, we've heard a lot about. What's going on? >> So I'll start with people. We are hyper focused on helping developers and development teams build and ship applications. That's what we're focused on. That's what we wake up every day thinking about. And we double click on that a minute in terms of what that means. If you think about where source control ends and having a running application on some production compute in the Cloud on the other end, there's a whole lot that needs to happen in the middle of those two things. And we hear from our development community and we see from those folks, there's a lot of complexity and choices and options and things in the middle there. And we really want to help streamline the creation of those pipelines to get those apps moving to production as fastly, as quickly as possible. >> And you can see it in some of the results and some of the sessions, one session coming up at around four, around how pipelining with Docker help increase the problem solving around curing cancer, really solving, saving people's lives to the front lines with COVID 19 to business value. So you seeing, again Docker coming back into the fold relative to the simple value proposition of making things super easy for developers, but on top of the mega trend of microservices. So, outside of some of these awesome sessions with his learning, the hardcore sessions here at DockerCon around microservices from monitoring, you name it, not a trivial thing cause you've got stateless and state, all kinds of new things are going on with multiple clouds. So not an easy-- >> No. >> road to kind of grok or understand you have to manage that. What are people paying attention to? What is happening? I think, first off I'll say, one of the things that I'm super passionate about is increasing access to technology, so the greatest and best ideas can get bubbled up to the top and expose no matter where they come from, whom they come from, et cetera. And I think one of the things that makes that harder, that makes that complex is just how much developers need to understand or even emerging developers need to understand. Just to even get started. Languages, IDEs, packaging, building where do you ship to? If you pick a certain powder end point, you have to understand networking and storage and identity models are just so much you have to absorb. So we're hyper focused on how can we make that complex super easy. And these are all the things that we get asked questions on. And we get interacted with on our public roadmap in other places to help with. So that's the biggest things that you're going to see coming out of Docker starting now and moving forward. We'll be serving that end. >> Let's talk about some of the new execution successes you guys had. Honestly, Snyk is security shifting left, that's a major, I think a killer win for Snyk. Obviously, getting access to millions of developers use Docker and vice versa. Into the shifting left, you get to security in that workflow piece. Microsoft expanding relationship's interesting as well because Microsoft's got a robust tech developer ecosystem. They have their own tools. So, you see these symbiotic relationship with Docker, again, coming into the fold where there's a lot of working together going on. Explain that meaning, what does that mean? >> So you're on the back of the refocus Docker in our hyperfocus on developers and development teams, one of the core tenants of the how. So before that was the what. This is the how we're going to go do it. Is by partnering with the ecosystem as much as possible and bringing the best of breed in front of developers in a way that they can most easily consume. So if you take the Snyk partnership that was just a match, a match made in developer dopamine as a Sean Connolly, would say. We're hyper focused on developers and development teams and Snyk is also hyperfocused on making it as easy as possible for developers and development teams to stay secure ship, fast and stay secure. So it really just matched up super well. And then if you think, "Well, how do we even get there in the first place?" Well, we launched our public roadmap a few months ago, which was a first that Docker has ever done. And one of the first things that comes onto that public roadmap is image vulnerability scanning. For Docker, at that time it was really just focused on Docker Hub in terms of how it came through the roadmap. It got up voted a bunch, there has been some interaction and then we thought, "Well, why just like checking that box isn't enough," right? It's just checking the box. What can we do that really brings sort of the promise of the Docker experience to something like this? And Sneak was an immediate thought, in that respect. And we just really got in touch with them and we just saw eye to eye almost immediately. And then off off the rest went. The second piece of it was really around, well why just do it in Docker Hub? What about Docker Desktop? It's downloaded 80,000 times a week and it's got 2.2 million active installations on a weekly basis. What about those folks? So we decided to raise the bar again and say, "Hey, let's make sure that this partnership includes "not only Docker Hub but Docker Desktop, so you'll be able, when we launch this, to scan your images locally on Docker Desktop. >> Awesome, I see getting some phone calls and then you got to hit this, hit the end button real quick. I saw that in there. I've got an interesting chat I want to just kind of lighten things up a little bit from Brian Stevenson. He says, "Justin, what glasses are those?" (Justin laughing) So he wants to know what kind of glasses you're wearing. >> They're glasses that I think signal that I turned 40 last year. >> (laughs) I'd say it's for your gaming environments, the blue light glasses. >> But I'm not going to say where they came from because it's probably not going to engender a bunch of positive good. But they're nice glasses. They help me see the computer screen and make sure that I'm not a bad fingering my CLI commands >> Well as old guys need the glasses, certainly I do. Speaking of old and young, this brought up a conversation since that came up, I'll just quickly riff into this cause I think it's interesting, Kelsey Hightower, during the innovation panel talked about how the developers and people want to just do applications, someone to get under the hood, up and down the stack. I was riffing with John Chrysler, around kind of the new generation, the kids coming in, the young guns, they all this goodness at their disposal. They didn't have to load Linux on a desktop and Rack and Stack servers all that good stuff. So it's so much more capable today. And so this speaks to the modern era and the expansion overall of opensource and the expansion of the people involved, new expectations and new experiences are required. So as a product person, how do you think about that? Because you don't want to just build for the old, you got to build for the new as well as the experience changes and expectations are different. What's your thoughts around that? >> Yeah, I think about sort of my start in this industry as a really good answer to that. I mean, I remember as a kid, I think I asked for a computer for every birthday and Christmas from when I was six, until I got one given to me by a friend's parents in 1994, on my way off to boarding school. And so it took that long just for me to get a computer into my hands. And then when I was in school there wasn't any role sort of Computer Science or coding courses until my senior year. And then I had to go to an Engineering School at Rensselaer city to sort of get that experience at the time. I mean, just to even get into this industry and learn how to code was just, I mean, so many things had to go my way. And then Microsoft hired me out of college. Another thing that sort of fell my way. So this work that we're doing is just so important because I worked hard, but I had a lot of luck. But not everybody's going to have some of that, right? Have that luck. So how can we make it just as easy as possible for folks to get started wherever you are. If you have a family and you're working another full time job, can you spend a few hours at night learning Docker? We can help you with that. Download Docker Desktop. We have tutorials, we have great docs, we have great captains who teach courses. So everything we're doing is sort of in service of that vision and that democratization of getting into the ideas. And I love what Kelsey, said in terms of, let's stop talking about the tech and let's stop talking about what folks can do with the tech. And that's very, very poignant. So we're really working on like, we'll take care of all the complexity behind the scenes and all of the VMs and the launching of containers and the network. We'll try to help take care of all that complexity behind the curtain so that you can just focus on getting your idea built as a developer. >> Yeah, and you mentioned Kelsey, again. He got a great story about his daughter and Serverless and I was joking on Twitter that his daughter convinced them that Serverless is great. Of course we know that Kelsey already loves Serverless. But he's pointing out this developer dopamine. He didn't say that's Shawn's word, but that's really what his daughter wanted to do is show her friends a website that she built, not get into, "Hey look, I just did a Kubernetes cluster." I mean it's not like... But pick your swim lane. This is what it's all about now. >> Yeah, I hope my son never has to understand what a service mesh is or proxy is. Right? >> Yeah. >> I just hope he just learn the language and just learns how to bring an idea to life and all the rest of it is just behind me here. >> When he said I had a parenting moment, I thought he's going to say something like that. Like, "Oh my kid did it." No, I had to describe whether it's a low level data structure or (laughs) just use Serverless. Shifting gears on the product roadmap for Docker, can you share how folks can learn about it and can you give some commentary on what you're thinking right now? I know you guys put on GitHub. Is there a link available-- >> Absolutely, available. Github.com/docker/roadmap. We tried to be very, very poignant about how we named that. So it was as easy as possible. We launched it a few months ago. It was a first in terms of Docker publicly sharing it's roadmap and what we're thinking and what we're working on. And you'll find very clear instructions of how to post issues and get started. What our code of conduct is. And then you can just get started and we even have a template for you to get started and submit an issue and talk to us about it. And internally my team and to many of our engineers as well, we triaged what we see changing and coming into the public roadmap two to three times a week. So for a half an hour to 45 minutes at a time. And then we're on Slack, batting around ideas that are coming in and saying how we can improve those. So for everyone out there, we really do pay attention to this very frequently. And we iterate on it and the image vulnerability scannings one of those great examples you can see some other things that we're working on up there. So I will say this though, there has been some continual asks for our Lennox version of Docker Desktop. So I will commit that, if we get 500 up votes, that we will triage and figure out how to get that done over a period of time. >> You heard 500 up votes to triage-- >> 500 >> You as get that. And is there a shipping date on that if they get the 500 up votes? >> No, no, (John laughs) you went to a shipping date yet, but it's on the public roadmap. So you'll know when we're working on it and when we're getting there. >> I want before I get into your session you had with the capital, which is a very geeky session getting under the hood, I'm more on the business side. The tail wind obviously for Docker is the micro services trend. What containers has enabled is just going to continue to get more awesome and complex but also a lot of value and agility and all the things you guys are talking about. So that obviously is going to be a tailwind for you. But as you guys look at that piece of it, specifically the business value, how is Docker positioned? Because a of the use cases are, no one really starts out microservices from a clean sheet of paper that we heard some talks here DockerCon where the financial services company said, "Hey, it's simple stack," and then it became feature creep, which became a monolith. And then they had to move that technical debt into a much more polyglot system where you have multiple tools and there's a lot of things going on, that seems to be the trend that also speaks to the legacy environment that most enterprises have. Could you share your view on how Docker fits into those worlds? Because you're either coming from a simple stack that more often and got successful and you're going to go microservice or you have legacy, then you want to decouple and make it highly cohesive. So your thoughts. >> So the simple answer is, Docker can help on both ends. So I think as these new technologies sort of gain momentum and get talked about a bunch and sort of get rapid adoption and rapid hype, then they're almost conceived to be this wall that builds up where people start to think, "Well, maybe my thing isn't modern enough," or, "Maybe my team's not modern enough," or, "Maybe I'm not moderate enough to use this." So there's too much of a hurdle to get over. And that we don't see that at all. There's always a way to get started. Even thinking about the other thing, and I'd say, one we can help, let us know, ping us, we'll be happy to chat with you, but start small, right? If you're in a large enterprise and you have a long legacy stack and a bunch of legacy apps, think about the smallest thing that you can start with, then you can begin to break off of that. And as a proof of concept even by just downloading Docker Desktop and visual studio code and just getting started with breaking off a small piece, and improve the model. And I think that's where Docker can be really helpful introducing you to this paradigm and pattern shift of containers and containerized packaging and microservices and production run time. >> And certainly any company coming out of his post pandemic is going to need to have a growth strategy that's going to be based on apps that's going to be based on the projects that they're currently working, double down on those and kind of sunset the ones that aren't or fix the legacy seems to be a major Taylor. >> The second bit is, as a company, you're going to also have to start something new or many new things to innovate for your customers and keep up with the times and the latest technology. So start to think about how you can ensure that the new things that you're doing are starting off in a containerized way using Docker to help you get there. If the legacy pieces may not be able to move as quickly or there's more required there, just think about the new things you're going to do and start new in that respect. >> Well, let's bring some customer scenarios to the table. Pretend I'm a customer, we're talking, "Hey Justin, you're looking good. "Hey, I love Docker. I love the polyglot, blah, blah, blah." Hey, you know what? And I want to get your response to this. And I say, "DevOps won't work here where we are, "it's just not a good fit." What do you say when you hear things like that? >> See my previous comment about the wall that builds up. So the answer is, and I remember hearing this by the way, about Agile years ago, when Agile development and Agile processes began to come in and take hold and take over for sort of waterfall processes, right? What I hear customers really saying is, "Man, this is really hard, this is super hard. "I don't know where to start, it's very hard. "How can you help? "Help me figure out where to start." And that is one of the things that we're very very very clearly working on. So first off we just, our docs team who do great work, just made an unbelievable update to the Docker documentation homepage, docs.docker.com. Before you were sort of met with a wall of text in a long left navigation that if you didn't know what you were doing, I would know where to go. Now you can go there and there's six very clear paths for you to follow. Do you want to get started? Are you looking for a product manual, et cetera. So if you're just looking for where to get started, just click on that. That'll give you a great start. when you download Docker Desktop, there's now an onboarding tutorial that will walk you through getting your first application started. So there are ways for you to help and get started. And then we have a great group of Docker captains Bret Fisher, many others who are also instructors, we can absolutely put you in touch with them or some online coursework that they deliver as well. So there's many resources available to you. Let us help you just get over the hump of getting started. >> And Jenny, and on the community side and Peter McKee, we're talking about some libraries are coming out, some educational stuff's coming around the corner as well. So we'll keep an eye out for that. Question for you, a personal question, can you share a proud devOps Docker moment that you could share with the audience? >> Oh wow, so many to go through. So I think a few things come to mind over the past few weeks. So for everyone that has no... we launched some exciting new pricing plans last week for Docker. So you can now get quite a bit of value for $7 a month in our pro plan. But the amount of work that the team had to do to get there was just an incredible thing. And just watching how the team have a team operated and how the team got there and just how they were turning on a dime with decisions that were being made. And I'm seeing the same thing through some of our teams that are building the image vulnerability scanning feature. I won't quote the number, but there's a very small number of people working on that feature that are creating an incredible thing for customers. So it's just how we think every day. Because we're actually almost trying to productize how we work, right? And bring that to the customer. >> Awesome, and your take on DockerCon virtual, obviously, we're all in this situation. The content's been rich on the site. You would just on the captains program earlier in the day. >> Yes. >> Doctor kept Brett's captain taught like a marathon session. Did they grill you hard or what was your experience on the captain's feed? >> I love the captain's feed. We did a run of that for the Docker birthday a few months ago with my co-worker Justin Cormack. So yes, there are two Justin's that work at Docker. I got the internal Justin Slack handle. He got the external, the community Slack Justin handle. So we split the goods there. But lots of questions about how to get started. I mean, I think there was one really good question there. Someone was saying asking for advice on just how to get started as someone who wants to be a new engineer or get into coding. And I think we're seeing a lot of this. I even have a good friend whose wife was a very successful and still is a very successful person in the marketing field. And is learning how to code and wants to do a career switch. Right? >> Yeah. >> So it's really exciting. >> DockerCon is virtual. We heard Kelsey Hightower, we heard James Governor, talk about events going to be more about group conventions getting together, whether they're small, medium, or large. What's your take on DockerCon virtual, or in general, what makes a great conference these days? Cause we'll soon get back to the physical space. But I think the genie's out of the bottle, that digital space has no boundaries. It's limitless and creativity. We're just scratching the surface. What makes a great event in your mind? >> I think so, I go back to thinking, I've probably flown 600,000 miles in the past three years. Lots of time away from my family, lots of time away from my son. And now that we're all in this situation together in terms of being sheltered in place in the global pandemic and we're executing an event that has 10 times more participation from attendees than we had in our in person event. And I sat back in my chair this morning and I was thinking, "Did I really need to fly that 600,000 miles "in the past three years?" And I think James Governor, brought it up earlier. I really think the world has changed underneath us. It's just going to be really hard to... This will all be over eventually. Hopefully we'll get to a vaccine really soon. And then folks will start to feel like world's a little bit more back to "normal" but man, I'm going to really have to ask myself like, "Do I really need to get on this airplane "and fly wherever it is? "Why can't I just do it from my home office "and give my son breakfast and take them to school, "and then see them in the evening?" Plus second, like I mentioned before in terms of access, no in person event will be able to compete ever with the type of access that this type of a platform provides. There just aren't like fairly or unfairly, lots of people just cannot travel to certain places. For lots of different reasons, monetary probably being primary. And it's not their job to figure out how to get to the thing. It's our job to figure out how to get the tech and the access and the learning to them. Right? >> Yeah (murmurs) >> So I'm super committed to that and I'll be asking the question continually. I think my internal colleagues are probably laughing now because I've been beating the drum of like, "Why do we ever have to do anything in person anymore?" Like, "Let's expand the access." >> Yeah, expand the access. And what's great too is the CEO was in multiple chat streams. So you could literally, it's almost beam in there like Star Trek. And just you can be more places that doesn't require that spatial limitations. >> Yeah. >> I think face to face will be good intimate more a party-like environment, more bonding or where social face to face is more impactful. >> We do have to figure out how to have the attendee party virtually. So, we have to figure out how to get some great electronic, or band, or something to play a virtual show, and like what the ship everybody a beverage, I don't now. >> We'll co-create with Dopper theCUBE pub and have beer for everybody if need they at some point (laughs). Justin, great insight. Thank you for coming on and sharing the roadmap update on the product and your insights into the tech as well as events. Appreciate it, thank you. >> Absolutely, thank you so much. And thanks everyone for attending. >> Congratulations, on all the work on the products Docker going to the next level. Microservices is a tailwind, but it's about productivity, simplicity. Justin, the product, head of the product for Docker, VP of product on here theCUBE, DockerCon 2020. I'm John Furrier. Stay with us for more continuous coverage on theCUBE track we're on now, we're streaming live. These sessions are immediately on demand. Check out the calendar. There's 43 sessions submitted by the community. Jump in there, there are own container of content. Get in there, pun intended, and chat, and meet people, and learn. Thanks for watching. Stay with us for more after this break. (upbeat music)

>>From around the globe. It's the queue with digital coverage of Docker con live 2020 brought to you by Docker and its ecosystem partners. >>Okay, everyone. Welcome back. We're in between segments, we just had Sydney from engine on Jenny, Peter. We're getting down to the last stretch. So our last little segment, before we go to the full wrap up where Jenny, you're going to give away the awards, Peter going to give it away. The awards for the captains, the community. How are you guys feeling? >>Right? Um, I'm feeling great. Peter, how about you? >>Awesome. It's been, it's been fun. Well, Peter, your internet celebrity. Now I hear, I don't know. Is there a special tweet we want to show? I think so. Okay. You see that tweet? It says you're internet famous. Your mom and dad are watching your presentation. Jenny, can you read that? Yeah. >>Yeah. And to be fair, right? They didn't tweet it. They, uh, they watched either session and, and joined and typed in the comments, even though, uh, they had to ask if he was speaking English. Cause they didn't understand anything. He was saying. >>I saw in the chat, I saw my dad's name go by and just, >>I feed her, but wait a minute. And then my wife >>Came in later, said, yeah, your mom and dad are watching your talk. Do we, do we ever stop parenting? >>I don't. Well, I had the opposite effect. I was in one of the sessions and I see a great comment. I'm like, who wrote this? It's my son, Alec farrier, like son, get out of the chat. He said, it's a dope. He said, it's a dope session. It could have been worse. Went in totally random. So it was good. Just look at it, which everywhere the cube and dr. Khan, what a great, uh, no boundaries, age geography has been. I'm really blown away guys. I really gotta say I'm super impressed with the community content program you put together. It's been so much fun. I learned so much. And so appreciate it. Thank you. >>Oh, thank you. I have to agree. Uh, Amanda silver said earlier that coding is the, and you know, Docker con is a team sport too. Uh, I have to take some time to think all the people, uh, that have participated in helped make this event so great. And we'll definitely do it again as we give out the community awards at the end. Okay. I guess 40 minutes from now, but thank you to the doctor theme. Um, many of them have been awakened for hours and hours, hours helping engage and have a great time. Thank you. Okay. Okay. An awesome platform. Rocks scheduling is next level. Um, and the captains, right? I don't know if anyone's had the chance that's watching to go check out the captain stream, especially Brett Fisher. Who's been on all day and he's been so involved in helping us plan to make sure that this is a conversation and not a large webinar. Right. Um, and then our sponsors, we could not have done this without our sponsors. They've been delivering great talks. They're all on demand, uh, except for the one coming up. So make sure to catch those. They'll have giveaways as well, um, that you can, that you can join into two more speakers. You've done awesome, uh, content and production. And then of course the thoughtfulness of the community, right. Thank you for bringing it here today, around the world. >>That's awesome. And I always just say the content presentations were really, really good. The graphics there's templates, but the work that was put into the video and the demos really just next level, as you said. So really just great. I mean, that makes the conference is the presentation. So those talks were engaging. Um, the comments were awesome. Again, I learned a ton and I love love when it's dynamic like that. Uh, Peter, you gotta be psyched developer relations, any, any new insights on the, uh, from the devs? >>Oh, it was great. Great talks. A lot of great. And I was really, really surprised with the chat that the interaction was tremendous. Uh, and I can't believe I used tremendous, but we'll just skip that anyways. Um, but also check out, uh, hashtag Docker con jobs. If you're looking for a job or if you have openings, please, please, uh, hashtag that in your, in your tweets, um, want to help the community out as much as possible. There's a ton of work out there. Just gotta help connect everybody and love to be part of that for sure. >>Yeah. Just so you know, in case you missed the Justin Warren who was live said on live cube, Docker TV, that if he gets 500 upvotes on Linux for Docker, desktop, I think it was. Or was it hub? Might've been desktop. I think he'll triage it out. So there it is. >>All right. I hope the internet heard that cause that's a popular one for sure. Yeah. >>He was on the record and he leaned in on that too. He said it like that. So he meant cool. Any other, uh, shout outs? I mean, I thought Brad was great. Um, the, his, uh, posse, uh, captains were amazing. Um, good feedback there. So gruesome some great chit chatter on that. Um, I didn't have a chance to peek into the session because we're hosting these mainstreams, but yeah. What are you hearing on the captains? >>Uh, tons of knowledge being dropped on that channel for sure. And really great in depth conversations there, uh, answering questions, interacting with the audience. Uh, and you know, a lot of these captains are teachers, uh, as their, as their day job. And a lot of them have, uh, fabulous Docker and Kubernetes content and are running sales right now. So if you do want learn more, if you like, what you heard today, definitely check out right? The horses are on sale this week or under $10, a huge investment in your future. And then Manning books is also running a promotion, a DTW Docker 20 for 40% off their content and a dr. Popkin Elton Stoneman, Jeff Nicola they'll have content there as well. And then Nigel, uh, is, is, has a number of training, uh, courses and, and books as well to check out. Um, and then the captains are running a charity stream. Awesome. People have been donating all day. It's been awesome. Uh, Docker's going to make sure that we reach our $10,000 goal. They wanted to announce that as well. >>I noticed cockroach labs had a similar thing for women for coding. They had another kind of virtual bag swipe. So check them out. They're donating cash as well to women who code. Okay. >>Right. >>Which is very cool. Um, anything else that we missed? Swag giveaways? >>I have one little, um, little comment, a little secret. So I don't know if anybody's caught it yet, Jenny, but if you go back and watch the, the, uh, you know, with Scott, there might be a surprise in there and anybody that finds it first and tweets me might have something for you. >>So Easter egg in there. Is there something going on there? >>I went on, I don't know. I'm just, just saying, >>Okay. All right. Check out the keynote. That was a pro tip right there for everyone's watching. So if you're watching this stream right now, as we get into our awesome next segment, which is going to be really one of my favorites, the children's cancer Institute, this was not only a moving segment from an impact standpoint, but talking about the people that interns and young developers really solving a big problem with Docker, this is a really high impact statement. So that segment, so, so watch it guys. Thanks so much. We'll see. On the wrap up after this next segment, of course, does the catalog of content in the schedule when it's not streaming, it becomes a catalog. So if you're watching it, check out all the sessions, we'll see you in the wrap up.

>>From around the globe. It's the view with digital coverage of Docker con live 2020 brought to you by Docker and its ecosystem partners. >>LeBron. Welcome back to DockerCon 2020 hashtag Docker 20 this is the cube and Dockers coverage of Docker con 20 I'm Sean for you and the Palo Alto studios with our quarantine crew. We've got a great interview segment here in big news around developer workflow code to cloud. We've got Amanda silver corporate vice president, product for developer tools at Microsoft and Scott Johnson, the CEO of Docker. Scott had a great keynote talking about this relationship news has hit about the extension of the Microsoft partnership. So congratulations Amanda. Welcome to the cube. >>Thanks for having me. >>Amanda, tell us a bit about what your role is at Microsoft. You guys are well known in the developer community to develop an ecosystem when even when I was in college going way back, very modern. Now cloud is, is the key code to cloud. That's the theme. Tell us about your role at Microsoft. >>Yeah. So I basically run the product, uh, product design and user research team that works on our developer tools that Microsoft and so that includes the visual studio product as well as visual studio code. Um, that's become pretty popular in the last few years, but it also includes things like the.net runtime and the TypeScript programming language as well as all of our Azure tooling. >>What's your thoughts on the relationship with Docker? I'll show you the news extension of an existing relationship. Microsoft's got a lot of tools. You've got a lot of things you guys are doing, bringing the cloud to every business. Tell us about your thoughts on this relationship with Donker. >>Yeah, well we're very excited about the partnership for sure. Um, you know, our goal is really to make sure that Azure is a fantastic place where all developers can kind of bring their code and they feel welcome. They feel natural. Uh, we really see a unique opportunity to make the experience really great for Docker, for the Docker community by creating more integrated and seamless experience across Docker, desktop windows and visual studio. And we really appreciate how, how Docker is kind of, you know, supported our windows ecosystem to run in Docker as well. >>Scott, this relationship and an extension with Microsoft is really, uh, I think impressive and also notable because Microsoft's got so many, so many tools out there and they have so successful with Azure. You guys have been so successful with your developer community, but this also is reflective of the new Docker. Uh, could you share your thoughts on how this partnership with Microsoft extending the way it is with the growth of the cloud is a reflection of the new Docker? >>Yeah, absolutely. John's great question. One of the things that we've really been focused on since November is fully embracing the ecosystem and all the partnerships and all the possibilities of that ecosystem. And part of that is just reality. That we're a smaller company now and we can't do it all, nor should we do it all. Part of us. The reality that developers love voice and no one's gonna change their minds on choice. And third is just acknowledging that there's so much creativity and so much energy. The four walls of Docker that we'd be building, not the big advantage of that and welcome it and embrace it and provide that as a phenomenal experience part of Alfred's. So this is a great example of that. The sneak partnership we announced last week is a grant to have that and you're going to see many more of uh, partnerships like this going forward that are reflective of exactly this point. >>You've been a visionary on the product side of the interviewed before. Also deploying is more important than ever. That whole workflow, simplifying, it's not getting complex. People want choice, building code, managing code, deploying code. This has been a big focus of yours. Can you just share your thoughts on where Microsoft comes in because they got stuff too. You've got stuff, it all works together. What's your thoughts? >>Right? So it needs to work together, right? Because developers want to focus on their app. They don't want to focus on duct taping and springing together different siloed pools, right? So you can see in the demo and you'll see in, uh, demonstrations later throughout the conference. Just the seamless experience that a developer gets in the document man line inter-operating with visual studio code with the Docker command line and then deploying to Azure and what's what's wonderful about the partnership is that both parties put real engineering effort and design effort into making it a great experience. So a lot of the complexities around the figuration around default settings around uh, security, user management, all of that is abstracted out and taken away from the developer so they can focus on applications and getting those applications deployed to the proudest quickly as possible. Getting their app from code to cloud is the wok word or the or the call to action for this partnership. And we think we really hit it out of the park with the integration that you saw, >>Great validation and a critical part of the workflow. You guys have been part of Amanda, we're living in a time we're doing these remote interviews. The coven crisis has shown the productivity gains of working at home and working in sheltering in place, but also as highlighted, the focus of developers mainly who have also worked at home. They've kind of used to this. Do you see the rigs? I saw her at Microsoft build some amazing rigs from the studio. So these guys streaming their code demos. This is, um, a Cambrin explosion of new kinds of productivity. And yet the world's getting more complex at scale. This is what cloud does. What's your thoughts on this? Cause the tooling is more tools than ever, right? So I still gotta deploy code. It's gotta be more agile. It's gotta be faster. It's gotta be at scale. This is what you guys believe in. What's your thinking on all these tooling and abstraction layers and the end of the day, don't you still got to do their job? >>Yeah, well, absolutely. And now, even more than ever. I mean, I think we've, we've certainly seen over the past few months, uh, uh, a more rapid acceleration of digital transformation. And it's really happened in the past few years. Uh, you know, paper processes are now becoming digit digital processes. All of a sudden, you know, everybody needs to work and learn from home. And so there's just this rapid acceleration to kind of move everything to support our new remote lifestyle. Um, but even more so, you know, we now have remote development teams actually working from home as well in a variety of different kinds of, uh, environments. Whether they're using their own personal machine to connect to their infrastructure or they're using a work issued machine. You know, it's more important than ever that developers are productive, but they are productive as a team. Right? Software is a team sport. >>We all need to be able to work together and to be able to collaborate. And one of the most important aspects of agility for developers is consistency. And, uh, what Docker really enables is, uh, with, with containerization is to make the infrastructure consistent and repeatable so that as developers are moving through the life cycle from their local, local dev desktop and developing on their local desktop to a test environment and to staging and to production, it's really, it's infrastructure of or, or developers as well as operations. And so it's that, that infrastructure that's completely customizable for what the developer's operating system of choices, what their app stack is, all of those dependencies kind of running together. And so that's what really enables developers to be really agile and have a really, really fast iteration cycle but also to have that consistency across all of their development team. And you know, we, we now need to think about things like how are we actually going to bring on interns for the summer, uh, and make sure that they can actually set up their developer boxes in a consistent way that we can actually support them. And things like Docker really helped with that >>As your container instances and a visual studio cloud that you guys have has had great success. Um, there's a mix and match formula here. At the end of the day, developers want to ship the code. What's the message that you guys are sending here with this? Because I think productivity is one, simplification is the other, but as developers on the front lines and they're shipping in real time, this is a big part of the value proposition that you guys are bringing to the table. >>Yeah, I mean the, the core message is that any developer and their code is welcome, uh, and that we really want to support them and power them and increase their velocity and the impact that they can have. Um, and so, you know, having things like the fact that the Docker CLI is natively integrated into the Azure experience, uh, is a really important aspect of making sure that developers are feeling welcome and feeling comfortable. Um, and now that the Docker CLI tools are, that are part of Docker desktop, have access to native commands that work well with Azure container instances. Uh, Azure container instances, if anybody's on familiar with that, uh, is the simplest and fastest way to kind of set up containers and Azure. And, and so we believe that developers have really been looking for a really simple way to kind of get containers on Azure. And now we that really consistent experience across our service services and our tools and visual studio code and visual studio extensions make full use of Docker desktop and the Docker CLI so that they can get that combination of the productivity and the power that they're looking for. And in fact, we've, we've integrated these as a design point since very early on in our partnership when we've been partnering with, with Docker for quite a while. >>Amanda, I want to ask you about the, the, the, the tool chain. We've heard about workflows, making it simpler, bottom line, from a developer standpoint, what's the bottom line for me? What does this mean to me? Uh, every day developer out there? >>Um, I, I mean, I really think it means you know, your productivity on your terms. Um, and so, you know, Microsoft has been a developer company since the very, very beginning with, you know, bill Gates and, and, uh, GW basic. Um, and it's actually similar for Docker, right? They really have a developer first point of view, uh, which certainly speaks to my heart. And so one of the things that we're really trying to do with, with Docker is to make sure that we can create a workflow that's super productive at every stage of the developer experience, no matter which stack they're actually targeting, whether there's targeting node or Python or.net and C-sharp or Java. Uh, we really want to make sure that we have a super simple experience that you can actually initiate all of these commands, create, you know, Docker container images and use the compose Docker compose files. >>Um, and then, you know, just kind of do that consistently as you're deploying it all the way up into your infrastructure in Azure. And the other thing that we really want to make sure is that that even post deployment, you can actually inspect and diagnose these containers and images without having to leave the tool. Um, so we, we also think about the process of writing the code, but also the process of kind of managing the code and remediating issues that might come up in production. And so, you know, we really want you to be able to look at containers up in the Azure. Uh, up that are deployed into Azure and make sure that they're running and healthy and that if there, if something's wrong, that you can actually open up a shell and be in an interactive mode and be able to look at the logs from those containers and even inspect when to see environment variables or other details. >>Yeah, that's awesome. You know, writing code, managing code, and then you've got to deploy, right? So what I've been loving about the, the past generation of agile is deployment's been fast to deploy all the time. Scott, this brings up that the ease of use, but you want to actually leverage automation. This is the trend that you want to get in. You want, you don't want, you want to make it easy to write code, manage code. But during the deployment phase, that's a big innovation. That's the last point. Making that better and stronger. What's your thoughts on simplifying that? >>So that was a big part of this partnership, John, that the Docker in Microsoft embarked on and as you saw from the demo and the keynote, um, all within the man line, the developers able to do in two simple commands, deploy an app, uh, defining compose from the desktop to Azure and there's a whole slew of automation and pre-configured smart defaults or sane defaults that have gone on behind the scenes and that took a lot of hardcore engineering work on part of Docker and Microsoft together to simplify that and make that easy and that, that goes exactly to your point. We just like the simpler you can make it more, you can abstract a way to kind of underlying plumbing and infrastructure. The faster devs can get there. Their application from code to cloud. >>Scott, you've been a product CEO, you've been a product person, a CEO, but you have a product background. You've been involved with the relationship with Microsoft for a long time. What's the state of the market right now? I mean, obviously Microsoft has evolved. Look at just the performance corporate performance. The shift to the cloud has been phenomenal. Now developers getting more empowered, there's more demand for the pressure to put on developers to do more and more, more creativity. So you've seen this evolve, this relationship, what does it mean? >>Yeah, it's honestly a wonderful question, John. And I want to thank Amanda and the entire Microsoft team for being long standing partners with us on this journey. So it's might not be known to everyone on today's, uh, day's event. But Microsoft came to the very first Docker con event, uh, way back in June, 2014 and I had the privilege of, of reading them and welcoming them and they're, they were full on ready to see what all the excitement about Docker was about and really embrace it. And you mentioned kind of openness and Microsoft's growth over that, uh, over time in that dimension. And we think kind of Docker together with Microsoft have really shown what an open developer community can do. And that started back in 2014 and then we embarked on an open source collaboration around the Docker command line of the Docker engine, bringing that Docker engine from Linux and now moving it to windows applications. And so all of a sudden the promise of right ones and use the same primitives, the same formats, the same fan lines, uh, as you can with Linux onto windows applications. We brought that promise to the market and it's been an ongoing journey together with Microsoft of open standards based, developer facing friendliness, ease of use, fast time to deploy. And this, this partnership that we announced yesterday and we highlighted at the keynote is just another example of that ongoing relationship laser like focused on developer productivity and helping teams build great apps. >>Why do you like Azure in the cloud for Docker? Can you share why? >>Well, it's as Amanda has been sharing, it's super focused on what are the needs of developers to help them continue to stay focused on their apps and not have their cognitive load burdened by other aspects of getting their apps to the cloud. And Azure, phenomenal job of simplifying and providing sane defaults out of the box. And as we've been talking about, it's also very open to partner like the one we've announced >>Yesterday and highlighted, you know, but >>Uh, make it just easy for development teams to choose their tools and build their apps and deploy them onto Azure. It's possible. So, uh, it's, it's a phenomenal plan, one for developers and we're very excited and proud of partner with Microsoft on it. >>Amanda, on your side, I see DACA has got millions of developers. You guys got millions of developers even more. How do you see the developers in Microsoft side engaging with Docker desktop and Docker hub? Where does it all fit? >>I think it's a great question. I mean, I mentioned earlier how the Docker context can help individuals and teams kind of work in their environments work. Let me try that over. I mentioned earlier how I, how I see Docker context really improving the way that individuals and teams work with their environments and making sure that they're consistent. But I think this really comes together as we work with Docker desktop and Docker hub. Uh, when developers sign into Docker hub from Docker desktop, everything kind of lights up. And so they can see all of the images in their repositories and they can also see the cloud environments they're running them in. And so, you know, once you sign into the hub, you can see all the contexts that map to the logical environments that they have access to like dev and QA and maybe staging. And another use case that's really important is that, you know, we can access the same integration environment. >>So, so I could have, you know, microservices that I've been working on, but I can also see microservices that my, my teammates and their logs, uh, from the services that they've been working on, which I think is really, really great and certainly helps with, with team productivity. The other thing too is that this also really helps with hybrid cloud deployments, right? Where, you know, you might have some on premises, uh, hosted containers and you might have some that's hosted in a public cloud. And so you can see all of those things, uh, through your Docker hub. >>Well, I got to say I love the code to cloud tagline. I think that's very relevant and, and catchy. Um, and I think, I guess to me what I'm seeing, and I'd love to get your thoughts, Amanda, on this, as you oversee a key part of Microsoft's business that's important for developers, just the vibe and people are amped up right now. I know people are tense and anxiety with the covert 19 crisis, but I think people are generally agreeing that this is going to be a massive inflection point for just more headroom needed for developers to accelerate their value on the front lines. What's your personal take on this and you've seen these ways before, but now in this time, what are you most excited about? What are you optimist about? What's your view on the opportunities? Can you share your thoughts? Because people are going to get back to work or they're working now remotely, but when we go back to hybrid world, they're going to be jamming on projects. >>Yeah, for sure. But I mean, people are jamming on projects right now. And I think that, you know, in a lot of ways, uh, developers are our first responders in, you know, in that they are, developers are always trying to support somebody else, right? We're trying to somebody else's workflow and you know, so we have examples of people who are, uh, creating new remote systems to be able to, uh, schedule meetings in hospitals or the doctors who are actually the first, first responders taking care of patients. But at the end of the day, it's the developer who's actually creating that solution, right? And so we're being called the duty right now. Um, and so we need to make sure that we're actually there to support the needs of our users and that we're, we're basically cranking on code as fast as we can. Uh, and to be able to do that, we have to make sure that every developer is empowered and they can move quickly, but also that they can collaborate freely. And so, uh, I think that, you know, Docker hub Docker kind of helps you ensure that you have that consistency, but you also have that connection to the infrastructure that's hosted by your, your organization. >>I think you nailed that amazing insight. And I think that's, you know, the current situation in the community matters because there's a lot of um, frontline work being done to your point. But then we've got to rebuild. The modernization is happening as well coming out of this. So there's going to be that and there's a lot of comradery going on and massive community involvement. I'm seeing more of, you know, the empathy, but also now there's going to be the building, the creation, the new creation. So Scott, this is going to call for more simplicity and to abstract away the complexities. This is the core issue. >>Well that's exactly right and it is time to build, right? Um, and we're going to build our way out of this. Um, and it is the community that's responding. And so in some sense, Microsoft and Docker are there to support that, that community energy and give them the tools to go. And identify and have an impact as quickly as possible. We have referenced in the keynote, um, completely bottoms up organic adoption of Docker desktop and Docker hub in racing to provide solutions against the COBIT 19 virus. Right? It's a, it's a war against this pandemic that is heavily dependent on applications and data and there's over 200 projects, community projects on Docker hub today where you've got uh, cools and containers and data analysis all in service to the photo at 19 battle that's being fought. And then as you said, John, as we, as we get through this, the other side, there's entire industries that are completely rethinking their approach that were largely offline before that. Now see the imperative and the importance of going online and that tectonic shift nearly overnight of offline to online behavior and commerce and social and go on down the list that requires new application development. And I'm very pleased about this partnership is that together we're giving developers the tools to really take advantage of that opportunity and go and build our way out of it. >>Well, Scott, congratulations on a great extended partnership with Microsoft and the Docker brand. You know, I'm a big fan of from day one. I know you guys have pivoted on a new trajectory which is very community oriented, very open source, very open. So congratulations on that Amanda. Thanks for spending the time to come on. I'll give you the final word. Take a minute to talk about what's new at Microsoft. For the folks that know Microsoft, know they have a developer mindset from day one cloud is exploding code to cloud. What's the update? What's the new narrative? What should people know about Microsoft with developer community? Can you share from some, some, some uh, data for the folks that aren't in the community or might want to join with folks in the community who want to get an update? >>Yeah, it's a, it's a great, great kind of question. I mean, you know, right now I think we are all really focused on making sure that we can empower developers throughout the world and that includes both those who are building solutions for their organizations today. But also I think we're going to end up with a ton of new developers over this next period who are really entering the workforce and uh, and learning to create, you know, digital solutions overall. There's a massive developer shortage across the world. Um, there's so much opportunity for developers to kind of, you know, address a lot of the needs that we're seeing out of organizations again across the world. Um, and so I think it's just a really exciting time to be a developer. Uh, and you know, my, my uh, my only hope is that basically we're, we're building tools that actually enable them to solve problems. >>Awesome insight and thank you so much for your time code to cloud developers are cranking away that the first responders are going to take care of business and then continue to build out the modern applications. And when you have a crisis like this, people cut right through the noise and get right to the tools that matter. So thanks for sharing the Microsoft Docker partnership and the things that you guys are working on together. Thanks for your time. Okay. This is the cubes coverage. We are Docker con 2020 digital is the cube virtual. I'm Sean for bringing all the action. More coverage. Stay with us for more Docker con virtual. After this short break.

>> 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)

>> Live from San Francisco, it's theCUBE, covering DockerCon 18. Brought to you by Docker and it's ecosystem partners. >> Welcome back to theCUBE's coverage of DockerCon 2018 in beautiful San Francisco. It's a stunning day here. We're at Moscone West, I'm Lisa Martin with John Troyer. Very honored to welcome to theCUBE, for the first time, the CEO of Docker Inc., Steve Singh. Welcome, Steve. >> Hi Lisa, very nice to meet you. John, how are you? >> So the general session this morning, standing room only between five and six thousand people. I gotta say a couple things that jumped out at me. One, coolest stage entrance I've ever seen with this great, if you haven't seen it from the livestream, this, like, 3D Golden Gate Bridge and I loved that and I loved the demo of Docker Desktop that your kids did, fueled by Mountain Dew, which actually single handedly got me through college here in San Francisco. So, the momentum that you guys, it was kicking off with a bang. >> Yeah, I, look, I've got a great team and one of the things we wanted to communicate this morning is that you're seeing a massive transformation in the world of software. And this transformation is enabling every company in the world to think about their business in a new light. To think about how their business meets customer needs in a way that's much more personal, in a way that delivers more value. And this is the beauty of where Docker is, right, we have a chance to help literally every company in the world. And that's the part, honestly, that gets me excited, is, like, how do you help other people go create amazing businesses? And so this is, I couldn't be more happy to be at Docker. >> Steve, keying on that, one of the customers on stage today, McKesson. >> Yeah. >> And I loved Rashmi Kumar came out and talked about future-proofing for applications, their infrastructure, their applications in partnership with Docker. >> Yeah. And that implies a certain amount of trust that they have in Docker and Docker's technology platform and in partnering with you. You come from a, so you've been at Docker for about a year now, right? Came in as CEO. Docker is still a small company, a couple hundred folks but punching way above its weight with a huge community impact. How do you, and, you know, you've worked with the biggest companies in the world, how do you come in and establish that trust and help reassure them that you're gonna be a good partner for them and, kinda, what are you seeing with your customers? >> It's a great question, John, and look, there's maybe two or three pieces of how we think about that. The first thing, trust is very human, right? You've gotta know that you're walking into a situation as a vendor and as a customer but really as partners. And you're trying to solve a problem together. Because the reality is, this transformation that companies are going through is the first time in 40 years that this kind of transformation has happened. Second is, the technology stack is still in the early stages. Now, it's incredible and it enables amazing things, but it's still in the early stages. So both of us have to walk into the relationship knowing that, you know what, sometimes it won't go perfect, but guess what? We're gonna be, you know, if it doesn't go perfect we're gonna honor everything we ever committed to you and the same thing on the customer's side. They look at it and say, "I may have actually described my needs differently than what they actually are." And that's what a real partnership is. That's number one. Number two is, trust is driven by culture. And one of the things that I love about Docker is that we see our place in the world but we wanna make sure the customer always has choice. We wanna make sure that if we do a great job the customer will choose to work with us. If we don't, they should have the choice to go somewhere else. And that's what our platform enables, is the choice to be able to work with anybody you'd like to work with, whether you're the developer or you're an operator or you're an IT, I'm sorry, an architect, or the executive. The other piece around this is that part of the value of Docker is it's not just the 400 people of our company, right? There's 5,000 members of our community that are adding value to our community. One of the things that I wanna make sure we do for our community is help them not just innovate on this incredible platform but how do we help them take their innovations to market? And so that's part of the ethos of our company. >> One of the things that you talked about this morning that I thought was really compelling was, you said software innovation used to be, for the last 40 years, it's been driven by tech companies. That's changing. You talked about distributed innovation and distributed consumption. How is Docker helping to, culturally, I don't wanna say instill, but helping to influence, maybe, organizations to be able to distribute innovation and be able to share bi-directionally? >> Yeah, so, a great question, Lisa. So, first of all, is there's a cultural change within companies. When you think about the next generation or the next 40 years being, software being driven from non-technology companies. First of all, we're seeing that. Second is that it requires a cultural change within the business but that change is critical 'cause in the absence of becoming more of a software company your business is gonna be under threat, right? From the competing business. Look at what Netflix has done in media compared to every other media company. That same example applies in every single industry. Now, the way that we help enable that software transformation is to provide a platform that is so easy to use that it doesn't require a lot of training. Now this is complicated platforms, so, yes you have to be a fantastic developer or an IT professional but our job is to take complicated technology like container management software, orchestration layers like Swarm or Kubernetes, service mesh, storage networking, all of those, and make it so simple and easy to use that your IT department can say, "I can use this platform to effectively future-proof your company," right? So, how do you have a platform that you can build every application on, take all of you legacy applications on, run it, and then run it anywhere you like. >> I think that's been one of the through lines for Docker since the very beginning, that developer experience, right? >> Yes. >> And what's been interesting in Docker's development was, I think for both inside and outside, is kind of, what is Docker Inc, and the project versus the company, what is it selling, what's the commercial aspect here? I think, I kind of think back to my experience at BMWare, where there was an enterprise side and then a huge install base of workstation folks. And it's even stronger with Docker because actually now with Docker Desktop as an application development environment or a, you know, I don't wanna, not quite development environment but, you know, the one you announced today with Docker Desktop. That's an even more valuable through line into the Enterprise Edition. >> Yeah. >> But I don't, so, I guess where I'm heading, Steve, is, can you talk a little bit about the commercial situation? Docker EE as the flagship platform. >> Yeah, of course. >> And, kind of, where we are in the maturity journey with customers right now, it's real and important. >> Absolutely John, but you're bringing up a great point within this. Look, we're both, we're a enterprise software company and we're this incredible community where innovation is being brought in by every member of the community. And there's nothing in the world that says you can't do both. This idea that you're one company versus another, this is nonsense, alright? It's a very narrow view of the world. In fact, I would argue that, more and more, companies have to think about that they have multiple people that they serve. Multiple constituents that they serve. In our case we serve the Enterprise IT organization and we also serve developers. And developers are a critical part, not just of our community, that is the life of every company going forward. Which is why we're so excited about this. That's the life of every company. So, Docker Desktop, the reason we're so excited about it is, first of all, it is the easiest way to engage with Docker, to build applications. And then we feel like there's a lot more innovation that we can actually deliver within Docker Desktop. Alright, so a million new developers joined on Docker Desktop this year. In fact, we're growing about seven or eight percent month over month on that. And so you should expect over the next year another million will be on Docker Desktop. But it's incumbent upon us to say, the only way that we continue to earn the trust of that portion of our constituents, that of the developer community, is to make sure we're innovative, to make sure we're open to allow others to innovate on top of us. >> I'd love to, kind of, explore on audience a little bit. So, in terms of innovation, you know, we know that the companies that have the ability to aggressively innovate, and to do that they have to have the budget, are the ones that stay relevant and that are the most competitive. But I think I saw some stats and I think Scott Johnson said that close to 90 percent of IT budgets are spent keeping the lights on. So you have very little dollars to actually drive innovation. So when you're talking with customers, and you said you just met with 25 of Docker Inc's biggest customers just this morning, are you talking to both the developer guys and girls as well as the C suite? >> Yeah. >> What is, how are you connecting and then, maybe, is it a conversation to enable the developers to be able to sell the value up the stack or is it vice versa? >> A couple of things here, so, first of all, John, I didn't answer part of your question which is the growth in our Enterprise customer base. We've literally doubled it year over year, right? So, more than 500 Global 10,000 companies that are using Docker to run their applications and to manage their applications. The way that we engage with our customers is literally across the entire constituents of that organization, right? A developer by themselves, as genius as that group of people are, you can't deliver the application. And delivering the application is just as important as building it. And so the IT organization, the ops organization is critical. And then there's gotta be an overriding objective. What is it we're trying to do? How do we transform ourselves into a software company? You think about, think about just for example, Tesla, right? When you have a company, and I realize Tesla's stock goes up and down, they're always in the news, but when you have a company that's worth more than some of the biggest automotive companies in the world, you have to ask yourself why. Well, part of the reason why isn't just the fact that we've got an electric vehicle that's better for the environment. Part of it is, it's really as much a software company as it is a automotive company. They have incredible amounts of data about how we use our cars, where we go, and in fact the Tesla cars are actually interconnected. And so, that brings a perspective in how you build cars and how they're gonna be used and how they're gonna be consumed that's radically different than if you're just an auto manufacturer. Now, look, Ford and GM and Volvo are all really smart, great companies and they're quickly moving through to themselves being software companies. >> Steve, can you talk a little bit about ecosystems? Microsoft, on stage this morning, a long partnership with them but also here at the show, right, enterprise folks, Dell and Accenture and I'm just looking down the list as well as Google and Amazon, right? So, you need to be partnering with a lot of folks to make all this work. How are you approaching that? >> John, part of the reason for that is, let's start with a simple premise, is something this large, alright, you can't possibly innovate fast enough on your own, alright? There's seven billion amazing people on this planet. The only way you can really drive mass scale global innovation, is you have to be open, right? I'm literally a guy that was born in a mud house in India, so I certainly appreciate the opportunity to participate in the rest of the world's economy. So we have to be open to say, anybody that wants to contribute, can. Now, obviously we think that contribution has to be within an ethos, right? If your definition of contribution is how do you help your own business, that's not good enough. You have to look at this and say, there has to be choice, in our view, choice, security and agility. So, how do we deliver those values or that ethos to our customers? And if you're willing to do that, man we want to partner with everybody in this space. >> Yeah, I, sometimes I despair of the tech press, although I consume a lot of it and if I never have to read another Swarm versus Kubernetes article again I would be happy. But Kubernetes' all over the keynote and it seems like Docker you all have embraced it and in fact are supporting it in very innovative ways with the cloud providers. In terms of ecosystem can you talk a little bit about-- >> Yeah, well, part of the value of Docker is we simplify very complex things and make it available to our customers to consume with little training, little understanding of the underlying deep technology. And the other part is that it comes back to this idea that innovation will happen everywhere. Why should we view the world as it's our solution or, you know, nobody's? That's nonsense, right? Kubernetes is a fantastic orchestrational entity. Why shouldn't it be integrated into the Docker container platform? And so, as we did that, guess what happened? Our customers, all they saw was, instead of conflict they saw the opportunity to work together. In fact it's been amazing for the growth in our business, that's why ewe doubled year over year. >> Now, collaboration is essential and we were talking with Scott Johnson a little bit earlier today about the internal collaboration but also the external collaboration with customers. You talked about partnerships, I think that the MTA program, the Modernization of Traditional Apps launched about a year ago with Avanade, Cisco, HPE and Microsoft. Tell us a little bit about that, probably around the same time that you came to the helm. You're seeing, you know, customers like Visa, PayPal as part of this program, be able to transform and go to the container journey. >> Yeah, and Lisa, this speaks to an observation you made a few minutes ago about the fact that, you know, 85, 90% of IT budgets are fixed before you even walk into the year. So, look, the Docker platform can be used for any kind of application. Legacy apps, next generation apps that run in the data center, next generation apps that run on Edge devices. But if you accept that 90% of the apps that sit within a company are all legacy apps, well, guess what, that's where their cost is. And then if you marry that to the fact that every CIO has this problem that I don't have a lot of money that's free in my budget. Well, how do we help solve that? And the way we chose to solve it is this Docker MTA solution. Modernizing Traditional Apps. Take your traditional apps, run 'em on the Docker platform, run 'em on any infrastructure you like, cut your app and infrastructure management costs in half. Now, then take that savings and then apply it towards innovation. This is why it resonates with CIO's. I mean, as much as they may love Docker and they may love us, they have a business to serve and they're very, very practical in how they think about, you know, going about their business. >> So with that approach, thanks John, how receptive were those enterprise CIO's to going, "You're right, we've gotta start with our enterprise apps." They don't have the luxury of time, of ripping out old infrastructure and building them on containers or microservices architectures. And these are often mission-critical applications. Was that an easy sell, was that, tell me about that. >> (laughs) Well, nothing's easy but the reality is, is that it, they got it quickly, right? Because it speaks directly to their paying point. And what I'm very proud of with my team is not only were we able to deliver a great product for MTA but we're also helping our customers actually make sure they can migrate these apps over. But what's been really a positive, you know, kind of a signal we've seen, that's still the early stages, is that as our customers are moving their legacy apps to Docker and running 'em on new infrastructure, sometimes public cloud, and cutting costs, they're starting to take that cost savings and actually applying it to their next generation apps. So they're not using Docker for new apps. And so that is, that's the benefit of when you really try to solve the problem the way the customer wants to consume it. >> So, Steve, the user conference, very energizing, right. >> Yeah. >> Already the energy's been good here, you've been doing trainings and certifications, there's people behind us, everyone's talking, so that kind of in some ways sets the tone for the year, so as you and your team go back to the office after this week, you know, what are you looking to do and what can we expect out of Docker? >> I'll just speak to two things. First of all, there's so much innovation we still have to deliver. If anything, you know, I would say my team will tell me I might be pushing a little hard. But you know what, this is the fun, you only have x number of years in life and you should make the most of it. So we're really excited about new apps, we're excited about SecurEdge apps. We're excited about, I don't know if you saw the demo this morning, of Armada, which allows you to run any app on any operating system, on any infrastructure, all from a single pane of glass. Our customers love that and they're very excited about that. That said, you know, this is a, it's a big test. We have a huge opportunity to welcome a lot of other companies, so when you walk around and see 5,000 people that see amazing opportunity, not just for Docker, for themselves, right? That's the secret part of Docker that I love. We're creating jobs that didn't exist before, right? I mean, you see kids coming out of college now getting Docker skills and they're using that to grow their IT profession. In fact, I was just at i.c.stars, this is an amazing organization in Chicago that helps individuals who've been displaced in the workforce learn the IT skills required to come back to the workforce and really help run internal IT organizations. Guess what they're learning? They're learning Docker. So that's, these are the kind of things that get us excited. >> And that's essential for enterprise organizations who, that's one of the challenges they face, was, you know, modernizing the data center, which they have to do, but then it requires new skill sets, maybe upskilling, so it's exciting to hear that you're seeing this investment in people that have an opportunity, the proclivity to actually learn this technology. >> Yeah, this is, we are happy because we help customers but we also create amazing new jobs that, you know, are, certainly our community can still benefit from. >> So, last question, the three themes that came out of your session and really the general session this morning was, you talked about someone's choice, agility and security. Are those the three pillars that you believe Docker, upon which Docker sits as really competitive differentiators? >> Amen, amen, number one, but it's also our values, right? This is rooted in our values and when a company performs best is when their values show up in their products. Because then you're never lost, you'll always know what you're focused on. And you know, when I ran Concur, we had this vision, north star, called The Perfect Trip. And our objective was to always go create a delightful business trip experience. And for Docker I wanna make sure that we have a north star. And our north star is our values and they have to translate directly to what actually helps the customer. >> Love that, the north star. Well, hopefully theCUBE is the north star of modern tech media. Steve, thanks so much for stopping by. >> Thank you, it's wonderful to meet you. It was great to meet you as well and congratulations on the big success. >> Thank you. >> We look forward to hearing-- >> Thank you Lisa, thank you John. >> What's coming out in the next year. >> Thank you. >> And we wanna thank you for watching theCUBE, I'm Lisa Martin with John Troyer today live from San Francisco DockerCon 2018. Stick around, we'll be back after a short break. (upbeat music)

>> Live from San Francisco, it's theCUBE, covering DockerCon '18, brought to you by Docker and it's ecosystem partners. >> Welcome back to theCUBE, we are live at DockerCon 2018 in San Francisco on a spectacular day. I am Lisa Martin with my with my co-host for the day, John Troyer, and we're very pleased to welcome back to theCUBE a distinguished CUBE alumni and Docker veteran, Steve Johnston, Chief Product Officer at Docker. Welcome back. >> Thank you, thank you very much. That's Scott Johnston but that's okay. >> What did I say? Steve? >> Steve. That's okay. >> Oh, I gave you a new name. >> You know, I get that all the time. >> I'm sorry, Scott. >> That's alright. >> This event, between five and six thousand people. >> Yes. >> You were saying in your general session in keynote this morning, that this is the fifth DockerCon. You started a few years ago with just 300 people and when I was walking out of the keynote this morning, I took a photograph, incredible. People as far as the eye can see. It was literally standing room only. >> It's crazy, right? And you think about four years ago, June 2014 when we did our very first DockerCon, here in San Francisco, 300 people, right? And we've gone from 300 to over 5,000 in that time, grown the community, grown the products, grown the partnerships and it's just, it's very humbling, honestly, to be part of something that's literally industry changing. >> You gave some great numbers during your keynote. You talked about 500 customers using Docker Enterprise Edition. >> Yes. >> Some big names. >> Yes. >> MET Life, Visa, PayPal, McKesson, who was on stage and that was a really interesting. McKesson is what, 183 years old? >> Healthcare company, yeah. >> Talking about data, life and death type of data. >> Right. >> Their transformation working with Docker and containers was really pretty impressive. >> It's exciting that companies get their hands on the technology and they start maybe on a small project or a small team but very quickly they see the potential impact of the solution and very quickly, it's almost infectious inside the organization and more and more teams want to jump on, understand how they can use it to help with their applications, their business to get impact in their operations and it just spreads, spreads like wildflower. That was really the story that McKesson was sharing, just how quickly they were seeing the adoption throughout their org. >> I thought that was really interesting and they did point it out on stage, how that developer adoption did help them go to the next level. >> Yes. >> And kind of transform their whole pipeline. >> Yes. >> Now Scott, you've been here the whole line of time and that through line has been, for Docker, that developer experience. >> That's exactly right. >> Now, as Product Lead here, you've got the Docker Desktop side and the Docker EE side and it's clear, there were some great announcements about desktop here, previews today but how do you balance the enterprise side with the developer centric desktop side and that developer experience idea? >> No, it's a great question, John. I'd reshape it almost to say, it's a continuous platform from developer experience to the operation side and you have to stand back and kind of see it as one and less about trading off one versus the other and how do you create an experience that carries all the way through. So a lot of Gareth's demonstration and the Lily Mason play, was showing how you can create apps in Docker very easily as a developer but those same artifacts that they put their apps in to carry all the way through into production, all the way through into operations. So it's about providing a consistent user experience, consistent set of artifacts that can be used by all the different personas that are building software so that they can be successful moving these Docker applications through the entire application development life cycle. Does that make sense? >> It does, thank you. I'd love to get your perspective, when you're talking with enterprises who might have some trepidation about the container journey, they probably know they have to do it to stay agile and competitive. I think in the press release, I believe it was you, that was quoted saying, "An estimated 85% of enterprise organizations are in a multi Cloud world." >> That's right. >> In a multi Cloud strategy. >> That's right. >> So when you're talking with customers, what's that executive conversation like? C level to C level, what are some of the main concerns that you hear and how influential are the developers in that C suite saying, "Hey guys, we've got to go this direction"? >> No, that's right. That's a great question, Lisa and what we hear again, and again, and again, is a realization going on in the C suite, that having software capabilities is strategic to their business, right? That was not always the case, as much as a decade ago, as recently as a decade ago, inside kind of big manufacturing businesses or big verticals that weren't kind of tech first, IT was a back office, right? It was not front and center but now they're seeing the disruption that software can have in other verticals and they're saying, "Wait a minute, we need to make software capabilities a core capability in our business." And who starts that whole cycle? It's the developers, right? If the developers can integrate with the lines of business, understand their objectives, understand how software can help them achieve those objectives, that's where it kicks off the whole process of, "Okay, we're going to build competitive applications. We then need an operations team to manage and deploy those applications to help us deploy them in a competitive way by taking them to the Cloud." So developers are absolutely pivotal in that conversation and core to helping these very large, Fortune 500, hundred year old companies, transform into new, agile, software driven businesses. >> Modernizing enterprise apps has been a theme >> Yes. >> also at Docker for a few years now. >> Yup. >> Up on stage Microsoft demonstrating the results of a multiyear partnership >> That's right. >> between Microsoft and Docker both with Docker integrating well with Windows server as well as, you talked about, Kubernetes now. >> That's right. >> Can you talk a little bit about what the implications of this are? The demo on stage, of course, was a very old enterprise app written in dot net, with just a few clicks, up and running in the Cloud on Kubernetes no less. >> That's right. >> Managed by Docker, that's actually very cool. You want to talk a little bit about, again, your conversations? >> Absolutely. >> Is this all about Cloud native or how much of your conversations are also supporting enterprise apps? >> Tying back to Lisa's question, so how do we help these organizations get started on their transformation? So they realize they need to transform, where do you start? Well guess what? 90% of their IT budget right now is going into these legacy applications and these legacy infrastructures, so if you start there and it can help modernize what they already have and bring it to modern platforms like Docker and Kubernetes, modern platforms like Window Server 2016, it's a modern operating system, modern platforms like Clouds, that's where you can create a lot of value out of existing application assets, reduce your costs, make these apps agile, even though they're thirteen years old and it's a way for the organization to start to get comfortable with the technology, to adopt it in a surface area that's very well known, to see results very, very quickly and then they gain the confidence to then spread it further into new applications, to spread it further into IOT, to spread it further into big data. But you've got to start it somewhere, right? So the MTA, Modernized Traditional Apps, is a very practical, pragmatic but also high, very quick, return way to get started. >> Oh, go ahead. >> Well I just, the other big announcement involving Kubernetes was managing Kubernetes in the Cloud and I wanted to make sure we hit that. >> That's right, that's right. >> Because I think if people aren't paying attention, they're just going to hear multi Cloud and they're going to go on and say, "Well everybody does multi Cloud, Docker's no different, Docker's just kind of catching up." Actually, this tech preview, I think, is a step forward. I think it's something- >> Thank you. >> I haven't actually seen in practice, so I'm kind of curious, again, how you as an engineering leader make those trade offs. Kind of talk a little bit about what you did and how deciding, "Well there's multi Cloud but the devil's in the details." You actually have integrated now with the native Kubernetes in these three Clouds, EKS, AKS and GKE. >> GKE, no that's right. No, it's a great question, John. The wonderful and fascinating but double edged sword of technology is that the race is always moving the abstraction up, right? You're always moving the abstraction up and you're always having to stay ahead and find where you can create real value for your customers. There was two factors that were going on, that you saw us kind of lean in to that and realize there's an opportunity here. One is, the Cloud providers are doing a wonderful job investing in Kubernetes and making it a manage service on their platforms, great. Now, let's take advantage of that because that's a horizontal infrastructure piece. At parallel we were seeing customers want to take advantage of these different Clouds but getting frustrated that every time they went to a different Cloud they were setting up another stack of process and tooling and automation and management and they're like, "Wait a minute. This is going to slow us down if we have to maintain these stacks." So we leaned in to that and said, "Okay, great. Let's take advantage of commoditized infrastructure, hosting Kubernetes. Let's also then take advantage of our ability to ingest and onboard them into Docker Enterprise Edition, and provide a consistent experience user based APIs, so that the enterprise doesn't get tied into these individual silos of tools, processes and stacks." Really, it's the combination of those two that you see a product opportunity emerged that we leaned heavily into and you saw the fruits of this morning. >> I saw a stat on the docker.com website that said that customers migrating to EE containers can reduce total cost by around 50%? >> Yes. >> That's a significant number. >> It's huge, right? You're reducing your cost of maintaining a ten year old app by 50% and you've made it Cloud portable, and you've made it more secure by putting it in the Docker container than outside and so it's like, "Why wouldn't you invest in that?" It shows a way to get comfortable with the technology, free up some cashflow that then you can pour back into additional innovation, so it's really a wonderful formula. That again, is why we start a lot of customers with their legacy applications because it has these types of benefits that gets them going in other parts of their business. >> And as you mentioned, 90% of an enterprise IT budget is spent keeping the lights on. >> That's right. >> Which means 10% for innovation and as we've talked about before, John, it's the aggressively innovating organizations that are the winners. >> That's exactly right and we're giving them tools, we're giving them a road map even, on how they can become an aggressively innovating organization. >> What about the visibility, in terms of, you know, an organization that's got eight different IT platforms, on prem, public Cloud, hybrid- >> Right. >> What are you doing with respect to being able to deliver visibility across containers and multiple clusters? >> That's right. Well that's a big part of today's announcement, was being able ... Every time we ingest one of these clusters, whether it's on prem, whether it's in the Cloud, whether it's a hosted Kubernetes cluster, that gives us that visibility of now we can manage applications across that, we can aggregate the logging, aggregate the monitoring. You can see, are your apps up, down, are they running out of resources? Do you need to load balance them to another cluster? So it's very much aligned with the vision that we shared on stage, which is fully federated management of the applications across clusters which includes visibility and all the tools necessary for that. >> Scott, I wanted to ask about culture and engineering culture >> Thank you. >> The DockerCon here is very, I think we called it humane in our intro, right? There's childcare on site, there's spoustivities, there's other places to take care of the people who are here and give them a great experience and a lot of training, of course, and things like that. But internally, engineering, there's a war for talent. Docker is very small compared to the Googles of the world but yet you have a very ambitious agenda. The theme of choice today, CLI versus GUI, Kubernetes versus Swarm, Lennox and Windows, not versus, Lennox and Windows, you know and, and, and, and now all these different Clouds and on prem. That's very ambitious and each "and" there takes engineering resources, so I'm kind of curious how the engineering team is growing, how you want to build the culture internally and how you use that to attract the right people? >> Well it certainly helps to be the start up that kicked off this entire movement, right? So a lot of credit to Solomon Hykes, our founder, and the original crew that ... Docker was a Skunkworks project in the previous version of our company and they had the vision to bring it forward and bring it to the world in an opensource model which at the time was a brand new language, go language. That was a catalyst that really got the company off and running in 2013/2014. We're staying true to that in that there's still a very strong opensource culture in the company and that attracts a lot of talent, as well as continuing to balance enterprise features and innovation and you see a combination of that on stage. You're also going to see a wonderful combination of that on the show floor, both from our own employees but also from the community. And I think that's the third dimension, John, which is being humble and call it "aware" that innovation doesn't just come from inside our four walls but that we give our engineers license to bring things in from the outside that add value to their projects. The Kubernetes is a great example of that, right? Our team saw the need for orchestration, we had our own IP in the form of Swarm, but they saw the capabilities of Kubernetes is very complimentary to that, or some customers were preferring to deploy that. So, no ifs, ands or buts, let's take advantage of that innovation, bring it inside the four walls and go. So, it's that kind of flexibility and awareness to attract great engineers who want to work on cutting edge, industry building technologies but also who are aware enough of, there's exciting things happening outside with the community and partnering with that community to bring those into the platform as well. >> So Scott, you guys are doing a lot of collaboration internally, but you're also doing a lot of collaboration with customers. How influential are customers to the development of Docker technologies? >> At ground zero, literally and we have at DockerCon, we call it a customer advisor group, where the customers who have been with us, who have deployed with us in production, we have them. And it's a very select group, it's about twelve to sixteen, and they tell us straight talk in terms of where it's working, where we need to improve. They give us feedback on the road map and so that happens every DockerCon, so that's once every six months. But then we actually have targets inside engineering and product management to be out in the field on a regular basis to make sure we're continuing to get that customer feedback. Innovation's a tricky balance, right? Because you want to be out in front and go where folks aren't asking you to, but you know there's opportunity, at the same time here, where they are today, and make sure you're not getting too far ahead. It's the old joke, Henry Ford, where if he's just listened to his customers, he would have made faster horses but instead he was listening to their problems, their real problems which was transportation and his genius, or his innovation, was to give them the Model T, right? We're trying to balance that ourselves inside Docker. Listen to customers but also know where the innovation, where the technology can take you to give you new solutions, hopefully many of which you saw on stage today. >> We did, well Scott, thanks so much for stopping by theCUBE again and sharing some of the exciting announcements that Docker has made and what you're doing to innovate internally and for the external enterprise community. We appreciate your time. >> Thank you, Lisa. Thank you, John. >> We want to thank you for watching theCUBE. Again, Lisa Martin with John Troyer, live in San Francisco at DockerCon 2018. Stick around, John and I will be right back with our next guest. (upbeat techno music)

(Upbeat Music) >> Announcer: Live from Los Angeles, it's theCUBE, covering Open Source Summit, North America, 2017, brought to you by the Linux Foundation and The Red Hat. >> Hey, welcome back everyone, live here in Los Angeles, California for theCUBE's exclusive coverage of Open Source Summit in North America. I'm John Furrrier, with my co-star Stu Miniman, Our next guest is Patrick Chanezan, who is a member of the technical docker, also on the governing board of the Cloud Native Compute Foundation, also known as CNCF, which is the hottest part of the open-source community right now. It's very fast, we're very trendy, a lot of people are on the bandwagon, a lot of contribution going on. Welcome back to theCUBE. Great to see you. >> Hey, thanks, John and Stu, it's very good to be back on theCUBE. >> Docker's been just a great company to follow since the beginning, the birth of Docker to the transformation from Dark Cloud to Docker. It's just a great team. We have a lot of respect for you guys. Congratulations. But the CNCF right now is the hottest thing, there's more platinum sponsors than I think maybe members. It seems to be very hot. Industry loves it, developer is going crazy about it, why is CNCF so hot? What's your perspective on that? >> What we're seeing right now is really the realization of adoption of containers, we talked about it two years ago. It was very early, and people were starting to use Docker and just covering containers. Today they're really putting them into production, and what we see at Docker with our customer base is that they are using it more and more to modernize traditional applications. So we see tremendous use of containers everywhere in enterprises, and the rise of CNCF is tied to that, I think. We're seeing more and more developers joining the bandwagon, more and more systems being built based on containers. And at Docker, we're playing a big role into that. >> Patrick, for a couple years, the chant was Docker, Docker, Docker, and sometimes people say, "Cubernetti's is where the hotness is." Well underneath that, there's containers. And a lot of those containers, Docker's involved there. Maybe you can help us understand the nuance a little bit as the Cubernetti's wave has grown, sure there was the Mezos, Docker Swarm, Cubernetti's war, if you will there, but what does this mean for Docker? What are you seeing from your customers? Give us the update on Docker itself. We'll probably need to get into the Mobi stuff, too, as we get into the interview. >> Sure, definitely. That's a big question, so let's start with the beginning. When enterprises adopt containers, what happens is that usually it starts with the wrappers who are adopting containers with Docker. So they download Docker for their Windows machine, or for their Mac, or on Linux, they start modernizing their applications. What we see is more and more enterprising wrappers, modernizing existing applications by Dockerizing them, and then the next step is that they want to put that into production. For that, you need the whole system. So at Docker, we have two systems. We have Docker C and Docker E, our enterprise version that has role-based controlled sequencing and all that good stuff. There are lots of different components that you need in order to have a production container system, and so Cuberneris, the orchestration engine is one piece of that. At Docker, we have swarm kits. But there are lots of other different components and lots of different layers to that system. So you have the infrastructure layer that you are using to deploy that inside the firewall or in different cloud providers. Many different solutions there. At Docker, we have one that's called infrakit, that we're using in our additions, to deploy it everywhere. Then on top of that, you need some version of Linux. At Docker Con in April, we released a project called Linuxkit, which helps you do that. On top of that, you need a container run-time. Traditionally, it's been Docker. Right now, we re-factored the Docker codebase to extract a core run-time component that's called container G, which we donated to CNCF. Container G is nearing one or better, so it would be one of them pretty soon. Then, on top of that, you need an orchestration engine. Docker E comes with its own orchestration based on swarm, Cuberneris is another orchestration engine that people like. Cuberneris, behind the scenes, is using Docker, and right now we are working very closely with theCUBE rneris community to implement CRI container G. So CRI is the container run-time interface in Cuberneris that lets you plug in different engines to plug container G in the place of Docker in there. >> Stu: There's a lot of pieces in here. We had too many interviews yesterday talking about the Open Container Initiative, or OCI, which really made sure we've got the 1.0 version of that done. What container format, seems like we're in agreement. We're not fighting over that kind of piece anymore. From the Cubernetti's community, I heard loud and clear, they're like, we've got container D. We've kind of got what we want. We're happy it's open-sourced. We're going. We were at Docker Con when you annouced Mobi, which is kind of open-source, and it felt like we were still trying to figure out all those pieces. Give us the update as to Mobi, you're talking at the open source show, you talk a little bit about CE and EE being the productized versions, but part of it is what we used to think of as Docker is now Mobi, and the company Docker versus the project. You kind of teased those apart a little bit, right? >> Yes. Exactly. And actually, that's what I came here at the Open Summit to talk about, to give people an update on the Mobi project. So what we announced back in April was the launch of the Mobi project, which is the end of a two year re-factoring of the Docker codebase into different components. So all these components on the stack that I told you about, we just tease them out from the Docker codebase so that it's a modular set of components that you can assemble together. Mobi is three things. It's an open source project where people can collaborate in container-based systems. It's also a tool that we're using to assemble our components into Mobi Corp, which is the upstream of Docker products. Then it's also a set of lots of components, like container G, Linux, Infrakit, Notary, and all the projects I talked about. One other thing we've started doing since April as well is we started proposing to donate some of these container projects to CNCF. So container G is already part of CNCF now. Recently, this summer, we proposed Infrakit, and they think it's a little bit too early for donation, because they want to see other, different projects in there. Right now we're in the process of donating and proposing Notary, so there's an active discussion in there, and I hope that the vote will happen probably next week or something like that. So Notary is the component that we're using for Docker, and we think that this could be used in lots of different Cloud Native systems, so it really has its place in the CNCF. >> So identity component for the container management, or what specifically is that going to address? >> So Notary is the piece that we're using in Docker Con Contrast to make sure that you can trust the images that you've built. A signed signature should be able to revoke all the signatures, all the kind of features that our customers love in Docker E. >> John: It's kind of like Stu and me on Twitter, he's verified, I'm not. But this is important, because now, this is a stamp of approval, if you will, that the community can look to. >> Yeah, definitely. So it's something that we implement in Docker, and now people building other containment systems who will be able to use it. And so Mobi saw a lot of traction for its different projects, some of them are going to CNCF, some of them are growing by themselves. On the Docker side, we made some progress prioritizing all that with Docker C and Docker E. We had a 1706 launch of Docker E recently, with lots of new role-based axis control, controls for enterprises, who are adopting it essentially to modernize their traditional apps. >> Take us through a kind of personal question. You were just at a board meeting with the CNCF. Did everyone show up or are people calling in? >> I think Alexi Richardson was the only one, maybe two people on the phone. >> John: Was Sam Redjay there? >> Sam was not there either, but Epona was standing for him. So the room was full, and to me it's really an impressive achievement, two years after we helped start the CNCF. The first meetings were 10, 15 people at Google deciding to create this foundation, and today, maybe we're twenty or thirty people around the table. An\d everybody-- >> Even before that Google meeting, we were covering theCUBE Con Cubernettis' movement early on from your event. So I think, out of Docker Con and some of the Linux Foundation events, the early momentum, we were there, Stu. Then it became the CNCF, and they decided, hey, let's get the Cloud Native Foundation. So it's interesting to me, seeing the growth from the beginning. And it's unique to have that opportunity to be in the front lines of an organically developing group. It wasn't really build the table and come, this was a realization. >> It was a realization and also a concerted effort to build something together to show customers where the containment systems were going in terms of architecture-- >> What were the factors beside, I mean Docker was big driver. Notably, you should get the credit for pioneering the space. But what were the drivers for this coalescing, this call to arms, if you will, or this organic formation of CNCF. What were the key drivers in your mind. Obviously, containers is one. What are the other ones? >> Yeah, to me, containers is a big one, because when you are starting to design your system with containers in mind, you need to change lots of things, how you're building them and things like that. And how you are architecting things together. There were lots of questions about how you do the balancing in that kind of system, how do you do monitoring, how do you do tracing. The CNCF was assembled so that all these components have a place where we can show our inter-repairability between them. So Docker is part of that, Mezos is part of that, as well as Cuberneris. There's a big inter-repairability work that's happening in there. We had a report in the board meeting today about the new CI Initiative that tests different CNCF projects together. >> John: What CI? >> Sorry, continuous integration. >> John: Got it, yeah. >> So there's the continuous integration-- >> John: Not conversion infrastructure. >> Oh, you're right, yeah. >> We always get acronym-ed up. But Chris Anazik was talking yesterday about the graduation path, still waiting to see something graduate from the process. What's going to graduate first? Any bets, what's the betting, what betting is going on? Do you guys actually make bets? Is there a fantasy drafting going on? >> I don't think that really matters, what matters is really adoption of the components. >> Okay, so what's happening on the graduation scale? What's coming out of the woodworks? What's next? What's going to graduate first? >> So one thing I'm curious about is whether Container G will graduate, because it's kind of mature now, it's reaching 1-0 with the CRI and soon integration in Docker, it may be a good candidate for graduation. For the others, I don't know which ones would be first into the graduation process. >> Well, we know it's a high bar, for sure. >> Patrick, the stuff that's getting mature. What about some of the roadmap there? From Docker and CNCF, something like serverless containers, first generation, are going to be important. We had too many interviews this week talking about, today, many of the containers we'll see in the future where serverless and open Faz and things like that go. So how does that all fit in? Can you give us a Docker and a CNCF view on that? >> Let's talk about the CNCF view first. CNCF is working on lots of different areas where there needs to be more definition about what Cloud Native means for storage, for example, with the CSI Initiative, container storage interface, CNI, container networking interface, and then there's the working group for CI, which is about integrating all these projects together, but the working group I'm most interested in is the serverless one. So we have a Docker rep at the serverless working group, and there we're trying to define what a portable, serverless stack looks like. And at Docker, we're naturally interested in this -- >> Of course, Serverless is a beautiful thing. >> Most of these projects are running on top of Docker, so open Faz for people-- >> I got to ask you, Patrick, because we love serverless, I have a love/hate relationship with the word serverless because technically it's a beautiful thing, but there's servers involved. I'm an old-school, so I kind of look at it differently. The younger generation, they want infrastructure as code. This is a clear obvious thing. It was once a dream, but now it's become a reality. What's your position on that? Where is it on the progress bar? How close are we to serverless? >> I'd say there's an initial adoption of serverless on one of the few stacks that exist out there today. So you have the hosted services, the Faz services, from Amazon, Microsoft, and Google, where I'm more interested, and I think customers are kind of looking for that, is a portable way of doing that. For example, in studying that on top of Docker platforms, so that's what projects like Open Faz is doing. Right now, I think we're really in the stage of discussions with CNCF of what a portable service layer would look like so that you could focus on your code, but be able to deploy on Prim, on top of Docker, or in different cloud providers. So that portability aspect to me is very important there. And I think it's important for customers as well. To me, also, I'm an old timer as well, I used to pitch a platform as a service at the beginning of it, Google App Engine, many years ago. To me, it's kind of a feeling of deja vu. We're kind of re-inventing that, but with containers and in a much more portable way. >> The beautiful thing about being an old-timer is we get to look back and, not so much to the young kids, get off my lawn, we had to walk to school with bare feet in the snow, build our own libraries. I was just talking to Eilene, she's like, "Oh, my low-level class was C and my high-level class was Python." I'm like, "Our low-level class was machine code "and high-level wasn't even C yet." >> Yesterday, at the party, I was discussing with one of the IBM engineers, who's working on Linux and containers on mainframe, and we were talking about GCL, and that's the type of feeling that we got. Like we're getting higher up in the stack, and I think for modern developers, it really helped them-- >> It's a beautiful thing right now. Just think about the young guns that are coming up. This is a beautiful library of options now. 90% of the code is leverage-able. That's like unbelievable. So it really allows the creativity of the developer to be a lot more about structural engineering code-base rather than just being very creative on the 10-20% of real intellectual property that they can bring to the table. >> I would add something, it's really about creating value, as opposed to building infrastructure. When we're getting up the stack, and serverless is an example of that, it's really about creating value for enterprises, and that's what these wrappers are about. >> When you start dreaming in code, you know you're doing good. Patrick, thanks so much for coming on theCUBE, and congratulations on all the success with CNCF, and certainty Docker. You guys continue to impress and do a great job. I know there's some changes over there we're looking for, some of the cool stuff graduating out of CNCF, more Docker container goodness from you guys. Thanks for coming on theCUBE. We appreciate it. I'm John Furrier, we're live in Los Angeles, California, for the Open Source Summit North America coverage with theCUBE. I'm John Furrier, Stu Miniman back with more after this short break.

>> Narrator: Live from San Francisco It's the Cube. Covering DevNet Create 2017. Brought to you by Cisco. >> Welcome back everyone. Live in San Francisco, this is the Cube's exclusive coverage of the inaugural event for Cisco systems DevNet Create. It's an extension or augmentation, a foot in the water of the new open source world for them. Cloud native DevOps infrastructure is code. It's Cisco's new mission, where applications meets infrastructure AKA infrastructure's code which is music to the ears of DevOps and all application developers. I'm John Furrier. My cohost Peter Burris, Head of Research at wikibon.com. Our next guest is Bradley Wong, Director of Product Management at Docker. Bradley welcome to the Cube. Good to see you again. >> Yeah, great, Thanks John. >> Docker, no other company to reference in terms of being a shining star in a paradigm shift or transformation where containers, Docker containers, and now containers and Kubernetes microservices has taken cloud and brought it into a whole nother dimension. We've been covering you guys at all your Dockercon events. It's been gray multiple years. Congratulations for your success. >> Bradley: Thank you. >> You got to be happy that you got Cisco coming out saying hey we're going to make the network programmable. Finally! You know, let's do it. Thoughts? >> Yeah, we're very excited about that. It's kind of interesting because we also found that networking is also one of those things that's quite difficult. And we saw this challenge probably about more than two years ago, after people started to get more comfortable with containers and they wanted to start doing some more interesting things with them and start getting the containers to talk to each other and the rest of the world. That's kind of really where we saw that networking could be improved upon. And I think maybe you remember, probably about two years ago now, maybe more actually, we made an acquisition company called SocketPlane? >> John: Yep. That really helped us define what it means to really do networking properly. And that was actually the genesis of where even the Cisco partnership also started devolving as well, because at Docker we really needed to build out a framework for how to do networking properly internally first. And we always followed a mantra, the mandate of batteries included but swappable. So, we built a reference implementation of what it meant to do networking properly for containers. But, in doing so we also then worked quite closely with Cisco to also bring their many, many years of expertise to the table as well. So, and you can probably see that now with the culmination of projects like Contiv, which is actually now a certified plug-in on Docker store. Cisco's really stepped it up and has really made lots of really great inroads and done a lot of good additions to Docker networking. >> It always seems that way. The conversation, we've been also following a lot of other communities, like OpenStack for instance, there's always debates but it always gets down to ay the network, network. I've had so many customers (mumbles) It's really hard. And also you see Cisco get pulled into conversations just but gravity pulling them in because they're the network guys. So now, it's nice to see that the executives at Cisco, led by Susie Wee and the team and Rick, not just puttin' their toe in the water, they're jumpin' in the deep end here with the cloud native approach by going to developers and outreaching to them in a different way and saying look it, we want to make your life easier. >> Bradley: Absolutely. >> That's what you guys have done. So certainly a success to you guys who are in Cisco, doing the work around the fringes but now that they're coming in, how do you, how would you tell someone, describe that move for Cisco? I mean, obviously Cisco has not been absent. They've been there with you guys. >> Bradley: Yeah. >> What does this really mean for them as they go fully committing here now? Right, that's a good question. Cisco is beyond just a, obviously, a networking company that's kind of' where it's roots came from. But we saw that there was some good opportunities to work with Cisco, not just on networking but a few other things. I think what a lot of people probably get familiar with Docker because it's a great development tool to start. And that's really where people's first interactions with Docker really is. It's really easy to get started, really easy to start building your applications in Docker, and start moving those applications into other environments, like going from Dev into Tes into Prod very, very seamlessly. So, Docker really becomes that sort of what we call a software supply chain that really enable Dev and Ops to use the same tooling, the same tool chain, end to end. And we feel that if we're able to use the same tool chain end to end, from Dev all the way through to Ops, we alleviate a lot of the challenges to deploying applications to production. Now, Cisco so far has been very, very strong in the Ops space, very strong in the infrastructure space, and we also come very, very strongly from the developer space as well. So, I think as we basically build out this software supply chain, there also is a need to make sure that there is this kind of underlying infrastructure that's also ready to run that software supply chain as well and to really harden it. And that's what, one of the first things that we really did with Cisco is to make sure that we have a very clear vision of how to make that operationalizable for the enterprise. >> Second time I've heard the word software supply chain. Peter's also used the word data supply chain. Data is asset (mumbles) software. Software is an asset. It's data as well. What is software supply chain mean? Describe that for a second. Take a minute to explain. >> So yeah, that's a good question. So in any supply chain I think there's sort of a progression of where there's inputs, where things come in and for us, we're on a mission to build tools of mass innovation. So, we really want to start with the developer and that's really where a lot of really good stuff comes from. Everyone's got great ideas and we piece those ideas together, give them the tools that they know how to use really well to develop them. But, it's not just good to have great applications, they need to be usable and they need to be able to be deployed. And what we believe the software supply chain is taking that development process and being able to have developers put their artifacts inside containers and then move those, because that's really what it is, it's actually moving those artifacts into places where they can be shared with greater teams to start testings those and to start iterating on those. And ultimately to move those into production whether it's on premise or whether it's in the cloud. And that's what we believe that we enable, is that movement of, and that >> John: Coding motion. >> Exactly. Exactly. And that doesn't stop there because, as you know, code is not stable. There's always iterative process and we enable that as well. So then , as we find issues or enhancements that we want to fix in production, we move that back to developer and that whole process starts again. Be able to do that really, really, quickly is what we want to do. >> So let's stay in that metaphor for a second. If we think about this as a software supply chain, Does that make Cisco a logistics supplier? >> I would say, with any supply chain, Cisco, once again, has lot's of different areas that they're focusing in and by no means am I speaking on behalf of Cisco where >> Peter: I understand. Just conceptually, are they the Ryder trucking, are they the ones responsible for moving things around? >> Yes, that's one of the places that Cisco does play very, very strongly in. For example, we identified that the computer platform that Cisco has, the UCS platform, is a great place to actually run Docker in production, especially on premise. And that's definitely one of the things that we needed to start validating, all these different infrastructures, that can actually have the right availability, the right performance characteristics, and things that then we can do together to make sure that these are essentially solid infrastructures to actually run these production environments on. Now, Cisco's been running solid enterprise infrastructure for many, many years. Docker's been running Dockerize applications also for many years as well. The marriage of the two, we hope and we believe that will culminate in a lot of the enterprises, which were very accountable at running enterprise applications on top of enterprise infrastructure, to now run Docker applications on enterprise infrastructure as well. So, just making sure that there is very, very good infrastructure that's in place to actually host that supply chain, I think that's definitely one of the key areas that we are hoping to get out of this partnership with Cisco. >> So now that we've talked about here in the last couple days (mumbles) is Conway's Law. And I'm sure you're familiar with Conway's Law. >> Bradley: Right. >> Which is basically the observation that the software that's generated is a reflection of the organization that generated it. You can use Docker or any other container technology to create really crappy software if you want to. >> Bradley: Yep. But one of the things that Docker does introduce is the idea of segmentation, compartmentalization, while at the same time simplified mechanics for how things work together. So talk a little bit about the expectations of people who get into the Docker and container world should have of the network. How should they think about, should they think about their software as essentially distributed elements that then require a network? What's your thoughts on that architecturally? How is it going to play out? >> It really depends on where their journey sits. Once again, I think we are the suppliers of these tools of innovation. But we want to also hold their hand as well through this journey. And that journey is not done day one. It's a step by step process as well. So, a good example is you can start off and build the greatest distributed microservice application and that might work well for certain parts of your company, but there's certainly many, many other applications that are already deployed out there, which it may not fit, at least not today, and there's a journey to take those existing, traditional applications along that journey as well. So, anything that basically requires interaction, with other components, any services that need to talk to each other, to the external world, obviously requires a network. Networking has been a very, very tough thing in the past. They're not always the simplest. Sometimes it could be over complicated. >> Peter: Sometimes? >> (laughs) Many, Many times. >> In all honesty, I do think that the network professionals have gone out of their way to make the network as obscure and abstract as possible. >> Bradley: You know, I think >> John: They're command line guys. Come on. (laughs) >> I've been in the networking world for a long time as well, before joining Docker. So, I see some of that. I think networking guys tend to, and girls, tend to really look at what are all the different things that we can do, all the different little knobs that we can actually tweak to squeeze every little bit of performance, convergence time, things like that, that might work well in some environments but may not others. That's why you needed so much variability, hence all these nerd knobs, so to speak. Docker comes from a very different place. If you look at the mentality of how we drive things, Usability is a very, very key thing for us. We talk about usable security, we talk about simple orchestrator, (mumbles) for example, We forgo the complex to focus on things that are usable. So, networking for us, we wanted to initially look at it and say, networking should be something that's simple and usable and essentially get out of the way of the developer. Developers shouldn't have to think about all these overcomplicated concepts. The network should be able to form its way around what the application needs and that's really what we're thinking about there. >> Peter: Make it simpler and no simpler than it needs to be. >> John: And make it programmable. >> Bradley: And make it programmable as well. Simple and programmable. And when I say programmable, we're not expecting Ops folks to have to learn how to code necessarily. I think if there's the right tools that are available, that should be a natural flow on. >> You have to enable it so that the app developer doesn't have to do all the hard stuff, like configuration management, all the hardware and the operational stuff that the networking guys have done for them. >> Bradley: Right. >> 'Cause they're not Ops guys right? They're Devs. >> That's a really good point because today, there is not really one single tool chain, and coming back to my earlier point, of what we're trying to solve for. There's not really one single tool chain that Ops folks use, and application developers use. They traditionally use different tooling. What we're trying to do is, first to have that common foundation of common tooling that people can converge on. And the second then is, if we provide all the right hooks, so, just enough hooks for the application developer to say, this is what my application looks like and then enough hooks for the operations folks then plug in and say hey, these are my security policies. These should talk to these and these shouldn't talk to these. And once we have the right ingestion points there, we should be able to take that end to end without having to manually ingest all these different after the fact concepts into that development process. It should be a natural flow on. We're not saying the work is done there. There's still a lot of things to do. But I think the first glimpse of what we have there is stunning. Docker, as you may know, has some great tools to define what an application is. Docker Compose, for example, you can see how a multi-service application is laid out. Cisco can actually then, provide plug-ins into that composed (mumbles) and say well, this web tier needs to talk to this application tier, and these are the basic premises of what networking security tools can then plug into to enforce policy. So, we feel that that can be a lot more automated. And we'll work towards that. >> Bradley, thanks so much for coming on the Cube. Really appreciate it. Great to see ya again. And Docker obviously continuing to do great and we'll continue to cover all your events. But my final question for you is, Take a minute to just explain quickly and succinctly for the audience, the Docker Cisco relationship. What is that? I mean, joint partnership? Is it, you guys just hi fivin' each other? You actually writin' code together? Is there a technology partnership? Give some details on the relationship. >> Yeah, sure. It's a strategic partnership, which basically means that it goes beyond just hi fiving each other. There's some of that as well but we believe that any relationship of this size needs to be built on solid attainable things. So, we worked on the Contiv project together, for example. We also worked together on what we call Cisco validated designs for Docker. >> John: Just joint engineering. >> Joint engineering work. We also work on joint marketing and joint go to market motions as well and joint support. So, you can actually call up Cisco for a Docker, Cisco solution that's deployed out there, you can call up Cisco support and they will hold that trouble ticket and if any troubles do arise, they take the call and then work on that on behalf of us. >> It's a nice relationship. It's a win-win. They get some cloud native mojo with Docker and this new app world. You guys get enterprise access to the huge amount of clients that they have. >> Bradley: Exactly. Alright, final, final question, Since one just popped in my head. It always happens that way when you're going to roll. But, what's on the roadmap for you guys with respect to the Cisco and this DevNet Create, obviously is going to their foray into this new world and bring in a new eco system with DevNet their core application, I mean, their core developer community, What's on the Docker roadmap? What can we expect to see that's going to be fruits of the labor? >> I think one of the things that we're definitely going to be focusing quite a lot on is to look at that first step of that journey, which is even taking, not just the microservices, that everyone loves to talk about, but even the traditional applications, those monolithic applications that are already deployed out there running mission critical enterprise workloads on there, We want to take those, together with partnerships, like Cisco, and Dockerize those. And eventually, modernize them and eventually evolve them into microservices. >> Yeah, might get those mission critical apps microservicized if that's a word. (laughs) Bradley Wong, Director of Product Management, Great to see you. Thanks for coming on the Cube. Live coverage at the Cube here at the Cisco's inaugural event. Again, great show. (mumbles) I'm John Furrier with Peter Burris. More analysis and commentary and interviews after this short break. (robotic music) >> Hi, I'm April Mitchell and I'm the Senior Director of Strategy