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

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

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

(upbeat music) >> Hello, welcome back to "theCUBE"'s coverage of DockerCon 2021. I'm John Furrier, host of "theCUBE". Great lineup in this event. Got some great guests. Matt Falk, VP of engineering at Orbital Insight. Matt, great to see you. Great keynote, thanks for coming on this cube. Appreciate it. >> Great, thanks for having me, John. >> So you at Orbital Insight, you guys doing some cutting edge work. Geospatial, big data, real-world problems. I mean, it's almost sci-fi for me. I mean, I just love how space, cybersecurity, data, all kind of rolling into like this whole very cool vibe. You know, drones, satellites, all this kind of you know, stuff going on in the cloud. But there's like real action happening, right? (chuckles) We all live on GPSes. Like, this is like very cool and relevant technology happening right now. Give us your take. What are you guys seeing, how's business? Give us a quick overview of what your journey is and how you guys are executing. >> Sure. And I think you're right there, it is a little bit like sci-fi actually, even to myself. Even having been in the industry for a few years at this point. You know, we all think about big data, it's become much more a thing especially over the past decade or two. Everything that we try and solve as big data, artificial intelligence, machine learning, they all thrive, they all need this big data. An untapped area about big data though, is geospatial data. And really data that comes from overhead sensors, coming from space. So to me, that feels a little bit like sci-fi like you're saying because that time is now. That time for us to be able to use and harness that data and provide actual or meaningful insights is here. You know, as a company for Orbital Insight, we got into it about seven, eight years ago and the title wave of this data was just forming. There weren't as many satellite provider companies, there weren't as many different types of disparate geospatial data. And by geospatial data you know, anything with a latitude and longitude associated with it, right? This data was, it was there but it wasn't as abundant there. It wasn't clear about how we could use that data. And over the past few years so many new use cases had really popped out and so many new disparate types of data and it's really about the fusion of all of them and getting more and more of that data. So right now the most exciting thing is really just how much of that data exists and how much is going to exist in the next few years. And honestly, we want to ride that tidal wave along with our customers. We can deal with many different types of data here. It's overhead satellite imagery, it's cell phone pings, it's identification system from ships, it's everything that you can get your hands on and incorporate into this platform. And then using this to feed the artificial intelligence and machine learning algorithms to derive new insights so it's sci-fi but it is here. >> Yeah and it's real computer science problems too. A lot of networking as well. You got this and it's transitioning too. You were out early doing these new use cases. But what's interesting about your journey and I want to get your thoughts on this, is that you guys really evolve from tackling these first kind of time problems, making solutions out of them to sequencing it to a fully on, fully-built scalable insight platform. Okay and this the pattern that we see in cloud native. Companies go from going in and doing things, that one-off, one-offs projects, POCs and then sequencing to a either cloud native or full blown platform. You guys have had that journey, take us through that effort and what's the result today? >> No, that's exactly right. The way we started, just like you mentioned, with many other companies was really around this proof of concept idea. It was going out, talking to customers, finding what their pain points were and figuring out what can we do to solve those pain points. So it was all about, "Okay, for this particular customer "take this data set, take satellite imagery "of this location, take cell phone things for this location, "take a digital elevation model from this area "of the planet, fuse them together in some "very specific custom way to try and solve that problem." And that's how we started. Over the first few years of that, this doesn't really scale as well. We had to keep building new solutions to solve new problems. What we started to identify was that there's so much commonality, there's so much overlap between a lot of these problems. So the solutions for them you know, if we're taking truck counts, if we're able to look at parking lots and detect cars from satellite imagery and use that to determine level of trends or sales at you know, a retail store. Well, we can also use that same overhead imagery to detect cars and look for their movement patterns, look for how they're going from a port to a particular warehouse or how they're driving on the road. Same thing with trucks. When we started identifying that a lot of the value from these different analytics and data sources can be used to solve many different problems in different ways but the underlying core technology is very similar. So for us about a few years ago, about two or three years ago at this point, we started really developing this into a platform that can solve generally any question about geospatial data analytics. So instead of, "I have a very specific problem, I wanted "to count the number of trees in this particular area." It's, "No, no, you want to do something similar to land use. "You want to try and classify different areas of the planet "that are covered in this particular type of land use "and then use that as an estimate for how many trees "there are." So we started to find these commonalities and that allowed us to really build this generic platform we call GO and use that to start solving many, many more questions. >> That's good. So real world problems are emerging. I'd love to get your thoughts on what those geospatial problems are because you can almost think about how the traditional distributed computing world looks at the edge for instance. Like you know, the intelligent edge or industrial edge, edge of the network as they call it in the hybrid world. You're bringing not just moving packets, you're talking about other data media. So pictures, images and (chuckles) different data sources. This is a huge aperture that changes the game on the analytics. Could you share some of the problems you saw that opened up with the new types of sources? Because it's not just packet to a device or an edge point in the traditional sense. >> Sure, sure. No, that's a great question for us. And I think a lot of people that don't really understand or haven't dealt with geospatial data before, don't understand necessarily a lot of the nuances that come with this data, there are quite a few of them. So I'll focus on satellite imagery in particular for the first part here. But you know, when people think about, even today what we can do with artificial intelligence. Computer vision on an image, you know, most people go to the images they can see from the cell phones. Most people start to think about self-driving cars and seeing the resolution of those images. Well, when you're dealing with overhead imagery, satellite imagery in particular, the game changes, the game is completely different. Yes, you're still working with an image but so many of the pieces of that image are just different and more complex. So for instance, when you're taking an image miles away from the planet, the first thing you have to realize is your resolution is not quite what people think. In particularly now, if we go outside and we stand in a satellite image, the best commercial sensors today, we're at most one pixel. And with one pixel you really can't identify people. You know, even a car or a truck at most, you're looking at 15 to 20 pixels and it becomes extremely difficult to classify objects at that resolution or at that scale compared to if you're using a cell phone picture, for instance. So that's really for us the first you know, major difficulty or change that comes into play. The second one would be the temporal aspect. So not only the spatial resolution but temporal resolution. You don't get an image every day. You don't even get an image, sometimes every week. So how do you, do you impute different data, impute different points to make your overall analysis worthwhile? Again, a slew of additional challenges that come with that. Other things like for instance georegistration or orthorectification. So the idea, when you take a satellite image of somewhere on the planet, you actually don't get very precisely where that image is. It could be off by five, 10, 15 or 20 meters even and you have to do work to actually relocate that image in the right particular position. Orthorectification refers to the angle at which the image was taken. If you're taking an image from a bird's eye view, yeah you're going to be able to see straight down and you're going to see buildings and they look like you know, squares of certain right edged polygons like that. But you can also take an angle 30 centimeters or excuse me, 30 degrees off, you can look at the side when you're taking this image and then the satellite image looks completely different. So that's another technique that we have to combat and another difficulty we have to work with in order to make this data usable. So for satellite imagery for other data sources too, there's a slew of additional challenges that we have to compete, that we have to fix and work with to make this data usable. And that's what our platform does. It takes this data, it fixes all those issues and allows you to compute the analytics on top of them. >> I love it. I mean, as a consumer, I can relate to like, say Google. I know there's trees there but they look like they just put trees there 'cause they can. Like there was a tree there and they fill it out, right? I mean kind of similar things going on there. All great stuff. I love the tech and I think it's going to be one of these eras that's going to be super valuable as more of these use cases can get this tap the data for not only insights but also maybe for features in software. Which brings me to the next question. How do people use you guys? I mean, as you have these use cases that are emerging, a lot of disparate use cases, different data sources now analytics as a platform, are you guys selling software is it a service, as a fee? Can you explain you know, how I might want to geek out and integrate you into my product or feature? Or do you do it that way? How does it work? >> Oh sure, thank you. So, there's two different aspects here really. And one of them is how people actually have access to this data. So the first is that we actually make this data available. And the second is the analytics that we put on top of this data. So for the first piece, a lot of these data sets are extremely expensive. So the average even consumer or a lot of businesses, it's much too expensive to go and actually buy all this satellite imagery or all this geolocation ping data or shipping information. It's just too expensive to buy these disparate data sources if you only have particular, single need for them. So the first thing our platform does, is it integrates with many different data providers. It integrates with, like I said, anything that has a latitude and longitude with it, we try and get that into our platform. And we become the broker almost, the provider of all that disparate data into a single unified source. So that's that first aspect, that's how they use us to get access to that data that otherwise they wouldn't be able to get access to. The second piece is the analytics. So for this, our platform, it does really you put three things into our platform. You ask where you want to look on the planet, what you want to look for and when do you want to look for it? And our platform takes care of going and getting all that information that it needs to compute that answer. Then using our custom analytics to derive what you're looking for, the question you're actually asking and produce similar to a data feed but it's much more custom than that, particular insights for the customer. So what comes out of the platform is effectively a time series that you're able to go explore and drill down into further. So a particular example of this is for supply chain right now and this is a problem that we're very passionate about right now. Especially with last year, how COVID impacted things. But from a supply chain perspective, we're actually able to identify locations on the planet that you're interested in, typically operating facilities and start looking at trends for where people are going to and from that particular facility. So we can see, "Oh, there were a hundred people that visited "this facility on a you know, the last seven days." And maybe produce a time series of how many people were there each day. But we can also then say, "Of those hundred people, "16 of them came from this location, 52 of them came "from this location, 53 of them visited this location "two days after visiting that location." And we can start to build this entire traceability map of that particular location and that our customers can use to identify patterns and then anomalies really, in their own supply chains. Or different things about their operating facilities. >> So pinging, like graph data, for instance. We got some insights into how to restructure their value chains or reconfigure their economics. Something like that would be like a use case. >> Exactly, exactly. Finding further efficiencies, ways they can optimize their supply chains or anticipating disruptions in it. If they know that part of their supply chain is dependent on you know, a particular facility, a particular location or a particular region. And they know from other news that something is about to happen to that region, they can know practically how to change their supply chain in order to you know, alleviate that pain before it even happens. >> Well, real time in the news just recently, just this month earlier in the month, we saw that gas shortage or stoppage or shortage/supply chain disruption, happen in the East coast, right? From the pipeline hack, the ransomware attack. That's a good example. I mean, some people don't even know the difference between a supply chain disruption and a shortage, there are two different things so I saw that big debate happening. This is kind of real world example where you can say, "Okay, we have a supply chain, "potential predictive disruption." Then maybe look at ways to do that. Am I thinking in the right way here? >> No, that's exactly the right way to think about it. You can start to see... So from that event, if you're operating a facility or a facility warehouse, you can look at that event, ask the question of, "How is this going to impact "my supply chain?" And the first thing you need to know is are you dependent on that, is that something that actually impacts or it plays a part in your supply chain? So you'd use our software, plug into your own operating facility, start to trace where people are coming from or going to. First thing you can do then, is identify, "Is that location "part of my supply chain?" If not, you know potentially you're in the clear. If so, then you can start to identify different locations that might be a suitable replacement for your supply chain. So can you practically avoid that going forward and make that move sooner than you would've been able to otherwise. >> I love the complexity challenge here. You guys doing the heavy lifting here in offering as a service makes total sense. You can almost democratizing the whole complexity of the data acquisition and then you know, providing value on top of it. The question I have for you is, what other learnings have you had? I mean, what was some of the difficulties? You mentioned you know, the artifacts, atmosphere, haze, noise, spatial temporal frequencies before. What are some of the other things that you're seeing and learnings that people might not know about that you guys have solved in this data capturing from the satellites? >> That's a great question. And there's plenty of them. A lot of things I think it would come down to is how to use this data or how best to combat some of the challenges like we talked about earlier, come with this data set. In particular, if we look at the foot traffic data that we look at. So pingings coming from different cell phones or what we call geolocation pings. Largely, you can think of that as any IOT device that's pinging their location you know, we can aggregate that data in and start using it within the platform. And what we've learned for that data is, it's very dependent on how you can actually get that to be normalized. And what I mean by that is none of this data is providing a complete picture of what's actually there. So again, if we look back at you know, even from image perspective when you're getting a satellite image when you're getting cell phone pings, you're only getting at best, 15 to 20% of the actual picture. And the challenges are really about going from that 20% view to the full contextual 100% view. So tactically, what that looks like for geolocation pings, where you're not getting geolocation pings from every person on the planet, we're not getting pings from every IOT device or every cell phone. We're getting a particular, almost randomized subset of those pings and they're all anonymized. So how do you go from that to an actual insight? How do you go from that to a full complete view of what's happening? And that's where our normalization algorithms come into play and other capabilities that we have that take that data and try and extrapolate what's truly happening. So if you're looking at you know, for instance if you look at a gas station. And it's a gas station in a you know, an area that's not very highly populated. And you're only getting two or three pings a day or some days you're getting none. Is that truly a signal of no one's going to that gas station or are you just missing the data? And you don't always know so part of what we've learned is how to take that data and actually translate it into the complete picture. We have very complex algorithms and they're constantly being improved on to account for differences like people turning their cell phone off or more than one person being in a car or things like that. So that's what we've really learned in it. It's all about taking that incomplete picture and trying to produce the most complete picture with as most context as possible to solve problems. >> So what's the secret sauce on all of this? Is it algorithms, is it data usage, all the above? I mean, take me through some of the secret sauce that's going on that you guys are building to make all this work. >> Sure, sure. And I'll go into it as much as I can. (John and Matt laugh) >> (speaking faintly) >> But there's a few different- Exactly. But a few different pieces really. The first one is the data itself, right? At the end of the day, no matter how good your machine learning capabilities are, if you don't have the data, you can't do anything. And this is true for all types of artificial intelligence or machine learning algorithm. If you don't have something to allow the system to learn from, you're at a loss. So the first piece of it really is getting the right data and making sure we have enough different or disparate data sources to really complete that overall picture. The second piece of it is allowing our platform to do this at a high scale. So it'd be one thing if you can produce a particular algorithm and get it to run in a single location one time. But it's all about for us, asking that aggregate question. So we're not you know, if somebody is asking about a particular gas station or a retail store, more often than not, they're not caring about just one location. They're caring about the aggregate, they're trying to look at this country as a whole and seeing what the trends or patterns are. So the second piece of secret sauce really is our platform and the ability to scale that up dynamically and allow you to ask any size question. So not just one AOI at a particular location but thousands of different locations and how that answer really compiles together. Third one is definitely the artificial intelligence and machine learning. For us, that is a extremely core competency. Something that allows us to really take that data and produce the insights. And that's a key factor of it. Like I mentioned, with the different challenges, part of our secret sauce there is not just the algorithms themselves but additional techniques or different R&D that we can do to solve or combat some of the additional issues that we have with overhead sensors. In particular, I'll point out two here but one is the rare object issue. So a lot of times if you're doing with satellite imagery and you're trying to find an object, it's very difficult to find a satellite image of that object. If you're looking for a particular type of ship you might only find one or two of them in thousands of images. So how do you build a machine learning algorithm that really uses that really small amount of data to produce an algorithm? And this is where our R&D capabilities come into play. And one to highlight is synthetic data. So the ability to produce almost fake or generated satellite images that actually produce these objects you're looking for so that we can train or learn off of that. So things like that really build our, I'll say, our secret sauce, are our R&D core competencies. The ability to produce newer novel techniques to generate data where satellite images or other geospatial data have deficiencies that we can combat. >> Yeah, I like that feature. Because you're almost saying, "The ship might look like this "depending upon where they're looking and muting that in there, good call. I guess the question I have for you is first of all, great tech loved the story. You guys are onto some really cool stuff and very relevant. The question, is in minds of peoples right now who are watching is why now for the critical time, why is now a critical time for geospatial analytics? What's your answer to that? >> Sure. That's a great, actually the answer is great for us too as a company. As I was kind of alluding to in the beginning, there's this tidal wave of geospatial data. And you know, if we were to look at five, 10, 15 years ago, the data itself and the technology was not really there to allow us to do what we're trying to do now. If you look back, I think it was in 2013, there was a particular computer vision paper that came out that really was the birth of the CNN world. And for that, that is a core compute capability that allows us to do the computer vision we need to be able to do. So that was a extreme catalyst for companies like ours, are being able to do this type of data fusion analytics. And the second one is the birth of the new sensors coming up right now. If you look back five years ago and where we're going five years from now, it's almost like Moore's Law. Where every other year, things are just starting to double. There's more and more satellites being thrown up, there's more and more data being thrown out and frankly, it's almost too much data at this point. There's just more and more data coming up. We already have petabytes of satellite imagery in our system, hundreds of terabytes of IOT device data and it's everyday just more and more of this data is coming up and being produced. So now is that perfect time because the data is finally there and it's only getting better over time. >> Yeah, I know we have a little bit of time left. I do want to ask just kind of, I'm curious. I'm sure people are too. As leader in that company, as engineering leader, you got a team that's working on some pretty cool stuff. A lot of computer science, a lot of new technology opportunities, kind of new problems that are emerging that are exciting. So everyone likes to solve hard problems, right? You got one, right? You got synthetic data, massive ingestion pipelines, normalizing algorithms, spatial imputation, et cetera, all this good stuff. How do you organize, how do you attract people? How are you looking at this? Because you have to lean into this. It's not like you're waiting for the market to come to you. You guys are going out there, making the market technically as well. So how do you organize, how do you recruit? (chuckles) Take us through some of the inside the ropes there. >> Sure, sure. So I'll start with kind of just how our engineering team is organized right now and where are we try and do find people and pull additional folks into our team. Right now we are split into four or five different areas. So like most cloud based platforms, we do have an infrastructure team. So you know, DevOps, site reliability, IT, everything that goes into that core cloud layer. So we do have an infrastructure team that builds that. On top of that, we do have our platform engineering team. So that team largely builds our microservices that play together to produce our external API. On top of that, we have a product engineering team that builds really with developing our UI, adding in our UX, making sure everything on top of the API plays nicely together. And also building a few additional dockerized computer vision and machine learning models that can plug into the platform. Separately, we have our R&D team. This is like as you know, where we talked about our synthetic data and all the other research areas that we get into, they focus there. Then we have our senior data engineering team. This team is largely focused on pulling disparate data sources, massaging them, cleaning them up into the right format so that it can be plugged into our platform. So from this, this is kind of how our team is structured. You're right, it's a ton of technical challenge. A lot of fun challenges. We're about 50 engineers right now. We're actually, we're looking to grow almost doubling in size by the end of the year. We're going to be bringing on an additional 30 people over the next few months. And what we're looking for is people from a wide area of expertise. So people that have you know, microservice core platform backgrounds, able to build on the backend system, deal with tons of tons of you know, transactions per second and really allow us to scale our platform. That's one set of expertise we like. Another one is people that really just have geospatial data backgrounds. And which to be honest at this point, it's somewhat of a rare niche finding people that have worked on a platform but also worked in geospatial data. But that's something that we love to bring into our system so we can add additional expertise and eventually get new data sources in. And then lastly, it's really around that core competency of machine learning and artificial intelligence. So we will look for anybody that has machine learning you know deep math, deep computer science background to come in and be a part of that team. If they're capable from a research perspective, we are actually you know, it's possible to teach them some of the computer vision aspects as well. So, if they have a computer vision background, great. If they have a data science and machine learning background, great. We want that diverse set of interests and diverse set of thinking to come in and really build our R&D team as well. >> Yeah. And I obviously DockerCon is here. You're talking about containers and that leads into Kubernetes, microservices, all kinds of cloud native technologies. Because what you guys are doing is you're taking an old construct. I mean, fairly old, I mean it's you know, it's data. But you're leveraging it in new ways. In a way that's kind of what cloud native's about. How are you seeing that world evolve? Obviously we're here at DockerCon, containers helps big time thoughts on the containerization wave that continues. And you got Kubernetes and more and more cloud natives, more SRE's are going to be hired. Again, people are scaling up. What's your take on what's going on around DockerCon? >> No, this is actually for us. It's really powerful and it's a really powerful tool. Whether it's Dock or (speaking faintly), the idea of containerization as a whole, it really allows our platform to get to that next level of scale. One piece I you know, originally we were not a microservice platform. Like I said, we were starting to do some more POCs. As we got into this platform play, one of the things we knew we needed to be able to do was scale different parts of our system. So whether it was scaling to ingest more data, scaling to involve new algorithms or scaling really to involve or be able to compute massive computation requests that come from our customer. This requires different pieces of our system to scale. If we were a monolithic application, if we were running on premise, that type of scale just wouldn't really be possible at the level that we need it to. So for us, the solution is all around being able to dockerize different parts of our system, keep them isolated, keep them talking to each other via different interfaces. And then as need be horizontally scale different pieces of our system to compat with that. So really the you know, Kubernetes Docker together, the ability for us it's allowing our developers to focus on the code that they need to be writing and not focusing on the SRE or the DevOps perspective of it. And then letting our DevOps team use these additional tools to make themselves more efficient. You know, we can do that with a smaller team now we don't need a team of 50 people on DevOps or infrastructure. You can do it with five or six solid engineers that can really you know, manage your entire environment. >> Yeah, I think having that horizontal scalability is critical and the containerizing it, so many benefits there allowing things to be completely portable and integrating really well. Great stuff. Unbelievable gems dropped here. My final question for you while I got you here is you know, as you look at other peers and people in the marketplace, the people who were on the right side of history are experiencing, certainly entrepreneurs and people who are in businesses and enterprises are waking up and going, "Hey, that can really change the game and flip "the script with cloud native." So people are experiencing similar journeys where they got product engineering saying, "We are more of a platform. "I could sequence and build out that platform and then build "my infrastructure on the cloud." So you're starting to see these point applications turn into platforms. What's your advice to people out there that are going to move from product engineering departments or groups to bring on that platform construction or that work and then build that infrastructure like you guys are? What's your advice to folks that are going to make that journey? >> No, that's a great question, John. I think the quick advice I would give to anybody you know, that has a product engineering team considering moving to the platform right now is do it now. There's no time better than right now and what I mean by that is, the longer you delay the harder it gets. You're going to be missing out on a lot of the new technologies that are really being solidified as part of the cloud computing world. Yes you know, there are trade-offs. Especially you know, you might have to go to your exec team or your product team and make these trade-offs and you won't be able to develop teachers as quickly as you're spending time porting to a platform play. But the benefits are amazing. And once you actually get there, you'll really be thankful that you took the time to do it. Yes it's, you know again, it's going to be challenging because it's one of those things where it's an engineering benefit at first. It's not going to be something you're going to say, "Yes product, "in two months, you're going to get this benefit from it." Or, "In you know, three months, you're going to get "this benefit for it." It's, "One year from now, this is how our platforms "are written, our new product is really going to be able "to expand and grow." And the best way to get there is to just do it now. Really starting encapsulating your system, break it out into different pieces, put it in a cloud, allow it to scale. And so yeah, my advice is to just bite the bullet and do it now. >> So people who buy into that notion of moving from monolithic to microservice based applications want that horizontal scalability, as you mentioned. What are some of the first principles in that platform? What's on the mind of the architect or the leader as they start thinking about those first principles for the modern platform? >> Sure. I'd say the first one is don't over design. So some people have a tendency when they start thinking about microservices is they really go to microservice almost nanoservices. They really start breaking off you know, as many different pieces of the code, making them as small as possible. And to some extent, that's what you want to do with microservices but you don't want to go too far. I mean, it's easy to go down that rabbit hole. So in particular, there are certain services or microservices that you find out, they're tightly coupled. They're constantly passing data back and forth and that's when you realize, passing data back and forth between two different logical separation of code, it takes time. So it might make sense for them to be one unified microservice as opposed to two. So the most important thing to think about is you know, what pieces really make sense to logically separate and how does that actually impact the flow of data or flow of information through your system? If you're adding too many hops between you know, a certain end point and the call to the backend system, it might be time to rethink the way you're breaking system the system down. But you really want to start out with what can be broken down into the logically encapsulated pieces? And that's where we want to pull our microservices. >> Highly cohesive decoupling, that's a concept. An operating system as we say, it's the platform, that's the cloud. >> It's not new, that's right. >> It's been around. Matt, great interview. Thanks for dropping the gems and sharing your knowledge. And congratulations for the work you're doing at Orbital Insight. Great focus, love the company, love the excitement. Thanks for coming on. >> Perfect. Pleasure chatting with you too, John. And thanks for having me. And thanks for having me be a part of DockerCon. >> All right. DockerCon 2021, CUBE coverage. I'm John Furrier, host of "theCUBE". Thanks for watching. (lighthearted music)

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

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