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

>>And welcome to the DockerCon cube cover here on the main stage. So HIRA RA development manager at J Frogg. Welcome to the cube. You guys have been on many times, uh, with J Frogg on the cube, great product you guys are doing great. Congratulations on all the six. Thanks for coming on the cube. >>Thank you. Thank you for having >>Me. So I'm really interested in talking about the supply chain, uh, package management, supply chain, and software workflow, huge discussion. This is one of the hottest issues that's being solved on by, with, with in DevOps and DevSecOps in, in the planet. It's all over the, all over the news, a real challenge, open source, growing so fast and so successful with cloud scale and with automation, as you guys know, you gotta ha you gotta know what's trusted, so you gotta build trust into the, the product itself. So developers don't have to do all the rework. Everyone kind of knows this right now, and this is a key solve problem you guys are solving. So I gotta ask you, what is the package management issue? Why is it such an important topic when you're talking about security? >>Yeah. Uh, so if you look at, uh, look at how software is built today, about 80 to 90% of that is open source. And currently the way we, the way we pull those open source libraries, we just, we just have blind trust in, in repositories that are central, and we rely on whatever mechanism they have built to, to establish that trust, uh, with the developer who is building it. And from, from our experience, uh, we have learned that that is not sufficient, uh, that is not sufficient to tell us that that particular developer built that end product and, uh, whatever code that they build is actually coming out in the end product. So we need, we need something to bridge that gap. We need, we need a trustworthy mechanism there to bridge that gap. And there are, there are a few other, uh, elements to it. >>Um, all these center depositories are prone to, uh, single point of failures. And, you know, in, we have all experience what happens when one of those goes down and how it stops production and how it, how it stops just software, uh, development, right? And we, what we are working on is how do we build a system where we, we can actually have, uh, liquid software as a reality and just continue to build software, regardless of all these systems of being live all the time, uh, and also have a, an implicit, uh, way of mechanism to trust, uh, what is coming out of those systems? >>You know, we've talked with you guys in the past about the building blocks of software and what flows through the pipelines, all that stuff's part of what is automated these days and, and, and important. And what I gotta ask you because security these days is like, don't trust anything, you know, um, here it's, you're, you're trusting software to be in essence verified. I'm simplifying, obviously. So I gotta ask you what is being done to solve this problem, because states change, you know, you got data, you got software injections, and you got, we got containers and Kubernetes right here, helping all this is on the table now, but what is currently being done to solve the problem? Cause it's really hard. >>Yeah, it is. It is a really hard problem. And currently, right, when we develop software, we have a team, uh, which, which we work with and we trust whatever is coming out of the team. And we have, we have a, um, what do you call certified, uh, pro production mechanism to build that software and actually release it to our customers. And when it is done in house, it is easy because we are, we control all the pieces. Now what happens when, when we are doing this with open source, we don't have that chain. We need that chain, which is independent. We just independent of where the software was, you know, produced versus where it is going to be used. We need a way to have Providence of how it was built, which parts actually went in, uh, making, uh, making the end product. Uh, and, and what are the things that we see are, are, are, uh, continuing, uh, uh, continuing evidences that this software can be used. So if there is a vulnerability that is discovered now, that is discovered, and it is released in some database, and we need to do corrective action to say that this vulnerability associated with this version, and there is no, there's no automated mechanism. So we are working on an automated mechanism where, where you can run a command, which will tell you what has happened with this piece of, uh, software, this version of it, and whether it is production worthy or not. >>It's a great goal. I gotta say, but I'll tell you, I can guarantee there's gonna be a ton of skeptics on this security people. Oh, no, I don't. I doubt it's always a back door. Um, what's the relationship with Docker? How do you guys see this evolving? Obviously it's a super important mission. Um, it's not a trend that's gonna go away. Supply chain software is here to stay. Um, it's not gonna go away. And we saw this in hardware and everyone kind of knows kind of what happens when you see these vulnerabilities. Um, you gotta have trusted software, right? This is gonna be continuing what's the relationship with DockerCon? What are you guys doing with dock and here at DockerCon? >>So we, when we actually started working on this project, uh, both Docker and, uh, J frog had had similar ideas in mind of how, how do we make this, uh, this trust mechanism available to anyone, uh, who wants it, whether they're, whether they're in interacting with dock hub or, or regardless of that, right. And how do we actually make it a mechanism, uh, that just, uh, uh, that just provides this kind of, uh, this kind of trust, uh, without, without the developer having to do something. Uh, so what we worked with, uh, with Docker is actually integrating, um, integrating our solution so that anywhere there, uh, there is, uh, Docker being used currently, uh, people don't have to change those, uh, those behaviors or change those code, uh, those code lines, uh, right. Uh, because changing hand, uh, changing this a single line of code in hundreds of systems, hundreds of CI systems is gonna be really hard. Uh, and we wanted to build a seamless integration between Docker and the solution that we are building, uh, so that, so that you can continue to do Docker pro and dock push and, but get, uh, get all the benefits of the supply chain security solution that we have. >>Okay. So let's step back for a minute and let's discuss about the pro what is the project and where's the commercial J Frogg Docker intersect take that, break that apart, just step out the project for us. What's the intended goals. What is the project? Where is it? How do people get involved and how does that intersect with the commercial interest of JRO and Docker? >>Yeah. Yeah. My favorite topic to talk about. So the, the project is called Peria, uh, Peria is, uh, is an open source project. It is, it is an effort that started with JRO and, and Docker, but by no means limited to just JRO and dock contributing, we already have five companies contributing. Uh, we are actually building a working product, uh, which will demo during, uh, during our, uh, our talk. And there is more to come there's more to come. It is being built iteratively, and, and the solution is basically to provide a decentralized mechanism, uh, similar to similar to how, how you, uh, do things with GI, so that you have, you have the, uh, the packages that you are using available at your nearest peer. Uh, there is also going to be a multi load build verification mechanism, uh, and all of the information about the packages that you're going to use will be available on a Providence log. >>So you can always query that and find out what is the latest state of affairs, what ES were discovered and make, make quick decisions. And you don't have to react after the fact after it has been in the news for a while. Uh, so you can react to your customer's needs, um, uh, as quick as they happen. And we feel that the, our emphasis on open source is key here because, uh, given our experience, you know, 80 to 90% of software that is packaged, contains open source, and there is no way currently, which we, uh, or no engineering mechanisms currently that give us that, uh, that confidence that we, whatever we are building and whatever we are dependencies we are pulling is actually worthwhile putting it into production. >>I mean, you really, it's a great service. I mean, you think about like all that's coming out, open source, open source become very social, too. People are starting projects just to code and get, get in the, in the community and hang out, uh, and just get in the fray and just do stuff. And then you see venture capitals coming in funding those projects, it's a new economic system as well, not just code, so I can see this pipeline beautifully up for scale. How do people get involved with this project? Cause again, my, my questions all gonna be around integration, how frictionless it is. That's gonna be the challenge. You mentioned that, so I can see people getting involved. What's what's how do people join? What do they do? What can they do here at Docker con? >>Yeah. Uh, so we have a website, Percy, I P yr S I a.io, and you'll find all kinds of information there. Uh, we have a GI presence. Uh, we have community meetings that are open to public. We are all, we are all doing this under the, uh, under the umbrella limits foundation. We had a boots scrap project within Linux foundation. Uh, so people who have interest in, in all these areas can come in, just, just attend those meetings, uh, add, uh, you know, add comments or just attend our stand up. So we are running it like a, like a agile from, uh, process. We are doing stand up, we are doing retrospectives and we are, we are doing planning and, and we are, we are iteratively building this. So what you'll see at Dr. Conn is, is just a, a little bit of a teaser of what we have built so far and what you, what you can expect to, uh, see in, in future such events. >>So thanks for coming on the queue. We've got 30 seconds left, put a quick plug in for the swamp up, coming up. >>Yeah. Uh, so we, we will talk a lot more about Peria and our open source efforts and how we would like you all to collaborate. We'll be at swamp up, uh, in San Diego on May 26th, uh, May 24th to 26th. Uh, so hope to see you there, hope to discuss more about Peria and, and see what he will do with, uh, with this project. Thank you. >>All right. Thanks for coming on the back to the main stage. I'm John cube. Thanks for watching. >>Thank >>You.

>>Okay, welcome back to Docker. Main stage is the cube coverage of DockerCon 2022. I'm John FRA host of the cube. We're here with a special segment with sneak. We've been partnering with Docker going back to the early days, Nate cloud native container vulnerability scanning within Docker desktop in 2020. We' it Mick McCulley field strategist sneak Mick. Thanks for coming on the cube. >>Thanks for having me glad to glad to be here. Excited to have this, this, this conversation. >>Yeah, love the background. Got I. Big football fan myself, and love that little mention. There love the sneak logo too. Good, good plug there. Uh, but I want to get into that. The security you guys were of the first conversations when shift left was hot, when it just started to come and it's never going away, but now there's been a huge focus and an increase of concerns around vulnerabilities, uh, within and within the supply chain of security software. So in open source software. So what are you guys doing now? Cause this is a new focus in the industry. Everyone's talking about it, your company's making changes and mitigate that risk. What do you guys have? >>Yeah, that's, it's, it's a great question. And, and shift left is definitely a big focus of ours, right? It's it's what sort of our core foundation is what we based. Um, our whole approach to software supply chain definitely has made its way to the top of the spectrum as far as conversations. And I think it plays very well into our focus. Um, you know, one of the things that, uh, I believe a lot of organizations are focused on is trying to get a hold of understanding a lot of the implicit trust and risk associated with everything that goes into building any sort of modern application. And that's all of the components that are being used. Everything from the open source to the containers that are consumed to the process, into all of the ecosystem and tooling, that's consumed a lot of the trust layers in there. It's, it's extremely important to understand what that is. What's, what's the risk, right? And from a sneak perspective, taking that, that intelligence and trust and giving it back to the developers when they're making these decisions, is, is our focus like that, that whole concept of taking all of that security expertise and pushing it back to the individuals, making those decisions, I think is probably one of the more powerful ways that you can start to implement some more security controls and get some trust and understand your risk process, um, throughout that software supply chain. >>Okay. So you said trust three times, I'm gonna come back to that because shifting left is all about empowering developers, but what good at shifting left? If you gotta stop and then go back and research something that, that wasn't in your pipeline or something else happened. So open source obviously is growing like a weed it's continuing to exponentially grow and more people are doing it commercialization as well, but the word trust is not zero trust. You're hearing, people's use the word zero trust security, that's different, right? They're talking about developers looking for trusted code. So it's interesting, you got hackers and, and zero trust and you got developers and trust and you got software in between. This is kind of the, kind of the core issue here. Isn't it? >>It, it is, um, because of that using, I mean, there's, there's huge advantages with all of these new approaches, right? Leveraging the open source and the containers and the, and the software packages and these ecosystems to automate a lot of those software processes, but doing so means that you've got this implicit trust that's there. And so, um, taking and trying to identify and, and, and share those details with the developers when they're making those decisions, but it doesn't stop there, right? Like that's, that's one of the other important aspects of this is what organizations have to do is to not only provide that and help those individuals when they're making those decisions, but then constantly understand if that posture changes at any given time, right. And knowing where it's happening, what is it, how do I prove and have some of the Providence details of the origination of the information, how can I trust to make sure that the security was, uh, accounted for, for all the components that I'm actually leveraging and using, and then making sure that you have that visibility through that the entire life cycle. That's probably one of the other important areas. So it's not only sort of giving that information in details and trying to take advantage of all of that, that early detection response and decision making process. But it's also maintaining that understanding of what that is, and that trust plays into that, right? There's so much implicit trust associated with it. And the more that you can understand it, comprehend it, take control of it, the better your organization from a security posture's gonna be, >>Yeah. I mean, you got builders and attackers. I mean, it's clearly the spectrum and the builders want the a hundred percent trust. Um, and I think this is gonna be such an important game changing topic that has to be addressed. It's the only way with the scale you're seeing in the growth of software. And by the way, open source become much more than just open source it's community. It's social people kind of hang out and build code together and then ventures are being started over. So this is a nice progression. Makes a lot of sense. I have to ask you though, on what are some of the what's some of the data say on the attacks, is it increasing at what rate what's the complexity look like? What's it look like as it evolves, because, you know, even though it's zero geo trust on one side and trust on the other, the attackers also adjust too. >>Yeah. >>So >>What's, that's, I think it's the staff. >>It's >>A very, yeah, it's a very good question. I think that's what we're seeing is, um, and this is just a natural evolution. I think there's been, you know, an historic focus on a lot of the security associated with, with running applications and locking them down. And I was reading blog just by Docker the other day about how it's like this hardened sort of outside layer, but there's this soft squishy inside that soft squishy inside is all of those building components that are inside of there. And because of that hardened layer, it, it makes those attack vectors a little bit more difficult, right. When you're trying to, to, to penetrate those. And so what we've seen is this natural evolution is say, well, let's go find the weak link. Let's go understand if there's a way to actually bypass these security controls. And sometimes the ways to do that is to simply go into the process in which the application's being built. >>If I can go upstream and actually change some of those components and implement my attack inside of the application, it automatically gets embedded instead of trying to attack it directly. And so we're seeing that, and, and it's, what's banking a lot of the news and why some of the conversations around software supply chain are becoming very prominent, it's this ecosystem. And, um, unfortunately, you know, in a lot of organizations that, that I think some of that development area hasn't had that security focus as a lot of the traditional areas associated with applications and exposure of your organization, because of that it's left a little bit more exposed, right? That, that trust that we talked about in addition to the processes has to have a little bit more of that security ingrained inside of those processes to make sure that it's not being left open. It's not an open door, an open window that's giving sort of an easy route into the application. >>Yeah, totally. I totally see that in the next, in the last couple minutes we have left. I want to get into what you guys are doing with your customers and what our company's doing to mitigate the risks in the software supply chain. Obviously open source is not going away. It's only gonna be part of it what's going on with the customers. >>Yeah, it's, it's a great question. And a big focus of ours is to, um, help organizations understand all of those areas as much as possible, right. And to provide them that guidance. And part of this is not only the solution and how we deploy it and how we can deliver it, but it's some of the security intelligence associated with it instead of putting the burden on our customers of trying to stay on top of all of that risk. Right? What, what, where is all of these different moving parts and something changes from being completely fine one day to, you know, a high vulnerability and risk posture. How do you react to that? And so providing as much of that insight, guidance and prioritization and the details to those organizations in, in an actionable format, um, that's probably one of the more core elements to this. >>It's not just the, Hey, here's a whole list of all your problems. It's what do you do? Like how do you take all of that information, those details, those risks, how do you prioritize them? How do you then what, what's the steps that you take from an action perspective in order to address those, right. If I've got a container with some problems, what is sort of the recommended approach to solving that? What should I upgrade to? What is the guides associated with those? And so a lot of it is focused on providing not only the insight and the ability to react and understand that risk at any given time, but also more focused on what do you gotta do, right? How do you actually take steps to alleviate or remediate that risk as much as possible? Can't not, that's >>The point what's so I gotta have to ask you, what's the difference between getting it right and getting it wrong, or in other words, why do some, um, supply chain vulnerable remain fixed, uh, unfixed and, and deprioritize? What's the, why isn't it going faster? >>Yeah. And, and some of that there's there's reasons across the board, right? Some of it crossed from the perspective that there, there might not be fixes. And so in some of those cases, just being aware of what that risk is. So you can put in other mitigating controls in order to accommodate those. In other cases, it's, it's prioritizing where your risk is most important, right. And part of this also stems from the fact that I, if you fall into sort of that reactionary bucket, then, then you have to be in sort of that prioritization reactive mode. The more that you can push this back to that early process, the less that that has to occur, because you have the ability to actually make the best decision possible with the information you have during that early process. So some of it's just, you know, predicated on the fact that there's not always solutions to all of the problems. Um, and then a part of this too, is where in the, where in the phase are you actually starting to attack and handle it? >>All right, Mick. Thanks. So for coming on, really appreciate it. Business is good at sneak. Thanks for sharing your insights here on the, on the main stage. Okay. This is the queue back to the DockerCon main stage. We'll be back more. See you soon.

(upbeat music) >> Hi, everyone welcome back to theCUBE's main stage coverage of DockerCon 2022. We got a great guest from Intel here, Ajay Mungara Senior Director of Edge Software and AI at Intel talking about cloud native and AI workloads at The Edge and building a better developer ecosystem for The Edge which we all know those where the actions going cloud native, compute data, data as code. These are things we've been talking about, so Ajay, welcome to theCUBE. >> Thank you, John. I'm really happy to be here in DockerCon and everything we do Docker makes it better. >> Well, you guys have done a lot in your career and looking at your background, The Edge was manufacturing the old school IOT stuff. Now that's converged completely in with cloud native IP technologies. Everything's kind of happening now at The Edge. This is where the problems are now shifting in solving because of the goodness of the cloud and what that's done for cloud operations which essentially distributed computing is making The Edge the battleground for where the innovation's happening. Could you just share with us your view of why The Edge is so important and why it's different than what we've been seeing in pure cloud on and on premise data centers? >> Yeah, you know 75% of the data that is getting generated of late is happening at The Edge. Okay, so there's a lot of value, there's a lot of value that's getting generated at The Edge because most of the compute we want to move it where closest to the data because of latency issues, bandwidth issues, security issues all of those things is getting people to move compute storage data towards more at The Edge. There's also one big shift from a developer point of view where 51% of all of the developers in the world have deployed in somewhere the other cloud native Docker based solutions out there, okay. What we are seeing is the combination of cloud computing, networking, edge computing all of that coming together. And that is where it is pushing the envelope from The Edge perspective. And one of the big drivers is AI at The Edge as well, right. The Edge inference workloads that is really happening with camera as one of the sensors is really driving that compute. And your question about what's so different about it. The challenges at The Edge are compounded because it's bringing together the operational technology, the information technology processes and cloud computing environments along with networking all together. So when a developer wants to build a solution for The Edge they have to figure out what part of that workload sits in the cloud, how they're going to move that workload towards The Edge using some form of networking. How are they going to protect the data in transport as well as at rest, because Edge devices can get stolen, you know. So there is all of these challenges about like how do you like figure out the trade offs between price, performance, functionality, power, heat, size, weight everything matters when you talk about The Edge. So anyway, that is why we see those differences. >> It's interesting you know you do a little go back in history and distribute computing, the movies still the same. Remember back in the day when I was breaking into the business memory was the bottleneck and storage was the resource. And you had to swap out memory, and as a developer you had to deal with that. Then memory became abundant and storage was the problem. Now you got networking is the latency problem. So again, these are a challenges that developers have to weave through, I was going to ask the question of why is The Edge important for the and what's in it for the developer, why should they care about The Edge? And I think what you were saying is there's design decisions going on around how to code, can you elaborate on what's in it for the developer? Why should they care about The Edge? >> Developers have to really care about The Edge is because when you are really building a solution you cannot move the data and make all the decisions at the cloud because it's late, right, sometimes latency, your bandwidth costs, your solution costs are going to get increased. And because of security and privacy concerns sometimes you have to make those decisions at The Edge itself. You will have to figure out only take the data strategically to the cloud where it makes sense, okay. And that is the reason why developers have no choice but they have to focus on the combination of cloud networking and edge, and that's where we are seeing a large scale set of deployments that are happening today. >> Yeah, and I can see the business value too which is one of the big themes that DockerCon this year is tracks on that people talking about that. Are you seeing trends like headless retail, which is basically, it's not Shopify managed service, it's more of you build your own stack and you put the head on there which is the application and business model. >> Right. >> So again, that's an example. There's also the manufacturing, there's automotive all kinds of use cases where there's money making opportunities, right. So there's business value there, so the developer's going to be pulled to The Edge 'cause they're in the front lines now. So this is about making The Edge ready, and I want to hear your thoughts on what Intel's doing to make that developer environment ready for The Edge because we know the developer on the front lines today and that front line vanguard will be The Edge. What's it look like? >> Exactly, right, so what we have done is we have created this environment for developers which we call it as IntelDevCloud. And in this dev cloud which is Kubernetes based environment where we support all of the Docker workloads and it's based off of Red Hat OpenShift. And we thought about this a little differently. What we did is it's a cloud environment where you could use a browser to do all of your development build test and all of that. But we also took a whole range of these edge devices and we made it available in the cloud. So as a developer, you don't have to have an edge device sitting at your desk. You have an edge device or a plethora of edge devices sitting in the cloud. So you have one environment where you have cloud, you have network, and you have all these edge nodes. So you could start building your solution, you could start building your cloud native or edge native solutions, test it, benchmark it, and figure out how and what type of combination that you actually need for your final solution as you said in retail, in smart cities, in healthcare, any of these vertical markets and get your solution closer to being a deployment ready. >> Yeah, and I love your description by the way it's called a container playground. I mean, it's just comes across as fun. And I think this idea of having these nodes available you guys bring a lot of expertise at the table. That's almost like your local host for Edge devices, right? You can work with it in a safe environment, am I getting that right. >> You're getting that right, and in fact, during the pandemic when we are all working remote, right, nobody has access to these labs where you have all these Edge devices available to you, you could actually play with all these network simulators everything. Now with dev all these developers spread all over the world, you don't have access to as many of those edge devices. So now with browser, with this container playground, you could develop any of your Docker composed, Docker based container workloads and try it on all of these edge devices which may range from an Intel's point of view, CPUs, VPUs, GPUS, anything, right. >> We know there's a lot of compute at The Edge which always ever helps in Intel but your north star is about making it easier for the developers as you guys invest cloud network and The Edge and the cloud native world, that's the goal. How do you do that? And what should the developers optimize for it sounds like they're going to learn with this playground that you have the dev cloud. What are you seeing that they're going to learn to optimize for? Is it like I use the oldest school example of memory optimization, swapping memory out and that kind of thing but what's the new issues that need to be optimized for your developer. >> If you're a developer you got to optimize for your edge AI workloads, right, so that means AI inference workloads. You have to look at like saying that how can I take like a model that is developed in a some type of a cloud environment, like a TensorFlow model or a Pieto model, bring it down to The Edge. And then you have to do inference workloads. You need to understand to do this inference, what type of compute you need, what type of storage do you need? What type of memory do you need? And we give you those options where you could optimize those type of inference AI, inference workloads, you could actually do that. Then you also can decide like what type of decisions you want to make at The Edge what decisions you want to make at the cloud. We give you those options and flexibility for you to build those solutions. >> Great. >> One last point I'll make is there's a lot of legacy applications that have been developed which is traditional embedded applications. We are also want to teach developers how to take these applications and containerize them. How to take advantage of the cloud native DevOps type of paradigms that it would make your life easier when it comes to scaling your solution, deploying your solution worldwide. >> All right, Ajay, thanks so much for coming on theCUBE DevCloud, a container playground. Now back to you at the main stage at DockerCon. (upbeat music)

>>Welcome to the cubes dock, our main stage coverage here at DockerCon 2022. I'm John furrier, host of the cube. We're here with cube alumni, a partner scene, the senior director of product and the developer platform at Google cloud, a partner. Great to see you. It's been a while how's things >>Great to see you, John. Thanks for having me. >>So obviously we've covered a lot about the Google's history and open source. If you go back, I mean go back generation 2000, it all started, it continues to continue to thrive the SDO, all the different projects you guys are around the future of containers and serverless all there. Give us the update. Why are customers choosing Google cloud? We're here at Docker con what's the big update from Google cloud's perspective from a, from a developer perspective? >>Well, John, uh, Google cloud has been, uh, the early cloud on containers, um, and by all measures from, we can, from what we can see, you know, it is the preferred cloud for container native workloads. Um, I think why our customers choosing cloud there's a, there's a few different reasons. Um, definitely one of the reasons is because it is a flexible and open platform. And I think that that is, uh, distinctive about Google cloud, as you mentioned, uh, many, many open source projects coming from Google and Google cloud in particular over the last 20 years, um, spanning, um, languages, um, you know, obviously, uh, the go programming language all the way to of course, Kubernetes. Um, and then, uh, more recently Isto and, uh, K native and many more, uh Tecton is one of the leading projects as well. Um, in the C I C D space. >>So I think that, uh, history is something that really attracts the developer population. It's also very, very important for enterprises that are, uh, modernizing and looking to accelerate their, uh, developer productivity. So that's been one major reason. I think the second major reason is really the security aspect, um, of the developer tool chain and in particular related to open source secure well, and I think the third, uh, reason that comes out, um, quite frequently when we, when we talk to our enterprise customers is Google cloud is unique in the multi-cloud space. Um, you know, one of the first, I think probably the first and, uh, only cloud provider to have a very strong multi-cloud strategy, uh, and that stems from the open source roots, but also, you know, uh, bringing more than just, uh, compute, bringing many of our data services also, uh, to the multi-cloud space. I think that's, those are the three reasons why, uh, developers often choose Google cloud. >>Yeah. And you see the multi-cloud also in a distributed computing environment. It's, I mean, multi-cloud is basically distributed computing where you've got hyperscalers and then edges emerging very quickly. Of course, we've talked about that in the past, on previous interviews, how security at the edge software opensource all coming together. Again, Kubernetes launched by Google contributed to the open source world that everyone knows that, or may not know that. Um, but, but that's key. Where do you see the container position come in? Because at the end of the day, containers is standard and now you've got Kubernetes and other parts wrapped around it. Where's container technology going in the coming, coming in the future years. Is it gonna be invisible? Is it gonna be programmable? What's your vision on that? >>This is an excellent question. And you're exactly right. You're seeing containers become mainstream. And some of the latest, uh, state of the, the state of the cloud business report, you're seeing, you know, 80% of enterprises, um, having some form of a container program and I've been involved in this industry since the very early days. So this is something we've been predicting, um, and it is happening even faster than expected. So that's becoming very mainstream, which is extremely exciting for us. Now you ask, you know, what is the future and what is the evolution of it? Um, so, and, and I think, uh, this is the right question because, um, you're seeing a lot of the future actually on Google cloud. Um, we're, we've won the, uh, Gartner and Forester quadrants as far as leader quadrants in, uh, you know, container offerings. And that's not just Kubernetes, of course, uh, Google Kubernetes engine has been, has been the leading area, but there's a whole host of offerings around that. >>Um, in particular I'd like to point out serverless containers with cloud run, as well as the entire DevOps pipeline around containers. And that's a big topic in the industry right now. It brings in, uh, security as related to, uh, developers. And then of course, uh, you know, providing an automated, secure pipeline for DevOps, um, as it relates to containers, we've had several announcements and, and, and a lot of success in this space. Uh, I, I can go through some of these things with cloud run, which is our serverless container offering. We've seen, uh, four X growth in adoption and, uh, consumption of that service last year in 2021. And that is continuing, uh, so it's very, very healthy and it is very much the reason customers are adopting. It is because they don't need to learn a lot of the underlying infrastructure. They don't need to manage any of the underlying infrastructure. >>There isn't necessarily a cluster to manage all of that is taken care of, uh, for them. And they can focus on their application. They can actually use, uh, make use of the benefits of containers, such as, uh, you know, scalability, um, such as, um, application awareness, uh, and such as a lot of the integrated tool chain for, uh, delivery for application delivery, right from your source repository into production, and then being able to bring out new versions of your application, test them, and then roll over. So this is kind of the new, uh, uh, generation I think is very much tied to the pandemic and what's happening in the world post pandemic, where developers are extremely important, developer productivity and, and fact developer work, life balance is extremely >>Important. Yeah. And I, and I think also one of the things that we're seeing to piggyback on that last comment, as well as your other points is developers have always been pulled to the front lines even 10 years ago. You saw the trend towards getting more closer to the customer now with cloud and edge and with open source being the innovation equation where entrepreneurs are starting projects, companies are starting projects, then they gotta get commercialized. So supply chain is a big discussion. We're hearing at Docker con we're hearing about shifting left of security data as code. You start to see the developer on the front lines in all aspects of this, and they want, they want security, they want efficiency, they want things in the pipeline. They don't wanna have to shift left, then come back again. So again, they starting to see this kind of productivity drive the business behavior of the companies cuz that's their, the value partners. That's the application side of cloud native. What's your thoughts for the developers who are doing that? What's in it for them with Google cloud? Why, why are you important to them? >>Yeah, and I think, uh, John, this is where, uh, developers, uh, tend to prefer Google cloud. And there's a couple of reasons for that. One is, you know, we are very much, uh, centered around developers. Um, you know, my job is, uh, you know, Google cloud developer platform. And, uh, our goal is to provide ease of use the easiest cloud for developers. Something that is, um, you know, really allows them to get their work done quickly. Developers want to be exposed to the best technology. They want to be able to be exposed to it in a way that that integrates into their workflow that integrates into the tools that they're used to, um, and allows them to get their job done quickly. And so a lot of what we're doing in, in the developer space is providing an integrated stack. Um, you know, whether you're building a web application or you're building a mobile application, or you're trying to do data analytics, uh, Google cloud should be a place that you come to. >>That's easy for you to use, to get the job done. Um, and, and, and the security aspect is not something that developers like to deal with. They want that to be taken care of for them, um, troubleshooting as well, you know, troubleshooting and, and upgrading. And all of that is something that they wanna be taken care of. And so that is something that we're baking into the platform. And you'll see that in a lot of our tooling, um, you know, the build process, uh, we're providing salsa compliance, um, and, and build Providence for the security teams to be able to audit. But it's not something that the, that the developer needs to take care of. It's something that is just part of the, the build process built into, uh, say, uh, cloud run or GK built into our compute options for making >>It for them, making it easy, simple, and reduce the steps it takes to get the job done. So great stuff par, great to see you in the last 30 seconds, we have left. Just give a quick commercial for what the key projects are in open source. You're proud of that people should pay attention to, we got CubeCon coming up, uh, in, uh, Europe and north America. What are some of the successes that you like to point out? >>Well, I really encourage, uh, developers to go and take a look, a new look at, go go 1.8, add support for generics. It should open up a brand new set of applications. So I definitely encourage folks to, to take a look at that, um, of, of course ISEO and service mesh. As, as your container footprint grows, you have many microservices looking at service mesh, uh, extremely important, and it also allows you to get to that SRE type of, um, uh, DevOps model where, you know, you're securing your services. You're also, uh, being able to monitor and control, uh, service usage. And then the last one is of course Tecton and this is where secure software supply chain comes up. Part I'll >>Mention that. I wish I had 20 minutes. Love chatting with you. We'll catch up with you later on the cube we're here at DockerCon. Thanks for your time. Back to the DockerCon main stages of the cube. I'm John farrier, back to the main stage for more coverage.

(upbeat music) >> Hey, welcome back to theCUBE's cover of DockerCon Mainstage, I'm John Furrier, host of theCUBE. We're here with Shubha Rao, Senior Manager, Product Manager at AWS, in the container services. Shubha, thanks for coming on theCUBE. >> Hi, thank you very much for having me, excited to be here. >> So obviously, we're doing a lot of coverage with AWS recently, on containers, cloud native, microservices and we see you guys always at the events. But tell me about what your role is in the organization? >> Yeah, so I lead the product management and developer advocacy team, in the AWS Container Services group, where we focus on elastic containers. And what I mean by elastic containers, is that, all the AWS opinionated, out of the box solutions that we have for you, like, you know, ECS and App Runner and Elastic BeanStalk. So where we bring in our services in a way that integrates with the AWS ecosystem. And, you know, my team manages the product management and speaking to customers and developers like you all, to understand how we can improve our services for you to use it more seamlessly. >> So, I mean, I know AWS has a lot of services tha t have containers involved with them and it's a lot of integration within the cloud. Amazon's as cloud native as you're going to get at AWS. If I was a new customer, where do I start with containers if you had to give me advice? And then, where I have a nice roadmap to grow within AWS. >> Yeah, no, that's a great question a lot of customers ask us this. We recommend that the customers choose whatever is the best fit for their application needs and for their operational flexibilities. So, if you have an application which you can use, pretty abstract and like end to end managed by AWS service, we recommend that you start at the highest level of abstraction that's okay to use for your application. And that means something like App Runner, where you can bring in a web application and run it like end to end. And if there are things that you want to control and tweak, then you know, we have services like ECS, where you get control and you get flexibility to tweak it to your needs. Be it needs of like, integrations or running your own agents and running your own partner solutions or even customizing how it scales and all the, you know, characteristics related to it. And of course we have, if there are a lot of our customers also run kubernetes, so that is a requirement for you, if your apps are already packaged to run, you know, easily with the kubernetes ecosystem, then we have, yes, for you. So, like application needs, the operational, how much of the operations do you want us to handle? Or how much of it do you want to actually have control over. And with all that, like the highest level of abstraction so that we can do the work on your behalf, which is the goal of AWS. >> Yeah, well, we always hear that all that heavy lifting, undifferentiated heavy lifting, you guys handle all that. Since you're in product management, I have to ask the question 'cause you guys have a little bit longer view, as you have think about what's on the roadmap. What type of customer trends are you seeing in container services? >> We see a lot of trends about customers who want to have the plugability for their, you know, services of choice. And our EKS offerings actually help in that. And we see customers who want an opinionated, you know, give me an out of the box solution, rather than building blocks. And ECS brings you that experience. The new strengths that we are seeing is that a lot of our customer workloads are also on their data centers and in their on-prem like environments. Be it branch offices or data centers or like, you know, other areas. And so we've recently launched the, anywhere offerings for you. So, ECS anywhere, brings you an experience for letting your workloads run and management that you control, where we manage the scaling and orchestration and the whole like, you know, monitoring and troubleshooting aspects of it. Which is the new trend, which seems to be something that our customers use as a way to migrate their applications to the cloud in the long term or just to get, you know, the same experience and the same, like, constructs that they're familiar with, come onto their data centers and their environments. >> You know, Shubha, we hear a lot about containers. It's becoming standard in the enterprise now, mainstream. But customers, when we talk to them, they kind of have this evolution, they start with containers and they realize how great it is and they become container full, right. And then you start to see kind of, them trying to evolve to the next level. And then you start to see EKS come into the equation. We see that in cloud native. Is EKS a container? Or is it a service? How does that work with everything? >> So EKS is a Amazon managed service, container service, where we do the operational set up, you know, upgrades and other things for the customer on their behalf. So basically, you get the same communities APIs that you get to use for your application but we handle a little bit of the integrations and the operations selected to keeping it up and running with high availability. in a way that actually meets your needs for the applications. >> And more and more people are dipping their toe in the water, as we say, with containers. What are some of the things you've seen customers do when they jump in and start implementing that kind of phase one containers? Also, there's a lot of head room beyond that, as you mentioned. What's the first couple steps that they take? They jump in,, is it a learning process? Is it serverless? Where is the connection points all come together? >> Great, so, I want to say that, no one solution that we have, fits all needs. Like, it's not the best case, best thing for all your use cases, and not for all of your applications. So, how it all comes together is that, AWS gives you a ecosystem of tools and capabilities. Some customers want to really build the, you know, castle themselves with each of the Lego block and some customers want it to be a ready made thing. And I want, you know, one of the things that I speak to customers about is, is to rethink which of the knobs and controls do they really need to have, you know because none of the services we have is a one way door. Like, there is always flexibility and, you know ability to move from one service to the other. So, my recommendation is to always like, start with things where Amazon handles many of the heavy lifting, you know, operations for you. And that means starting with something like, serverless offerings, where, like, for example, with Lambda and Forget, we manage the host, we manage the patching, we manage the monitoring. And that would be a great place for you to use ECS offering and, you know, basically get an end to end experience in a couple of days. And over time, if you have more needs, if you have more control, you know, if you want to bring in your own agents and whatever else you have, the option to use your own EC2 Instances or to take it to other, like, you know, parts of the AWS ecosystem, where you want to, you know, tweak it to your needs. >> Well, we're seeing a lot of great traction here at DockerCon. And all the momentum around containers. And then you're starting to get into trust and security supply chain, as open source becomes more exponentially in growth, it's growing like crazy, which is a great thing. So what can we expect to see from your team in the coming months, as this rolls forward? It's not going away anytime soon. It's going to be integrated and keep on scaling. What do we expect from the team in the next month or so? Couple of months. >> Security and, you know, is our number one job. So you will continue to see more and more features, capabilities and integrations, to ensure that your workloads are secure. Availability and scaling are the things that we do, you know, as keep the lights on. So, you should expect to see all of our services growing to make it like, more user friendly, easier, you know, simpler ways to get the whole availability and scaling to your needs, better. And then like, you know, very specifically, I want to touch on a few services. So App Runner, today we have support for public facing web services. You can expect that the number of use cases that you can meet with app runner is going to increase over time. You want to invest into making it AWS end to end workflow experience for our customers because, that's the easiest journey to the cloud. And we don't want you to actually wait for months and years to actually leverage the benefits of what AWS provides. ECS, we've already launched our, like, you know, Forget and Anywhere, to bring you more flexibility in terms of easier networking capabilities, more granular controls in deployment and more controls to actually help you plug in your preferred, you know, solution ties. And in EKS, we are going to continue to keep the communities, you know, versions and, you know, bring simpler experiences for you. >> A lot of nice growth there, containers, EKS, a lot more goodness in the cloud, obviously. We have 30 seconds left. Tell us what you're most excited about personally. And what should the developers pay attention to in this conference around containers and AWS? >> I would say that AWS has a lot of offerings but, you know, speak to us, like, come to us with your questions or, you know, anything that you have, like in terms of feature requests. We are very, very eager and happy to speak to you all. You know, you can engage with us on the container store map, which is on GitHub. Or you can find, you know, many of us in events like this, AWS Summits and, you know, DockerCon and many of the other meetups. Or find us on LinkedIn, we're always happy to chat. >> Yeah, always open, open source. Open source meets cloud scale, meets commercialization. All happening, all great stuff. Shubha, thank you for coming on theCUBE. Thanks for sharing. We'll send it back now to the DockerCon Mainstage. I'm John Furrier with theCUBE. Thanks for watching. (upbeat music)

(upbeat bright music) >> Hello, welcome back to theCUBE's main stage coverage of DockerCon 2022. I'm John for your host of theCUBE. We have Knox Anderson, vice president of Product Management, Sysdig. Knox, welcome to theCUBE. >> Thanks for having me. Glad to be back. >> So IAC containers is going crazy madness in terms of adoption, standard, even mainstream enterprise, IT and cloud are all containerized. It's only getting better, and it increases the complications when you start thinking about scale and supportability. This is a huge discussion, and it ranges from how do you support, how do you run operations, how do you secure in the supply chain. All this is happening, and with the growth of cloud and server (indistinct) seeing Kubernetes at the center of everything. So I got to ask you, how has Kubernetes changed how you secure cloud infrastructure? >> Yeah, so Kubernetes is really the modern operating system for the cloud. And with that, you get a lot of facilities. So you get things like Kubernetes' network policies, you can use things like admission controllers. And with that, you're securing multiple layers, whether it's the control plane, individual workloads. And so there's a nice mixture of built-in tools, and part of the Kubernetes platform that then you can leverage to do prevention, auditing, and things like that. But it really requires an entire rethink of your stack and the tools you bring in alongside your people and processes. And so it's an exciting time because it gives you an opportunity to be more secure, but really have to rethink your approach there. >> And I want to get into the whole observability trend here 'cause you start thinking about the mobility, what containers enables. And getting all the data is everything. And then also that feeds into kind of having a good sense of what is going on. And when you hear about shift left and data as code, you know, developers don't want to get stopped coding, right? And then have to come back and go dig into things that they thought they had taken care of. So you kind of got this kind of flywheel going in the wrong direction. So that's causing teams to be disrupted. So how do teams keep up with the changes to the containerized applications or what to prioritize around that? Because if I shift left, am I done or what? And these are the things that come up all the time. >> Yeah. You have to shift left but also watch the right. Like, shifting left is a little bit harder from a people and process perspective. Like you put a tool in place, then it's a gating factor for getting in. And so that runtime context on the right is equally as important. And it's often easier to roll out a runtime tool just because you're not going in and introducing new processes. And that runtime visibility can also make shift left much better. If you're scanning a container image, you might get a thousand different vulnerabilities that you need to address, but only three of those are in packages that are actually executed at runtime. And so we recently released a feature called risk spotlight which does that exact feedback loop. And that's something that's important whether you're addressing vulnerabilities, misconfigurations, or responding to event. What's on the right, what's on the left, and then tie those together. >> Yeah, it's like left, right, it's like driving training here in the United States. You got a stop sign, you want to be moving, always be moving. I got to ask you what are some of the side effects of infrastructure automation and the result in code artifacts? >> Yeah, it's really, like, Kubernetes is nice because it's a declarative system, but it doesn't always work out that way. Like, someone might have a Helm chart and then someone else changes it in production. So understanding what is drift is really important in these environments. And then it also has enabled real remediation workflows. I think previously, you might patch something, a week later there's a new deploy, that patch gets written over. And so because Kubernetes and the rise of IAC, it's now easier to see a misconfiguration in production, open a poll request, and then fix that at source, which provides that full kind of visibility across those different environments. And it allows you to actually fix issues versus constantly being in that kind of whack-a-mole of patching things and moving on. >> Yeah, I mean this is all about cloud native development, and you look at, you know, some of the things going on, you're starting to see best practices developed. What do you guys see as a best practice for getting started with designing and securing cloud native applications? What are some of the tools that people should look at for beginners and for the entry-level position? And then as they get traction, what does that turn into? >> Yeah, so the pattern we've often seen is like someone gets started on the open source side, whether you're using Open Policy Agent or Falco, which Laurice who've you met with before created. And so really when you're starting, choose kind of the open source option. Learn from that. And then often what we've seen with customers is at scale, there's some companies like if you're in Uber, or Snapchat, and Apple, you can maybe build something around open source, but a lot of other people start to really consolidate platforms that are built on top of those open source technologies, and trying to get that really single view into what's happening in their environment, what are those events. And the thing that I would say, process wise, is most important is build that container center of excellence, that cloud center of excellence, whatever you call it, that brings together people from your ops team, your infrastructure team, your dev team, your security team. Everyone's got to have a seat at the table to have containers be successful. It's a big shift, and if you do it right, it really takes off, but each team really needs to be included there. >> Yeah, there's a lot of operational discussions going on around the devs, and the devs are being pulled to the front lines. We've been saying this for a decade, but now when you got edge computing, you got cloud native operations, on-premises, you start to see that they're getting pulled even further to the frontline. So, you know, what are you guys up to Sysdig? You know, they got a lot of developers here at DockerCon, what's in it for them? Why Sysdig, why should they care? What would you say to the old developers that are watching? What's in it for them? >> Yeah, we really make it easier for you to prioritize what to fix and what to address in your environment. I know I've built something before and like, my test suite or my scanner just lights up like a Christmas tree, and you just want to move to another task because it's just too much to deal with at that time. And so we really help you focus on what matters and get the most bang for your buck. Everyone has way too much time or too many things going on and not enough time. And so being able to understand effective risk, your different vulnerabilities, what to fix, is really key to delivering secure software. >> I mean, it's like a doctor needs to know what to work on with the patient, if you will, when to, and what's important, and then the dependencies, and you got, a system's mindset, you got to know what the consequences. So it sounds easy, just knock down a list of things, but isn't that easy. You got to want to hit things that you know that will be, to have an impact right away. That seems to be the big aha moment here. >> Yeah, definitely. >> So we're going to be at KubeCon in Europe, you guys going to have booth there, what's the quick plug for the company? Give a shout out to what's happening at Sysdig and cloud native world. >> Yeah, really excited to be in Valencia. We have a ton of people at, sorry, at DockerCon with, giving a couple different talks here. So the first is Master Your Container Security Model and then Software Supply Chain Security and Standards. On the supply chain one, we're getting deep into SBOMs. So if that's a topic that's important to you, please join that one. >> Awesome, and then that's a big topic supply chain. We've got a minute and a half left. What's the most important thing people should pay attention to as open source continues to grow in prominence, not just from a code standpoint, but as a social environment, as people's doing ventures and venture capitalists are mining the area, what should they pay attention to as supply chain becomes important, what's the big thing? >> There's a lot of companies I think going around the SBOM space, and kind of trying to certify like where did this come from, and have that providence across the entire supply chain. We, under the hood, use those SBOMs to understand kind of what have you built, what packages are used, and then tie that with that runtime data. So a lot of the things that we talked around before with RiskSpotlight is based on that deep SBOM knowledge. And that's something that, I think the standards are still getting kind of worked out where there's CycloneDX, SBX. And so people really are saying, "Hey, I need to generate SBOMs," and we're regenerating them, but there's going to be more and more applications on "Okay what do you do with that? How does it integrate with other tools?" So it's kind of I think in the little bit of the early data lake phases where it's like, "I've taken all my data, I put it here. Now I need to do more with it." And so that's where I think we'll start to see some pretty exciting things over the next year or two. >> It's super exciting. On one hand you got the attackers, and that's a zero trust environment, and you get the builders, the developers where trust is everything. You got to know what it's in the code. It's really interesting time and super important to scale. So Knox, thanks for for coming on theCUBE and sharing the Sysdig update. Appreciate it, thanks for coming on. Now back to you at the DockerCon main stage, this is theCUBE. I'm John for your host. Thanks for watching. (upbeat bright music)

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

>>Hey, everyone. I want to welcome you back. This is our intermission. And let me tell you what a morning we've had for those of you that don't know. I'm, Hayma Ganapati, I'm in product marketing at Docker. And I would just want to quote, actually someone who was in one of the chat rooms and this, I think encapsulates exactly how I feel today, because this is my first Docker con and the quote was from. And he said, I feel like a kid in an ice cream store where I don't know which flavor to choose. I want to go to all of the sessions and I got to tell you that's how I felt. And, you know, um, I want to just do some specific call-ups. Um, first of all, Dana way to keep it real in your interview. I love the cube interview. If you miss that, um, it was really great. >>She talks a lot about, uh, CI CD pipeline and you know, what to do with GoodHub. It was great. Um, I also want to say that I was, uh, slipping back and forth between the community rooms and way to go Brazil obrigado until all of the people who participate in the Brazil room, we had about 250 plus people in that room. And the, the chat window was just going crazy and in the French community room, Vive left hall. So if you've a uncle funny, uh, we had about 150 plus people in that room. So I just want to say that, you know, we've been seeing a lot of participation and I just want to thank everyone for attending and for participating on people have been so kind in the chat rooms, we just want to remind you to stay kind, you know, presenters put a lot of effort into their presentations, so just, you know, offer some positive and supportive critique to them. >>And the other thing I want to mention is all of the countries that we're seeing, all of the participation. So I'm just going to call out a few. We have people from the Netherlands, from Canada, from South Africa, Akron, Ohio, Belgium, Austria, yeah, Ecuador, New Zealand. And he cut up Westchester. Like, I mean, it just goes list goes on and on and on. And I think this really speaks to the power of Docker community. And it's a real testimony to how people from all over the world are in love with Docker technology and are excited to be here. And so I just wanted to thank everyone again and want to remind you that we want to leverage the power of community. And we have a fundraising campaign going on to help, uh, people who are affected by COVID. And you know, some of our big communities, especially in India and Brazil are, have been really affected by COVID. >>So we're asking you to contribute and we'd really like you to participate. Um, we have, uh, the, the link you can see here, Docker donates, you can tweet about it and would love to see the numbers go up for those donations, because, you know, I've personally been affected, had some family members pass away from COVID in India, and I'm sure other people may have stories that firsthand or secondhand. So please do that and let's show what the power of Docker community can do. And before I hand over to, to Peter, I'm just going to read out some of the tweets we've been getting, okay, this Brett and Peter, these are great. Uh, one of the, one of the tweets said dev environments is one of the most exciting features in the past few years. Super excited to try this out. Great, great, great tweet. Yeah. >>I agree to, um, another loving the content that was not your tweets. You can, you can slip me the 20 bucks later. Um, there's another tweet that says loving the content from hashtag Docker con so far fascinating use cases and interesting progress and future directions love that. And then there's another one I'm trying to find it here. Uh, I've been waiting for this so long Docker builds now work on Intel and M one. So keep those tweets coming. We love getting this kind of feedback and we love reading the chat room. So, um, Peter, you know, I attended your, your panel and I love that we were talking about a security and that moving, moving it left. So how did that go for you? >>Uh, it was, it was, uh, it was extremely fun. And for those that are, uh, I think my parents might be watching, so they probably watched it and were like, w this is the most boring thing I've ever seen, but, um, you know, you get a bunch of geeks and, uh, Brett has told me I should use geek instead of nerd, but I, I liked, uh, geek. So you get a bunch of geeks talking about security and coding and, um, what, what, what containers actually are, what vulnerabilities are. Yeah, it was, it was extremely fun. The panel was fantastic. They were very engaging the chat. I mean, I couldn't keep up with the chat. Right. It would just kept flying by, uh, luckily I had a helper to pull off questions, but, um, yeah, it's super exciting. You can, I know we're all remote, but you can just feel that energy, right. It was, it was great. It was great. Yeah. Yeah, for sure. It's super >>Connected. I felt that with your panel to Brett as well, sorry to talk over you there, but yeah. How did, how did it go for you? I, there was a lot of engagement in your session. >>Uh, ditto, like it was just, uh, there was so many questions. We only got to get a fraction of them. I tried to pick themes because, uh, when you talk about continuous testing and integration and all the things that take a part of that, um, you, you end up with lots of, well, what I like is the discussion around opinions, because so much of these pipelines from code on your machine, into production and everything in between, it's really, uh, it's a culture. It turns out to be the description of your culture and how you all perceive testing, how you, what you value in testing. And so that really started to come out as a theme, um, throughout that show. And we, we ran at a time. I was also watching Peters and it was fantastic, but like you think an hour is enough time to cover a topic, but it's just tipping tip of the iceberg kind of stuff. So I think it was super helpful. I learned some things, um, I really enjoyed watching Peters and, uh, yeah, can't wait for the next one. There's >>More than that. And likewise, great. I mean, I know, I know we're w maybe we pat chose it, but it, it was, it was super exciting to watch your panel. They were very Nikos, one of my favorite people in the world, uh, a fellow Austinite, but, um, yeah, I love that too. How you, uh, you were talking about opinions right. And playing off each other. It's, it's always interesting to hear smart people, uh, how they think, right. Yeah. I learned from how they think, right. Yeah. A hundred percent. >>So, all right. So we're, we're, um, what's next? Like, we, we gotta keep this thing going, so I've got to remember that. >>I want to, so I want to talk a bit about some of the panels that are, or the sessions that are coming up and just want to remind people that happened this afternoon. I'm all about use cases. You know, I was a developer for many decades, and it's great to hear how other developers are using the tools. But, uh, as a developer, I always wanted to know how are, what are the end user applications? And so we have two exciting sessions at 1:00 PM. We have sneak and red ventures, and they're going to be talking about how they used Docker containers. The title of the, uh, uh, session is great. An ounce of prevention, curing, insecure, container images. So check that out. And we also have another one at one 30 with Massimo, from AWS and Dexter Legaspi from Sirius XM. And they're going to be talking about a real world application using Docker containers. So I really want you to, to encourage you to attend those. >>Yeah. Um, can I say one really quick? Cause I'm Sue and a shout out to Eric Smalling. He's giving the red ventures talk with our partners. He's awesome. Go check out his, uh, but I'm really excited about Matt. Jarvis's sneak talk around. Uh, I think we might've talked about it earlier. My container image has 500 vulnerabilities vulnerabilities now what, right. I mean, I think as developers, as we're coming into this and dev ops and everybody right. You scan and then you see all these vulnerabilities just shoot by. And you're like, well, what do I do? So Matt, Matt will be addressing that. And he is fantastic. I can go on. There's a bunch of them. >>Yeah. There's a whole bunch of coming up and right up after this, I'm on a live stream with a bunch of panels on get ops. And then after that, Peter will be back. And so stay tuned and thanks for watching during the intermission. And we'll see you soon. >>I'm also leading the women in tech panel attend that. Don't forget to do that. >>Absolutely. Yep. All right. Ciao. Ciao >>For me like my first, oh, I get it about Docker was when I used a SQL server container on my neck book for the first time >>Being able to install Docker desktop, which was the first thing that I did and be able to build this without worrying about any of my software versions that I currently had on my machine. It was >>Awesome. One of the things, because I love the most about Docker is because I write books and I do video training courses to help a lot of people take their first steps with Docker and containers and to get a connection with those people and for them to come back to me and say, do you know what this is so cool, so easy, and it's going to change both my job. And, but also my organization, my team, all of that kind of stuff, change the experience that our customers have with our applications and what our business really puts a smile on my face. If >>You want to use containers, then Docker is the first toys, especially with tools like the mark Docker, compose, you can, uh, easily do your day-to-day job as a developer, or even if you're an ops person, then there are the books of the cloud and other things. So yeah, the idea is that we can go the simplicity one simple task, uh, to, uh, Daugherty mate and make that reuse as many times. Uh, that is one of the cool things I like about my >>Favorite part about Docker is using it as a developer tool. I using Docker desktop, really easy to install, really easy to run. >>Every time I come back to DACA, I love the simplicity of the way that it works, especially on things like security, which I find frustrating and hard. It's just done so seamlessly. And so my favorite thing about DACA is not just that it changed the world in the way that we develop in and ship and build applications and put that. It's just so easy that even the guy, like, I think >>It really is all about finding that aha moment, that hook where Docker really makes sense to you because once you have that moment, then all of a sudden, you, you know, you are on your way to being a Docker power user. >>We need for people to understand this technology better before they can, uh, actually dive deep into that. And Docker makes it easier to explain things, to explain the concept of containers, to explain how containers will work, how you can split your environments, how you can, uh, standardize all your pipelines and so on. It's important that we also take the time to help other people. And I think it's very important that we also give back and that's part of the motto of open sources. How do we give back to other people and how we help other people learn? And I think that's what I'm really passionate about. This whole thing is continuing, uh, giving back to the community. I just >>Hope and has fun at Docker con. And I know that there's a lot of great speakers coming and I will be watching the talks, even though they're happening at 3:00 AM and in my local time zone, um, I'm pretty excited to watch and, uh, hopefully watch more than later on streaming or YouTube or wherever they're going to be. So I hope everyone has fun and learn something and yeah, I don't see how you couldn't have fun.

>>Hello everybody. And welcome back. Wow. What a Docker con we've been gone all day. There's so many great breakout sessions, live panels. How many you just came off a live panel. >>He did. It was great. It was awesome. >>So I'm Peter McKie, head of developer relations and we have Brett Fisher hammer one on everybody just introduced herself. We have a new guest here. I'm not sure if people know who you are. Uh, Scott, maybe if you can introduce yourself. Hello? Hello. Hello? Is this Mike? All right. Awesome. So I thought, well cool. What a long day. I think we had some really awesome talks. Of course. Um, it was hard to jump around right. And see everything. So, um, so I missed a lot, but I got to see some great talks. I love the Kubernetes talk. The, the, the, the minimal things you need to know from Kubernetes from Elton, which was fantastic. Yeah. I really loved. And the M one talk from tonus man. I'm super excited about my. >>Yeah, I'm super excited, but I didn't get the Mac until I knew that Docker would support containers on it. There you go. >>There you go. Everybody should have one. Yep. Yep. So you said we were running windows. It's just a personal, personal preference. Okay. So I thought, I thought we could talk about maybe reminisce a little bit, but uh, you know, Scott has the shirt on there from 14, but I doubt that's the first DockerCon you have ever been to Scott? Is it the first, first? Yeah, that was the first one we ever held. So first one we ever held was, uh, June, 2014. And so it was about what, 15 months after Docker was opensource. And we had 300 people all crammed in a little room in a hotel in San Francisco. Right. And we had Lego whale schwag and, you know, talks. And it w what's that, that was the first one. Yeah, it was the first one. And then after that, I remember I wasn't there, but in, um, was it an Amsterdam where the video, the great video where the, the, the, the crowd, we got to play a video game and they were kicking around the, the, uh, beach balls and it would move, moved a little arcade character. Brett, do you remember this? And, and you had to move with the crowd. It was, it looked like a nightclub. It was closed. >>That was fantastic. Like those intros were some of the most, it was like being in a nightclub when, uh, a new band debuted or >>All right. Well, how am I, w is this your, this is your first Docker con, correct? >>It is. I'm like, I feel like I'm just a new, but, uh, I had a great time, like I said, before, kid in the candy store, I learned so much, especially the panels, even from our Docker individuals. So that was, it was great. I I'm enthralled, I'm excited. I'm going to watch all the recordings afterwards as everyone else will be able to do too, since we got that question a lot, but yeah. Super exciting for me. >>Yeah. You might have to wait until tomorrow because the adrenaline is just going to just going to drop. You might just sleep, sleep, and then, but then you can watch them watch all the replays tomorrow. I know that's what I'm going to do, catch up on things sleep with. But, um, I have some that talk about, and so some of the highlights that I was interested in, maybe some of them, you know, might not be at the top of everybody's mind, but the verified publisher program. I mean, that, that is it's incredible, right. That's just about all the security, uh, supply chain security problems that are happening. Right. That's a huge, huge win for us. I think Scott of having, uh, partners around, uh, around containers, around software, joining us to, and we verify their content, uh, just building trust, more trust with the community, right? >>Yeah. I mean, I mean, you saw this theme throughout the conference, right? Is that the, the security theme kind of ran deep and you saw a lot of talks and panels. And so this is just kind of playing into that where it's like, how do you, how do you start with content you trust as developers updated or their put their apps on it and then hand it off to ops and then deploy from there. And so, um, the verified publisher program is just another layer if you will, of providing kind of trusted content that, that people want to use and want to use in their application. So yeah, no, I think it's a great ad and it's very consistent with what you see kind of the conversation, the community that we saw throughout the day. Yeah, absolutely. But w what was the highlight for you for today? Put you on the spot a little bit. >>Um, again, hanging out, getting to hang out with my friends again and meet new people like that was basically, you know, at Docker con uh, I have so many memories. In fact, uh, we were earlier today on Twitter. We were throwing up some old pictures of like the original captains, uh, gathering in Seattle. And we actually got to be captains on little boats. They get, they, they put us in boats, we didn't have any training and we got to drive them around in a, in a lake. And it was hilarious. Um, and, and having those memories and then re reliving them with people that were there or people that were, um, a part of that early days of Docker. And that's one of my favorite parts of Docker course, the learning is fantastic, the new features, but yeah, that, that those memories >>Let, let, let me lean into Brett it's point. Like, like, so we're all, we're all nerds and introverts, right? So like, we get excited by the tech and the bits and the bites, but Brett's point about like the community and how, like it's just grown over the years. And it's always been kind of welcoming to newcomers as well as providing forums for cutting edge discussions as well. Like that, that is one of those things. I think we, we often don't fully appreciate no fully celebrate. And so today was a great example of just celebrating that and putting that front and center of the whole conversations for everything. Yeah, yeah. A hundred percent in the, all of the community leaders, the community, the rooms that we had. I mean, they were, we just chatting before we came online about the Brazil, uh, community room there they're just trucking along, keep going. Yeah. Yeah. I mean, they're, they're just, um, yeah, it amazes me every, every time and the captains program. Right. I mean, everybody on there is they're experts in what they do, but not a whole lot of egos. I mean, it just super nice people always willing to help. I mean, the whole community is like that in my opinion, for sure. Yeah. Awesome. >>Just a couple of highlights that I wanted to share if I could, what was your favorite? Um, you know, my favorite, this is going to sound super geeky. It was the people talked about documentation. And so I just wanted to do a call out to OSHA who does such a great job on our documentation and that as a developer, I mean, documentation was a very important part of what I needed to do. It's like a critical tool for me, and that we have that on the program was great, but of course, verified publisher program I've been working closely on that. That has been great. We have some great press releases that have gone out from our partners. So I encourage you to check that out. I wanted to share some stats if that's okay. I think attendees would be very interested. We have over 79,000 people who signed up for DockerCon. >>So, uh, that's a great number that exceeds last year's number, I believe. And, uh, we had the, the sound right. And then we had about 23,000, um, attendees during the, the day today, which is, which is also incredible. And we're still crunching those numbers, but it's wonderful. And then the, GoFund me, we're sitting at about a little over a thousand dollars. So, you know, DockerCon, doesn't end after this. There's still recordings and presentations you can look at and the GoFund me will still be up for a while. So I encourage you to, to donate for that. But those are just some interesting stats. >>Oh, that's awesome. Yeah. It's amazing. The numbers that, that happened. And again, I think it's because of the community for real, there's just so many great folks. Yeah. I mean, the chat is just on fire, right. Everybody wants to engage so much. It just flies by right. When you see it, right. You see folks waking up at 2:00 AM, 3:00 AM to participate, and it's not, you know, part of it's for the content, but, but a lot of it is the community because they know they're going to find folks willing to answer questions, willing to share. And, and you know, how often do you experience that in tech communities? And so I think that's what makes Docker, um, special. There's a lot of great communities out there, but the doc community is really special in that sense of like, like you can wait in, you can be a newbie, you can be an expert and there's a place for you, right. >>There's a place for you to share. There's a place for you to learn. And there's always something to learn. There's always something you can share with someone else. And I think that's something that we all should like celebrate, but also work hard and be deliberate to kind of, kind of preserve right. And, and protect as we grow this to like 80,000 this year, a hundred thousand next year, 200,000 million after that, right? Yeah. Yeah. A hundred percent. Yeah. It's important to stay authentic and true to our roots for sure. And I think that's, I mean, it's one of the biggest reasons I am here at Dockers because of the community. The tools are awesome too. Uh, you know, I'm a big fan for sure. And that's what drew me in, but I stay before the people, one that I work with and to the, the broader community, I think it's one of the best in the industry. >>I possibly could be a little biased, but I truly believe that it's okay to, you're a lot of advice. What do you hear in the chat? Yeah. Yeah. You got one, one 30 in the morning and the UK two 25 in the morning. Where's Tony Switzerland. So yeah. That's great. Philippines. Yeah. Yeah. Jacob Howard was on my, uh, on my panel for, uh, development dev containers. Right. He's in Ukraine and he's like, yeah, Nope, no problem. I'll wake up. I'd love to be on. Right. It's it's amazing. Yeah. Okay. What did we, and this might be, I risk, uh, not thinking too far in the future, but you know, you know, sitting in America, looking at COVID right. I think we're starting to come out of it a little bit. Uh, the rest of the world is, you know, still struggling a bit, but, um, yeah. >>Be interesting. Let's say everything goes well. Right. Hi, some kind of hybrid, um, events seems interesting to me, um, possibly some local events that, you know, these communities are coming together, live to watch and to also do their thing. I don't know. I don't know anybody's thoughts about, um, you know, what a hybrid model looks like next year or maybe a year and a half. I don't, I don't know, but I just, no, Peter, I think you're spot on. And that's, that's the topic of the moment, right? It's like, how do you preserve the, the wonderful reach and accessibility that we're seeing today? Right. And last year with the virtual conferences, but we also know that like the face to face in person, our IRL conferences also have a lot of value. Right. So how do you, how do you blend the two of those and still have a great experience, honestly, like community, like give us your feedback, give us your ideas. >>Like we're, we're right in the middle of figuring out what we do for the next 12 months, once it's safe to meet face to face. Right. That's a great question. Yeah. Yeah. I don't, you can't beat the power of sitting down beside someone, like you mentioned earlier, Scott, where a lot of us are introverts and, um, you know, so the screen in front of us is a little bit hard, but I, those connections you make in the hallways after, after the talks in, in the hotel lobby, I mean, white boarding on a, on a yeah. Like it's, it's invaluable, right? Yeah. Yeah. Well, awesome. Brett time-check we're where are we at? Here? We are at time. Okay. It felt like that. Oh man. Oh, bummer. Well it's okay. What a great day. Goodbye. >>See you later. Goodbye. Yeah. Well, thanks guys for jumping on here at the end and with everybody, I really appreciate it. And uh, thank you to the Docker community, all the speakers, all the panelists, all the keynote speakers, everybody behind the scenes did a phenomenal job. Um, I I'm super excited to be part of this team and I totally look forward to being able to see everybody in person. And, uh, yeah, I'll shut up and let anybody else close out. I don't want to be the last one, but, uh, well, no. Well done Peter. Well done Brett, and look, Dr. Communities is what makes us, makes us strong, makes it work. And through trials like COVID and other challenges of last year, the community held strong, right? And so let's all respect that let's cherish that let's protect that. And like, let's look forward in the next 12 months, have a great 12 months and figure out what DockerCon 20, 22 looks like the conclude, all these great voices have as much interactivity, whether it's on-prem, whether it's virtual, whether it's hybrid and just want to say thank you to community. Thank you. The sponsors. Thank you. The Docker team who went above and beyond to make this happen. Thank you. The Docker, captains and the community behind the scenes. A phenomenal event. And just want to thank everyone so much. Yeah. Yep. All right. Well, that'll wrap it up. Thanks everybody. We'll see you we'll see you soon. Awesome. All right. Thanks everyone, doctor

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