>>mhm. Hello and welcome to the cubes Ducker con coverage. I'm John Ferry, host of the Cube. We've got a great segment here with slim dot AI CEO John Amaral. Stealth mode, SAS Company. Start up in the devops space with tools today and open source around. Supply chain security with containers closed beta with developers. John, Thanks for coming on. Congratulations for being platinum sponsor here, Dr Khan. Thanks for coming on The Cube. >>Thanks so much on my pleasure. >>You know, container analysis, management optimisation. You know, that's super important. But security is at the centre of all the action we're seeing with containers. We've been talking shift left on a lot of cube conversations. What that means? Is it an outcome? Is that the product software supply chain? You seek them? A secure where malware. All these things are part of now the new normal in cloud Native. You guys at the centre of this, the surface areas change. All these things are important. Take a minute to explain what you guys are doing as a as a tools and open source. Some of the things you're doing, I know you got a stealth mode product. You probably can't talk about. But you gotta close, Beta. Can you give us a little bit of a teaser? What slim dot ai about >>sure. So someday I is about helping developers build secure containers fast, and that really plays to a few trends in the marketplace that are really apparent and important right now in a federal mandate and a bunch of really highly publicised breaches that have all been caused by software supply, chain risks and security and software supply, chain security has become a really top of mind concept for people who secure things and people who develop software and runs. SAS so slim that AI has built a bunch of capabilities and tools that allow software developers at their desks to better understand and build secure containers that really reduce software supply. Chain risk as you think about containers being run in production. And we do three things to help developers one, as we help them know everything about their software. It's a kind of a core concept of suffering supply chain security. Just know what software is in your containers to. Another core concept is only ship to production. What you need to run. That's all about risk surface and the ability for you to easily make a container small that has as much a software reduction in it as possible. And three, it's removed as many vulnerabilities as possible to Slim Toolset. Both are open source and our SAS data platform make that easy for developers to do >>so. Basically, you have a nice, clean, secure environment. Know what's in there. Don't only put in production was needed and make sure it's tight and it's trimmed down perfectly. So you're kind of teasing out this concept of slimming, which is in the name of the company. But it really is about surface area of attack around containers and super important as it becomes more and more prominent in the environment these days. What is container slimming and why is it important for supply chain security? >>Sure. So in the in the in the realm of software supply chain security, best practises right, there are three core concepts. One is the idea of an S bahn that you should know the inventory of all the software that runs in your world to its security posture, signing containers, making sure that the authenticity of the software that you use and production is well understood. And the third is, well, managing exactly what shopper you ship. The first two things I said are simply just inventory and basics about knowing what software you have. But no one answers the question. What software do I need? So I run a container and say, It's a gig and it's got all these packages in. It comes from the operating system from note, etcetera. It's got all this stuff in it. I know the parts that I write my code to. But all that other stuff, what is it? Why is it there? What's the risk in it? That slimming part is all about managing the list of things you actually shipped to the absolute minimum and with confidence that you know that that code will actually work when it gets production but be as small as possible. That's what slimming is all about, and it really reduces supply chain risk by lowering the attack surface in your container, but also trimming your supply chain to only the minimum pieces you need, which really causes a lot of improvements in in the operational overhead of having software supply chain security >>It's interesting as you get more more volume and velocity around containers, uh, and automation kicks in. Sometimes things are turning on and off you don't even know. And shift left has been a great trend for getting in the CI CD pipeline for developer productivity. Really cool. What are some of the consequences that's going on with this? Because then you start to get into some of these areas like some stuff happens that the developers have to come shift back and can take care of stuff. So, you know, C. Tus and CSOs are really worried about this container dynamic. What's the What's the new thing that's causing the problems here? What's the issue around the management that CDOs and CDOs care about? >>Sure. And I'll talk about the shift left implications as well for that exact point. So as you start to worry about software supply, chain security and get a handle on all the software you ship to prod well, part of that is knowledge is power. But it's also, um, risk and work as soon as I know about problems with my containers or the risk surface, and I got to do something about it so we're really getting into the age where everyone has to know about the software they ship. As soon as you know about that, say there's a vulnerability or a package that's a little risky or some surface area you don't really understand. The only place that can be evaded is by going back to the developers and asking them. What is that? How do I remove it? Please do that work. So the software supply chain security knowledge turns into developer security work. Now the problem is, is that historically, the knowledge was imperfect, and the developer, you know, involvement in that was, I'd say, at Hawk, meaning that developers had best practises that did the best they could. But the scrutiny we have now on minimising this kind of risk is really high. The beautiful part about containers is their portable, and it's an easily transferrable piece of software. So you have a lot of producers and a lot of consumers of containers. Consumers of containers that care about supply chain risk are now starting to push back on, producers saying, Take those vulnerabilities out, move those packages, make this thing more secure, lower the risk profile this works its way all the way back to the developers who don't really have the tools, capabilities and automation is to do the work I just described easily, and that's an opportunity that Slim is really addressing, making it easy for developers to remove risk. >>And that's really the consequences of shifting left without having the slimming. Because what you're saying is your shift left and that's kind of annulled out because you've got to go back and fix it. The work comes, >>that's right. And yeah, and it's not an easy task for a developer to understand the code that they didn't intentionally put in the container. It's like, Okay, there's a package in that operating system. What does it do? I don't know. Do I even use it? I don't know. So there's like tonnes of analytic and I would say even optimisation questions and work to be done, but they're just not equipped to, because the tooling for that is really immature Slims on a mission to make that really easy for them and do it automatically so they don't have to think about it. We just automatically remove stuff you don't use and voila! You've got this like perfectly pre optimised capability. >>You know, this suffer supply chain is huge, and I remember when open source started when I remember when I was breaking into the business. Now it's such a height in such an escalation of new developers. This it's a real issue that that's going to be resolved. It has to be because supply chain is part of open source, right? As more code comes in, you got to verify. You gotta make sure it's it's slimming where it needs to be slim and optimised. There needs to be optimised, huge trend. Um and so I just love this area. I think it's really innovative and needed. So congratulations on that, you know, have one more question for you before we get into to close out. Um, you guys are part of the Docker Extensions launch and your partner, >>Why >>is this important to participate in this programme and and what do you guys hope to hope it does for slim dot ai, >>First of all, doctors, the ubiquitous platform, their hub has millions and millions of containers. We've got millions and millions of developers using Docker desktop to actually build and work on containers. It's like literally the sandbox for all local work for building containers. It's a fair statement. So inclusion in Dr Khan and the relationship we're building with Docker is really important for developers and that we're bringing these capabilities to the place where developers work and live every day. It's where all the containers live in the world. So we want to have our technology be easy to use with docker tools. We want to keep developers workflows and systems and and tools of record be the same. We just want to help them use those tools better and optimist outputs. From that we've we've worked since our inception to make our tools really, really friendly for darker and darker environments to, um, we are building a doctor extension. Uh, they have, uh, in this darker con. They're launching their doctor extensions programme to the worldwide audience. We have been one of the lucky Cos that's been selected to build one of the early Dr desktop plug ins. It's derived from our capabilities and our Saas platform and an open source, and it's it's effectively an MRI machine, an awesome analytic tool that allows any developer to really understand the composition, security and profile of any container they work with. So it's giving the sight to the blind, so to speak, that it's this new tool to make container analysis easy. >>Well, John, you guys got a great opportunity. Container analysis, management, optimisation key to security, enabling it and maintaining and sustaining it. And it's changing. I know you guys. Your co founder also did a doctor Slim. So you guys are deep in the open source. I Congratulations on that. We'll see a Q. Khan for the remaining time. We have give a plug for the company, obviously in stealth mode price going to come out later this year. You got a developer preview? What's What's the company all about? What's the most important story here? Dr. Khan? >>Sure, just to playback. So we help developers do three important things. Know everything about the software in their containers to only ship stuff to production that you need, and and and three remove as many vulnerabilities as possible. That's really about managing and understanding the risk surface. It ties right back to software supply chain security, and any developer can use these tools today to emit and build containers that are more secure and better production grade containers, and it's easy to do. We have an open source project called Dioxin. Go check it out. Uh, it's not. It's on git Hub. It's easy to find if you go to w w w dot slim that ai you can find access to that. We have tens of thousands of developers, 500,000 plus downloads. We have developers everywhere using those tools today and open source to do the objectives. I just said You can also easily sign up for our data for our Saas platform, you can use the doctor extension, go ahead and do that and really get on your journey to make those outcomes reality for you. And really kind of make those SEC ops people downstream not have to shift anything left. It's super easy for you to be a great participant in software slash insecurity. >>All right. John Amaral, CEO slim dot ai Stealth. Most thanks for coming The Cube Cube coverage of Dr Khan. Thanks for watching. I'm John Kerry hosted the Cube back to more Dr Khan after the short break. Mhm mhm

>>Welcome back to the cubes coverage of dr khan 2021. I'm john for your host of the cube. We're here with Amanda Silver, corporate vice president, product developer division at Microsoft. Amanda, Great to see you you were on last year, Dr khan. Great to see you again a full year later were remote. Thanks for coming on. I know you're super busy with build happening this week as well. Thanks for making the time to come on the cube for Dr khan. >>Thank you so much for having me. Yeah, I'm joining you like many developers around the globe from my personal home office, >>developers really didn't skip a beat during the pandemic and again, it was not a good situation but developers, as you talked about last year on the front lines, first responders to creating value quite frankly, looking back you were pretty accurate in your prediction, developers did have an impact this year. They did create the kind of change that really changed the game for people's lives, whether it was developing solutions from a medical standpoint or even keeping systems running from call centres to making sure people got their their their goods or services and checks and and and kept sanity together. So. >>Yeah absolutely. I mean I think I think developers you know get the M. V. P. Award for this year because you know at the end of the day they are the digital first responders to the first responders and the pivot that we've had to make over the past year in terms of supporting remote telehealth, supporting you know online retail, curbside pickup. All of these things were done through developers being the ones pushing the way forward remote learning. You know my kids are learning at home right behind me right now so you might hear them during the interview that's happening because developers made that happen. >>I don't think mom please stop hogging the band with, they've got a gigabit. Stop it. Don't be streaming. My kids are all game anyway, Hey, great to have you on and you have to get the great keynote, exciting to see you guys continue the collaboration with Docker uh with GIT hub and Microsoft, A great combination, it's a 123 power punch of value. You guys are really kind of killing it. We heard from scott and dan has been on the cube. What's your thoughts on the partnership with the developer division team at Microsoft with Doctor, What's it all about this year? What's the next level? >>Well, I mean, I think, I think what's really awesome about this partnership is that we all have, we all are basically sharing a common mission. What we want to do is make sure that we're empowering developers, that we're focused on their productivity and that we're delivering value to them so they can do their job better so that they can help others. So that's really kind of what drives us day in and day out. So what we focus on is developer productivity. And I think that's a lot of what dana was talking about in her session, the developer division. Specifically, we really try to make sure that we're improving the state of the art from modern developers. So we want to make sure that every keystroke that they take, every mouse move that they make, it sounds like a song but every every one of those matter because we want to make sure that every developers writing the code that only they can write and in terms of the partnership and how that's going. You know my team and the darker team have been collaborating a ton on things like dr desktop and the Doctor Cli tool integrations. And one of the things that we do is we think about pain points and various workflows. We want to make sure that we're shaving off the edges of all of the user experience is the developers have to go through to piece all of these applications together. So one of the big pain points that we have heard from developers is that signing into the Azure cloud and especially our sovereign clouds was challenging. So we contributed back to uh back to doctor to actually make it easier to sign into these clouds. And so dr developers can now use dr desktop and the Doctor Cli to actually change the doctor context so that its Azure. So that makes it a lot easier to connect the other. Oh, sorry, go ahead. No, I was just >>going to say, I love the reference of the police song. Every breath you take, every >>mouth moving. Great, >>great line there. Uh, but I want to ask you while you're on this modern cloud um, discussion, what is I mean we have a lot of developers here at dr khan. As you know, you guys know developers in your ecosystem in core competency. From Microsoft, Kublai khan is a very operator like focus developed. This is a developer conference. You guys have build, what is the state of the art for a modern cloud developer? Could you just share your thoughts because this comes up a lot. You know, what's through the art? What's next jan new guard guard? It's his legacy. What is the state of the art for a modern cloud developer? >>Fantastic question. And extraordinarily relevant to this particular conference. You know what I think about often times it's really what is the inner loop and the outer loop look like in terms of cycle times? Because at the end of the day, what matters is the time that it takes for you to make that code change, to be able to see it in your test environment and to be able to deploy it to production and have the confidence that it's delivering the feature set that you need it to. And it's, you know, it's secure, it's reliable, it's performance, that's what a developer cares about at the end of the day. Um, at the same time, we also need to make sure that we're growing our team to meet our demand, which means we're constantly on boarding new developers. And so what I take inspiration from our, some of the tech elite who have been able to invest significant amounts in, in tuning their engineering systems, they've been able to make it so that a new developer can join a team in just a couple of minutes or less that they can actually make a code change, see that be reflected in their application in just a few seconds and deploy with confidence within hours. And so our goal is to actually be able to take that state of the art metric and democratize that actually bring it to as many of our customers as we possibly can. >>You mentioned supply chain earlier in securing that. What are you guys doing with Docker and how to make that partnership better with registries? Is there any update there in terms of the container registry on Azure? >>Yeah, I mean, you know, we, we we have definitely seen recent events and and it almost seems like a never ending attacks that that you know, increasingly are getting more and more focused on developer watering holes is how we think about it. Kind of developers being a primary target um for these malicious hackers. And so what it's more important than ever that every developer um and Microsoft especially uh really take security extraordinarily seriously. Our engineers are working around the clock to make sure that we are responding to every security incident that we hear about and partnering with our customers to make sure that we're supporting them as well. One of the things that we announced earlier this week at Microsoft build is that we've actually taken, get have actions and we've now integrated that into the Azure Security Center. And so what this means is that, you know, we can now do things like scan for vulnerabilities. Um look at things like who is logging in, where things like that and actually have that be tracked in the Azure security center so that not just your developers get that notification but also your I. T. Operations. Um In terms of the partnership with dR you know, this is actually an ongoing partnership to make sure that we can provide more guidance to developers to make sure that they are following best practices like pulling from a private registry like Docker hub or at your container registry. So I expect that as time goes on will continue to more in partnership in this space >>and that's going to give a lot of confidence. Actually, productivity wise is going to be a big help for developers. Great stuff is always good, good progress. They're moving the needle. >>Last time we >>spoke we talked about tools and setting Azure as the doctor context duty tooling updates here at dot com this year. That's notable. >>Yeah, I mean, I think, you know, there's one major thing that we've been working on which has a big dependency on docker is get help. Code space is now one of the biggest pain points that developers have is setting up a new DEV box, which they often have to do when they are on boarding a new employee or when they're starting a new project or even if they're just kicking the tires on a new technology that they want to be able to evaluate and sometimes creating a developer environment can actually take hours um and especially when you're trying to create a developer environment that matches somebody else's developer environment that can take like a half a day and you can spend all of your time just debugging the differences in environment variables, for example, um, containers actually makes that much easier. So what you can do with this, this services, you can actually create death environment spun up in the cloud and you can access it in seconds and you get from there are working coding environment and a runtime environment and this is repeatable via containers. So it means that there's no inadvertent differences introduced by each DEV. And you might be interested to know that underneath this is actually using Docker files and dr composed to orchestrate the debits and the runtime bits for a whole bunch of different stacks. And so this is something that we're actually working on in collaboration with the with the doctor team to have a common the animal format. And in fact this week we actually introduced a couple of app templates so that everybody can see this all in action. So if you check out a ca dot m s forward slash app template, you can see this in action yourself. >>You guys have always had such a strong developer community and one thing I love about cloud as it brings more agility, as we always talk about. But when you start to see the enterprise grow into, the direction is going now, it's almost like the developer communities are emerging, it's no longer about all the Lennox folks here and the dot net folks there, you've got windows, you've got cloud, >>it's almost >>the the the solidification of everyone kind of coming together. Um and visual studio, for instance, last year, I think you were talking about that to having to be interrogated dr composed, et cetera. >>How do you see >>this melting pot emerging? Because at the end of the day, you pick the language you love and you got devops, which is infrastructure as code doesn't matter. So give us your take on where we are with that whole progress of of making that happen. >>Well, I mean I definitely think that, you know, developer environments and and kind of, you know, our approach to them don't need to be as dogmatic as they've been in the past. I really think that, you know, you can pick the right tool and language and stand developer stack for your team, for your experience and you can be productive and that's really our goal. And Microsoft is to make sure that we have tools for every developer and every team so that they can build any app that they want to want to create. Even if that means that they're actually going to end up ultimately deploying that not to our cloud, they're going to end up deploying it to AWS or another another competitive cloud. And so, you know, there's a lot of things that we've been doing to make that really much easier. We have integrated container tools in visual studio and visual studio code and better cli integrations like with the doctor context that we had talked about a little bit earlier. We continue to try to make it easier to build applications that are targeting containers and then once you create those containers it's much easier to take it to another environment. One of the examples of this kind of work is now that we have WsL and the Windows subsystem for Lennox. This makes it a lot easier for developers who prefer a Windows operating system as their environment and maybe some tools like Visual Studio that run on Windows, but they can still target Lennox with as their production environment without any impedance mismatch. They can actually be as productive as they would be if they had a Linux box as their Os >>I noticed on this session, I got to call this out. I want to get your reaction to it interesting. Selection of Microsoft talks, the container based development. Visual studio code is one that's where you're going to show some some some container action going on with note and Visual Studio code. And then you get the machine learning with Azure uh containers in the V. S. Code. Interesting how you got, you know, containers with V. S. And now you've got machine learning. What does that tell the world about where Microsoft's at? Because in a way you got the cutting edge container management on one side with the doctor integration. Now you get the machine learning which everyone's talking about shifting, left more automation. Why are these sessions so important? Why should people attend? And what's the what's the bottom line? >>Well, like I said, like containers basically empower developer productivity. Um that's what creates the reputable environments, that's what allows us to make sure that, you know, we're productive as soon as we possibly can be with any text act that we want to be able to target. Um and so that's kind of almost the ecosystem play. Um it's how every developer can contribute to the success of others and we can amor ties the kinds of work that we do to set up an environment. So that's what I would say about the container based development that we're doing with both visual studio and visual studio code. Um in terms of the machine learning development, uh you know, the number of machine learning developers in the world is relatively small, but it's growing and it's obviously a very important set of developers because to train a machine learning uh to train an ml model, it actually requires a significant amount of compute resources, and so that's a perfect opportunity to bring in the research that are in a public cloud. Um What's actually really interesting about that particular develop developer stack is that it commonly runs on things like python. And for those of you who have developed in python, you know, just how difficult it is to actually set up a python environment with the right interpreter, with the right run time, with the right libraries that can actually get going super quickly, um and you can be productive as a developer. And so it's actually one of the hardest, most challenging developer stacks to actually set up. And so this allows you to become a machine learning developer without having to spend all of your time just setting up the python runtime environment. >>Yeah, it's a nice, nice little call out on python, it's a double edged sword. It's easier to sling code around on one hand, when you start getting working then you gotta it gets complicated can get well. Um Well the great, great call out there on the island, but good, good, good project. Let me get your thoughts on this other tool that you guys are talking about project tie. Uh This is interesting because this is a trend that we're seeing a lot of conversations here on the cube about around more too many control planes. Too many services. You know, I no longer have that monolithic application. I got micro micro applications with microservices. What the hell is going on with my services? >>Yeah, I mean, I think, you know, containers brought an incredible amount of productivity in terms of having repeatable environments, both for dev environments, which we talked about a lot on this interview already, but also obviously in production and test environments. Super important. Um and with that a lot of times comes the microservices architecture that we're also moving to and the way that I view it is the microservices architecture is actually accompanied by businesses being more focused on the value that they can actually deliver to customers. And so they're trying to kind of create separations of concerns in terms of the different services that they're offering, so they can actually version and and kind of, you know, actually improve each of these services independently. But what happens when you start to have many microservices working together in a SAS or in some kind of aggregate um service environment or kind of application environment is it starts to get unwieldy, it's really hard to make it so that one micro service can actually address another micro service. They can pass information back and forth. And you know what used to be maybe easy if you were just building a client server application because, you know, within the server tear all of your code was basically contained in the same runtime environment. That's no longer the case when every microservices actually running inside of its own container. So the question is, how can we improve program ability by making it easier for one micro service that's being used in an application environment, be to be able to access another another service and kind of all of that context. Um and so, you know, you want to be able to access the service is the the api endpoint, the containers, the ingress is everything, make everything work together as though it felt just as easy as as um you know, server application development. Um And so what this means as well is that you also oftentimes need to get all of these different containers running at the same time and that can actually be a challenge in the developer and test loop as well. So what project tie does is it improves the program ability and it actually allows you to just write a command like thai run so that you can actually in stan she ate all of these containers and get them up and running and basically deploy and run your application in that environment and ultimately make the dev testing or loop much faster >>than productivity gain. Right. They're making it simple to stand up. Great, great stuff. Let me ask you a question as we kind of wrap down here for the folks here at Dakar Con, are >>there any >>special things you'd like to talk about the development you think are important for the developers here within this space? It's very dynamic. A lot of change happening in a good way. Um, but >>sometimes it's hard to keep >>track of all the cool stuff happening. Could you take a minute to, to share your thoughts on what you think are the most important develops developments in this space? That that might be interesting to ducker con attendees. >>I think the most important things are to recognize that developer environments are moving to containerized uh, environments themselves so that they can be repeated, they can be shared, the work, configuring them can be amortized across many developers. That's important thing. Number one important thing. Number two is it doesn't matter as much what operating system you're running as your chrome, you know, desktop. What matters is ultimately the production environment that you're targeting. And so I think now we're in a world where all of those things can be mixed and matched together. Um and then I think the next thing is how can we actually improve microservices, uh programming development together um so that it's easier to be able to target multiple micro services that are working in aggregate uh to create a single service experience or a single application. And how do we improve the program ability for that? >>You know, you guys have been great supporters of DACA and the community and open source and software developers as they transform and become quite frankly the superheroes for the transformation, which is re factoring businesses. So this has been a big thing. I'd love to get your thoughts on how this is all coming together inside Microsoft, you've got your division, you get the developer division, you got GIT hub, got Azure. Um, and then just historically, and he put this up last year army of an ecosystem. People who have been contributing encoding with Microsoft and the partners for many, many decades. >>Yes. The >>heart Microsoft now, how's it all working? What's the news? I get Lincoln, Lincoln, but there's no yet developer model there yet, but probably is soon. >>Um Yeah, I mean, I think that's a pretty broad question, but in some ways I think it's interesting to put it in the context of Microsoft's history. You know, I think when I think back to the beginning of my career, it was kind of a one stack shop, you know, we was all about dot net and you know, of course we want to dot net to be the best developer environment that it can possibly be. We still actually want that. We still want that need to be the most productive developer environment. It could we could possibly build. Um but at the same time, I think we have to recognize that not all developers or dot net developers and we want to make sure that Azure is the most productive cloud for developers and so to do that, we have to make sure that we're building fantastic tools and platforms to host java applications, javascript applications, no Js applications, python applications, all of those things, you know, all of these developers in the world, we want to make sure it can be productive on our tools and our platforms and so, you know, I think that's really kind of the key of you know what you're speaking of because you know, when I think about the partnership that I have with the GIT hub team or with the Azure team or with the Azure Machine learning team or the Lincoln team, um A lot of it actually comes down to helping empower developers, improving their productivity, helping them find new developers to collaborate with, um making sure that they can do that securely and confidently and they can basically respond to their customers as quickly as they possibly can. Um and when, when we think about partnering inside of Microsoft with folks like linkedin or office as an example, a lot of our partnership with them actually comes down to improving their colleagues efficiency. We build the developer tools that office and lengthen are built on top of and so every once in a while we will make an improvement that has, you know, 5% here, 3% there and it turns into an incredible amount of impact in terms of operations, costs for running these services. >>It's interesting. You mentioned earlier, I think there's a time now we're living in a time where you don't have to be dogmatic anymore, you can pick what you like and go with it. Also that you also mentioned just now this idea of distributed applications, distributed computing. You know, distributed applications and microservices go really well together. Especially with doctor. >>Can you share >>your thoughts on the framework that you guys released called Dapper? >>Yeah, yeah. We recently released Dapper. It's called D A P R. You can look it up on GIT hub and it's a programming model for common microservices pattern, two common microservices patterns that make it really easy and automatic to create those kinds of microservices. So you can choose to work with your favorite state stores or databases or pub sub components and get things like cloud events for free. You can choose either http or g R B C so that you can get mesh capabilities like service discovery and re tries and you can bring your own secret store and easily be able to call it from any environment variable. It's also like I was talking about earlier, multi lingual. Um so you don't need to embrace dot net, for example, as you're programming language to be able to benefit from Dapper, it actually supports many programming languages and Dapper itself is actually written and go. Um and so, you know, all developers can benefit from something like Dapper to make it easier to create microservices applications. >>I mean, always great to have you on great update. Take a minute to give an update on what's going on with your division. I know you had to build conference this week. V. S has got the new preview title. We just talked about what are the things you want to get to plug in for? Take a minute to get to plug in for what you're working on, your goals, your objectives hiring, give us the update. >>Yeah, sure. I mean, you know, we we built integrated container tools in visual studio uh and the Doctor extension and Visual Studio code and cli extensions. Uh and you know, even in this most recent release of our Visual Studio product, Visual Studio 16 10, we added some features to make it easier to use DR composed better. So one of the examples of this is that you can actually have uh Oftentimes you need to be able to use multiple doctor composed files together so that you can actually configure various different container environments for a single single application. But it's hard sometimes to create the right Yeah. My file so that you can actually invoke it and invoke the the container and the micro services that you need. And so what this allows you to do is to actually have just a menu of the different doctor composed files so that you can select the runtime and test environment that you need for the subset of the portion of the application that you're working on at the end of the day. This is always about developer productivity. You know, like I said, every keystroke matters. Um and we want to make sure that you as a developer can focus on the code that only you can Right. >>Amanda Silver, corporate vice president product development division of Microsoft. Always great to see you and chat with you remotely soon. We'll be back in in real life with real events soon as we come out of the pandemic and thanks for sharing your insight and congratulations on your success this year and and congratulations on your announcement here at Dakar Gone. >>Thank you so much for having me. >>Okay Cube coverage for Dunkirk on 2021. I'm John for your host of the Cube. Thanks for watching. Mhm

>>mhm Yes. >>Hello and welcome back to the cubes coverage of dr khan 2021 virtual. I'm john Kerry hosted the Q got a great cube segment here. Simon Maple Field C T Oh it's technique. Great company security shifting left great to have you on Simon. Thanks for thanks for stopping by >>absolute pleasure. Thank you very much for having me. >>So you guys were on last year the big partnership with DR Conn remember that interview vividly because it was really the beginning at the beginning but really come to me the mainstream of shifting left as devops. It's not been it's been around for a while. But as a matter of practice as containers have been going super mainstream. Super ballistic in the developer community then you're seeing what's happening. It's containers everywhere. Security Now dev sec apps is the standard. So devops great infrastructure as code. We all know that but now it's def sec ops is standard. This is the real deal. Give us the update on what's going on with sneak. >>Absolutely, yeah. And you know, we're still tireless in our approach of trying to get make sure developers don't just have the visibility of security but are very much empowered in terms of actually fixing issues and secure development is what we're really striving for. So yeah, the update, we're still very, very deep into a partnership with DACA. We have updates on DR desktop which allows developers to scan the containers on the command line, providing developers that really fast feedback as as early as possible. We also have uh, you know, new updates and support for running Docker scan on Lennox. Um, and yeah, you know, we're still there on the Docker hub and providing that security insights um, to, to users who are going to Docker hub to grab their images. >>Well, for the folks watching maybe for the first time, the sneak Docker partnership, we went in great detail last year was the big reveal why Docker and sneak partnership, what is the evolution of that partnership over the year? They speak highly of you guys as a developer partner. Why Doctor? What's the evolution looked like? >>It's a it's a really great question. And I think, you know, when you look at the combination of DACA and sneak well actually let's take let's take each as an individual. Both companies are very, very developer focused. First of all, right, so our goals and will be strife or what we what we tirelessly spend their time doing is creating features and creating, creating an environment in which a developer you can do what they need to do as easily as possible. And that, you know, everyone says they want to be developer friendly, They want to be developer focused. But very few companies can achieve. And you look at a company like doctor, you're a company like sneak it really, really provides that developer with the developer experience that they need to actually get things done. Um, and it's not just about being in a place that a developer exists. It's not enough to do that. You need to provide a developer with that experience. So what we wanted to do was when we saw doctor and extremely developer friendly environment and a developer friendly company, when we saw the opportunity there to partner with Yoko, we wanted to provide our security developer friendliness and developer experience into an already developed a friendly tool. So what the partnership provides is the ease of, you know, deploying code in a container combined with the ease of testing your code for security issues and fixing security issues in your code and your container and pulling it together in one place. Now, one of the things which we as a as a security company um pride ourselves on is actually not necessarily saying we provide security tools. One of what our favorite way of saying is we're a developer tooling company. So we provide tools that are four developers now in doing that. It's important you go to where the developers are and developers on DACA are obviously in places like the Docker hub or the Docker Cli. And so it's important for us to embed that behavior and that ease of use inside Dhaka for us to have that uh that that flow. So the developer doesn't need to leave the Docker Cli developer that doesn't need to leave Docker hub in order to see that data. If you want to go deeper, then there are probably easier ways to find that data perhaps with sneak or on the sneak site or something like that. But the core is to get that insight to get that visibility and to get that remediation, you can see that directly in in the in the Dhaka environment. And so that's what makes the relationship so so powerful. The fact that you combine everything together and you do it at source >>and doing it at the point of code. >>Writing >>code is one of the big things I've always liked about the value proposition is simple shift left. Um So let's just step back for a second. I got to ask you this question because this I wanted to make sure we get this on the table. What are the main challenges uh and needs to, developers have with container security? What are you seeing as the main top uh A few things that they need to have right now for the challenges uh with container security? >>Yeah, it's a it's a very good question. And I think to answer that, I think we need to um we need to think of it in a couple of ways. First of all, you've just got developers security uh in general, across containers. Um And the that in itself is there are different levels at which developers engage with containers. Um In some organizations, you have security teams that are very stringent in terms of what developers can and can't do in other organizations. It's very much the developer that that chooses their environment, chooses their parent image, et cetera. And so there when a developer has many, many choices in which they need to need to decide on, some of those choices will lead to more issues, more risk. And when we look at a cloud native environment, um uh Let's take let's take a node uh image as an example, the number of different uh images tags you can choose from as a developer. It's you know, there are hundreds, probably thousands. That you can actually you can actually choose. What is the developer gonna do? Well, are they going to just copy paste from another doctor file, for example, most likely. What if there are issues in that docker file? They're just gonna copy paste that across mis configurations that exist. Not because the developer is making the wrong decision, but because the developer very often doesn't necessarily know that they need to add a specific directive in. Uh So it's not necessarily what you add in a conflict file, but it's very often what you admit. So there are a couple of things I would say from a developer point of view that are important when we think about cloud security, the first one is just that knowledge that understanding what they need to do, why they need to do it. Secure development doesn't need to be, doesn't mean they need to be deep in security. It means they need to understand how they can develop securely and what what the best decisions that could come from guard rails, from the security team that they provide the development team to offer. But that's the that's an important error of secure development. The second thing and I think one of the most important things is understanding or not understanding necessarily, but having the information to get an act on those things early. So we know the length of time that developers are uh working on a branch or working on um some some code changes that is reducing more and more and more so that we can push to production very, very quickly. Um What we need to do is make sure that as a developer is making their changes, they can make the right decision at the right time and they have the right information at that time. And a lot of this could be getting information from tools, could be getting information from your team where it could be getting information from your production environments and having that information early is extremely important to make. That decision. May be in isolation with your team in an autonomous way or with advice from the security team. But I would say those are the two things having that information that will allow you to make that action, that positive change. Um uh and and yeah, understanding and having that knowledge about how you can develop security. >>All right. So I have a security thing. So I'm a development team and by the way, this whole team's thing is a huge deal. I think we'll get to that. I want to come back to that in a second but just throw this out there. Got containers, got some security, it's out there and you got kubernetes clusters where containers are coming and going. Sometimes containers could have malware in them. Um and and this is, I've heard this out and about how do how that happens off container or off process? How do you know about it? Is that infected by someone else? I mean is it gonna be protected? How does the development team once it's released into the wild, so to speak. Not to be like that, but you get the idea, it's like, okay, I'm concerned off process this containers flying around. What is it How do you track all >>and you know, there's a there's a few things here that are kind of like potential potential areas that, you know, we can trip up when we think about malware that's running um there are certain things that we need to that we need to consider and what we're really looking at here are kind of, what do we have in place in the runtime that can kind of detect these issues are happening? How do we block that? And how do you provide that information back to the developer? The area that I think is, and that is very, very important in order to in order to be able to identify monitor that those environments and then feed that back. So that that that's the kind of thing that can be that can be fixed. Another aspect is, is the static issues and the static issues whether that's in your os in your OS packages, for example, that could be key binaries that exist in your in your in your docker container out the box as well or of course in your application, these are again, areas that are extremely important to detect and they can be detected very very early. So some things, you know, if it's malware in a package that has been identified as malware then absolutely. That can be that can be tracked very very early. Sometimes these things need to be detected a little bit later as well. But yeah, different tools for different for different environments and wear sneak is really focused. Is this static analysis as early as possible. >>Great, great insight there. Thanks for sharing that certainly. Certainly important. And you know, some companies classes are locked down and all of sudden incomes, you know, some some malware from a container, people worried about that. So I want to bring that up. Uh The other thing I want to ask you is this idea of end to end security um and this is a team formation thing we're seeing where modern teams have essentially visibility of their workload and to end. So this is a huge topic. And then by the way it might integrate their their app might integrate with other processes to that's great for containers as well and observe ability and microservices. So this is the trend. What's in it for the developer? If I work with sneak and docker, what benefits do I get if I want to go down that road of having these teams began to end, but I want the security built in. >>Mhm. Yeah, really, really important. And I think what's what's most important there is if we don't look end to end, there are component views and there are applications. If we don't look into end, we could have our development team fixing things that realistically aren't in production anyway or aren't the key risks that are potentially hurting us in our production environment. So it's important to have that end to end of you so that we have the right insights and can prioritize what we need to identify and look at early. Um, so I think, I think that visibility into end is extremely important. If we think about who, who is re fixing uh certain issues, again, this is gonna depend from dog to walk, but what we're seeing more and more is this becoming a developer lead initiative to not just find or be given that information, but ultimately fixed. They're getting more and more responsible for DR files for for I see for for their application code as well. So one of the areas which we've looked into as well is identifying and actually running in cuba Netease workloads to identify where the most important areas that a developer needs to look at and this is all about prioritization. So, you know, if the developer has just a component view and they have 100 different images, 100 different kubernetes conflicts, you know, et cetera. Where do they prioritize, where do they spend their time? They shouldn't consider everything equal. So this identification of where the workloads are running and what um is causing you the most risk as a business and as an organization, that is the data. That can be directly fed back into your, your your vulnerability data and then you can prioritize based on the kubernetes workloads that are in your production and that can be fed directly into the results in the dashboards. That's neat. Can provide you as well. So that end to end story really provides the context you need in order to not just develop securely, but act and action issues in a proper way. >>That's a great point. Context matters here because making it easy to do the right thing as early as possible, the right time is totally an efficiency productivity gain, you see in that that's clearly what people want. It's a great formula, success, reduce the time it takes to do something, reduced the steps and make it easy. Right, come on, that's a that's a formula. Okay, so I gotta bring that to the next level. When I ask you specifically around automation, this is one the hot topic and def sec ops, automation is part of it. You got scale, you got speed, you've got a I machine learning, you go out of all these new things. Microservices, how do you guys fit into the automation story? >>It's a great question. And you know, one of the recent reports that we that we did based on a survey data this year called the state of a state of cloud, native applications security. We we asked the question how automated our people in their in their deployment pipelines and we found some really strong correlations between value from a security point of view um in terms of in terms of having that automation in it, if I can take you through a couple of them and then I'll address that question about how we can be automated in that. So what we found is a really strong correlation as you would expect with security testing in ci in your source code repositories and all the way through the deployment ci and source code were the two of the most most well tested areas across the pipeline. However the most automated teams were twice as likely to test in I. D. S. And testing your CLS in local development. And now those are areas that are really hard to automate if at all because it's developers running running their cli developers running and testing in their I. D. So the having a full automation and full uh proper testing throughout the sclc actually encourages and and makes developers test more in their development environment. I'm not saying there's causation there but there's definite correlation. A couple of other things that this pushes is um Much much more likely to test daily or continuously being automated as you would expect because it's part of the bills as part of your monitoring. But crucially uh 73% of our respondents were able to fix a critical issue in less than a week as opposed to just over 30% of people that were not automated, so almost double people are More likely to fix within a week. 36% of people who are automated can fix a critical security issue in less than a day as opposed to 8% of people who aren't automated. So really strong data that correlates being automated with being able to react now. If you look at something like Sneak what if our um goals of obviously being developer friendly developer first and being able to integrate where developers are and throughout the pipeline we want to test everywhere and often. Okay, so we start as far left as we can um integrating into, you know, CLS integrating into Docker hub, integrating into into doctors can so at the command line you type in doctors can you get sneak embedded in DHAKA desktop to provide you those results so as early as possible, you get that data then all the way through to to uh get reposed providing that testing and automatically testing and importing results from there as well as as well as other repositories, container repositories, being at a poor from there and test then going into ci being able to run container tests in C I to make sure we're not regressing and to choose what we want to do their whether we break, whether we continue with with raising an issue or something like that, and then continuing beyond that into production. So we can monitor tests and automatically send pull requests, etcetera. As and when new issues or new fixes occur. So it's about integrating at every single stage, but providing some kind of action. So, for example, in our ui we provide the ability to say this is the base level you should be or could be at, it will reduce your number of vulnerabilities by X and as a result you're going to be that much more secure that action ability across the pipeline. >>That's a great, great data dump, that's a masterclass right there on automation. Thanks for sharing that sign. I appreciate it. I gotta ask you the next question that comes to my mind because I think this is kind of the dots connect for the customer is okay. I love this kind of hyper focus on containers and security. You guys are all over it, shift left as far as possible, be there all the time, test, test, test all through the life cycle of the code. Well, the one thing that is popping up as a huge growth areas, obviously hybrid cloud devops across both environments and the edge, whether it's five G industrial or intelligent edge, you're gonna have kubernetes clusters at the edge now. So you've got containers. The relationship to kubernetes and then ultimately cloud native work clothes at, say, the edge, which has data has containers. So there's a lot of stuff going on all over the place. What's your, what's your comment there for customer says, Hey, you know, I got, this is my architecture that's happening to me now. I'm building it out. We're comfortable with kubernetes put in containers everywhere, even on the edge how to sneak fit into that story. >>Yeah, really, really great question. And I think, you know, a lot of what we're doing right now is looking at a developer platform. So we care about, we care about everything that a developer can check in. Okay, so we care about get, we care about the repositories, we care about the artifact. So um, if you look at the expansion of our platform today, we've gone from code that people uh, third party libraries that people test. We added containers. We've also added infrastructure as code. So Cuban eighties conflicts, Terror form scripts and things like that. We're we're able to look at everything that the developer touches from their code with sneak code all the way through to your to your container. And I see, so I think, you know, as we see more and more of this pushing out into the edge, cuba Nitties conflict that that, you know, controls a lot of that. So much of this is now going to be or not going to be, but so much of the environment that we need to look at is in the configurations or the MIS configurations in that in those deployment scripts, um, these are some of the areas which which we care a lot about in terms of trying to identify those vulnerabilities, those miS configurations that exist within within those scripts. So I can see yeah more and more of this and there's a potential shift like that across to the edge. I think it's actually really exciting to be able to see, to be able to see those uh, those pushing across. I don't necessarily see any other, any, you know, different security threats or the threat landscape changing as a result of that. Um there could be differences in terms of configurations, in terms of miS configurations that that that could increase as a result, but, you know, a lot of this and it just needs to be dealt with in the appropriate way through tooling through, through education of of of of how that's done. >>Well, obviously threat vectors are all gonna look devops like there's no perimeter. So they're everywhere right? Looking at I think like a hacker to be being there. Great stuff. Quick question on the future relationship with DR. Obviously you're betting a lot here on that container relationship, a good place to start. A lot of benefits there. They have dependencies, they're going to have implications. People love them, they love to use them, helps old run with the new and helps the new run better. Certainly with kubernetes, everything gets better together. What's the future with the DACA relationship? Take us through how you see it. >>So yeah, I mean it's been an absolute blast the doctor and you know, even from looking at some of the internal internal chats, it's been it's been truly wonderful to see the, the way in which both the doctor and sneak from everything from an engineering point of view from a marketing, from a product team. It's been a pleasure to, it's been a pleasure to see that relationship grow and flourish. And, and I think there's two things, first of all, I think it's great that as companies, we, we both worked very, very well together. I think as as as users um seeing, you know, doctor and and and sneak work so so seamlessly and integrated a couple of things. I would love to see. Um, I think what we're gonna see more and more and this is one of the areas that I think, um you know, looking at the way sneak is going to be viewing security in general. We see a lot of components scanning a lot, a lot of people looking at a components can and seeing vulnerabilities in your components. Can I think what we need to, to to look more upon is consolidating a lot of the a lot of the data which we have in and around different scans. What I would love to see is perhaps, you know, if you're running something through doctors can how can you how can you view that data through through sneak perhaps how can we get that closer integration through the data that we that we see. So I would love to see a lot more of that occur, you know, within that relationship and these are kind of like, you know, we're getting to that at that stage where we see integration, it just various levels. So we have the integration where we have we are embedded but how can we make that better for say a sneak user who also comes to the sneak pages and wants to see that data through sneak. So I would love to see at that level uh more there where as I mentioned, we have we have some some additional support as well. So you can run doctors can from from Lenox as well. So I can see more and more of that support rolling out but but yeah, in terms of the future, that's where I would love to see us uh to grow more >>and I'll see in the landscape side on the industry side, um, security is going beyond the multiple control planes out there. Kubernetes surveillance service matches, etcetera, continues to be the horizontally scalable cloud world. I mean, and you got you mentioned the edge. So a lot more complexity to rein in and make easier. >>Yeah, I mean there's a lot more complexity, you know, from a security point of view, the technology is the ability to move quickly and react fast in production actually help security a lot because you know, being able to spin a container and make changes and and bring a container down. These things just weren't possible, you know, 10 years ago, 20 years ago. Pre that it's like it was it's insanely hard compared trying to trying to do that compared to just re spinning a container up. However, the issue I see from a security point of view, the concerns I see is more around a culture and an education point of view of we've got all this great tech and it's it's awesome but we need to do it correctly. So making sure that as you mentioned with making the right decision, what we want to make sure is that right decision is also the easy decision and the clear decision. So we just need to make sure that as we as we go down this journey and we're going down it fast and it's not gonna, I don't see it slowing down, we're going fast down that journey. How do we make, how do we prepare ourselves for that? We're already seeing, you know, miss configurations left, right and center in the news, I am roles as three buckets, etcetera. These are they're they're simpler fixes than we than we believe, right? We just need to identify them and and make those changes as needed. So we just need to make sure that that is in place as we go forward. But it's exciting times for sure. >>It's really exciting. And you got the scanning and right at the point of coding automation to help take that basic mis configuration, take that off the table. Not a lot of manual work, but ultimately get to that cloud scale cool stuff. >>Simon, thank you >>for coming on the cube dr khan coverage. Really appreciate your time. Drop some nice commentary there. Really appreciate it. Thank you. >>My pleasure. Thank you very much. >>Simon Maple Field C T. O. A sneak hot startup. Big partner with Docker Security, actually built in deVOPS, is now dead. Say cops. This is dr khan cube 2021 virtual coverage. I'm sean for your host. Thanks for watching. Mm.

>>Hello and welcome back to the cubes coverage of dr khan 2021. I'm john for your host of the cube. Great guests here cube alumni Stephen Chin, vice president of developer relations for jay frog Stephen, great to see you again this remote this time this last time was in person. Our last physical event. We had you in the queue but great to see you. Thanks for coming in remotely. >>No, no, I'm very glad to be here. And also it was, it was awesome to be in person at our s a conference when we last talked and the last year has been super exciting with a whole bunch of crazy things like the I. P. O. And doing virtual events. So we've, we're transitioning to the new normal. We're looking forward to things getting to be hybrid. >>Great success with jay frog. We've been documenting the history of this company, very developer focused the successful I. P. O. And just the continuation that you guys have transitioned beautifully to virtual because you know, developer company, it runs virtual, but also you guys have been all about simplicity for developers and and we've been talking for many, many years with you guys on this. This is the theme that dr khan again, this is a developer conference, not so much an operator conference, but more of a deva deV developer focused. You guys have been there from the beginning, um nationally reported on it. But talk about jay Frog and the Doctor partnership and why is this event so important for you? >>Yeah. So I think um like like you said, jay Frog has and always is a developer focused company. So we we build tools and things which which focus on developer use cases, how you get your code to production and streamlining the entire devoPS pipeline. And one of the things which which we believe very strongly in and I think we're very aligned with with doctor on this is having secure clean upstream dependencies for your Docker images for other package and language dependencies and um you know, with the announcement of dr khan and dr Hubbs model changing, we wanted to make sure that we have the best integration with doctor and also the best support for our customers on with Docker hub. So one of the things we did strategically is um, we um combined our platforms so um you can get the best in class developer tools for managing images from Docker. Um everyone uses their um desktop tools for for building and managing your containers and then you can push them right to the best container registry for managing Docker Images, which is the jay frog platform. And just like Docker has free tools available for developers to use. We have a free tier which integrates nicely what their offerings and one of the things which we collaborate with them on is for anybody using our free tier in the cloud. Um there's there's no limits on the Docker images. You can pull no rate limiting, no throttling. So it just makes a clean seamless developer experience to to manage your cloud native projects and applications. >>What's the role of the container registry in cloud NATO? You brought that up? But can you just expand on that point? >>Yeah. So I think when you when you're doing deployments to production, you want to make sure both that you have the best security so that you're making sure that you're scanning and checking for vulnerabilities in your application and also that you have a complete um traceability. Basically you need a database in a log of everything you're pushing out to production. So what container registries allow you to do is um they keep all of the um releases all of the Docker images which are pushing out. You can go back and roll back to a previous version. You can see exactly what's included in those Docker images. And we jay frog, we have a product called X ray which does deep scanning of container images. So it'll go into the Docker Image, it'll go into any packages installed, it'll go into application libraries and it does kind of this onion peel apart of your entire document image to figure out exactly what you're using. Are there any vulnerabilities? And the funny thing about about Docker Images is um because of the number of libraries and packages and installed things which you haven't given Docker Image. If you just take your released Docker Image and let it sit on the shelf for a month, you have thousands of vulnerabilities, just just buy it um, by accruing from different reported zero day vulnerabilities over time. So it's extremely important that you, you know what those are, you can evaluate the risk to your organization and then mitigated as quickly as possible. If there is anything which could impact your customers, >>you bring up a great point right there and that is ultimately a developer thing that's been, that's generational, you know what generation you come from and that's always the problem getting the patches in the old days, getting a new code updated now when you have cloud native, that's more important than ever. And I also want to get your thoughts on this because you guys have been early on shift left two years ago, shift left was not it was not a new thing for you guys ever. So you got shift left building security at the point of coding, but you're bringing up a whole another thing which is okay automation. How do you make it? So the developments nothing stop what they're doing and then get back and say, okay, what's out there and my containers. So so how do you simplify that role? Because that's where the partnership, I think really people are looking to you guys and Dakar on is how do you make my life easier? Bottom line, what's it, what's it, what's it about? >>Yeah. So I I think when you when you're looking at trying to manage um large applications which are deployed to big kubernetes clusters and and how you have kind of this, this um all this infrastructure behind it. One of the one of the challenges is how do you know what you have that in production? Um So what, how do you know exactly what's released and what dependencies are out there and how easily can you trace those back? Um And one of the things which we're gonna be talking about at um swamp up next week is managing the overall devops lifecycle from code all the way through to production. Um And we we have a great platform for doing package management for doing vulnerability scanning, for doing um ci cd but you you need a bunch of other tools too. So you need um integrations like docker so you can get trusted packages into your system. You need integrations with observe ability tools like data, dog, elastic and you need it some tools for doing incident management like Patriot duty. And what we've, what we've built out um is we built out an ecosystem of partner integrations which with the J frog platform at the center lets you manage your entire and and life cycle of um devops infrastructure. And this this addresses security. It addresses the need to do quick patches and fixes and production and it kind of stitches together all the tools which all of the successful companies are using to manage their fast moving continuous release cycle, um and puts all that information together with seamless integration with even developer tools which um which folks are using on a day to day basis, like slack jeer A and M. S. Teams. >>So the bottom line then for the developer is you take the best of breed stuff and put it, make it all work together easily. That right? >>Yeah. I mean it's like it's seamless from you. You've got an incidents, you click a button, it sticks Ajira ticket in for you to resolve. Um you can tie that with the code, commits what you're doing and then directly to the security vulnerability which is reported by X ray. So it stitches all these different tools and technologies together for a for a seamless developer experience. And I think the great relationship we have with Docker um offers developers again, this this best in class container management um and trusted images combined with the world's best container registry. >>Awesome. Well let's get into that container issue products. I think that's the fascinating and super important thing that you guys solve a big problem for. So I gotta ask you, what are the security risks of using unverified and outdated Docker containers? Could you share your thoughts on what people should pay attention to because if they got unverified and outdated Docker containers, you mentioned vulnerabilities. What are those specific risks to them? >>Yeah, so I there's there's a lot of um different instances where you can see in the news or even some of the new government mandates coming out that um if you're not taking the right measures to secure your production applications and to patch critical vulnerabilities and libraries you're using, um you end up with um supply chain vulnerability risks like what happened to solar winds and what's been fueling the recent government mandates. So I think there's a there's a whole class of of different vulnerabilities which um bad actors can exploit. It can actually go quite deep with um folks um exploiting application software. Neither your your company or in other people's systems with with the move to cloud native, we also have heavily interconnected systems with a lot of different attack points from the container to the application level to the operating system level. So there's multiple different attack vectors for people to get into your software. And the best defense is an organization against security. Vulnerabilities is to know about them quickly and to mitigate them and fix them in production as quickly as possible. And this requires having a fast continuous deployment strategy for how you can update your code quickly, very quick identification of vulnerabilities with tools like X ray and other security scanning tools, um and just just good um integration with tools developers are using because at the end of the day it's the developers who both are picking the libraries and dependencies which are gonna be pushed into production and also they're the ones who have to react and and fix it when there's a uh production incident, >>you know, machine learning and automation. And it's always, I love that tech because it's always kind of cool because it's it's devops in action, but you know, it's it's not like a silver bullet, your machine, your machine learning is only as good as your your data and the code is written on staying with automation. You're not automating the right things or or wrong things. It's all it's all subjective based on what you're doing and you know Beauty's in the eye of the beholder when you do things like that. So I wanna hear your thoughts on on automation because that's really been a big part of the story here, both on simplicity and making the load lighter for developers. So when you have to go out and look at modifying code updates and looking at say um unverified containers or one that gets a little bit of a hair on it with with with more updates that are needed as we say, what do you what's the role of automation? How do you guys view that and how do you talk to the developers out there when posturing for a strategy on and a playbook for automation? >>Yeah, I think you're you're touching on one of the most critical parts of of any good devops um platform is from end to end. Everything should be automated with the right quality gates inserted at different points so that if there's a um test failure, if you have a build failure, if you have a security vulnerability, the the automatic um points in there will be triggered so that your release process will be stopped um that you have automated rollbacks in production um so that you can make sure that their issues which affect your customers, you can quickly roll back and once you get into production um having the right tools for observe ability so that you can actually sift through what is a essentially a big data problem. So with large systems you get so much data coming back from your application, from the production systems, from all these different sources that even an easy way to sift through and identify what are the messages coming back telling you that there's a problem that there's a real issue that you need to address versus what's just background noise about different different processes or different application alerts, which really don't affect the security of the functionality of your applications. So I think this this end to end automation gives you the visibility and the single pane of glass to to know how to manage and diagnose your devops infrastructure. >>You know, steve you bring up a great point. I love this conversation because it always highlights to me why I love uh Coop Con and Cloud Native con part of the C N C F and dr khan, because to me it's like a microcosm of two worlds that are living together. Right? You got I think Coop khan has proven its more operated but not like operator operator, developer operators. And you got dr khan almost pure software development, but now becoming operators. So you've got that almost those two worlds are fusing together where they are running together. You have operating concerns like well the Parachute open, will it work? And how do I roll back these roll back? These are like operating questions that now developers got to think about. So I think we're seeing this kind of confluence of true devops next level where you can't you can be just a developer and have a little bit of opposite you and not be a problem. Right? Or or get down under the under the hood and be an operator whenever you want. So they're seeing a flex. What's your thoughts on this is just more about my observation kind of real time here? >>Yeah, so um I think it's an interesting, obviously observation on the industry and I think you know, I've been doing DEVOPS for for a long time now and um I started as a developer who needed to push to production, needed to have the ability to to manage releases and packages and be able to automate everything. Um and this naturally leads you on a path of doing more operations, being able to manage your production, being able to have fewer incidents and issues. Um I think DEVOPS has evolved to become a very complicated um set of tools and problems which it solves and even kubernetes as an example. Um It's not easy to set up like setting up a kubernetes cluster and managing, it is a full time job now that said, I think what you're seeing now is more and more companies are shifting back to developers as a focus because teams and developers are the kingmakers ends with the rise of cloud computing, you don't need a full operations team, you don't need a huge infrastructure stack, you can you can easily get set up in the cloud on on amazon google or as your and start deploying today to production from from a small team straight from code to production. And I think as we evolve and as we get better tools, simpler ways of managing your deployments of managing your packages, this makes it possible for um development teams to do that entire site lifecycle from code through to production with good quality checks with um good security and also with the ability to manage simple production incidents all by themselves. So I think that's that's coming where devoPS is shifting back to development teams. >>It's great to have your leadership and your experience. All right there. That's a great call out, great observation, nice gym there. I think that's right on. I think to get your thoughts if you don't mind going next level because you're, you're nailing what I see is the successful companies having these teams that could be and and workflows and have a mix of a team. I was talking about Dana Lawson who was the VP of engineering get up and she and I were riffing on this idea that you don't have to have a monolithic team because you've got you no longer have a monolithic environment. So you have this microservices and now you can have these, I'm gonna call micro teams, but you're starting to see an SRE on the team, that's the developer. Right? So this idea of having an SRE department maybe for big companies, that could be cool if you're hyper scalar, but these development teams are having certain formations. What's your observation to your customer base in terms of how your customers are organizing? Because I think you nailed the success form of how teams are executing because it's so much more agile, you get the reliability, you need to have security baked in, you want end to end visibility because you got services starting and stopping. How are teams? How are you seeing developers? What's the state of the art in your mind for formation? >>Yeah, so I think um we we work with a lot of the biggest companies who were really at the bleeding edge of innovation and devoPS and continuous delivery. And when you look at those teams, they have, they have very, very small teams, um supporting thousands of developers teams um building and deploying applications. So um when you think of of SRE and deVOPS focus there is actually a very small number of those folks who typically support humongous organizations and I think what we're hearing from them is their increasingly getting requirements from the teams who want to be self service, right? They want to be able to take their applications, have simple platforms to deploy it themselves to manage things. Um They don't they don't want to go through heavy way processes, they wanted to be automated and lightweight and I think this is this is putting pressure on deVOPS teams to to evolve and to adopt more platforms and services which allow developers to to do things themselves. And I think over time um this doesn't this doesn't get rid of the need for for devops and for SRE roles and organizations but it it changes because now they become the enablers of success and good development teams. It's it's kind of like um like how I. T. Organizations they support you with automated rollouts with all these tools rather than in person as much as they can do with automation. Um That helps the entire organization. I think devops is becoming the same thing where they're now simplifying and automating how developers can be self service and organizations. >>And I think it's a great evolution to because that makes total sense because it is kind of like what the I. T. Used to do in the old days but its the scale is different, the services are different, the deVOPS tools are different and so they really are enabling not just the cost center there really driving value. Um and this brings up the whole next threat. I'd love to get your thoughts because you guys are, have been doing this for developers for a while. Tools versus platform because you know, this whole platform where we're a platform were control plane, there's still a need for tooling for developers. How do we thread the needle between? What's, what's good for a tool? What's good for a platform? >>Yeah, So I I think that um, you know, there's always a lot of focus and it's, it's easier if you can take an end to end platform, which solves a bunch of different use cases together. But um, I I think a lot of folks, um, when you're looking at what you need and how you want to apply, um, devops practices to your organization, you ideally you want to be able to use best in breed tools to be able to solve exactly what your use cases. And this is one of the reasons why as a company with jay frog, we we try to be as open as possible to integrations with the entire vendor ecosystem. So um, it doesn't matter what ci cd tool you're using, you could be using Jenkins circle, ci spinnaker checked on, it doesn't matter what observe ability platform you're using in production, it doesn't matter what um tools you're using for collaboration. We, we support that whole ecosystem and we make it possible for you to select the the best of breed tools and technologies that you need to be successful as an organization. And I think the risk is if, if you, if you kind of accept vendor lock in on a single platform or or a single cloud platform even um then you're, you're not getting the best in breed tools and technologies which you need to stay ahead of the curve and devops is a very, very fast moving um, um, discipline along with all the cloud native technologies which you use for application development and for production. So if you're, if you're not staying at the bleeding edge and kind of pushing things forward, then you're then you're behind and if you're behind, you're not be able to keep up with the releases, the deployments, you need to be secure. So I think what you see is the leading organizations are pushing the envelope on on security, on deployment and they're they're using the best tools in the industry to make that happen. >>Stephen great to have you on the cube. I want to just get your thoughts on jay frog and the doctor partnership to wrap this up. Could you take them in to explain what's the most important thing that developers should pay attention to when it comes to security for Docker images? >>Yeah. So I think when you're when you're developer and you're looking at your your security strategy, um you want tools that help you that come to you and that help you. So you want things which are going to give you alerts in your I. D. With things which are going to trigger your in your Ci cd and your build process. And we should make it easy for you to identify mitigate and release um things which will help you do that. So we we provide a lot of those tools with jay frog and our doctor partnership. And I think if you if you look at our push towards helping developers to become more productive, build better applications and more secure applications, this is something the entire industry needs for us to address. What's increasingly a risk to software development, which is a higher profile vulnerabilities, which are affecting the entire industry. >>Great stuff. Big fan of jay frog watching you guys be so successful, you know, making things easy for developers is uh, and simpler and reducing the steps it takes to do things as a, I say, is the classic magic formula for any company, Make it easier, reduce the steps it takes to do something and make it simple. Um, good success formula. Great stuff. Great to have you on um for a minute or two, take a minute to plug what's going on in jay frog and share what's the latest increase with the company, what you guys are doing? Obviously public company. Great place to work, getting awards for that. Give the update on jay frog, put a plug in. >>Yeah. And also dr Frog, I've been having a lot of fun working at J frog, it's very, very fast growing. We have a lot of awesome announcements at swamp up. Um like the partnerships were doing um secure release bundles for deployments and just just a range of advances. I think the number of new features and innovation we put into the product in the past six months since I. P. O. Is astounding. So we're really trying to push the edge on devops um and we're also gonna be announcing and talking about stuff that dr khan as well and continue to invest in the cloud native and the devops ecosystem with our support of the continuous delivery foundation and the C. N C F, which I'm also heavily involved in. So it's it's exciting time to be in the devoPS industry and I think you can see that we're really helping software developers to improve their art to become better, better at release. Again, managing production applications >>and the ecosystem is just flourishing. It's only the beginning and again Making bring the craft back in Agile, which is a super big theme this year. Stephen. Great, great to see you. Thanks for dropping those gems and insights here on the Cube here at Dr. 2021 virtual. Thanks for coming on. >>Yeah. Thank you john. >>Okay. Dr. 2020 coverage virtual. I'm John for your host of the Cube. Thanks for watching. Mhm. Mhm. Yeah.

>>Mhm. Yes. Hello. Welcome back to the cubes coverage of dr khan 2021 virtual. I'm john for your host of the cube. We're messing my fair principal technologist at AWS amazon Web services messman. Thank you for coming on the cube, appreciate it. Um >>Thank you. Thank you for having me. >>Great to see you love this amazon integration with doctor want to get into that in a second. Um Been great to see the amazon cloud native integration working well. E. C. S very popular. Every interview I've done at reinvent uh every year it gets better and better more adoption every year. Um Tell us what's going on with amazon E. C. S because you have Pcs anywhere and now that's being available. >>Yeah that's fine, that's correct, join and uh yeah so customers has been appreciating the value and the simplicity of VCS for many years now. I mean we we launched GCS back in 2014 and we have seen great adoption of the product and customers has always been appreciating. Uh the fact that it was easy to operate and easy to use. Uh This is a journey with the CS anywhere that started a few years ago actually. And we started this journey uh listening to customers that had particular requirements. Um I'd like to talk about, you know, the the law of the land and the law um uh of the physic where customers wanted to go all in into uh into the cloud, but they did have this exception that they need to uh deal with with the application that could not move to the cloud. So as I said, this journey started three years ago when we launched outpost. Um and outpost is our managed infrastructure that customers can deploy in their own data centers. And we supported Pcs on day one on outpost. Um having that said, there are lots of customers that came to us and said we love outputs but there are certain applications and certain requirements, uh such as compliance or the fact simply that we have like assets that we need to reuse in our data center uh that we want to use and before we move into into the cloud. So they were asking us, we love the simplicity of Vcs but we have to use gears that we have in our data center. That is when we started thinking about Pcs anywhere. So basically the idea of VCS anywhere is that you can use e c s E C as part of that, you know, and love um uh appreciated the simplicity of using Pcs but using your customer managed infrastructure as the data plane, basically what you could do is you can define your application within the Ec. S country plane and deploy those applications on customer own um infrastructure. What that means from a very practical perspective is that you can deploy this application on your managed infrastructure ranging from uh raspberry pis this is the demo that we show the invent when we pronounce um e c s anywhere all the way up to bare metal server, we don't really care about the infrastructure underneath. As long as it supported, the OS is supported. Um we're fine with that. >>Okay, so let's take this to the next level and actually the big theme at dr Connors developer experience, you know, that's kind of want to talk about that and obviously developer productivity and innovation have to go hand in hand. You don't want to stunt the innovation equation, which is cloud, native and scale. Right. So how does the developer experience improve with amazon ECs and anywhere now that I'm on, on premises or in the cloud? Can you take me through? What's the improvements around pcs and the developer? >>Yeah I would argue that the the what you see as anywhere solved is more for operational aspect and the requirements that more that are more akin to the operation team that that they need to meet. Uh We're working very hard to um to improve the developing experience on top of the CS beyond what we're doing with the CS anywhere. So um I'd like to step back a little bit and maybe tell a little bit of a story of why we're working on those things. So um the customer as I said before, continue to appreciate the simplicity and the easier views of E. C. S. However what we learn um over the years is that as we added more features to E. C. S, we ended up uh leveraging more easy. Um AWS services um example uh would be a load balancer integration or secret manager or Fc. Or um other things like service discovery that uses underneath other AWS products like um clubman for around 53. And what happened is that the end user experience, the developer experience became a little bit more complicated because now customers opportunity easy of use of these fully managed services. However they were responsible for time and watering all uh together in the application definition. So what we're working on to simplify this experience is we're working on tools that kind of abstract these um this verbal city that you get with pcs. Um uh An example is a confirmation template that a developer we need to use uh to deploy an application leveraging all of these features. Could then could end up being uh many hundreds of transformation lines um in the in the in the definition of the service. So we're working on new tools and new capabilities to make this experience better. Uh Some of them are C d k uh the copilot cli, dws, copilot cli those are all instruments and technologies and tools that we're building to abstract that um uh verbosity that I was alluding to and this is where actually also the doctor composed integration with the CS falls in. >>Yeah, I'm just gonna ask you that the doctor piece because actually it's dr khan all the developers love containers, they love what they do. Um This is a native, you know, mindset of shifting left with security. How is the relationship with the Docker container ecosystem going with you guys? Can you take him in to explain for the folks here watching this event and participating in the community, explain the relationship with Docker container specifically. >>Yeah, absolutely. Uh so basically we started working with dR many, many years ago, um uh Pcs was based on on DR technology when we launch it. Uh and it's still using uh DR technology and last year we started to collaborate with dR more closely um when DR releases the doctor composed specification um as an open source projects. So basically doctor is trying to use the doctor composed specification to create uh infrastructure product gnostic, uh way to deploy Docker application um uh using those specification in multiple infrastructure as part of these journey, we work with dr to support pcs as a back end um for um for the specification, basically what this means from a very practical perspective, is that you can take a doctor composed an existing doctor composed file. Um and doctor says that there are 650,000 doctor composed files spread across the top and all um uh lose control uh system um over the world. And basically you can take those doctor composed file and uh composed up and deploy transparently um into E. C. S Target on AWS. So basically if we go back to what I was alluding to before, the fact that the developer would need to author many 100 line of confirmation template to be able to take their application and deploy it into the cloud. What they need to do now is um offering a new file, a um a file uh with a very clear and easy to use dr composed syntax composed up and deploy automatically on AWS. Um and using Pcs Fargate um and many other AWS services in the back end. >>And what's the expectation in your mind as you guys look at the container service to anywhere model the on premise and without post, what does he what's the vision? Because that's again, another question mark for me, it's like, okay, I get it totally makes sense. Um, but containers are showing the mainstream enterprises, not the hyper skills. You guys always been kind of the forward thinkers, but you know, main street enterprise, I call it. They're picking up adoption of containers in a massive way. They're looking at cloud native specifically as the place for modern application development period. That's happening. What's the story? Say it again? Because I want to make sure I get this right e C s anywhere if I want to get on premises hybrid, What's it mean for me? >>Uh, this goes back to what I was saying at the beginning. So there are there are there when we have been discussing here are mostly to or token of things. Right. So the fact that we enable these big enterprises to meet their requirements and meet their um their um checkboxes sometimes to be able to deploy outside of AWS when there is a need to do that. This could be for edge use cases or for um using years that exist in the data center. So this is where e c s anywhere is basically trying, this is what uh pcs anywhere is trying to address. There is another orthogonal discussion which is developer experience, uh and that development experience is being addressed by these additional tools. Um what I like to say is that uh the confirmation is becoming a little bit like assembler in a sense, right? It's becoming very low level, super powerful, but very low level and we want to abstract and bring the experience to the next level and make it simple for developers to leverage the simplicity of some of these tools including Docker compose um and and and being able to deploy into the cloud um and getting all the benefits of the cloud scalability, electricity and security. >>I love the assembler analogy because you think about it. A lot of the innovation has been kind of like low level foundational and if you start to see all the open source activity and the customers, the tooling does matter. And I think that's where the ease of use comes in. So the simplicity totally makes sense. Um can you give an example of some simplicity piece? Because I think, you know, you guys, you know, look at looking at ec. S as the cornerstone for simplicity. I get that. Can you give an example to walk us through a day in the life of of an example >>uh in an example of simplicity? Yeah, supposedly in action. Yeah. Well, one of the examples that I usually do and there is this uh, notion of being served less and I think that there is a little bit of a, of an obsession around surveillance and trying to talk about surveillance for so many things. When I talk about the C. S, I like to use another moniker that is version less. So to me, simplicity also means that I do not have to um update my service. Right? So the way E C. S works is that engineering in the service team keeps producing and keeps delivering new features for PCS overnight for customers to wake up in the morning and consuming those features without having to deal with upgrades and updates. I think that this is a very key, um, very key example of simplicity when it comes to e C s that is very hard to find um in other, um, solutions whether there are on prime or in the cloud. >>That's a great example in one of the big complaints I hear just anecdotally around the industry is, you know, the speed of the minds of business, want the apps to move faster and the iteration with some craft obviously with security and making sure things buttoned up, but things get pulled back. It's almost slowed down because the speed of the innovation is happening faster than the compliance of some sort of old governance model or code reviews. I want to approve everything. So there's a balance between making sure what's approved, whether security or some pipeline procedures and what not. >>So that I could have. I cannot agree more with you. Yeah, no, it's absolutely true because I think that we see these very interesting um, uh, economy, I would say between startups moving super fast and enterprises try to move fast but forced to move at their own speed. So when we when we deliver services based on, for example, open source software uh, that customers need to um, look after in terms of upgrade to latest release. What we usually see is start up asking us can you move faster? There is a new version of that software, can you enable us to deploy that version? And then on the other hand of the spectrum, there are these big enterprises trying to move faster but not so much that are asking us can use lower. Can you slow down a little bit? Right, because I cannot keep that pigs. So it's a very it's a very interesting um, um, a very interesting time to be alive. >>You know, one of the, one of the things that pop up into these conversations when you talk, when I talk to VP of engineering of companies and then enterprises that the operational efficiency, you got developer productivity and you've got innovation right, you've got the three kind of things going on there knobs and they all have to turn up. People want more efficiency of the operations, they want more developed productivity and more innovation. What's interesting is you start seeing, okay, it's not that easy. There's also a team formation and I know Andy Jassy kinda referred to this in his keynote at Reinvent last year around thinking differently around your organizational but you know, that could be applied to technologists too. So I'd love to get your thoughts while you're here. I know you blog about this and you tweet about this but this is kind of like okay if these things are all going to be knobs, we turned up innovation efficiency, operationally and develop productivity. What's the makeup of the team? Because some are saying, you have an SRE embedded, you've got the platform engineering, you've got version lists, you got survival is all these things are going on all goodness. But does that mean that the teams have to change? What's your thoughts on that you want to get your perspective? >>Yeah, no, absolutely. I think that there was a joke going around that um as soon as you see a job like VP of devoPS, I mean that is not going to work, right? Because these things are needs to be like embedded into each team, right? There shouldn't be a DEVOPS team or anything, it would be just a way of working. And I totally agree with you that these knobs needs to go insane, right? And you cannot just push too hard on innovation which are not having um other folks um to uh to be able to, you know, keep that pace um with you. And we're trying to health customers with multiple uh tools and services to try to um have not only developers and making developer experience uh better but also helping people that are building these underneath platforms. Like for example, prod on AWS protein is a good example of this, where we're focusing on helping these um teams that are trying to build platforms because they are not looking themselves as being a giant or very fast. But they're they're they're measured on being secure, being compliant and being, you know, within a guardrail uh that an enterprise um regulated enterprise needs to have. So we need to have all of these people um both organizationally as well as with providing tools and technologies that have them in their specific areas um to succeed. >>Yeah. And what's interesting about all this is that you know I think we're also having conversations and and again you're starting to see things more clearly here at dr khan we saw some things that coop con which the joke there was not joke but the observation was it's less about kubernetes which is now becoming boring, lee reliable to more about cloud native applications under the covers with program ability. So as all this is going on there truly is a flip of the script. You can actually re engineer and re factor everything, not just re platform your applications in I. T. At once. Right now there's a window whether it's security or whatever. Now that the containers and and the doctor ecosystem and the container ecosystem and the The kubernetes, you've got KS and you got six far gay and all the stuff of goodness. Companies can actually do this right now. They can actually change everything. This is a unique time. This window might close are certainly changed if you're not on it now, it's the same argument of the folks who got caught in the pandemic and weren't in the cloud got flat footed. So you're seeing that example of if you weren't in the cloud up during the pandemic before the pandemic, you were probably losing during the pandemic, the ones that one where the already guys are in the cloud. Now the same thing is true with cloud native. You're not getting into it now, you're probably gonna be on the wrong side of history. What's your reaction to that? >>Yeah, No, I I I agree totally. I I like to think about this. I usually uh talk about this if I can stay back step back a little bit and I think that in this industry and I have gray areas and I have seen lots of things, I think that there has been too big Democratisation event in 90 that happened and occurred in the last 30 years. So the first one was from, you know from when um the PC technology has been introduced, distributed computing from the mainframe area and that was the first Democratisation step. Right? So everyone had access to um uh computers so they could do things if you if you fast forward to these days. Um uh what happened is that on top of that computer, whatever that became a server or whatever, there is a state a very complex stack of technologies uh that allow you to deployment and develop and deploy your application. Right. But that stack of technology and the complexity of that stack of technology is daunting in some way. Right? So it is in a bit access and democratic access to technology. So to me this is what cloud enabled, Right? So the next step of democratisation was the introduction of services that allow you to bypass that stack, which we call undifferentiated heavy lifting because you know, um you don't get paid for managing, I don't know any M. R. Server or whatever, you get paid for extracting values through application logic from that big stack. So I totally agree with you that we're in a unique position to enable everyone um with what we're building uh to innovate a lot faster and in a more secure way. >>Yeah. And what comes out, I totally agree. And I think that's a great historical view and I think let's bring this down to the present today and then bring this as the as the bridge to the future. If you're a developer you could. And by the way, no matter whether you're programming infrastructure or just writing software or even just calling a PS and rolling your own, composing your services, it's programmable and it's just all accessible. So I think that that's going to change the again back to the three knobs, developer productivity or just people productivity, operational efficiency, which is scale and then innovation, which is the business logic where I think machine learning starts to come in, right? So if you can get the container thing going, you start tapping into that control plane. It's not so much just the data control plane. It's like a software control plane. >>Yeah, no, absolutely. The fact that you can, I mean as I said, I have great hair. So I've seen a lot of things and back in the days, I mean the, I mean the whole notion of being able to call an api and get 10 servers for example or today, 10 containers. It would be like, you know, almost a joke, right? So we spent a lot of time racking and um, and doing so much manual stuff that was so ever prone because we usually talk about velocity and agility, but we, we rarely talk about, you know, the difficulties and the problems that doing things manually introduced in the process, the way that you can get wrong. >>You know, you know, it reminds me of this industry and I was like finally get off my lawn in the old days. I walk to school with no shoes on in the snow. We had to build our own colonel and our own graphics libraries and then now they have all these tools. It's like, you're just an old, you know, coder, but joking aside, you know that experience, you're bringing up appointments for the younger generation who have never loaded a Linux operating system before or had done anything like that level. It's not so much old versus young, it's more of a systems thinking, he said distributed computing. If you look at all the action, it's essentially distributed computing with new software paradigm and it's a system architecture. It's not so much software engineering, software developer, you know, this that it's just basically all engineering at this point, all software. >>It is, it is very much indeed. It's uh, it's whole software, there is no other um, there is no other way to call it. It's um, I mean we go back to talk about, you know, infrastructure as code and everything is now uh corridor software in in in a way. It's, yeah. >>This is great to have you on. Congratulations. A CS anywhere being available. It's great stuff. Um, and great to see you and, and great to have this conversation. Um, amazon web services obviously, uh, the world has has gone super cloud. Uh, now you have distributed computing with edge iot exploding beautifully, which means a lot of new opportunities. So thanks for coming on. >>Thank you very much for having me. It was a pleasure. Okay, cube >>Coverage of Dr Khan 2021 virtual. This is the Cube. I'm John for your host. Thanks for watching.

>>mhm Yes, everyone, welcome back to the cubes coverage of dr khan 2021. I'm john for your host of the cube. Got a great segment here. One of the big supporters and open source amazon web services returning back second year. Dr khan virtual Deepak Singh, vice president of the compute services at AWS Deepak, Great to see you. Thanks for coming back on remotely again soon. We'll be in real life. Reinvent is going to be in person, we'll be there. Good to see you. >>Good to see you too, john it's always good to do these. I don't know how how often I've been at the cube now, but it's great every single time your >>legend and getting on there, a lot of important things to discuss your in one of the most important areas in the technology industry right now and that is at the confluence of cloud scale and modern development applications as they shift towards as Andy Jassy says, the new guard, right. It's been happening. You guys have been a big proponent of open source and enabling open source is a service creating business models for companies. But more importantly, you guys are powering, making it easier for folks to use software. And doctor has been a big relationship for you. Could you take a minute to first talk about the doctor, a W S relationship and your involvement and what you're doing? >>Yeah, actually it goes back a long way. Uh you know, Justin, we announced PCS had reinvented 2014 and PCS at that time was very much managed orchestration service on top of DACA at that time. I think it was the first really big one out there from a cloud provider. And since then, of course, the world has evolved quite a bit and relationship with DR has evolved a lot. The thing I'd like to talk to is something that we announced that Dr last year, I don't remember if I talked about it on the cube at that time. But last year we started working with DR on how can we go from doctor Run, which customers love or DR desktop, which customers love and make it easy for people to run containers on pcs and Fergie. Uh so most new customers running containers and AWS today start with this Yes and party or half of them and we wanted to make it very easy for them to start with where they are on the laptop which is often bucket to stop and have running services the native US. So we started working with DR and that that collaboration has been very successful. We want to keep you look forward to continuing to work on evolving that where you can use Docker compose doctor, desktop, doctor run the fuel that darker customers used and the labour grand production services on the end of your side, which is the part that we've got that on. So I think that's one area where we work really well together. Uh, the other area where I think the two companies continue to work well together. It's open source in general as some of, you know, AWS has a very strong commitment to contain a. D uh, EKS our community service is moving towards community. Forget it actually runs all on community today and uh, we collaborate dr Rhonda on the Ocr specification because, you know, the Oc I am expect is becoming the de facto packaging format idea. W S. This morning we launched yesterday, we launched a service called Opera. And the main expected input for opera is an Ocr image are being in this Atlanta as well, where those ci images now a way of packaging for lambda. And I think the last one I like to call out and it has been an amazing partnership and it's an area where most people don't pay attention is amid signing. Uh, there's a project called Notary. We do the second version of the Notary Spec for remit signing and AWS Docker and a couple of other companies have been working very closely together on bringing that uh, you know, finalizing no tv too, so that at least in our case we can start building services for our customers on top of that. You know, it's it's a great relationship and I expect to see it continue. >>Well, I think one of the themes this year is developer experience. So good. Good call out there in the new announcements on the tools you have and software because that seems to be a great developer integration with Docker question I have for you is how should the customers think about things like E C. S and versus E K. S. App, Runner lambda uh for kind of running their containers. How do they understand the difference is, what's there? What's the, what's the thought process there? What's >>that? It's a good question actually been announced after. And I think there was one of the questions I started getting on twitter. You know, let's start at the very beginning. Anyone can pick up a Docker container and run it on easy to today. You can run it on easy to, we can run a light sail, but doc around works just fine. It's the limits machine. Then people want to do more complex things. They want to run large scale orchestrated services. They won't run their entire business and containers. We have customers will do that today. Uh, you know, you have people like Vanguard who runs a significant portion of the infrastructure on pcs frg or you have to elope with the heavy user of chaos, our community service. So in general, if you're running large scale systems, you're building your platforms, you're most likely to use the csny Chaos. Um, if you come from a community's background, you're, you're running communities on prem or you want the flexibility and control the communities gives you, you're gonna end up with the chaos. That's what we see our customers doing. If you just want to run containers, you want to use AWS to its fullest extent where you want the continue a P I to be part of the W A S A P. I said then you pick is yes. And I think one of the reasons you see so many customers start with the CSN, Forget is with forget to get the significant ease of use from an operational standpoint. And we see many start ups and you know, enterprises, especially security focus enterprises leaning towards farming. But there's a class of customers that doesn't want to think about orchestration that just wants. Here's my code, here's my container image just run my service for me and that's when things like happen, I can come and that's one of the reasons we launched it. Land is a little bit different. Lambda is a unique service. You buy into an event driven architecture. If you do that, then you can figure our application into this. That's they should start its magic. Uh, the container part, there is what land announced agreement where they now support containers, packaging. So instead of zip files, you can package up your functions as containers. Then lambda will run them for you. The advantage it gives you with all the tooling that you built, that you have to build your containers now works the land as well. So I won't call and a container orchestration service in the same sense of the CSC cso Afrin are but it definitely allows the container image format as a standard packaging format. I think that's the sort of universal common theme that you find across AWS at this point of time. >>You know, one of the things that we're observing at this at this event here is a lot of developers Coop con and Lennox foundations. A lot of operators to kubernetes hits that. But here's developers. And the thing is I want to ease of use, simplicity experience, but also I want the innovation. Yeah, I want all of it. When I ask you what is amazon bring to the table for the new equation, what would you say? >>Yeah, I mean for me it's always you've probably heard me say this 100 times. Many 1000 times. It's foggy fog. It's unique to us. It takes a lot of what we have learned about operating infrastructure scale. The question we asked ourselves, you know, in many ways we talk about forget even before belong pcs but we have to learn on what it meant and what customers really wanted. But the idea was when you are running clusters of instances of machines to run containers on, you have to start thinking about a lot of things that in some ways VMS but BMS in the car were taken away capacity. What kind of infrastructure to run it on? Should have been touched. Should have not been back. You know, where is my container running? Those are things. They suddenly started having to think about those kind of backwards almost. So the idea was how can we make your containerized bundles? So TCS task or community is part of the thing that you talk to and that is the main unit that you operate on. That is the unit that you get built on and meet it on. That's where Forget comes in and it allows us to do many interesting things. We've effectively changed the engine of forget since we've launched it. Uh, we run it on ec two instances and we run it on fire cracker. Uh, we have changed the forget agent architecture. We've made a lot of underneath the hood, uh, changes that even take the take advantage of the broader innovation, the rate of us, We did a whole bunch more to launch acronym trans on top of family customers don't have to think about it. They don't have to worry about it. It happens underneath the hood. It's always your engine as as you go along and it takes away all the operational pain of managing clusters of running into picking which instances to use to getting out, trying to figure out how to bend back and get efficiency. That becomes our problem. So, you know, that is an area where you should expect to see a Stuart done more. It's becoming the fabric of so many things that eight of us now. Uh, it's, you know, in some ways we're just talking a lot more to do. >>Yeah. And it's a really good time. A lot more wave of developers coming in. One of the things that we've been reporting on on Silicon England cube with our cute videos is more developers keep on coming on, more people coming in and contributing to the open source community. Even end users, not just the normal awesome hyper scholars you're talking about like classic, I call main street enterprises. So two things I want to ask you on the customer side because you have kind of to customers, you have the community that open source community and you have enterprise customers that want to make it easier. What are you seeing and hearing from customers? I know you guys work backwards from the customer. So I got to ask you work backwards from the community and work backwards from the enterprise customer. What's going on in their environment? What's the key trends that they're riding? What's the big challenges? What's the big opportunities that they're facing and saying for the community? >>Yeah, I start with the enterprise. That's almost an easier answer. Which is, you know, we're seeing increasingly enterprises moving into the cloud wholesale. Like in some ways you could argue that the pandemic has just accelerated it, but we have started seeing that before. Uh they want to move to the cloud and adult modern best practices. Uh If you see my talk agreement last few years, I've talked about modernization and all the aspects of modernization, and that's 90% of our conversation with enterprises, I've walked into a meeting supposedly to talk about containers, whatever half a conversation is spent on. How does an organization modernize? What does an organization need to do to modernize and containers and serverless play a pretty important part in it, because it gives them an opportunity to step away from the shackles of sort of fixed infrastructure and the methods and approaches that built in. But equally, we are talking about C I C. D, you know, fully automated deployments. What does it mean for developers to run their own services? What are the child, how do you monitor and uh, instrument uh, your services? How do you do observe ability in the modern world? So those are the challenges that enterprises are going towards, and you're spending a ton of time helping them there. But many of them are still running infrastructure on premises. So, you know, we have outpost for them. Uh, you know, just last week, you're talking to a bunch of our customers and they have lots of interesting ideas and things that they want to do without both, but many of them also have their own infrastructure and that's where something like UCS anywhere came from, which is hey, you like using Pcs in the cloud, You like having the safety i that just orchestrates containers for you. It does it on on his in an AWS region. It will do it in an outpost. It'll do it on wavelength, it'll do it on local zone. How about we allow you to do it on whatever infrastructure you bring to us. Uh you want to bring a raspberry pi, you can do that. You want to bring your on premises data center infrastructure, we can do that or a point of sale device, as long as you can get the agent running and you can connect to an AWS region, even though it's okay to lose connectivity every now and then. We can orchestrate a container for you over there and, you know, the same customer that likes the ease of use of Vcs. And the simplicity really resonated with that message really resonates with them. So I think where we are today with the enterprise is we've got some really good solutions for you in eight of us and we are now allowing you to take those a. P. I. S and then launch containers wherever you want to run them, whether it's the edge or whether it's your own data center. I think that's a big part of where the enterprise is going. But by and large, I think yes, a lot of them are still making that change from running infrastructure and applications the way they used to do a modern sort of, if you want to use the word cloud native way and we're helping them a lot. We've done, the community is interesting. They want to be more participatory. Uh that's where things like co pilot comes from. God, honestly, the best thing we've ever done in my order is probably are open road maps where the community can go into the road map and engage with us over there, whether it's an open source project or just trying to tell us what the feature is and how they would like to see it. It's a great engagement and you know, it's not us a lot. It's helped us prioritize correctly and think about what we want to do next. So yeah, I think that's, that >>must be very hard to do for opening up the kimono on the road map because normally that's the crown jewels and its secretive and you know, and um, now it's all out in the open. I think that is a really interesting, um, experiment and what's your reaction to that? What's been the feedback on the road map peace? Because I mean, I definitely want to see, uh, >>we do it pretty much for every service in my organization and we've been doing it now for three years. So years forget, I think about three years and it's been great. Now we are very we are very upfront, which is security and availability. Our job 000 and you know, 100 times out of 100 at altitudes between a new feature and helping our customers be available and safe. We'll do that. And this is why we don't put dates in that we just tell you directionally where we are and what we are prioritizing Uh, there every now and then we'll put something in there that, you know, well not choose not to put a feature in there because we want to keep it secret until it launches. But for the most part, 99% of our own myself there and people engaged with it. And it's not proven to be a problem because you've also been very responsible with how we manage and be very transparent on whether we can commit to something or not. And I think that's not. >>I gotta ask you on as a leader uh threaded leader on this group. Open source is super important, as you know, and you continue to do it from under years. How are you investing in the future? What's your plan? Uh plans for your team, the industry actually very inclusive, Which is very cool. It's gonna resonate well, what's the plans? Give us some details on what you're investing in, what your priorities? What's your first principles? >>Yeah, So it goes in many ways, one when I I also have the luxury also on the amazon open source program office. So, you know, I get the chance to my team, rather not me help amazon engineers participate in open source. That that's the team that helps create the tools for them, makes it easy for them to contribute, creates, you know, manages all the licenses, etcetera. I'll give you a simple example, you know, in there, just think of the cr credential helper that was written by one of our engineers and he kind of distorted because he felt it was something that we needed to do. And we made it open source in general, in in many of our teams. The first question we asked is should something the open why is this thing not open source, especially if it's a utility or some piece of software that runs along with services. So they'll step one. But we've done some big things also, I, you know, a couple of years ago we launched Lennox operating system called bottle Rocket. And right from the beginning it was very clear to us that bottle Rocket was two things. It was both in AWS product. But first it was an open source project. We've already learned a little bit from what we've done at Firecracker. But making bottle rocket and open source operating system is very important. Anyone can take part of Rocket the open source to build tooling. You can run it whatever you want. If you want to take part of Rocket and build a version and manage it for another provider. For another provider wants to do it, go for it. There's nothing stopping you from doing that. So you'll see us do a lot there. Obviously there's multiple areas. You've seen WS investing on the open source side. But to me, the winds come from when engineers can participate in small things, released little helpers or get contributions from outside. I think that's where we're still, we can always have that. We're going to continue to strive to make it better and easier. And uh, you know, I said, I have, you know, me and my team, we have an opportunity to help their inside the company and we continue to do so. But that's what gets me excited. >>Yeah, that's great stuff. And congratulations on investing in the community, really enjoys it and I know it moves the needle for the industry. Deepak, I gotta ask you why I got you here. Dr khan obviously, developers, what's the most important story that they should be paying attention to as a developer because of what's going on shift left for security day two operations also known as a I ops getups, whatever you wanna call it, you know, ongoing, you get server lists, you got land. I mean, all kinds of great things are going on. You mentioned Fargate, >>um >>what should they be paying attention to that's going to really help their life, both innovation wise and just the quality of life. >>Yeah, I would say look at, you know, in the end it is very easy developers in particular, I want to build the buildings and it's very easy to get tempted to try and get learn everything about something. You have access to all the bells and whistles and knobs, but in reality, if you want to run things you want to, you want to focus on what's important, the business application, that and you the application. And I think a lot of what I'll tell developers and I think it's a lot of where the industry is going is we have built a really solid foundation, whether it's humanity, so you CSN forget or you know, continue industries out there. We have very solid foundation that, you know, our customers and develop a goal of the world can use to build upon. But increasingly, and you know, they are going to provide tools that sort of take that wrap them up and providing a nice package solution After another great example, our collaboration, the doctor around Dr desktop are a great example where we get all the mark focus on the application and build on top of that and you can get so much done. I think that's one trend. You'll see more and more. Those things are no longer toys, their production grade systems that you can build real world applications on, even though they're so easy to use. The second thing I would add to that is uh, get uh, it is, you know, you can give it whatever name you want. There's uh, there's nuances there, but I actually think get up is the way people should be running the infrastructure, my virus in my personal, you know, it's something that we believe a lot in homicide as hard as you go towards immutable infrastructure, infrastructure, automation, we can get off plays a significant role. I think developers naturally gravitate towards it. And if you want to live in a world where development and operations are tightly linked, I think it after the huge role to play in that it's actually a big part of how we're planning to do things like yes, anywhere, for example, a significant player and that it would be a proton. I think get up will be a significant in the future of proton as well. So I think that's the other trend. If you wanted to pick a trend that people should pay attention. That's what I believe in a lot. >>Well you're an expert. So I want to get you a quick definition. What is get Ops, how would you define it? Because that's a big trend. What does it, what does that mean? >>Electricity will probably shoot me for getting this wrong. I tell you how I think about it. Which is, you know, in many cases, um, you when you're doing deployments are pushing a deployment getups is more of a full deployment. When you are pushing code to get depository, you have a system that knows that the event has happened and then pulls from there and triggers the thing as opposed to you telling it take I have this new piece of code now go deployed everywhere. So to me, the biggest changes that Two parts one is it's more for full mechanism where you're pulling because something has changed. So it needs systems like container orchestrators to keep them, you know, to keep them in sync. And the second part of the natural natural evolution of infrastructure score, which is basically everything is called the figures code. Infrastructure as code, code is code and everything is getting stored in that software repo and the software repo becomes your store of record and drives everything. Uh So for a glass of customers, that's going to be a pretty big deal. >>Yeah, when you're checking in code, that's again, it's like a compiler for the compiler, a container for the container, you've got things for each other. Automation is ultimately what we're talking about here. And that's to me where machine learning kicks in. So again, having this open source foundational fabric, as you said, forget out the muck or the undifferentiated heavy lifting. This is what we're talking about automation, isn't it? Deepak? >>Yes. I mean I said uh one thing where we hang our hat on is there's such good stuff out there in the world which we like to contribute to, but the thing we like to hang our hat on is how do you run this? How do you do it this in ways that you can uniquely bring capabilities to customers where there's things like nitro or things are nitro open stuff. Well, the fact that we have built up this operational infrastructure over the last in a decade plus or in the container space over the last seven years where we really really know how to run these things at scale and have made all the investments to make it easy to do. So that's that's where we have hanger hard keeping people safe, helping them only available applications, their new startup, that just completely takes off in over the weekend. For whatever reason, because, you know, you're the next hot thing on twitter and our goal is to support you whether you are, you know, uh enterprise that's moving from the main train or you are the next hot startup, that's you know, growing virally and uh, you know, we've done a lot to build systems help both sides and yeah, it's >>interesting if you sing about open source where it's come from, I mean I remember that base wouldn't open source wasn't open, I would be peddling software, there's a free copy of Linux, UNIX um in college and now it's all free. But I mean just what's changed now. It used to be just free software, download software. You got it now, it's a service. Service now can be monetized quickly. And what you guys are offering with AWS and cloud scale is you've done all these things as I don't have to have a developer. I get the benefits of the scale, I can bring my open source code to the table, make it a service integrated in with other services and be the next snowflake, be the next, you know, a company that could scale. And that is that's the that's the innovation, right? That's the this is a new phenomenon. So it also changes the business model. >>Yeah, actually you're you're quite right. Actually, I I like one more thing to it. But you look at how a lot of enterprises use containers today. Most of them are using something like this year, Symphony or GS to build an internal developer platform and internal developer portal. And then the question then becomes this hard to scale this modern and development practices to an entire organization. What is your big bank that's been around as thousands and thousands of ID stuff That may not all be experts are running communities running container is when you scale it out different systems that proton come into play. That was actually the inspiration is how do you help an organization where they're building these developer Portholes and developer infrastructure, developer platforms, How do you make it easy for them to build it? Be almost use it as a way to get these modern practices into the hands of all the business units, where they may not have the time to become experts at the modern ways of running infrastructure because they're busy doing other things. And I think you'll see the a lot more happening that space that's not happening in the open source community. There's proton, there's a bunch of interesting things happening here and be interesting to see how that evolves. >>And also, you know, the communal, communal aspect of not just writing code together, but succeeding, right, building something. I mean, that's when you start to see the commercial meets open kind of ethos of communal activity of working together and sharing a big part of this year's. Dakar Con is sharing not just running and shipping code but sharing. >>Yeah, I mean if you think about it uh Dockers original value was you build run and shit right? You use the same code to build it, you use the same code to ship it, the same sort of infrastructure interface and then you run it and that, you know, the fact that the doctor images such a wonderfully shareable entity uh that can run every girl is such a powerful and it's called the Ci Image. Now I still call him Dr images because it's just easier. But that to me like that is a big deal and I think it's becoming and become an even bigger deal over the years. I came from something before, Amazon has to work in The sciences and bioinformatics and you know, the ability to share codeshare dependencies, package all of that up in a container image is a big deal. It's what got me one of the reasons I got fascinated with container 78 years ago. So it will be interesting to see where all of systems. >>It's great, great stuff. Great success. And congratulations. Deepak, Great to always talk to you got a great finger on the pulse. You lead a really important organizations at AWS and you know, doctor has such a huge success with developers, even though the company has gone through kind of a uh change over and a pivot to what they're doing now. They're back to their open source roots, but they have millions and millions of developers use Docker and new developers are coming in dot net developers are coming in. Windows developers are coming in and and so it's no longer about Lennox anymore. It's about just coding. >>Yeah. And it's it's part of this big trend towards infrastructure, automation and and you know development and deployment practices that I think everyone is going to adopt faster than we think they will. But you know, companies like Doctor and opens those projects that they involved are critical in making that a lot easier for them. And then you know, folks like us get to build on top of that orbit them and make it even easier. >>Well, great testimony the doctor that you guys based your E C. S on Docker Doctor has a critical role in developing community. I run composed in their hub with dr desktop and we'll be watching amazon and and the community activity and see what kind of experiences you guys can bring to the table and continue that momentum. Thank you Deepak for coming on the >>cube. Thank you, john. That's always a pleasure. >>Okay. Mr cubes. Dr khan 2021 virtual coverage. I'm john for your host of the cube. Thanks for watching.

>>welcome back everyone. We're back to intermission. I'm hama in case you forgot and hear them with Brett and Peter. So what a great morning afternoon. We've had like we're now in the home stretch and you know, I really want to give a shout out to all of you who are sticking with us, especially if you're in different time zone than pacific. So I then jumped into the community rooms. The spanish won, the Brazilian won the french one. Everybody is just going strong. So again, so much so gratitude for that. Thank you for being so involved and really participating the chat rooms in the community. The chat windows in the community rooms are just going nuts. So it's, it's really good to see that. And as usual, Peter and brat had some great, very interactive panels and that was very exciting to watch. But you know, since they were on the panels, I decided to go and see some other things and I actually attended the last mile of container ization. That was, that was actually a very good session. We had a lot of good interactivity there. Yeah. And then while also talked about the container security in the cloud native world. So that was, I think that was your panel peter. That was, that was very exciting. And um, I want to share with everybody the numbers that we've been seeing for dr khan live. So as, as of, I'm sorry, said we need a drumroll. We do need a drum roll. Can you do a drum roll for me? No, no, no. >>Just a >>symbol. Okay, good. Go. Uh, we're at over 22,000 attendees um, today. So that's amazing. That's great. I love the sound effect. That's a great sound effect. The community rooms continue to be really engaged. We're still seeing hundreds of people in those rooms. So again shout out to everyone who is participating. And I felt again like a kid in a candy store didn't know which sessions to attend. They were all very interesting and you know, we're getting some good feedback on twitter. I want to read out some more tweets that we got and one in particular, I don't know whether to feel happy for this person or sad for this person, but it's uh well the initials are P. W. And he said that he was up at two am to watch the keynotes. So again, I'll let you decide whether you're it's a good thing or not, but we're happy to have you PW is awesome. Um as well. There was someone who said that these features are so needed. The things that dr announced this morning in the keynotes and that doctor has reacted to our pains and I think they mean has addressed their pain. So that was really gratifying to read. Yeah, really wonderful. That's some other countries that I didn't shout out before this just tells you what the breadth and scope of our community is. Indonesia, la paz Bolivia, Greece, Munich, Ukraine, oxford UK Australia Philippines. And there's just more and I'm going to do a special shadow to Montreal because that's where I'm from. So yes, applause for that. It was really great. And so I just want to thank all of you. Um, I want to encourage you when we talked about the power of community. Remember we're doing a fundraiser. So to combat Covid for Covid relief or actually all that money is going to go to UNICEF. Docker is contributing 10,000 and we're doing a go fund me. And the link is there on the screen. So please donate. You know, just $1. 1 person each of you donates $1. We would have raised over $22,000. So please please find it within you to contribute because again, our communities that are, that are the most effective are India and brazil, which are are very active doctor affinity. So please give back. I really appreciate that >>highlighted by the brazil. Yeah. >>You're going to brazil room and get them all to donate. Exactly. Um, also want to encourage, you know, if you're interested in participating in our, in our road map. Our public road map is on GIT hub. So it's get home dot com slash docker slash roadmap. And that's something that you can participate in and vote up features that you want to see. We love to get the community involved and participating in our, in our road map. So make sure to check that out. And I also want to note on that >>Hello can real quick. I'm sorry. Yeah, I talk about our road map all the time, but honestly folks out there are PMS are in their our ceo is in there that we do watch that. That is our roadmap is extremely, extremely important to us. So any features complaints, right, joining the conversation. That's a great way to get uh to interact with Docker in our products. Right. We we really highly valued the road map. Okay, back to your mama, sorry. >>Oh absolutely. And if you want to see us be even more responsive to what you need to participate in that road map discussion. That's really great. Um a couple of things coming up, just want to put the spotlight on. We have at 3 15 what's new with with desktop from our own ue cow. So I highly recommend that you attend that session and of course there's the Woman in tech live panel. So this is very exciting, moderated by yours truly and it has putting a spotlight on our women captains and our women developers. So that's very exciting. But I also hear that we're doing there's a session with jay frog coming up so peter, why don't you talk about that a little bit? >>Yeah, we have a session coming up from our partners from jay frog around devops patterns and anti patterns for continuous software updates. And another one that I'm extremely excited about is uh RM one talk from our very own Tony's from Docker. So if you have an M one and you're interested in multi arc architecture builds, check that out. It's gonna be a great, great talk. Um and then we have melissa McKay also from jay frog, talking about Docker and the container ecosystem and last but definitely not least. We'll check them all out there. Going to be great. But Brett is going to be doing I think the best panel that I'm gonna go watch and he made up a new word, it's called say this. I'm all about the trending new words today about this is gonna be awesome. Yeah. Yeah >>I'm going to have the battle bottle of the panels. >>Yeah. Yeah well mine's before years so we're not competing. So yeah we have we have two excellent panels in a row to finish off the day and just seven list is basically how to run, how can we run containers without managing servers? So it doesn't mean you don't actually have infrastructure just let's not manage service. Um Yeah and we we uh need to wrap it up and >>Uh before we do that I just want to um tell everyone that we actually have a promotion going on. So we um for those that sign up for a pro or team subscription, we're offering a 20% off so there's the U. R. L.. You can check out what the promotion is and this is for a new and returning users so you can use the promo code dr khan 21 all the information is on the website are really encourage you to check that out promotion for 20% off, join us for our panels. And we're doing a wrap up at five p.m. Where we'll have our own Ceo and that wrap up portion. Look forward to seeing there. All right, >>thank you too. All right everyone we'll see you on the next go around coming up next me and some other people awesome and Yeah. Mhm. Mhm. Yeah. >>Yeah. Yeah. Mhm. Is >>a really varied community. There's a lot of people with completely different backgrounds, completely different experience levels and completely different goals about how they want to use Docker. And I think that's really interesting. It's always easy to talk about the technology that I've used for so many years. I really love Doctor and I can find so many ways that it's useful and it's great to use in your day to day work clothes. I've >>used doctor for anything from um tracking airplanes with my son, which was a kind of cool project to more professional projects where we actually Built one of the first database as his services using docker even before it was 10 and I was released and we took it further and we start composing monitoring tools. We really start taking it to the next level. And we got to the point where I was trying to make everything in a container, I love to use >>doctor to make disposable project so I can download the project and it's been that up using Docker compose or something like that in a way that every developer that works in the project doesn't even need to know the underlying technology doesn't just need to run Docker compose up and the whole project is going to be up and running even if >>you're not using doctor and production, there are a lot of other ways that you can use doctor to make your life so much easier. As a developer, you can run your projects on your machine locally. Um as a tester you can actually launch test containers and be able to run um dependencies that your project requires. You can run real life versions so that um you're as close to production as possible. >>I was able to migrate most of the workloads from our on from uh to the cloud. Running complete IEDs inside a docker or running it or using it basically to replace their build scripts or using it to run not web applications but maybe compile c plus plus code or compile um projects that really just require some sort of consistency across their team, >>whether it be a web app or a database, I can control these all the same. That was really the power I saw within Doctors standardization and the portability >>doctor isn't the one that created containers uh and uh but it's the one that made it uh democratically possible, so everyone use it. And this effort has made the technology environment so much better for everyone that uses it, both for developers and for end users. So this >>past year has been quite interesting and I think we're all in the same boat here, so no one has, no one is an exception to this, but what we all learn from it is, you know, the community is very important and to lean on other people for help for assistance. >>Yeah, it's been really challenging of course, but I think the biggest and most obvious thing that I've learned both on a personal and a business perspective is just to be ready to adapt to change and don't be afraid of it either. I think it's worth noting that you should never really take it for granted that the paradigms of, you know, the world or technology or something like that aren't going to shift drastically and very, very quickly. >>I'm looking forward to what is coming down the pipe with doctor. What more are they going to throw our way in order to make our lives easier? >>It's very interesting to see the company grow and adapt the way it has. I mean it as well as the community, it's been very interesting to see, you know, how, you know, the return to develop our focus is now the main focus and I find that's very interesting because, you know, developers are the ones that really boost the doctor to where it is today. And if we keep on encouraging these developer innovation, we'll just see more tools being developed on top of Doctor in the future, and that's what I'm really excited to see with Doctor and the technology in the future.

>>and hello, we're back. I've got my panel and we are doing things real time here. So sorry for the delay a few minutes late. So the way let's talk about things, the reason we're here and we're going around the room and introduce everybody. Got three special guests here. I got my evil or my john and the normal And we're going to talk about get ops I called it future office just because I want to think about what's the next thing for that at the end, we're gonna talk about what our ideas for what's next for getups, right? Um, because we're all starting to just get into get ups now. But of course a lot of us are always thinking about what's next? What's better? How can we make this thing better? So we're going to take your questions. That's the reason we're here, is to take your questions and answer them. Or at least the best we can for the next hour. And all right, so let's go around the room and introduce yourself. My name is Brett. I am streaming from Brett from that. From Brett. From Virginia Beach in Virginia beach, Virginia, United States. Um, and I talk about things on the internet, I sell courses on you, to me that talk about Docker and kubernetes Ive or introduce yourself. >>How's it going? Everyone, I'm a software engineer at axel Springer, currently based in Berlin and I happen to be Brett Brett's teaching assistant. >>All right, that's right. We're in, we're in our courses together almost every day. Mm john >>hey everyone, my name is john Harris, I used to work at Dhaka um, I now work at VM ware is a star field engineer. Um, so yeah, >>and normal >>awesome by the way, you are streaming from Brett Brett, >>I answered from breath to breath. >>Um I'm normal method. I'm a distinguished engineer with booz allen and I'm also a doctor captain and it's good to see either in person and it's good to see you again john it's been a little while. >>It has the pre covid times, right? You're up here in Seattle. >>Yeah. It feels, it feels like an eternity ago. >>Yeah, john shirt looks red and reminds me of the Austin T shirt. So I was like, yeah, so we all, we all have like this old limited edition doctor on E. >>T. That's a, that's a classic. >>Yeah, I scored that one last year. Sometimes with these old conference church, you have to like go into people's closets. I'm not saying I did that. Um, but you know, you have to go steal stuff, you to find ways to get the swag >>post post covid. If you ever come to my place, I'm going to have to lock the closets. That >>that's right, That's right. >>So the second I think it was the second floor of the doctor HQ in SAn Francisco was where they kept all the T shirts, just boxes and boxes and boxes floor to ceiling. So every time I went to HQ you just you just as many as you can fit in your luggage. I think I have about 10 of these. You >>bring an extra piece of luggage just for your your shirt shirt grab. Um All right, so I'm going to start scanning questions uh so that you don't have to you can you help you all are welcome to do that. And I'm going to start us off with the topic. Um So let's just define the parameters. Like we can talk about anything devops and here we can go down and plenty of rabbit holes. But the kind of, the goal here is to talk about get ups and get ups if you haven't heard about it is essentially uh using versioning systems like get like we've all been getting used to as developers to track your infrastructure changes, not just your code changes and then automate that with a bunch of tooling so that the robots take over. And essentially you have get as a central source of truth and then get log as a central source of history and then there's a bunch of magic little bits in the middle and then supposedly everything is wonderful. It's all automatic. The reality is is what it's often quite messy, quite tricky to get everything working. And uh the edges of this are not perfect. Um so it is a relatively new thing. It's probably three, maybe four years old as an official thing from. We've uh so we're gonna get into it and I'll let's go around the room and the same word we did before and um not to push on that, put you on the spot or anything. But what is, what is one of the things you either like or either hate about getups um that you've enjoyed either using it or you know, whatever for me. I really, I really love that I can point people to a repo that basically is hopefully if they look at the log a tracking, simplistic tracking of what might have changed in that part of the world or the environment. I remember many years past where, you know, I've had executive or some mid level manager wants to see what the changes were or someone outside my team went to see what we just changed. It was okay, they need access to this system into that dashboard and that spreadsheet and then this thing and it was always so complicated and now in a world where if we're using get up orbit bucket or whatever where you can just say, hey go look at that repo if there was three commits today, probably three changes happened. That's I love that particular part about it. Of course it's always more complicated than that. But um Ive or I know you've been getting into this stuff recently. So um any thoughts? Yeah, I think >>my favorite part about get ops is >>reproducibility. Um >>you know the ability to just test something and get it up and running >>and then just tear it down. >>Uh not >>being worried that how did I configure it the first time? I think that's my favorite part about >>it. I'm changing your background as we do this. >>I was going to say, did you just do it get ups pushed to like change his >>background, just a dialogue that different for that green screen equals false? Uh Change the background. Yeah, I mean, um and I mean I think last year was really my first year of actually using it on anything significant, like a real project. Um so I'm still, I still feel like I'm very new to john you anything. >>Yeah, it's weird getups is that thing which kind of crystallizes maybe better than anything else, the grizzled veteran life cycle of emotions with the technology because I think it's easy to get super excited about something new. And when I first looked into get up, so I think this is even before it was probably called getups, we were looking at like how to use guest source of truth, like everything sounds great, right? You're like, wait, get everyone knows, get gets the source of truth, There's a load of robust tooling. This just makes a sense. If everything dies, we can just apply the get again, that would be great. Um and then you go through like the trough of despair, right? We're like, oh no, none of this works. The application is super stateless if this doesn't work and what do we do with secrets and how do we do this? Like how do we get people access in the right place and then you realize everything is terrible again and then everything it equalizes and you're kind of, I think, you know, it sounds great on paper and they were absolutely fantastic things about it, but I think just having that measured approach to it, like it's, you know, I think when you put it best in the beginning where you do a and then there's a magic and then you get C. Right, like it's the magic, which is >>the magic is the mystery, >>right? >>Magic can be good and bad and in text so >>very much so yeah, so um concurrence with with john and ever uh in terms of what I like about it is the potential to apply it to moving security to left and getting closer to a more stable infrastructures code with respect to the whole entire environment. Um And uh and that reconciliation loop, it reminds me of what, what is old is new again? Right? Well, quote unquote old um in terms of like chef and puppet and that the reconciliation loop applied in a in a more uh in a cleaner interface and and into the infrastructure that we're kind of used to already, once you start really digging into kubernetes what I don't like and just this is in concurrence with the other Panelist is it's relatively new. It has um, so it has a learning curve and it's still being, you know, it's a very active um environment and community and that means that things are changing and constantly and there's like new ways and new patterns as people are exploring how to use it. And I think that trough of despair is typically figuring out incrementally what it actually is doing for you and what it's not going to solve for you, right, john, so like that's that trough of despair for a bit and then you realize, okay, this is where it fits potentially in my architecture and like anything, you have to make that trade off and you have to make that decision and accept the trade offs for that. But I think it has a lot of promise for, for compliance and security and all that good stuff. >>Yeah. It's like it's like the potentials, there's still a lot more potential than there is uh reality right now. I think it's like I feel like we're very early days and the idea of especially when you start getting into tooling that doesn't appreciate getups like you're using to get up to and use something else and that tool has no awareness of the concept so it doesn't flow well with all of the things you're trying to do and get um uh things that aren't state based and all that. So this is going to lead me to our first question from Camden asking dumb questions by the way. No dumb questions here. Um How is get apps? Not just another name for C. D. Anybody want to take that as an answer as a question. How is get up is not just another name for C. D. I have things but we can talk about it. I >>feel like we need victor foster kids. Yeah, sure you would have opinions. Yeah, >>I think it's a very yeah. One person replied said it's a very specific it's an opinionated version of cd. That's a great that's a great answer like that. Yeah. >>It's like an implement. Its it's an implementation of deployment if you want it if you want to use it for that. All right. I realize now it's kind of hard in terms of a physical panel and a virtual panel to figure out who on the panel is gonna, you know, ready to jump in to answer a question. But I'll take it. So um I'll um I'll do my best inner victor and say, you know, it's it's an implementation of C. D. And it's it's a choice right? It's one can just still do docker build and darker pushes and doctor pulls and that's fine. Or use other technologies to deploy containers and pods and change your, your kubernetes infrastructure. But get apps is a different implementation, a different method of doing that same thing at the end of the day. Yeah, >>I like it. I like >>it and I think that goes back to your point about, you know, it's kind of early days still, I think to me what I like about getups in that respect is it's nice to see kubernetes become a platform where people are experimenting with different ways of doing things, right? And so I think that encourages like lots of different patterns and overall that's going to be a good thing for the community because then more, you know, and not everything needs to settle in terms of only one way of doing things, but a lot of different ways of doing things helps people fit, you know, the tooling to their needs, or helps fit kubernetes to their needs, etcetera. Yeah, >>um I agree with that, the, so I'm gonna, since we're getting a load of good questions, so um one of the, one of the, one of the, I want to add to that real quick that one of the uh from the, we've people themselves, because I've had some on the show and one of things that I look at it is distinguishing is with continuous deployment tools, I sort of think that it's almost like previous generation and uh continuous deployment tools can be anything like we would consider Jenkins cd, right, if you if you had an association to a server and do a doctor pull and you know, dr up or dr composed up rather, or if it did a cube control apply uh from you know inside an ssh tunnel or something like that was considered considered C. D. Well get ops is much more rigid I think in terms of um you you need to apply, you have a specific repo that's all about your deployments and because of what tool you're using and that one your commit to a specific repo or in a specific branch that repo depends on how you're setting it up. That is what kicks off a workflow. And then secondly there's an understanding of state. So a lot of these tools now I have uh reconciliation where they they look at the cluster and if things are changing they will actually go back and to get and the robots will take over and will commit that. Hey this thing has changed um and you maybe you human didn't change it, something else might have changed it. So I think that's where getups is approaching it, is that ah we we need to we need to consider more than just a couple of commands that be runnin in a script. Like there needs to be more than that for a getups repo to happen anyway, that's just kind of the the take back to take away I took from a previous conversation with some people um >>we've I don't think that lost, its the last piece is really important, right? I think like for me, C d like Ci cd, they're more philosophical ideas, write a set of principles, right? Like getting an idea or a code change to environments promoting it. It's very kind of pipeline driven um and it's very imperative driven, right? Like our existing CD tools are a lot of the ways that people think about Cd, it would be triggered by an event, maybe a code push and then these other things are happening in sequence until they either fail or pass, right? And then we're done. Getups is very much sitting on the, you know, the reconciliation side, it's changing to a pull based model of reconciliation, right? Like it's very declarative, it's just looking at the state and it's automatically pulling changes when they happen, rather than this imperative trigger driven model. That's not to say that there aren't city tools which we're doing pull based or you can do pull based or get ups is doing anything creatively revolutionary here, but I think that's one of the main things that the ideas that are being introduced into those, like existing C kind of tools and pipelines, um certainly the pull based model and the reconciliation model, which, you know, has a lot in common with kubernetes and how those kind of controllers work, but I think that's the key idea. Yeah. >>Um This is a pretty specific one Tory asks, does anyone have opinions about get ops in a mono repo this is like this is getting into religion a little bit. How many repos are too many repose? How um any thoughts on that? Anyone before I rant, >>go >>for it, go for it? >>Yeah. How I'm using it right now in a monitor repo uh So I'm using GIT hub. Right, so you have what? The workflow and then inside a workflow? Yeah, mo file, I'll >>track the >>actual changes to the workflow itself, as well as a folder, which is basically some sort of service in Amman Arepa, so if any of those things changes, it'll trigger the actual pipeline to run. So that's like the simplest thing that I could figure out how to, you know, get it set up using um get hubs, uh workflow path future. Yeah. And it's worked for me for writing, you know? That's Yeah. >>Yeah, the a lot of these things too, like the mono repo discussion will, it's very tool specific. Each tool has various levels of support for branch branching and different repos and subdirectories are are looking at the defense and to see if there's changes in that specific directory. Yeah. Sorry, um john you're going to say something, >>I was just going to say, I've never really done it, but I imagine the same kind of downsides of mono repo to multiple report would exist there. I mean, you've got the blast radius issues, you've got, you know, how big is the mono repo? Do we have to pull does the tool have to pull that or cashier every time it needs to determine def so what is the support for being able to just look at directories versus you know, I think we can get way down into a deeper conversation. Maybe we'll save it for later on in the conversation about what we're doing. Get up, how do we structure our get reposed? We have super granular repo per environment, Perper out reaper, per cluster repo per whatever or do we have directories per environment or branches per environment? How how is everything organized? I think it's you know, it's going to be one of those, there's never one size fits all. I'll give the class of consultant like it depends answer. Right? >>Yeah, for sure. It's very similar to the code struggle because it depends. >>Right? >>Uh Yeah, it's similar to the to the code problem of teams trying to figure out how many repose for their code. Should they micro service, should they? Semi micro service, macro service. Like I mean, you know because too many repose means you're doing a bunch of repo management, a bunch of changes on your local system, you're constantly get pulling all these different things and uh but if you have one big repo then it's it's a it's a huge monolithic thing that you usually have to deal with. Path based issues of tools that only need to look at a specific directory and um yeah, it's a it's a culture, I feel like yeah, like I keep going back to this, it's a culture thing. Does your what is your team prefer? What do you like? What um what's painful for everyone and who's what's the loudest pain that you need to deal with? Is it is it repo management? That's the pain um or is it uh you know, is that that everyone's in one place and it's really hard to keep too many cooks out of the kitchen, which is a mono repo problem, you know? Um How do we handle security? So this is a great one from Tory again. Another great question back to back. And that's the first time we've done that um security as it pertains to get up to anyone who can commit can change the infrastructure. Yes. >>Yes. So the tooling that you have for your GIT repo and the authentication, authorization and permissions that you apply to the GIT repo using a get server like GIT hub or get lab or whatever your flavor of the day is is going to be how security is handled with respect to changes in your get ups configuration repository. So um that is completely specific to your implementation of that or ones implementation of of how they're handling that. Get repositories that the get ups tooling is looking at. To reconcile changes with respect to the permissions of the for lack of better term robot itself. Right? They get up tooling like flux or Argosy. D Um one kid would would create a user or a service account or uh other kind of authentication measures to limit the permissions for that service account that the Gaddafi's tooling needs to be able to read the repose and and send commits etcetera. So that is well within the realm of what you have already for your for your get your get um repo. Yeah. >>Yeah. A related question is from a g what they like about get apps if done nicely for a newbie it's you can get stuff done easily if you what they dislike about it is when you have too many get repose it becomes just too complicated and I agree. Um was making a joke with a team the other week that you know the developer used to just make one commit and they would pass pass it on to a QA team that would then eventually emerging in the master. But they made the commits to these feature branches or whatever. But now they make a commit, they make a pR there for their code then they go make a PR in the helm chart to update the thing to do that and then they go make a PR in the get ups repeal for Argo. And so we talked about that they're probably like four or five P. R. Is just to get their code in the production. But we were talking about the negative of that but the reality was It's just five or 4 or five prs like it wasn't five different systems that had five different methodologies and tooling and that. So I looked at it I was like well yeah that's kind of a pain in the get sense but you're also dealing with one type. It's a repetitive action but it's it's the one thing I don't have to go to five different systems with five different ways of doing it. And once in the web and one's on the client wants a command line that I don't remember. Um Yeah so it's got pros and cons I think when you >>I think when you get to the scale where those kind of issues are a problem then you're probably at the scale where you can afford to invest some time into automation into that. Right? Like what I've when I've seen this in larger customers or larger organizations if there ever at that stage where okay apps are coming up all the time. You know, there's a 10 X 100 X developer to operations folks who may be creating get repose setting up permissions then that stuff gets automated, right? Like, you know, maybe ticket based systems or whatever. Developers say I need a new app. It templates things or more often using the same model, right of reconciliation and operators and the horrific abuse of cogs that we're seeing in the communities community right now. Um You know, developers can create a crd which just says, hey, I'm creating a new app is called app A and then a controller will pick up that app a definition. It will go create a get a repo Programmatically it will add the right definitely will look up and held up the developers and the permissions that need to be able to get to that repo it will create and template automatically some name space and the clusters that it needs in the environments that it needs, depending on, you know, some metadata it might read. So I think, you know, those are definite problems and they're definitely like a teething, growing pain thing. But once you get to that scale, you kind of need to step back and say, well look, we just need to invest in time into the operational aspect of this and automating this pain away, I think. Yeah, >>yeah. And that ultimately ends in Yeah. Custom tooling, which it's hard to avoid it at scale. I mean, there's there's two, there's almost two conversations here, right. There is what I call the Solo admin Solo devops, I bought that domain Solo devops dot com because, you know, whenever I'm talking to dr khan in the real world, it's like I asked people to raise hands, I don't know how we can raise hands here, but I would ask people to raise hands and see how many of you here are. The sole person responsible for deploying the app that your team makes and like a quarter of the room would raise their hand. So I call that solo devops like those, that person can't make all the custom tooling in the world. So they really need dr like solutions where it's opinionated, the workflow is sort of built in and they don't have to wrangle things together with a bunch of glue, you know, in other words bash. Um and so this kind of comes to a conversation uh starting this question from lee he's asking how do you combine get ops with ci cd, especially the continuous bit. How do you avoid having a human uh sort of the complaint the team I was working with has, how do you avoid a human editing and get committing for every single deploy? They've settled on customized templates and a script for routine updates. So as a seed for this conference, this question I'm gonna ask you all uh instead of that specific question cause it's a little open ended. Um Tell me whether you agree with this. I I kind of look at the image, the image artifact because the doctor image or container image in general is an artifact that I I view it that way and that thing going into the registry with the right label or right part of the label. Um That tag rather not the label but the tag that to me is like one of the great demarche points of, we're kind of done with Ci and we're now into the deployment phase and it doesn't necessarily mean the tooling is a clear cut there, but that artifact being shipped in a specific way or promoted as we sometimes say. Um what do you think? Does anyone have opinions on that? I don't even know if that's the right opinion to have so mhm. >>So um I think what you're, what you're getting at is that get ups, models can trigger off of different events um to trigger the reconciliation loop. And one way to do that is if the image, if it notices a image change in the registry, the other is if there's a commit event on a specific rebo and branch and it's up to, you are up to the person that's implementing their get ups model, what event to trigger there, that reconciliation loop off of, You can do both, you can do one or the other. It also depends on the Templeton engine that you're using on top of um on top of kubernetes, such as helm or um you know, the other ones that are out there or if you're not even doing that, then, you know straight. Yeah, mo um so it kind of just depends, but those are the typically the two options one has and a combination of of those to trigger that event. You can also just trigger it manually, right? You can go into the command line and force a a, you know, a really like a scan or a new reconciliation loop to occur. So it kind of just, I don't want to say this, but it depends on what you're trying to do and what makes sense in your pipeline. Right? So if you're if you're set up where you are tag, if you're doing it based off of image tags, then you probably want to use get ups in a way that you're using the image tags. Right. And the pattern that you've established there, if you're not really doing that and you're more around, like, different branches are mapped to different environments, then triggered off of the correct branch. And that's where the permissions also come into play. Where if you don't want someone to touch production and you've got your getups for your production cluster based off of like uh you know, a main branch, then whoever can push a change to that main branch has the authority to push that change to production. Right? So that's your authentication and permissions um system same for the registry itself. Right. So >>Yeah. Yeah. Sorry, anyone else have any thoughts on that? I was about to go to the next topic, >>I was going to say. I think certain tools dictate the approach, like, if you're using Argosy d it's I think I'm correct me if I'm wrong, but I think the only way to use it right now is just through image modification. Like, the manifest changes, it looks at a specific directory and anything changes then it will do its thing. And uh Synchronize the cost there with whatever's and get >>Yeah, flux has both. Yeah, and flux has both. So it it kind of depends. I think you can make our go do that too, but uh this is back to what we were saying in the beginning, uh you know, these things are changing, right? So that might be what it is right now in terms of triggering the reconciliation loops and get ups, tooling, but there might be other events in the future that might trigger it, and it's not completely stand alone because you still need you're tooling to do any kind of testing or whatever you have in terms of like the specific pipeline. So oftentimes you're bolting in getups into some other part of broader Cfd solution. That makes sense. Yeah, >>we've got a lot of questions about secrets or people that are asking about secrets. >>So my my tongue and cheek answered the secrets question was, what's the best practices for kubernetes? Secrets? That's the same thing for secrets with good apps? Uh getups is not last time I checked and last time I was running this stuff get ups is not has nothing to do with secrets in that sense. It's just there to get your stuff running on communities. So, um there's probably a really good session on secrets at dr concept. I >>would agree with you, I agree with you. Yeah, I mean, get off stools, I mean every every project of mine handles secrets differently. Uh huh. And I think I'm not sure if it was even when I was talking to but talking to someone recently that I'm very bullish on get up actions, I love get up actions, it's not great for deployments yet, but we do have this new thing and get hub environments, I think it's called. So it allows me at least the store secrets per environment, which it didn't have the concept of that before, which you know, if you if any of you running kubernetes out there, you typically end up when you start running kubernetes, you end up with more than one kubernetes, like you're going to end up with a lot of clusters at some point, at least many multiple, more than two. Um and so if you're trying to store secret somewhere, you do have and there's a discussion happening in chat right now where people are talking about um sealed secrets which if you haven't heard of that, go look that up and just be versed on what sealed secrets is because it's a it's a fantastic concept for how to store secrets in the public. Um I love it because I'm a big P. K. I nerd but um it's not the only way and it doesn't fit all models. So I have clients that use A W. S. Secrets because they're in A W. S. And then they just have to use the kubernetes external secret. But again like like like normal sand, you know, it's that doesn't really affect get ops, get ops is just applying whatever helm charts or jahmal or images that you're, you're you're deploying, get off. It was more about the approach of when the changes happen and whether it's a push or pull model like we're talking about and you know, >>I would say there's a bunch of prerequisites to get ups secrets being one of them because the risk of you putting a secret into your git repo if you haven't figured out your community secrets architecture and start diving into getups is high and removing secrets from get repose is you know, could be its own industry, right. It's >>a thing, >>how do >>I hide this? How do I obscure this commit that's already now on a dozen machines. >>So there are some prerequisites in terms of when you're ready to adopt get up. So I think is the right way of saying the answer to that secrets being one of them. >>I think the secrets was the thing that made me, you know, like two or three years ago made me kind of see the ah ha moment when it came to get ups which, which was that the premier thing that everyone used to say about get up about why it was great. Was its the single source of truth. There's no state anywhere else. You just need to look at git. Um and then secrets may be realized along with a bunch of other things down the line that is not true and will never be true. So as soon as you can lose the dogmatism about everything is going to be and get it's fantastic. As long as you've understood everything is not going to get. There are things which will absolutely never be and get some tools just don't deal with that. They need to earn their own state, especially in communities, some controls on their own state. You know, cuz sealed secrets and and other projects like SOps and I think there are two or three others. That's a great way of dealing with secrets if you want to keep them in get. But you know, projects like vault more kind of like what I would say, production grade secret strategies. Right? And if you're in AWS or a cloud, you're more likely to be using their secrets. Your secret policy is maybe not dictated by you in large organizations might be dictated by CSO or security or Great. Like I think once if you, if you're trying to adopt getups or you're thinking about it, get the dogmatism of get as a single point of truth out of your mind and think about getups more as a philosophy and a set of best practice principles, then you will be in much better stead, >>right? Yeah. >>People are asking more questions in chat like infrastructure as code plus C d essentially get ups or C I rather, um, these are all great questions and a part of the debate, I'm actually just going to throw up on screen. I'm gonna put this in chat, but this is, this is to me the source, Right? So we worked with when they coined the term. We, a lot of us have been trying to get, if we talk about the history for a minute and then tell me if I'm getting this right. Um, a lot of us were trying to automate all these different parts of the puzzle, but a lot of them, they, some things might have been infrastructure as code. Some things weren't, some things were sort of like settings is coded, like you're going to Jenkins and type in secrets and settings or type in a certain thing in the settings of Jenkins and then that it wasn't really in get and so what we was trying to go for was a way to have almost like eventually a two way state understanding where get might change your infrastructure but then your infrastructure might also change and needs to be reflected in the get if the get is trying to be the single source of truth. Um and like you're saying the reality is that you're never gonna have one repo that has all of your infrastructure in it, like you would have to have, you have to have all your terra form, anything else you're spinning up. Right. Um but anyway, I'm gonna put this link in chat. So this guide actually, uh one of things they talk about is what it's not, so it's, it's kind of great to read through the different requirements and like what I was saying well ago um mhm. Having having ci having infrastructure as code and then trying a little bit of continuous deployment out, it's probably a prerequisite. Forget ops so it's hard to just jump into that when you don't already have infrastructure as code because a machine doing stuff on your behalf, it means that you have to have things documented and somewhere and get repo but let me put this in the in the >>chitty chat, I would like to know if the other panelists agree, but I think get apps is a okay. I would say it's a moderate level, it's not a beginner level communities thing, it's like a moderate level advanced, a little bit more advanced level. Um One can start off using it but you definitely have to have some pre recs in place or some understanding of like a pattern in place. Um So what do the other folks think about that opinion? >>I think if you're if you're trying to use get out before, you know what problem you have, you're probably gonna be in trouble. Right. It's like having a solution to it probably don't have yet. Mhm. Right. I mean if if you're just evil or and you're just typing, keep control apply, you're one person right, Get off. It doesn't seem like a big a big jump, like, I mean it doesn't like why would I do that? I'm just, I'm just gonna inside, it's the type of get commit right, I'm typing Q control apply. But I think one of the rules from we've is none of your developers and none of your admins can have cute control access to the cluster because if you can't, if you do have access and you can just apply something, then that's just infrastructure as code. That's just continuous deployment, that's, that's not really get ops um, getups implies that the only way things get into the cluster is through the get up, get automation that you're using with, you know, flux Argo, we haven't talked about, what's the other one that Victor Farsi talks about, by the way people are asking about victor, because victor would love to talk about this stuff, but he's in my next life, so come back in an hour and a half or whatever and victor is going to be talking about sys, admin list with me. Um >>you gotta ask him nothing but get up questions in the next, >>confuse them, confuse them. But anyway, that, that, that's um, it's hard, it's hard to understand and without having tried it, I think conceptually it's a little challenging >>one thing with getups, especially based off the we've works blog post that you just put up on there. It's an opinionated way of doing something. Uh you know, it's an opinionated way of of delivering changes to an environment to your kubernetes environment. So it's opinionated were often not used to seeing things that are very opinionated in this sense, in the in the ecosystem, but get apps is a opinionated thing. It's it's one way of doing it. Um there are ways to change it and like there are options um like what we were talking about in terms of the events that trigger, but the way that it's structured is an opinion opinionated way both from like a tooling perspective, like using get etcetera, but also from a devops cultural perspective, right? Like you were talking about not having anyone access cube control and changing the cluster directly. That's a philosophical opinion that get ups forces you to adopt otherwise. It kind of breaks the model and um I just I want everyone to just understand that. That is very opinion, anything in that sense. Yeah, >>polygamy is another thing. Infrastructure as code. Um someone's mentioning plummy and chat, I just had actually my life show self plug bread that live go there. I'm on Youtube every week. I did the same thing. These these are my friends um and had palami on two weeks ago uh last week, remember uh and it was in the last couple of weeks and we talked about their infrastructure as code solution. Were actually writing code instead of um oh that's an interesting take on uh developer team sort of owning coding the infrastructure through code rather than Yamil as a data language. I don't really have an opinion on it yet because I haven't used it in production or anything in the real real world, but um, I'm not sure how much they are applying trying to go towards the get up stuff. I will do a plug for Solomon hikes. Who has a, the beginning of the day, it's already happened so you can go back and watch it. It's a, it's a, what's it called? Q. Rethinking application delivery with Q. And build kit. So go look this up. This is the found co founder of Dr and former CTO Solomon hikes at the beginning of the day. He has a tool called dagger. I'm not sure why the title of the talk is delivering with Q. And built it, but the tool is showing off in there for an hour is called dagger. And it's, it's an interesting idea on how to apply a lot of this opinionated automated stuff to uh, to deployment and it's get off space and you use Q language. It's a graph language. I watched most of it and it was a really interesting take. I'm excited to see if that takes off and if they try that because it's another way that you can get a little bit more advanced with your you're get deployments and without having to just stick everything in Yemen, which is kind of what we're in today with helm charts and what not. All right. More questions about secrets, I think. I think we're not going to have a whole lot of more, a lot more about secrets basically. Uh put secrets in your cluster to start with and kubernetes in encrypted, you know, thing. And then, you know, as it gets harder, then you have to find another solution when you have five clusters, you don't wanna have to do it five times. That's when you have to go for Walton A W. S secrets and all >>that. Right? I'm gonna post it note. Yeah. Crm into the cluster. Just kidding. >>Yes, there are recordings of this. Yes, they will be later. Uh, because we're that these are all gonna be on youtube later. Um, yeah, detects secrets cushion saying detect secrets or get Guardian are absolute requirements. I think it's in reference to your secrets comment earlier. Um, Camels asking about Cuban is dropping support for Docker that this is not the place to ask for that, but it, it is uh, basically it's a Nonevent Marantz has actually just created that same plug in available in a different repos. So if you want to keep using Docker and kubernetes, you know, you can do it like it's no big deal. Most of us aren't using doctor in our communities anyway, so we're using like container D or whatever is provided to us by our provider. Um yeah, thank you so much for all these comments. These are great people helping each other and chat. I feel like we're just here to make sure the chats available so people can help each other. >>I feel like I want to pick up on something when you mentioned pollux me, I think there's a um we're talking about getups but I think in the original like the origination of that I guess was deploying applications to clusters right, picking up deployment manifest. But I think with the gloomy and I obviously terra form and things have been around a long time, folks are starting to apply this I think I found one earlier which was like um kub stack the Terror Forms get ups framework. Um but also with the advent of things like cluster A. P. I. Um in the Cuban at the space where you can declare actively build the infrastructure for your clusters and build the cluster right? We're not just talking about deploying applications, the cluster A. P. I will talk to a W. S. Spin up, VPc spin up machines, you know, we'll do the same kind of things that terra form does and and those other tools do I think applying getups principles to the infrastructure spin up right, the proper infrastructure as code stuff, constantly applying Terror form um you know, plans and whatever, constantly applying cluster Api resources spinning up stuff in those clouds. That's a super interesting. Um you know, extension of this area, I'd be curious to see if what the folks think about that. >>Yeah, that's why I picked this topic is one of my three. Uh I got I got to pick the topics. I was like the three things that there like the most bleeding edge exciting. Most people haven't, we haven't basically we haven't figured all this out yet. We as an industry, so um it's I think we're gonna see more ideas on it. Um what's the one with the popsicle as the as the icon victor talks about all the time? It's not it's another getups like tool, but it's um it's getups for you use this kubernetes limit and then we have to look it up, >>You're talking about cross plane. >>So >>my >>wife is over here with the sound effects and the first sound effect of the day that she chooses to use is one. >>All right, can we pick it? Let's let's find another question bret >>I'm searching >>so many of them. All right, so uh I think one really quick one is getups only for kubernetes, I think the main to tooling to tools that we're talking about, our Argosy D and flux and they're mostly geared toward kubernetes deployments but there's a, it seems like they're organized in a way that there's a clean abstraction in with respect to the agent that's doing the deployment and the tooling that that can interact with. So I would imagine that in the future and this might be true already right now that get ups could be applied to other types of deployments at some point in the future. But right now it's mostly focused and treats kubernetes as a first class citizen or the tooling on top of kubernetes, let's say something like how as a first class citizen? Yeah, to Brett, >>to me the field, back to you bret the thing I was looking for is cross plane. So that's another tool. Um Victor has been uh sharing a lot about it in Youtube cross plane and that is basically runs inside a kubernetes, but it handles your other infrastructure besides your app. It allows you to like get ops, you're a W. S stuff by using the kubernetes state engine as a, as a way to manage that. And I have not used it yet, but he does some really great demos on Youtube. So people are liking this idea of get off, so they're trying to figure out how do we, how do we manage state? How do we uh because the probably terra form is that, well, there's many problems, but it's always a lot of problems, but in the get outs world it's not quite the right fit yet, It might be, but you still, it's still largely as expected for people to, you know, like type the command, um, and it keeps state locally the ss, clouds and all that. And but the other thing is I'm I'm now realizing that when I saw the demo from Solomon, I'm going back to the Solomon hikes thing. He was using the demo and he was showing it apply deploying something on S three buckets, employing internet wifi and deploying it on google other things beyond kubernetes and saying that it's all getups approach. So I think we're just at the very beginning of seeing because it all started with kubernetes and now there's a swarm one, you can look up swarm, get office and there's a swarm, I can't take the name of it. Swarm sink I think is what's called swarm sink on git hub, which allows you to do swarm based getups like things. And now we're seeing these other tools coming out. They're saying we're going to try to do the get ups concepts, but not for kubernetes specifically and that's I think, you know, infrastructure as code started with certain areas of the world and then now then now we all just assume that you're going to have an infrastructure as code way of doing whatever that is and I think get off is going to have that same approach where pretty soon, you know, we'll have get apps for all the clouds stuff and it won't just be flexor Argo. And then that's the weird thing is will flex and Argo support all those things or will it just be focused on kubernetes apps? You know, community stuff? >>There's also, I think this is what you're alluding to. There is a trend of using um kubernetes and see rDS to provision and control things that are outside of communities like the cloud service providers services as if they were first class entities within kubernetes so that you can use the kubernetes um focus tooling for things that are not communities through the kubernetes interface communities. Yeah, >>yeah, even criticism. >>Yeah, yeah, I'm just going to say that sounds like cross plane. >>Yeah, yeah, I mean, I think that's that's uh there were, you know, for the last couple of years, it's been flux and are going back and forth. Um they're like frenemies, you know, and they've been going back and forth with iterating on these ideas of how do we manage this complicated thing? That is many kubernetes clusters? Um because like Argo, I don't know if the flux V two can do this, but Argo can manage multiple clusters now from one cluster, so your, you can manage other clusters, technically external things from a single entity. Um Originally flux couldn't do that, but I'm going to say that V two can, I don't actually >>know. Um I think all that is gonna, I think that's going to consolidate in the future. All right. In terms of like the common feature set, what Iver and john what do you think? >>I mean, I think it's already begun, right, I think haven't, didn't they collaborate on a common engine? I don't know whether it's finished yet, but I think they're working towards a common getups engine and then they're just going to layer on features on top. But I think, I mean, I think that's interesting, right, because where it runs and where it interacts with, if we're talking about a pull based model, it shouldn't, it's decentralized to a certain extent, right? We need get and we need the agent which is pulling if we're saying there's something else which is orchestrating something that we start to like fuzzy the model even right. Like is this state living somewhere else, then I think that's just interesting as well. I thought flux was completely decentralized, but I know you install our go somewhere like the cargo has a server as well, but it's been a while since I've looked in depth at them. But I think the, you know, does that muddy the agent only pull model? >>I'm reading a >>Yeah, I would say that there's like a process of natural selection going on as as the C. N. C. F. Landscape evolves and grows bigger and a lot of divide and conquer right now. But I think as certain things kind of get more prominent >>and popular, I think >>it starts to trend and it inspires other things and then it starts to aggregate and you know, kind of get back into like a unified kind of like core. Maybe like for instance, cross plane, I feel like it shouldn't even really exist. It should be, it like it's a communities add on, but it should be built in, it should be built into kubernetes, like why doesn't this exist already >>for like controlling a cloud? >>Yeah, like just, you know, having this interface with the cloud provider and be able to Yeah, >>exactly. Yeah, and it kinda, you're right. That kinda happens because you do, I mean when you start talking about storage providers and networking providers was very specific implementations of operators or just individual controllers that do operate and control other resources in the cloud, but certainly not universally right. Not every feature of AWS is available to kubernetes out of the box. Um and you know, it, one of the challenges across plane is you gotta have kubernetes before you can deploy kubernetes. Like there's a chicken and egg issue there where if you're going to use, if you're going to use our cross plane for your other infrastructure, but it's gotta, but it has to run on kubernetes who creates that first kubernetes in order for you to put that on there. And victor talks about one of his videos, the same problem with flux and Argo where like Argo, you can't deploy Argo itself with getups. There has to be that initial, I did a thing with, I'm a human and I typed in some commands on a server and things happened but they don't really have an easy deployment method for getting our go up and running using simply nothing but a get push to an existing system. There's something like that. So it's a it's an interesting problem of day one infrastructure which is again only day one, I think data is way more interesting and hard, but um how can we spend these things up if they're all depending on each other and who is the first one to get started? >>I mean it's true of everything though, I mean at the end of that you need some kind of big bang kind of function too, you know, I started running start everything I >>think without going over that, sorry, without going off on a tangent. I was, I was gonna say there's a, if folks have heard of kind which is kubernetes and Docker, which is a mini kubernetes cluster, you can run in a Docker container or each container will run as a as a node. Um you know, that's been a really good way to spin up things like clusters. KPI because they boot strap a local kind, install the manifests, it will go and spin up a fully sized cluster, it will transfer its resources over there and then it will die itself. Right? So that, that's kind of bootstrapping itself. And I think a couple of folks in the community, Jason to Tiberius, I think he works for Quinyx metal um has, has experimented with like an even more minimal just Api server, so we're really just leveraging the kubernetes ideas of like a reconciliation loop and a controller. We just need something to bootstrap with those C R D s and get something going and then go away again. So I think that's gonna be a pattern that comes up kind of more and more >>Yeah, for sure. Um, and uh, the next, next quick answer to the question, Angel asked what your thoughts on getups being a niche to get or versus others vcs tools? Well, if I knew anyone who is using anything other than get, I would say no, you know, get ops is a horrible name. It should just be CVS office, but that doesn't or vcs ops or whatever like that, but that doesn't roll off the tongue. So someone had to come up with the get ups phrase. Um but absolutely, it's all about version control solutions used for infrastructure, not code. Um might get doctor asks a great question, we're not gonna have time for it, but maybe people can reply and chat with what they think but about infrastructure and code, the lines being blurred and that do develop, how much of infrastructure does developer do developers need to know? Essentially, they're having to know all the things. Um so unfortunately we've had way more questions like every panel here today with all the great community, we've got way more questions we can handle in this time. So we're gonna have to wrap it up and say goodbye. Go to the next live panel. I believe the next one is um on developer, developer specific setups that's gonna be peter running that panel. Something about development in containers and I'm sure it's gonna be great. Just like this one. So let's go around the room where can people find you on the internet? I'm at Brett fisher on twitter. That's where you can usually find me most days you are? >>Yeah, I'm on twitter to um, I'll put it in the chat. It's kind of confusing because the TSR seven. >>Okay. Yeah, that's right. You can't just say it. You can also look at the blow of the video and like our faces are there and if you click on them, it tells you our twitter in Arlington and stuff, john >>John Harris 85, pretty much everywhere. Get hub Twitter slack, etc. >>Yeah >>and normal, normal faults or just, you know, living on Youtube live with Brett. >>Yeah, we're all on the twitter so go check us out there and thank you so much for joining. Uh thank you so much to you all for being here. I really appreciate you taking time in your busy schedule to join me for a little chit chat. Um Yes, all the, all the cheers, yes. >>And I think this kid apps loop has been declarative lee reconciled. >>Yeah, there we go. And with that ladies and gentlemen, uh bid you would do, we will see you in the next, next round coming up next with Peter >>bye.

>>Welcome back to the doctor khan cube conversation. Dr khan 2021 virtual. I'm john for your host of the cube of mulch, Donny co founder and CTO and see so for accurate hot startup hot company. Uh, thanks for coming on the cube for dr continent and talking cybersecurity and cloud native. Super important. Thanks for coming on, >>appreciate john. Thanks for having me. >>So here dr khan. Obviously the conversations around developer experience, um, making things more productive. Obviously cloud scale cloud native with docker containers with kubernetes all lining up right in line with the trend that's now going mainstream and all commercial enterprises. I mean developer productivity security is a huge times thing if you don't get it right. So, you know, shifting left is that everyone's talking about, but this is a huge challenge. Can you, can you talk about what you guys do at your company and specifically why it relates to this conversation for developers at dr khan. >>Sure. Um, so john as we understand today, there are millions of uh, you know, code comments that are happening in cloud native environments on daily basis. Um, you know, in a recent report, Airbnb reported, they've checked in 125,000 plus times ham charts in an ear. And what that means is that, you know, the guitars revolution is here. Uh, and that also means that, well, you got your kubernetes clusters sinking up with infrastructure as code, such as ham chart customized and yarrow files right almost several times a day now, what that also means is that the opportunity to make sure that your clusters are being deployed securely by these infrastructure as code templates and deployment has called template is available before the deployment happens and not after the deployment. Also, in order to reduce the cost or detecting security challenges. The best option and opportunity is during the development time and during the deployment time, which is the pipeline time and that's what we offer. We shift your cloud, native security posture detection to left. We detect all your security posture related issues while the code is in development in the design phase as well as while it is about to get deployed, that is within the guitars pipelines or your traditional develops pipelines and not only with detect where we sell feel the code as well, specifically infrastructure as code. So we detect the problems and we fix the problem by generating the remediation code which we like to call it as remediation is called. The detection mechanisms like all this policy is called. That's the primary use case that we offer. We help developers reduce the cost of remediation and also meantime to the mediations for security problems >>and actually see them a boatload of hassle to going back and figure out how they wrote the code at that time. And kind of what happened always is a problem. Um, I gotta Okay, so I'm gonna get into this policy is code. You mentioned that also you mentioned Getafe's revolution. Let's get to that in a second. But first I want you to explain to the folks what is cloud native security and what does that mean? And what kind of attacks emerge as that surface area becomes apparent? >>Absolutely. So cloud native security is a very interesting new paradigm. Uh it's not just related with one single control pain like take, for example, Cuban haters, it's not just that, it's also the supply chain elements that go into the deployment of your cloud native clusters. Like see if kubernetes cluster you need to secure not just the application code which is running inside your container images, but also the container image itself, then the pod, then the name space, then the cluster. And also you need to do all the other cyber hygienic, high generated things that we were doing previously. So it's so much of complexity because availability of different control planes, you need to be able to make sure that you are doing security, not just right, but at a very, very cost effective in a very, very cost effective manner. And the kind of attacks that we are predicting we're going to see in cloud native world are going to be very different from what we have seen so far. Especially there's a new attack type that I am have coined. I call that as cloud native waterhole attack. What it means is that imagine that most of the cloud native infrastructures are developed out of a lot of different open source components and pieces. So imagine you're pulling up a container image from a open source container agency and that continued which contains a man there container image can directly land into your cluster and not only can enter into your so called secure cluster environment. Usually the cluster control planes are not exposed to internet but deployment of one supply chain element like a Mallory's container image and exposed to an entire cluster. And that's what is waterhole attack when it comes to chlorinated water hole attacks to supply chains. So these are some very innovative and noble attacks that you know, we Uh you know, predict are going to come to our weigh in next 12-18 months. >>So you say it's a waterhole attack. That's the that's the coin term that you've made. So basically what you're saying is the container could be infected with all the properties that is containing into a secure cluster. It's almost been penetrated like malware would or spear phishing attack, it targets the cluster and then infects it. >>So not only that because your continuing images that you're pulling in um from your registries registries can be located anywhere right? If you do not do proper sanitization and checking off your supply chain components such as a continuing image, it can land insecure zones like this. So not only in a cluster, it can become part of a system named space very soon and and that's where the risks are that, you know, you had a parameter, you know, at least of some sort when it was non cloud native environments. And now you have a kind of false sense of security that I have equivalent is cluster, which sort of air gap in one way like there's no exposure to internet of the control plane control being a P. I. Is not supposed to Internet, that doesn't mean anything. A container enters into your cluster can take over the entire cluster. >>All right, so that's cool. So I love that attacks kind of attack. So back to cloud native security definition. So you're defining cloud native security as cloud native clusters. Is it specific around kubernetes or what specifically the cloud native security? What's the category? If the if water holds the attack vector, what's cloud native security means? >>So what it means is that you need to worry about multiple different control planes in a cloud native environment. It's not just a single control pain that you have to worry about. You have to worry about your uh as I said, kubernetes control plane, you have service measures on top of it, You could have server less layers on top of it and when you have to worry about so many different control pains, but it also means is that the security needs to become part of and has to get baked into the entire process of building cloud native environment, not afterthought or it shouldn't happen after the fact. >>See the containers for containers that watch the containers security for the security to watch the security. So you get so let's get we'll get to that. I want to get back to the solution, but one more thing. Um this one piece. So your c so um there you have a lot of shops in there from your background, I know that. Um So if if people out there, other Csos are looking at expanding, You know, day one day 2 ongoing, you know, ai ops get upstate to operate what everyone call it cloud native environments. How do they consider figuring out how to deploy and understand cloud need to secure? What do they have to do if you're a c So knowing what, you know, what steps are you taking? >>Yeah, it's funny that, you know, there's a big silo today between the sea, so organizations and the devops and get ops teams. Uh so the number one priority, in my opinion, that the sea so s uh you know, have to really follow is having visibility into the uh developers. So developers who are developing not just code but also infrastructure as code. So there is a slight difference between writing python code versus writing uh say ham charts or customized templates. Right? So you need as a see saw, you know, see so our needs to have full visibility into Okay, out of 100 developers, how many do I have who are writing deployment as code? And then how many of them are continuously checking in code and introducing security issues? Those issues have to be visualized while the issues are written in code and as they are getting checked into the repositories, so catch the security issues while the code is getting checked into the repository. And the next best stages catch the issues while the pipelines are picking up the code from the repository. So sisters needs to have visibility into this. I call it as shift left visibility for CSOS. So sisters need to know, okay, what are my top 10 developers who are writing infrastructure as code? How many of those developers are committing wonderful code. How many of these pull requests which have been raised have got security violations? How many of them have been fixed and how many have not been fixed? That's what is the visibility that can uh you know, provide opportunities to seize organizations to >>react and more things to put KPI S around two to understand where the gaps are and where the potential blind spots are. Okay, shift left visibility to see. So if you've got the get ups revolution, you got the waterhole attacks. You have multiple control planes obviously complex. The benefits of cloud native though are significant and people doing modern applications are seeing that. So clearly this is direction that everyone's going. The consensus is clear. So how do you solve this? You mentioned policy as code. I'm kind of connecting the dots here. If I'm going to understand what's going on in real time as the code is in flight as it's checking in. For instance, this is kind of in the pipeline as you say. So this has to be solved. What is the answer to this? Because it's clearly the way people want it. No one wants to come back and say we got hacked or development being pulled off task to figure out what they fixed or didn't do what's the policy is code angle? >>So um you know, of course, you know, there could be more than one ways to solve this problem. The way we are solving this problem is that first thing we are bringing all top type of infrastructure as code and the control planes into a single uniform format, which we like to call it as cloud, as code. The reason why we do that so that we can normalize the representation of these different data sets in one single normalized format. And then we apply open policy agent which is a C N C F uh graduated project, which is kind of the de facto standard to do any kind of policy is called use cases in the cloud native world today. So we apply open policy agent to this middleware that we create, which basically brings all these different control plane data, all the different infrastructures code into anomalous format. We apply O P A and we use policies to apply uh Opie on this data this way. What happens is that we write, for example, we want to write a policy, you don't want certain parts to be exposed to Internet in a given name space. You can write such a policy. This policy, you can run on life cluster as well as on the hand charts, which is your development side of the artifact. Right. Because we're bringing both these datasets into middleware. So in short, one of the solutions that we are proposing is that different control planes, different infrastructures, code has to be brought into a normalized format. And then you apply frameworks like Opie a open policy agent to achieve your policy is called use cases. >>What is the attraction for this direction? O. P. A. In particular obviously controlled planes. I get that. I can see the benefit of having this abstraction away with the normalization. I think that would enable a lot of innovation on top of it. Um Makes a lot of sense, totally cool. What's the attraction? What's the vibe? Are people reacting to this? Uh Some people might say whoa hold on, you're taking on too much uh your eyes are bigger than your stomach. You're taking on too much territory. Whoa, slow down. I can I I want to own that control plane. There's a lot of people trying to own the control plane. So again it's a little bit of politics here. What's your what's your thoughts on the momentum? What's the support, what's it look like? >>Yeah, I think you are getting it right, the political side of things. So, um, you know, one responses that, look, we have launched our open source project contour a scan uh last year and uh you know, we're doing pretty well. It's a full opium based uh in a project which allows you to do policies code on not only new cloud control planes, like, you know, kubernetes and others, but also the traditional control planes provided by CSP s like cloud security, cloud service providers. So parents can can be used not just for hand charts and customized, but also for terra form. What we are uh promoting is open culture. With scan. We want community to contribute, become part of it. Um yes, we are promoting a middleware here uh but we want to do it with the help of the community and our reaction what we're getting is very very good. We are in our commercial offering also we use opa we have good adoption going on right now. We believe will be able to uh you know with the developer community, you have this thing going for us. >>I love cloud as code. It's so much more broader than infrastructure as code and I'll see the control plane benefits. You know when I talk to customers, I want to get your reaction to this because I really appreciate your experience and and leadership here. I talked to customers all the time and I wont say name, I won't name names but they're big, big and fintech and you'll big and life sciences in other areas. They all say we want to bring best to breed together but it's too hard to make it all work. We can get it done, but it's a lot of energy. So obviously building code and getting into production that is just brute force. Anyway, they got to get that done and they're working on their pipe lining. But getting other best of breed stuff together and making it work is really hard. Does this solve that? Do you, are you helping solve that problem? Is this an integration opportunity? >>Yes, that and that is true and we have realized it, you know, uh long back. So that's why we do not introduce any new tooling into the existing developer workflows, no new tool whatsoever. We integrate with all existing developer workflows. So if you are a, you know, modern uh, you know, get off shop and you're using flux or Argo, we integrate terrace can seamlessly integrated flux in Argo, you don't even get to know that you already have what policy is called enabled if you're using flux Argo or any equivalent, you know, getups, toolkit. Likewise, if you are using any kind of uh, you know, say existing developer pipeline or workflows such as, you know, the pipelines available on guitar, get lab, you know, get bucket and other pipelines. We seamlessly integrate our motor is very, very simple. We don't want to introduce one more two for developers, we want to introduce one more per security. We want to get good old days, >>no one wants another tool in the tool shed. I mean it's like, it's like really like the tool shit, they get all these tools laying around. But everyone again, this is back to the platform wars in the old days when I was younger. Breaking into the early days of the web platforms were everything you have to build your own proprietary platform Wasn't some open source being used, but mostly it was full stack. Now platforms are inter operating with hybrid and now Edge. So I want to get your thoughts on and I'm just really a little bit off topic. But it's kind of related. How should companies think about platform engineering? Because you now have the cloud scale, which in a way is half a stack. You don't really if you're gonna have horizontal scalability and you're gonna have these kind of unified control planes and infrastructure as code. Then in a way you don't really need that full stack developer. I mean I could program the network. I don't need to get into the weeds on that. I got now open policy agent on with terrorists. Can I really can focus on developing this is kind of like an OS concept. So how should companies think about platforms and hiring platform engineers and and something that will scale and have automation and all the benefits and goodness of the cloud scale. >>Yeah, I mean you actually nailed it when you began uh we've been experienced since we've been experiencing now since last at least 18 months that and if I were specifically also, I'll touch based on the security side of things as well. But platform engineering and platforms, especially now everything is about interoperability and uh, what we have started experiencing is that it has to be open. The credibility any platform can gain is only through openness interoperability and also neutrality. If these three elements are missing, it's very hard to push and capture the mind share of the users to adopt the platform. And why do you want to build a platform to actually attract partners who can build integrations and also to build apps on top of it or plug ins on top of it? And that can only be encouraged if there is, you know, totally openness, key components have to be open source, especially in security. I can give you several examples. The future of security is absolutely open source, the credibility cannot be gained without that. A quick example of that is cystic. I mean, who thought they were gonna be pulling such a huge, you know, funding round, of course that all is on the background of Falco, Right? So what I'm trying to play and sing and same for psyllium, Right? So what I'm clearly able to see is the science are that especially in cybersecurity community, you are delivering open source based platforms, you will have the credibility because that's where you will get the mindshare developers will come and you know, and work with you of course, you know, I have no shame naming fellow vendors right, who are doing this right and this is the right way to do it. >>Yeah. And I think it's it's totally true and you see the validation on that just to verify your point out that we have a little love fest here on open source, it's pretty obvious the the end user communities are controlled not the hard core and users like the hyper scholars, you know, classic enterprises are are starting not only contribute participate but add value more than they've ever have. The question I want to ask you is okay. I totally agree on open as data becomes super important because remember data is only as good as what you have and the more data the better the machine learning the better the data scale, um, sharing is important. So open sharing kind of ties into open source. What's your thoughts on data? Data policy, is this going to extend out into data control planes? What's your thoughts there? I'd love to get your input. >>We are a little little bit early in that thought. I think it's gonna take a little while uh for you know, the uh for the industry bosses to come to terms to that uh data lakes and uh you know, data control planes eventually will open up. But you know, I I see there is resistance in that space today uh but eventually it's gonna come around. You know, that has because that would be the next level of openness, you know, once the platforms uh in a mature as an example right today. Um you want to write uh you know, any kind of say policies for your same products, right. Uh you have the option available to write policies and customized, you know, languages. But then many platforms are coming up which are supporting policy is developed in in languages which are open and that's data which is going to open up, you know very soon. So you will not be measured in terms of how many policies you have as a product, but you will be measured. Can you consume? Open policies are not so i that it is going to go there, it's going to take a little while, but I think he is going to move that. >>It makes sense. Get the apparatus built on the infrastructure side. Once you have some open policy capability that's going to build an abstraction on top of it, then you can program data to be more policy driven or dynamic based upon contextual behavioural dynamics. So it makes a lot of sense. Oh, great insight here, love the conversation, Congratulations on your success. Love the vision. Love the openness. I'll see. We think uh data as code is big too. Obviously media's data where CUBA is open. We have we have the same philosophy. So thanks for sharing. Love the vision. Take a minute to plug the company. What are you guys looking to do? Uh you guys hiring, take a minute to put the plug out for the for the company? >>Absolutely. We are absolutely hiring great ingenious, you know, a great startup mind folks who want to come and work for a very, very innovative environment. Uh we are very research and development, you know driven and have brought various positions available today. Um we are trying to do something which has not been attempted before. Our focus is 100% on reducing the cost of security. And uh you know, in order to do that, you really have to do things that previously were not in development environments. And that's where we're going. We're open source uh, you know, open source initiatives, big open source lovers and we welcome people come in and apply our positions, >>reduce the cost of security, do the heavy lifting for the customer with code and have great performance, that's the ultimate goal. Great stuff. Cloud need security, threat modeling, deV stickups, shifting left in real time. You guys got a lot of hard problems you're attacking? >>Um well, you know, some of the good things uh that we're doing is also because of the team that we have right. Most of our co team comes from very heavy threat modeling, threat analysis and third intelligence background. So we have we're blending a very unique perspective of allowing developers to tackle the threats, which they're not supposed to even understand how they work. We do the heavy lifting from threat intelligence point of view, we just let the developers work on the code that we generate for them to fix those threats. So we're shipping threat intelligence and threat modeling also to left. Uh we're one of the first companies to create threat models just out of infrastructure is called, we read your infrastructure as code and we create a digital twin of your cloud late at one time, even before it has been actually built. So we do some of those things which we like to call it just advanced bridge card prediction where we can predict whether you have reach parts a lot in your runtime environment that would have been committed. >>And then the Holy Grail obviously the automation and self healing um is really kind of where you've got to get to. Right, that's the whole that's the whole ballgame, right? They're making that productive. Oh, thank you for coming on a cube here. Dr khan 2021 sharing your insights, co founder and CTO and see so. Oh much Danny. Thank you for coming on. I appreciate it, >>monsieur john thank you for having >>Okay Cube coverage of Dr Khan 2021. Um your host, John Fury? The Cube. Thanks for watching. Yeah.

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

>>Okay, welcome back to the Cube coverage of Dr Khan 2021. I'm John for your host. Had a great guest here. Dana Lawson. Vice president. Engineering and technology partnerships that get up dana. Welcome to the cube. You're leading the engineering team over at GIT hub. Been been around the block in the cloud enterprise area. Congratulations. Welcome to the cube. >>Well, thanks for having me. Don, I am super excited. Dr. 2021 Wow. I can't believe it's been that long. Right. >>Got the keynote coverage automation. The top trend here in the world. DevoPS DEP sec apps, developer productivity, modern errors here, a lot of action uh and dr conscious more attendance every year, containers setting up the cloud native. You know the tsunami of new ways that people are programming. New way teams are formed new way people are being super productive with the pandemic. We've seen developers really lead the charge in the virtual work environment. So a lot of action. So first tell us what's going on in the developer community right now, give us your take, >>I mean, my take on it is the developer teams are just working closer than ever before. You know, we see this across all industries, whether you're going through your own digital transformation and trying to streamline your workflow, um you know, we have this concept of devops now for about a decade and and we all were hopeful I was one of those early adopters that like, yes, this will change the world, as you can imagine, and like we're seeing it materialized and I feel like in this historic year, uh it's on steroids, we see teams working across the aisle doing things we've never experienced before with this concept of interconnected tools. And so we're seeing really the, I would say the practice of devops really going across every member of the team and not being just a practice that maybe one person on your team did. You know, this trend has been ongoing for a while. But with these new key technologies out there, it's really on fire in my opinion, >>outside of just the whole cloud native awesomeness that's happening. You see kubernetes enabling a lot of new things, the virtual work environment with the pandemic developers, just like just the way we've been working a long time. Finally, it just got standardized for the rest of the world, the world. Um they didn't really miss a beat and, and combined again with the cloud scale and we saw the earnings from all the big companies, the developers have been super productive this year. Do you see um that continuing and what, how is it going to change in your opinion as the pandemic kind of lifts a little bit and now the new normal gets back to real life. Certainly those benefits came out is what's your take on this engineering dynamic going on. >>I mean you said it they're like this is a common kind of workflow that people had pre pandemic, especially in the open source community where it's literally a bunch of random people around the world that don't obviously get to talk as as quickly and as uh you know, synchronously and so a saint communications gone up in what we've seen there is teams really tuning in their automation, right? So whereas you may have had it in your backlog to say, you know what, I should probably go automate that workflow now that we have been forced. Even even companies that haven't haven't thought about in the past to say, okay, how do I get code from A to B. Seamlessly? There's spending time on those workflows. and I think that we're seeing that naturally, you know, in the keynote where I mentioned some of the Research that we've done is we're seeing developers work more but we're seeing them work more on open source projects and the things that they want to work on not necessarily going and saying I'm going to go and spend 20 hours at work. But really it's that that continuation of like hey instead of automation being an afterthought we're gonna make it something that is at the forethought of what we're doing. And so what it's really done is just increase the time spent on writing great code and hopefully having a better up time. I am a I am a DEvops SRE sys admin, whatever you wanna call it at heart forever will be. Um and so you know, getting to have more time to spend on S. L. O. S. And really the, you know like I call it the safety guards, the rails of your system so that you can just really go in there and allow everybody to contribute. And that's what I think we're seeing and we're going to continue to see that as things just get easier as stuff happens out of the virtual box. >>I mean simple or easy. It's always a good strategy. I was just reporting for our team on the cube con and cloud native con. There's more cloud native con going on than cube con because kubernetes got kind of boring. Um, and enabled more cloud native development. And then the other trend that we've been reporting on is end user contribution to open sores. You're starting to see end users, not just the usual suspects like lift and whatnot. You're seeing like real enterprises like having teams contributing into open source in a big way. This is a kind of a new, interesting dynamic. What's your take on that? Is that a signal of simplicity? What does it mean? >>I'm going to tell you, I think that companies and big names that realized they were using open source and they have been all along, um, it's been around for a minute. Some of our most favorite libraries and frameworks have been open source from the beginning. You hear me talking about Java and Tomcat that's open source. And so it's really this understanding of the workflow. So I want to say that what we see now is there should be an investment because the world's team of open source developers are powering our technology and why shouldn't we as companies embrace and actually get back and spend that quality time because us innovating together on open source privately and publicly just makes everything better for everybody. And so I I think we're going to continue to see this trim. I'm excited about it. GIT hub has done some amazing work in this space by with get up sponsors because we want open source to continue to enable the innovation and having people participate. And now we're seeing it with businesses alike. And so I think we're going to see this practice continue on and really take a look not only of the technology they're using, but the open source practices like how do these maintainers and these open source teams shit reliable quality code that is changing the world. And how can we put those practices within our own development teams on what we're building for our customers? So you're just going to continue to see this. And I think also with that being said because the barrier of entry has has lowered some by the advancement. What we're seeing the rise of the citizen developer as well. So we're seeing you know people all within the company and some that are much more further along with their transformations participate in a way they never have before. Whether it's like you know the design part in the design thinking of it to like how do you curate and have a great experience for your customers. We're just seeing participation at all levels of development stack and that also is the stuff outside of the actual code being written because it's so interconnected and so I I don't know I'm excited. I'm excited to see what we're going to unlock by having people participate more so than ever and then having companies invest in that participation. >>I love your enthusiasm. I agree. I think it's a great time for open source because it has democratized, it is bringing in new people. The aperture of the personas coming in >>is not >>just computer science and engineering. This hybrid SRE rolls developing and then you've got creative. There's a creativity aspect coming back and I've been riffing on this for a few years but I'm kind of seeing this development, love to get your thoughts used to be like craftsmanship was involved in building software and then Agile came in ship fast and iterate. Um and now craft is coming back. You're starting to see creativity and the developer experience through collaboration tools and kind of this democratization. What's your thoughts on this? And no, I know you I know you think about this as an engineering leader. Um Craft agile bring them both together. Speed and quality is craft coming back. >>Craft is definitely coming back and I think it is because we we melt the mundane stuff, right? Like, you know, we're all hyper focused on like you want to be the bush out there, you gotta ship immediately agile, agile, agile. But what we know is like you can ship a bunch of stuff, nobody wants very fast, you can ship a bunch of stuff that hasn't been curated to really, you know, solve the problem now, you'll be fast but will be awesome. I think people demand more. And I really believe that because we've embraced some of these frameworks, workflows and tool sets, that we get a focus on the craft and that's what we're trying to do, right? Ultimately we want every person that builds to be an innovator and not just an innovator for innovation state, but because they're changing and affecting somebody's life, right? And so when we dig deep and focusing on the craft, and we still have these expertise, we're just gonna be applying that in a very intentional way versus okay, hurry up. Bill, Bill Bill, hurry up, hurry up. Bill Bill, Bill, go, go, go, because now it's connected. And so we're seeing the rise of that craft and what I think is going to in turn happen is we're all going to have a better experience, we're all going to reap the benefits of having that expertise. You know, there's a spirit sometimes when we talk about automation and devops and, you know, interconnected tool systems that maybe you're taking somebody's job that they were doing before the daily task. No way. All we're doing is saying like, cool, take the repeatable thing that you're doing over and over and over, and let's focus on that craft, lets you know if your security person and you want to get down and deep and understand where vulnerabilities are going to come from and things that people haven't even thought of. Cool, let's take away some of the other things that we know can be caught and solved without you paying attention in some aspects. I think we just need along the whole stack. So it's pretty exciting times. >>Yeah, I did it and we call that different, undifferentiated heavy lifting, you know, just get it out of the way since you brought that up. Let's take automation down that road of experience. What does it mean for the developer? Because this is really an opportunity. Right. So the phrase I've heard is if you do it more than a few times, just automated away. So when is the right time to automate where this automation play into the developer experience? When does it make it more productive? Where's the innovation angle you share your thoughts on when people look through the prism of automation productivity versus innovation? What's the what's the automation view there? >>I mean, you know it is it is a good like, you know, little metric could be done it five times and it's the same thing over and over and over. Your question is now like do you have to be doing that? I mean you should because you're doing it. So I think it's about finding and defining your own boundary for what you need, right? I mean it's hard to get out there and say every workflow like we can go and apply the stamp. We already tried that with agile frameworks for like everybody you're gonna do scrum, we're going to combine, you know what? It doesn't work. What we really need to do is have teams understand their workflows, right, understand and do some diagnosis and saying like we're in the system and I think that's powerful metrics and insights of going like where are we having a slowdown? Where are people spending their time if people are spending their time doing break fix or they're spending their time continuously trying to jam something into a certain pipeline, you have to ask yourself, is this something that we should be spending that time on? What if we had that time freed up? And so I do think you can go and put some good boundaries in there, whatever yours may be. I love I love some of those rule sets but really you know, deadlocks and automation starts with the process, right? We think about it and when I developed software always think about it through that design. Thinking lands of how will this work when I get to it. And so if we're focusing on the design aspect and the user experience, then we start looking at the pieces in between from that code to having people use it and say what do I need to do? And sometimes you know depending on your industry, you may have these other needs that not everybody has. So it's hard to say there's a one size fits all. But there is a good rule like if you've done the same repeatable thing over every every day, uh numerous days like you probably should just go spend the time to automate that. And I think it's the convincing point, right? Like if we go and and a lot of us are are nerds and engineers at heart and I love freaking math. So it's that like okay if we spend two hours building maybe a hub action for a doctor one time instead of somebody happened to repeat this process no matter what it is. Like you're giving that time back in that time is mental capacity, mental capacity that can be applied to something that's more important and hopefully the more important thing is the user experience. Um So yeah, I mean you know we all have those little systems out there. I say use them but take a step back. I think the bigger, the harder part is like yes, you will have to slow down for a minute, which is scary to go and build something repeatable so that you can speed back up. You know, >>it's awesome. Great, great inside love, love the energy a lot to ask you while you're here because this is something I've been thinking about. I'm hearing a lot of developers talking about, understand the workflow you mentioned that's a key thing. I love that. Getting in and understanding the customer experience working backwards, but that brings up the whole. How do you form the teams? How do you think about team formation? Because at cloud scale with cloud native, you can use building blocks, You have automation, you can easily compose and then build intellectual property around things. Use containers, make things easier. So as you start thinking about teams, is it better to have teams focus on, say workflows and then decoupled teams? Is there a strategy for general purpose teams or how do you look at the team formation from the developer perspective to make the experience great, high quality. Is there a state of the art in your opinion, given the compose ability and all the ease of use going on? I mean, what's the ideal way to think this through? What's your thoughts? >>Oh, you know, there's, I'm going to say there's not one team team to rule them all, there's not one team kind of foundation that's gonna be able to be applicable, it's all different, right? Like even within the same company, especially at scale, you may have these different compositions of your team and I think it comes down to like, what problems are you trying to solve within your workflow? What are you trying to accomplish? I think when we, when we step back and we think about our Ci cd pipelines and really code from idea into cloud that I believe in a unified system, because I don't want developers worrying about it and doing one offs, I'm like, you don't need to know that, and that's been an argument that's going on, you know, I'm a huge kubernetes fan and so it's been like, should, should, should the feature developers understand the entrance of kubernetes? I'm gonna say something controversial, I'm gonna say no, I'm gonna say they don't need to know, they need to know how to monitor alert and how to have smart rollbacks and have a system that does it for them. That's why we have Orchestration, that's why we have dr containers, that's why we have world class eight PM and monitoring systems in place because we've done that, we've done that hard work. So I would say no, they don't need to know that, so, but you still need these needs, right? Depending upon where you are in this transformation, right? Maybe you're still like, you know, integrating some of these cloud needed principles and toolsets and so you need some smes I do really love the SRE embedded model, not embedded, like on your, you know, like embedded, like a chip set, but embedded in the team, because that person really should be a mentor and should be a force multiplier. You don't want to fall in the trap and be like oh we have an SRE on the team. They're going to do all the devops stuff. No no no no they're going to go and help you think about your product through a customer lens right there. They're the experts going like whoa maybe we should have an S. L. A. Because this is a tier one feature lets go and make sure we build that automation so that we curate this feature with the highest level availability but then teach the team how to do that. So now you have this practice as a part right? Like you're honing your craft, you have this practice now. Does that mean they need to go learn everything about like the monitoring sweet and tools are used. No, but they should understand how to read the output of that. And so there's not one team size to rule them all. Unfortunately, I personally, I'll tell you what I'm a fan of is like I think that you should have flexibility. Like once again think about the points where you need to have the connective unified system, right? And then you have this opportunity for developers to have some agency and creative freedom because maybe you've been on a team that's been working on, I don't know, let's say your audit service. I think every every software has some component of audit uh, you know, in some ability because you want to know what he was using one well after they've done their tour of duty because most of the cool stuff, they've already fixed and made a feature set. Let them go roll into something else because then you have that connective tissue on the inner points of your system that are always the same, right? We want really repeatability. We want them just to focus on writing the code. And I think because of these advancements we are unlocking opportunity for developers to think broader, right? Like maybe you've been on the platform team and you want to go dip your toes into writing features well, 90 okay, maybe not 90 but also 80% of that, you know, every day repeatable task, like focus on that and get that shit out. But then you have the sme and you're really thinking holistically as a customer obsessed team of what you're building and why. So I love that. No one way. >>Yeah, I love the idea of the platform person just having more flex out because that brings a platform mindset to the other pieces, but also feature acceleration versus product strategy. Thinking through the arc of why you're building in the first place, Right? So and then the embedded SRE great point there, great call out there because everything's cloud scale now, you gotta have pen tests built in automation, >>who's gonna >>design that. So I think it's really interesting how you're putting that together and I think that's very relevant. Um and any um new things that you see happening now with with cloud Native, you mentioned cabernets, I think you know the story that we've been telling is kubernetes got boring and that's good. Right? So, >>meaning its meaning it's working >>and people like it, it's interoperability or frustration. It feels like a unifying connective tissue between under the hood and above at the application layer. So it's nice but the consequence of that is there's more cloud native going on, so that means more services are going to be connected and torn down. You mentioned observe ability and monitoring. That's important too. So as an engineering leader, that's not another department. Right? That's gonna be core to the developers. What's your thoughts on how to integrate observe ability now there's a zillion companies doing it now but is that you know >>there is a zillion. My thoughts are like heck yeah. Like conservative observe ability isn't at the end of the stack. Right, observe ability is apart just like qualities apart. Just like when we think about agile, let me just throw it this way right? Like when dr came right, we had it basically have this maybe this baby os encompassed on servers. So you can have multiple, multiple, multiple, multiple distributed. Right? I think of like let's let's say that like your team is that Docker container man, you want everything in their right? It is a part of the practice. You want your learning, you want your logging, you want it all wrapped up in this nice little bow and you want lots of them all working together harmoniously. The same thing can be said about our teams. We want them to be their own little micro operating system where they have all the resources available for them to go and do the thing that they are intending to do and not have to worry about that subset. But it also gives them that control. Right? So it's building in that layer of abstraction that's needed but also understanding why it's important. So it's a little bit of both. Right? We're not going to curate deep subject matter experts. You know, I'm, you know the Oh yes, I model and every aspect right? Like we're not going to turn a friend and engineer necessarily into a network engineer. But utilizing the tool sets, having a playbook where it is controlled, maintained in a part of your culture. All that's gonna do is allow you to move faster and it's allow you to see what's really running out there in the wild. And I see these trends happening. I think we're continuing to see the rise of cloud native technologies because applications now are really a set of a P. I. S. That go across the world and in and out. And so the way that we develop is slightly different. And so we need to think about, well, how is it orchestrated and deployed? Well, if you have a repeatable pattern once again, if we go back to that and think of our team and I promise nobody asked me to come up with this as like a little darker, a little docker container itself. You know, you're gonna write that image into what makes sense for you and have all the resources available and you're gonna rinse and repeat that over and over and over again. And so I mean, we're just seeing, seeing this continue this continuation of, you know, monitoring devops? S sorry, it's not a problem. It's a culture, right? It's not one person's job or a role. It's a part of how you build great software. It's just a practice. >>You mentioned abstraction layer used to be conventional wisdom that they were good. But there's trade offs whose performance tradeoffs or some overhead. Not anymore. It's good. You can basically build an abstraction layer and say, hey, I don't want to deal with networking anymore. It's gonna make it programmable. >>That's cool. No >>problem. So you start to see these new innovation patterns. Right. So what are you most excited about when you start to see these new kinds of things of being brought on that were limited years ago? Like you start an abstraction layers, you see the role of the SRE you're seeing um the democratization of new developers coming in that are bringing new perspectives. She's seeing all these new kinds of ways that's re factoring how people write code. But what are you seeing is the most exciting >>for me? Honestly, it's like the opportunity for anybody to really be a builder maker developer, right? You don't have to have a traditional CS degree if you do that's awesome, Like come and teach us awesome stuff that we probably should know. That's foundational. I don't have a CS degree. You know, we're moving on from these opportunities where it's self taught to where you actually 100% can go and learn and build and create. We're seeing the rise in these communities. I feel like these toolsets are really just lowering the barrier of entry for those people that don't have advantage to go to like a four year school and get a degree for people that are just like have a great idea what excites me is that next developer, You know, we talk about the 100 million developer sitting somewhere in the world, just going, I have a great idea and I'm gonna change the world and I don't know how to get started, but they do, they have it at their hands now. You know, if you can go onto a website, get a little bit dangerous with these tool sets, you can go and get your idea to the masses and what we're going to end up doing is like you said, democratizing tech, it's going to bring in new ways to think it's going to change how we interact with systems. We get we get our blinders on sometimes, especially, you know, I live in Portland on the West Coast, the US, we know that the world is vast, majorly huge, dynamic, awesome place. The things that work for me may not work for somebody on the other side of the world. The things that I do may not be relevant. But we're going to find that human connection. We're going to continue to say, well, wait a minute. How can we optimize for any human anywhere? How can we help take all these differences but doing them in a repeatable pattern. So like for me that's exciting is these toolsets that we've been working on for years, are now going to put put in people's hands that never thought they could. And that is exciting. And like to see to see the rise of just creativity is what really makes humans special because we build and make >>and the fact that it's more inclusive now becoming more inclusive on all aspects of inclusive whether it's individuals and coders types of code. So uh integration is the new normal right integrating in uh data control planes, all that goodness coming in because of the ease of use of developer experience. Super awesome. Um dana you're awesome. Great to have you on the cube and sharing your energy and insight. Great call outs on many topics. A lot of gems being dropped. Their thanks for coming on the cube. >>Well thanks for having me. It's been awesome and doctor comes been great. I can't wait to see the rest of the show. >>Dr khan 2021 Virtual real life coming back maybe in physical next year or hybrid for sure. Just the cube coverage of Dr khan 2021. I'm sean for your host. Thanks for watching

>>Welcome welcome back to the cubes coverage of dr khan 2021. I'm john for a host of the cube. We're here to talk about observe ability in the enterprise, enabling developers. Fabian lang VP of engineering and co founder of Istana, now part of IBM. Fabian, Congratulations on everything and great to have you on the cube here for dr gone. >>Thank you. Thanks for having me. >>So I'm in Palo Alto, you're in Germany were doing the remote thing obviously virtual second year in a row for dr khan. Soon real life is coming back. Uh no real impact of developers as they continue to be more productive than ever. The hottest conversation topic being discussed, being funded by venture capitalists and private equity is observe ability. This is an area you guys are playing in aggressively and you got some product observe ability. What's the big deal about Docker con Docker containers observe ability kubernetes, Why is observe ability at the center of all these conversations and the center of the value. >>So observe ability basically means you understand what's going on and today it's more important than ever to understand what's going on because there is so much more going on. If you think back five years maybe before Dr even was featured prominently, you had very little things that you needed to control that you need to understand and then micro service and coordinative became more popular and became really more important to understand what all those moving parts are doing. And that's where observe ability was born out of what we have been doing before at that time it was called application performance monitoring A PM. It's now called observe ability. It's really understanding all those parts of your architecture, of your stack of the application and in the end of the end user experience, you want to know if a user is experiencing a slow service and what's the reason for that? Because today, so many things are moving so many things that maybe even outsourced into cloud providers, it's more important than ever to know what's going on. >>Well we're here at Dunkirk on 2021 virtual. I want to get you to take a minute if you don't mind explaining to the folks why Dr and Dr Khan is important to Astana. >>So I, I said we were founded like six years ago and at that time Doctor was the rising star. It was promoting a lot of new technology. It was giving developers new abilities to develop applications in a very agile away. Microservices were enabled by Doctor before you had to deploy those things somehow it was a city Rome and then you needed to install >>debian >>package but with microservices you have so many more things to install. So it was really, I would say instrumental to the success of microservices to have a platform like docker that was really the next gen of technology that helped to enable those applications. And for us it was really an important driver to understand the whole stack, the traditional tools where eyes are oriented to infrastructure monitoring. So you understand the quality of your host if it's running slow or to look into application of an application was throwing errors but everything was disconnected and unique functionality of Astana is to connect all those bits and pieces of the application together and for that containers. And now kubernetes is a really important part to understand because it is part of this whole picture. >>Did you talk about the problem that you guys solve? Um obviously with those availability, I mean the general concept, we kind of get that great, great overview on your part, but when you start to get into devoPS teams, you start looking at def sec off, start looking at cloud native applications. I see Docker containers provides all that goodness and kubernetes, orchestration, etcetera. What problem do you guys solve? And um what's the benefit? >>The main problem that in stana solves is getting all this understanding that I said is required to provide a good experience of to your users, to your end customers uh without requiring you to do all the instrumentation work or the capture and configuration work because in stana is very automatic, it automatically sees all the works lords that are running in your communities, for example, that are running in Dr containers, but it also connects to legacy databases, fully automatic. So no configuration required also means that with a high rate of change that some of those applications hard have is that we will see all those change happening in real time. And you can't forget to make a configuration to enable your observe ability. So it's really return of investment on the viability solution that we provide and we provide a lot of this insight uh that you can get and that enables you to provide better service for your users. >>So you guys aren't just a doctor monitoring service and company, you guys actually run on Docker. Right, is that true? >>That's correct. So we are not only monitoring doctor and all these things connected to applications, but we are running on a doctor or platform as a service. SaAS software as a service. We run for you so you don't need to operate and stana, we are running it on managed kubernetes clusters and uh, IBM cloud and amazon cloud in google cloud. We have all that and it's it's all running on docker containers and that gives us so many features that are really great with DACA. So all the configuration that specific to microservices are being baked into the images and you can just roll it out, especially for monitoring products that is dependent on the data, that the performance depends on the data our customers send. Um, these ease of scalability with doctor is just so much bigger than it would be with a traditional deployment type. We can just add worker notes to our cluster and have ports auto scale to new notes and this is functionality that wasn't there before and that's great and that's important, essential for our business. >>You know, one of the conversations that's being talked about here at dr khan and in the industry at large is this idea of happy developers and everyone wants to keep developers happy. I've been hearing that conversation, have many chats with folks, you know, productivity and innovation, um but productivity and happy developers of the concept, but also, you know, on the, on the business side or on the developer side, it's more accelerated pipeline. Right? So, so how do you manage to flow, keep that productivity going, But also enabling happy developers, what do you guys do to help there? I mean what if someone asks you, hey, how do you make my developers happier and accelerate my pipeline? >>Well, that's really dependent on what makes the developers happy. I think most developers really want to get their functionality. They are working on their passionate about into production into the hands of end users. So um, skipping out a lot of the manual configuration work that's boring and not really appealing to develop us, helps everything is pre packaged and configured automatically. So that's a big, big plus. And the standard monitoring as I said, uh, is also automatic. So you don't need to configure it, your, your application on how to monitor it. So developers can just focus on delivering features and whenever there is something we will tell them, I think they enjoy that >>innovations creates great, that's a benefit. Can you talk about the on prem version of installing a, that's something that you guys are talking about and featuring um what is that about? Can you take a minute to explain beyond prem version of in Astana for dr containers? >>Yeah, it's a, it's an interesting topic, especially at the conference like dr khan, where it's all about virtualization, container realization and going into the cloud, that there are still companies, enterprises government mental entity that are very heavily invested on an on premise solution. They want to have control or are legally required to have control over what they have been deployed. So we knew when we founded in Astana that our solution, unlike our competitors, can't be only software as a service. We want to have a fantastic software as a service product and experience, but it should be equally good on premises as well. And when we were looking at ways how to actually do it, how to deliver an architecture that a little bit complicated to on premises customers to have themselves as the solution. We saw that doctor solves a lot of problems for us. We don't need to manually petra around operating system that customers, we don't have different versions of packages installed. It's all the same and actually it's not only all the same for all the deployment of all our customers, but it's also the same technology that we run as a software. As a service customers can run it now on their own. So we have feature parity, it's not lagging behind and this is also ease of support for us. >>So why was it, what was the motivation behind that was just customer demand? Um, more efficiency? What was the motivation behind moving on, supporting the on prem version? >>Uh, so for a start up, it's all about addressing the market share. Right? So you wanna have everything you can get, you don't want to spend any extra money on it. And as I said, the enterprise market is big. There are still many players that want to have the data in house. This is potentially sensitive data that's being tracked. So an on premise solution having, it was really instrumental to the success of in Stana because we were able to target and help those customers even in a fully adapt scenario, for example where they don't even have internet access. >>Take me through the process of DACA rising the product sitting on prime product that you get the thing going on there, like okay, let's do this. What does that look like? How did that work out? >>So as I said, we looked at this from the beginning and we picked DACA as a technology from the beginning, so there wasn't really like a shift and left type of scenario that other customers might be having. We were doing it from the beginning and we were aligning our architecture so that there are no fundamental differences between an on premise solution and anti size solution. That's of course configuration, that's different. But that configuration we just put into a single configuration file and that turned out to be a great idea because this is how you nowadays configure your application kubernetes, you'll make a customer resource for example, and then have an operator run the product, any kind of product, but also in stana, you run on premises with an operator that just works on the single configuration that you give it. And this is actually great because our customers are used to operating products like that, their own software, everything customers are running in dhaka in kubernetes, they are used to operating it that way. And that helped us because our customers now get the same functionality that we offer as a, as a service on premises very easily very quickly. And that make them happier. We talked about developer happiness that makes them happy because now they are not lagging behind but it also enables us to give better quality support, lot fixes faster and helps us to no longer support very old presence because they don't exist. They are frequently updated. I think this is really a benefit of container realization is also how easy it is to upgrade because you just stop apart and start a part in the new version and then you have a new verse. >>That's also great insights may be great to chat with you on that. I got to ask you on a personal note, you've been in the industry for a while and your leader, um you know, that's a performance geek, you'll have to build fast code. I was been chatting with other VPs of engineering and we were talking about the shift in engineering and with devops you've got kind of s our reaction, you have some just straight up application coding, just modernize that cloud native applications and you've got a kind of under the devoPS as the world's shifts. It seems like there's more of an architectural systems engineering approach or a systems mindset and that seems to be changing the mindset of a developer from Iterate fast. And then the line I heard was you can iterate and pump out code fast, but it might not be good, might be crap. So, so this notion of iterating code and crafting good product because with now this module Ization with containers, you're doing a lot more design work. So craft seems to be coming back to coding. Uh, I don't think it's coming back, it's been there, but it just seems more of like, hey, let's do this, right? And it's not just ship code. What's your take on that? >>So I think this always was there. It's just that traditionally companies approached software engineering similar to how companies approach manufacturing. So somebody writing a designs back and somebody verifying it and then it's going onto the line to mass production. But software doesn't work that way. We make way more changes, it's way harder to understand it up front. So the developed the iterative and exile development that has been ongoing is really, is really what people want and develops well. There is this notion of being a being waking up in the middle of the night and that's what developers don't want. So you need to prepare your application, you need to make it resilient against that. And developers are very eager to build in functionality that helps them to troubleshoot to make their application available. With a high rate of change. There is a high rate of risk as you said and I think the ability to deploy 1000 times per day is great but you don't necessarily need to do that. I think it's also important for your users that you find the right pace of when you deliver functionality and when you deliver fixes. >>I was just talking to a friend the other day and we were just talking about organizations and teams and yeah, we always riff on the the two pizza team or having more agility and you have this democratization because of the agility is also a benefit for any developer to add value if they have the right perspective or creativity. But it kind of disrupts the kind of the old way of thinking. I'm the principal engineer is my job. No, I'm the chief architect. So you have these titles and you have roles, the roles are changing and sometimes just the arguments. Oh wait, that's my job is that I'm this kind of changes. What's your thoughts on, how do you manage that dynamic? Because as you have more, uh, I won't say surface here more democratized engineering with virtual teams and whatnot You have compose ability with, with with code. You have more of a systems are a lot more going on. It's not your standard engineering mindset. What's your thinking on this as a leader in engineering and visionary? >>Well as we know the architecture of a software full of the organization that the company has. That creates. All right. So I think what you want when you want to have a micro service architecture, you want to have a micro service teams. You want to have teams, we call him at and standard delivery teams that work more or less independently on a certain set of features and are responsible for them and to end. So my engineers, they are talking to our customers figuring out how to make a feature better. They are then designing this with our user designers and then they are developing and deploying it and this really entry and responsibility. And we don't really have those titles like architect anymore. I think those roles are still there but it's more like a shared responsibility. So you of course want an architecture, you want to have your components talk to each other in an efficient way and it's more really communities of practice that are establishing. So you will find out that you have people and your teams who have specific skills who like to work on architecture. Some of them like to work on continuous delivery systems And then you you form those cross functional teams dynamically and when it's no longer hit this bands. And I think that's a major difference to assigning a person to a road. >>Yeah and and also that with you have new trends like observe ability, enterprise observe ability you know new things are happening um And new net new things like new architecture and also new roles and responsibilities. I'll see new patterns to with the data you have services being stood up and turned down all the time. You have a lot of dynamic environment. So you know having a happy developers one eliminate the manual work what you do but also giving them good work assignments to work on some good hard problems. So what is what are those hard problems that engineers like to work on these days? Is it like design? Is it coding? I mean I know it depends as you mentioned on the personalities but generally speaking as dev ops def sec Ops becomes much more of an agile edge hybrid play. What's the hard problem? >>I think big data is not really a new term but I think this is still a very interesting territory because you can apply various aspects to it. You have this data science aspect to it to understand how to detect pattern in it. And then automation is actually artificial intelligence. Right? So you automate data science and that's very interesting because those are large scale problems and new problems and new solutions. So yes there are existing frameworks but there's so much innovation to be found and making this work efficiently is another dimension of the same problem. That's also not easy and challenging problems. Make developers happy and then you can even have people think about the financial aspects. So it should also be cheap Big data and AI is usually very expensive because it requires so much hardware. So not only tried to make it fast but maybe even make it efficient. So this whole domain is very appealing. There is new technology to be invented, tough problems and I think that's really exciting to developed. >>Fabian Lang, vice president of engineering co founder and stand a great to have you on the q Great insight. Thank you for sharing that knowledge there. And the overview of installing here at dr khan observe ability very relevant for next gen next level solutions. Thanks for coming on the cube. Right, okay. I'm john Fury with the queue here. Dr khan 2021 coverage. Thanks for watching. Mm.

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

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