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

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

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

>>Individuals create developers, translate ideas to code, to create great applications and great applications. Touch everyone. A Docker. We know that collaboration is key to your innovation sharing ideas, working together. Launching the most secure applications. Docker is with you wherever your team innovates, whether it be robots or autonomous cars, we're doing research to save lives during a pandemic, revolutionizing, how to buy and sell goods online, or even going into the unknown frontiers of space. Docker is launching innovation everywhere. Join us on the journey to build, share, run the future. >>Hello and welcome to Docker con 2021. We're incredibly excited to have more than 80,000 of you join us today from all over the world. As it was last year, this year at DockerCon is 100% virtual and 100% free. So as to enable as many community members as possible to join us now, 100%. Virtual is also an acknowledgement of the continuing global pandemic in particular, the ongoing tragedies in India and Brazil, the Docker community is a global one. And on behalf of all Dr. Khan attendees, we are donating $10,000 to UNICEF support efforts to fight the virus in those countries. Now, even in those regions of the world where the pandemic is being brought under control, virtual first is the new normal. It's been a challenging transition. This includes our team here at Docker. And we know from talking with many of you that you and your developer teams are challenged by this as well. So to help application development teams better collaborate and ship faster, we've been working on some powerful new features and we thought it would be fun to start off with a demo of those. How about it? Want to have a look? All right. Then no further delay. I'd like to introduce Youi Cal and Ben, gosh, over to you and Ben >>Morning, Ben, thanks for jumping on real quick. >>Have you seen the email from Scott? The one about updates and the docs landing page Smith, the doc combat and more prominence. >>Yeah. I've got something working on my local machine. I haven't committed anything yet. I was thinking we could try, um, that new Docker dev environments feature. >>Yeah, that's cool. So if you hit the share button, what I should do is it will take all of your code and the dependencies and the image you're basing it on and wrap that up as one image for me. And I can then just monitor all my machines that have been one click, like, and then have it side by side, along with the changes I've been looking at as well, because I was also having a bit of a look and then I can really see how it differs to what I'm doing. Maybe I can combine it to do the best of both worlds. >>Sounds good. Uh, let me get that over to you, >>Wilson. Yeah. If you pay with the image name, I'll get that started up. >>All right. Sen send it over >>Cheesy. Okay, great. Let's have a quick look at what you he was doing then. So I've been messing around similar to do with the batter. I've got movie at the top here and I think it looks pretty cool. Let's just grab that image from you. Pick out that started on a dev environment. What this is doing. It's just going to grab the image down, which you can take all of the code, the dependencies only get brunches working on and I'll get that opened up in my idea. Ready to use. It's a here close. We can see our environment as my Molly image, just coming down there and I've got my new idea. >>We'll load this up and it'll just connect to my dev environment. There we go. It's connected to the container. So we're working all in the container here and now give it a moment. What we'll do is we'll see what changes you've been making as well on the code. So it's like she's been working on a landing page as well, and it looks like she's been changing the banner as well. So let's get this running. Let's see what she's actually doing and how it looks. We'll set up our checklist and then we'll see how that works. >>Great. So that's now rolling. So let's just have a look at what you use doing what changes she had made. Compare those to mine just jumped back into my dev container UI, see that I've got both of those running side by side with my changes and news changes. Okay. So she's put Molly up there rather than mobi or somebody had the same idea. So I think in a way I can make us both happy. So if we just jumped back into what we'll do, just add Molly and Moby and here I'll save that. And what we can see is, cause I'm just working within the container rather than having to do sort of rebuild of everything or serve, or just reload my content. No, that's straight the page. So what I can then do is I can come up with my browser here. Once that's all refreshed, refresh the page once hopefully, maybe twice, we should then be able to see your refresh it or should be able to see that we get Malia mobi come up. So there we go, got Molly mobi. So what we'll do now is we'll describe that state. It sends us our image and then we'll just create one of those to share with URI or share. And we'll get a link for that. I guess we'll send that back over to you. >>So I've had a look at what you were doing and I'm actually going to change. I think that might work for both of us. I wondered if you could take a look at it. If I send it over. >>Sounds good. Let me grab the link. >>Yeah, it's a dev environment link again. So if you just open that back in the doc dashboard, it should be able to open up the code that I've changed and then just run it in the same way you normally do. And that shouldn't interrupt what you're already working on because there'll be able to run side by side with your other brunch. You already got, >>Got it. Got it. Loading here. Well, that's great. It's Molly and movie together. I love it. I think we should ship it. >>Awesome. I guess it's chip it and get on with the rest of.com. Wasn't that cool. Thank you Joey. Thanks Ben. Everyone we'll have more of this later in the keynote. So stay tuned. Let's say earlier, we've all been challenged by this past year, whether the COVID pandemic, the complete evaporation of customer demand in many industries, unemployment or business bankruptcies, we all been touched in some way. And yet, even to miss these tragedies last year, we saw multiple sources of hope and inspiration. For example, in response to COVID we saw global communities, including the tech community rapidly innovate solutions for analyzing the spread of the virus, sequencing its genes and visualizing infection rates. In fact, if all in teams collaborating on solutions for COVID have created more than 1,400 publicly shareable images on Docker hub. As another example, we all witnessed the historic landing and exploration of Mars by the perseverance Rover and its ingenuity drone. >>Now what's common in these examples, these innovative and ambitious accomplishments were made possible not by any single individual, but by teams of individuals collaborating together. The power of teams is why we've made development teams central to Docker's mission to build tools and content development teams love to help them get their ideas from code to cloud as quickly as possible. One of the frictions we've seen that can slow down to them in teams is that the path from code to cloud can be a confusing one, riddle with multiple point products, tools, and images that need to be integrated and maintained an automated pipeline in order for teams to be productive. That's why a year and a half ago we refocused Docker on helping development teams make sense of all this specifically, our goal is to provide development teams with the trusted content, the sharing capabilities and the pipeline integrations with best of breed third-party tools to help teams ship faster in short, to provide a collaborative application development platform. >>Everything a team needs to build. Sharon run create applications. Now, as I noted earlier, it's been a challenging year for everyone on our planet and has been similar for us here at Docker. Our team had to adapt to working from home local lockdowns caused by the pandemic and other challenges. And despite all this together with our community and ecosystem partners, we accomplished many exciting milestones. For example, in open source together with the community and our partners, we open sourced or made major contributions to many projects, including OCI distribution and the composed plugins building on these open source projects. We had powerful new capabilities to the Docker product, both free and subscription. For example, support for WSL two and apple, Silicon and Docker, desktop and vulnerability scanning audit logs and image management and Docker hub. >>And finally delivering an easy to use well-integrated development experience with best of breed tools and content is only possible through close collaboration with our ecosystem partners. For example, this last year we had over 100 commercialized fees, join our Docker verified publisher program and over 200 open source projects, join our Docker sponsored open source program. As a result of these efforts, we've seen some exciting growth in the Docker community in the 12 months since last year's Docker con for example, the number of registered developers grew 80% to over 8 million. These developers created many new images increasing the total by 56% to almost 11 million. And the images in all these repositories were pulled by more than 13 million monthly active IP addresses totaling 13 billion pulls a month. Now while the growth is exciting by Docker, we're even more excited about the stories we hear from you and your development teams about how you're using Docker and its impact on your businesses. For example, cancer researchers and their bioinformatics development team at the Washington university school of medicine needed a way to quickly analyze their clinical trial results and then share the models, the data and the analysis with other researchers they use Docker because it gives them the ease of use choice of pipeline tools and speed of sharing so critical to their research. And most importantly to the lives of their patients stay tuned for another powerful customer story later in the keynote from Matt fall, VP of engineering at Oracle insights. >>So with this last year behind us, what's next for Docker, but challenge you this last year of force changes in how development teams work, but we felt for years to come. And what we've learned in our discussions with you will have long lasting impact on our product roadmap. One of the biggest takeaways from those discussions that you and your development team want to be quicker to adapt, to changes in your environment so you can ship faster. So what is DACA doing to help with this first trusted content to own the teams that can focus their energies on what is unique to their businesses and spend as little time as possible on undifferentiated work are able to adapt more quickly and ship faster in order to do so. They need to be able to trust other components that make up their app together with our partners. >>Docker is doubling down and providing development teams with trusted content and the tools they need to use it in their applications. Second, remote collaboration on a development team, asking a coworker to take a look at your code used to be as easy as swiveling their chair around, but given what's happened in the last year, that's no longer the case. So as you even been hinted in the demo at the beginning, you'll see us deliver more capabilities for remote collaboration within a development team. And we're enabling development team to quickly adapt to any team configuration all on prem hybrid, all work from home, helping them remain productive and focused on shipping third ecosystem integrations, those development teams that can quickly take advantage of innovations throughout the ecosystem. Instead of getting locked into a single monolithic pipeline, there'll be the ones able to deliver amps, which impact their businesses faster. >>So together with our ecosystem partners, we are investing in more integrations with best of breed tools, right? Integrated automated app pipelines. Furthermore, we'll be writing more public API APIs and SDKs to enable ecosystem partners and development teams to roll their own integrations. We'll be sharing more details about remote collaboration and ecosystem integrations. Later in the keynote, I'd like to take a moment to share with Docker and our partners are doing for trusted content, providing development teams, access to content. They can trust, allows them to focus their coding efforts on what's unique and differentiated to that end Docker and our partners are bringing more and more trusted content to Docker hub Docker official images are 160 images of popular upstream open source projects that serve as foundational building blocks for any application. These include operating systems, programming, languages, databases, and more. Furthermore, these are updated patch scan and certified frequently. So I said, no image is older than 30 days. >>Docker verified publisher images are published by more than 100 commercialized feeds. The image Rebos are explicitly designated verify. So the developers searching for components for their app know that the ISV is actively maintaining the image. Docker sponsored open source projects announced late last year features images for more than 200 open source communities. Docker sponsors these communities through providing free storage and networking resources and offering their community members unrestricted access repos for businesses allow businesses to update and share their apps privately within their organizations using role-based access control and user authentication. No, and finally, public repos for communities enable community projects to be freely shared with anonymous and authenticated users alike. >>And for all these different types of content, we provide services for both development teams and ISP, for example, vulnerability scanning and digital signing for enhanced security search and filtering for discoverability packaging and updating services and analytics about how these products are being used. All this trusted content, we make available to develop teams for them directly to discover poll and integrate into their applications. Our goal is to meet development teams where they live. So for those organizations that prefer to manage their internal distribution of trusted content, we've collaborated with leading container registry partners. We announced our partnership with J frog late last year. And today we're very pleased to announce our partnerships with Amazon and Miranda's for providing an integrated seamless experience for joint for our joint customers. Lastly, the container images themselves and this end to end flow are built on open industry standards, which provided all the teams with flexibility and choice trusted content enables development teams to rapidly build. >>As I let them focus on their unique differentiated features and use trusted building blocks for the rest. We'll be talking more about trusted content as well as remote collaboration and ecosystem integrations later in the keynote. Now ecosystem partners are not only integral to the Docker experience for development teams. They're also integral to a great DockerCon experience, but please join me in thanking our Dr. Kent on sponsors and checking out their talks throughout the day. I also want to thank some others first up Docker team. Like all of you this last year has been extremely challenging for us, but the Docker team rose to the challenge and worked together to continue shipping great product, the Docker community of captains, community leaders, and contributors with your welcoming newcomers, enthusiasm for Docker and open exchanges of best practices and ideas talker, wouldn't be Docker without you. And finally, our development team customers. >>You trust us to help you build apps. Your businesses rely on. We don't take that trust for granted. Thank you. In closing, we often hear about the tenant's developer capable of great individual feeds that can transform project. But I wonder if we, as an industry have perhaps gotten this wrong by putting so much emphasis on weight, on the individual as discussed at the beginning, great accomplishments like innovative responses to COVID-19 like landing on Mars are more often the results of individuals collaborating together as a team, which is why our mission here at Docker is delivered tools and content developers love to help their team succeed and become 10 X teams. Thanks again for joining us, we look forward to having a great DockerCon with you today, as well as a great year ahead of us. Thanks and be well. >>Hi, I'm Dana Lawson, VP of engineering here at get hub. And my job is to enable this rich interconnected community of builders and makers to build even more and hopefully have a great time doing it in order to enable the best platform for developers, which I know is something we are all passionate about. We need to partner across the ecosystem to ensure that developers can have a great experience across get hub and all the tools that they want to use. No matter what they are. My team works to build the tools and relationships to make that possible. I am so excited to join Scott on this virtual stage to talk about increasing developer velocity. So let's dive in now, I know this may be hard for some of you to believe, but as a former CIS admin, some 21 years ago, working on sense spark workstations, we've come such a long way for random scripts and desperate systems that we've stitched together to this whole inclusive developer workflow experience being a CIS admin. >>Then you were just one piece of the siloed experience, but I didn't want to just push code to production. So I created scripts that did it for me. I taught myself how to code. I was the model lazy CIS admin that got dangerous and having pushed a little too far. I realized that working in production and building features is really a team sport that we had the opportunity, all of us to be customer obsessed today. As developers, we can go beyond the traditional dev ops mindset. We can really focus on adding value to the customer experience by ensuring that we have work that contributes to increasing uptime via and SLS all while being agile and productive. We get there. When we move from a pass the Baton system to now having an interconnected developer workflow that increases velocity in every part of the cycle, we get to work better and smarter. >>And honestly, in a way that is so much more enjoyable because we automate away all the mundane and manual and boring tasks. So we get to focus on what really matters shipping, the things that humans get to use and love. Docker has been a big part of enabling this transformation. 10, 20 years ago, we had Tomcat containers, which are not Docker containers. And for y'all hearing this the first time go Google it. But that was the way we built our applications. We had to segment them on the server and give them resources. Today. We have Docker containers, these little mini Oasys and Docker images. You can do it multiple times in an orchestrated manner with the power of actions enabled and Docker. It's just so incredible what you can do. And by the way, I'm showing you actions in Docker, which I hope you use because both are great and free for open source. >>But the key takeaway is really the workflow and the automation, which you certainly can do with other tools. Okay, I'm going to show you just how easy this is, because believe me, if this is something I can learn and do anybody out there can, and in this demo, I'll show you about the basic components needed to create and use a package, Docker container actions. And like I said, you won't believe how awesome the combination of Docker and actions is because you can enable your workflow to do no matter what you're trying to do in this super baby example. We're so small. You could take like 10 seconds. Like I am here creating an action due to a simple task, like pushing a message to your logs. And the cool thing is you can use it on any the bit on this one. Like I said, we're going to use push. >>You can do, uh, even to order a pizza every time you roll into production, if you wanted, but at get hub, that'd be a lot of pizzas. And the funny thing is somebody out there is actually tried this and written that action. If you haven't used Docker and actions together, check out the docs on either get hub or Docker to get you started. And a huge shout out to all those doc writers out there. I built this demo today using those instructions. And if I can do it, I know you can too, but enough yapping let's get started to save some time. And since a lot of us are Docker and get hub nerds, I've already created a repo with a Docker file. So we're going to skip that step. Next. I'm going to create an action's Yammel file. And if you don't Yammer, you know, actions, the metadata defines my important log stuff to capture and the input and my time out per parameter to pass and puts to the Docker container, get up a build image from your Docker file and run the commands in a new container. >>Using the Sigma image. The cool thing is, is you can use any Docker image in any language for your actions. It doesn't matter if it's go or whatever in today's I'm going to use a shell script and an input variable to print my important log stuff to file. And like I said, you know me, I love me some. So let's see this action in a workflow. When an action is in a private repo, like the one I demonstrating today, the action can only be used in workflows in the same repository, but public actions can be used by workflows in any repository. So unfortunately you won't get access to the super awesome action, but don't worry in the Guild marketplace, there are over 8,000 actions available, especially the most important one, that pizza action. So go try it out. Now you can do this in a couple of ways, whether you're doing it in your preferred ID or for today's demo, I'm just going to use the gooey. I'm going to navigate to my actions tab as I've done here. And I'm going to in my workflow, select new work, hello, probably load some workflows to Claire to get you started, but I'm using the one I've copied. Like I said, the lazy developer I am in. I'm going to replace it with my action. >>That's it. So now we're going to go and we're going to start our commitment new file. Now, if we go over to our actions tab, we can see the workflow in progress in my repository. I just click the actions tab. And because they wrote the actions on push, we can watch the visualization under jobs and click the job to see the important stuff we're logging in the input stamp in the printed log. And we'll just wait for this to run. Hello, Mona and boom. Just like that. It runs automatically within our action. We told it to go run as soon as the files updated because we're doing it on push merge. That's right. Folks in just a few minutes, I built an action that writes an entry to a log file every time I push. So I don't have to do it manually. In essence, with automation, you can be kind to your future self and save time and effort to focus on what really matters. >>Imagine what I could do with even a little more time, probably order all y'all pieces. That is the power of the interconnected workflow. And it's amazing. And I hope you all go try it out, but why do we care about all of that? Just like in the demo, I took a manual task with both tape, which both takes time and it's easy to forget and automated it. So I don't have to think about it. And it's executed every time consistently. That means less time for me to worry about my human errors and mistakes, and more time to focus on actually building the cool stuff that people want. Obviously, automation, developer productivity, but what is even more important to me is the developer happiness tools like BS, code actions, Docker, Heroku, and many others reduce manual work, which allows us to focus on building things that are awesome. >>And to get into that wonderful state that we call flow. According to research by UC Irvine in Humboldt university in Germany, it takes an average of 23 minutes to enter optimal creative state. What we call the flow or to reenter it after distraction like your dog on your office store. So staying in flow is so critical to developer productivity and as a developer, it just feels good to be cranking away at something with deep focus. I certainly know that I love that feeling intuitive collaboration and automation features we built in to get hub help developer, Sam flow, allowing you and your team to do so much more, to bring the benefits of automation into perspective in our annual October's report by Dr. Nicole, Forsgren. One of my buddies here at get hub, took a look at the developer productivity in the stork year. You know what we found? >>We found that public GitHub repositories that use the Automational pull requests, merge those pull requests. 1.2 times faster. And the number of pooled merged pull requests increased by 1.3 times, that is 34% more poor requests merged. And other words, automation can con can dramatically increase, but the speed and quantity of work completed in any role, just like an open source development, you'll work more efficiently with greater impact when you invest the bulk of your time in the work that adds the most value and eliminate or outsource the rest because you don't need to do it, make the machines by elaborate by leveraging automation in their workflows teams, minimize manual work and reclaim that time for innovation and maintain that state of flow with development and collaboration. More importantly, their work is more enjoyable because they're not wasting the time doing the things that the machines or robots can do for them. >>And I remember what I said at the beginning. Many of us want to be efficient, heck even lazy. So why would I spend my time doing something I can automate? Now you can read more about this research behind the art behind this at October set, get hub.com, which also includes a lot of other cool info about the open source ecosystem and how it's evolving. Speaking of the open source ecosystem we at get hub are so honored to be the home of more than 65 million developers who build software together for everywhere across the globe. Today, we're seeing software development taking shape as the world's largest team sport, where development teams collaborate, build and ship products. It's no longer a solo effort like it was for me. You don't have to take my word for it. Check out this globe. This globe shows real data. Every speck of light you see here represents a contribution to an open source project, somewhere on earth. >>These arts reach across continents, cultures, and other divides. It's distributed collaboration at its finest. 20 years ago, we had no concept of dev ops, SecOps and lots, or the new ops that are going to be happening. But today's development and ops teams are connected like ever before. This is only going to continue to evolve at a rapid pace, especially as we continue to empower the next hundred million developers, automation helps us focus on what's important and to greatly accelerate innovation. Just this past year, we saw some of the most groundbreaking technological advancements and achievements I'll say ever, including critical COVID-19 vaccine trials, as well as the first power flight on Mars. This past month, these breakthroughs were only possible because of the interconnected collaborative open source communities on get hub and the amazing tools and workflows that empower us all to create and innovate. Let's continue building, integrating, and automating. So we collectively can give developers the experience. They deserve all of the automation and beautiful eye UIs that we can muster so they can continue to build the things that truly do change the world. Thank you again for having me today, Dr. Khan, it has been a pleasure to be here with all you nerds. >>Hello. I'm Justin. Komack lovely to see you here. Talking to developers, their world is getting much more complex. Developers are being asked to do everything security ops on goal data analysis, all being put on the rockers. Software's eating the world. Of course, and this all make sense in that view, but they need help. One team. I told you it's shifted all our.net apps to run on Linux from windows, but their developers found the complexity of Docker files based on the Linux shell scripts really difficult has helped make these things easier for your teams. Your ones collaborate more in a virtual world, but you've asked us to make this simpler and more lightweight. You, the developers have asked for a paved road experience. You want things to just work with a simple options to be there, but it's not just the paved road. You also want to be able to go off-road and do interesting and different things. >>Use different components, experiments, innovate as well. We'll always offer you both those choices at different times. Different developers want different things. It may shift for ones the other paved road or off road. Sometimes you want reliability, dependability in the zone for day to day work, but sometimes you have to do something new, incorporate new things in your pipeline, build applications for new places. Then you knew those off-road abilities too. So you can really get under the hood and go and build something weird and wonderful and amazing. That gives you new options. Talk as an independent choice. We don't own the roads. We're not pushing you into any technology choices because we own them. We're really supporting and driving open standards, such as ISEI working opensource with the CNCF. We want to help you get your applications from your laptops, the clouds, and beyond, even into space. >>Let's talk about the key focus areas, that frame, what DACA is doing going forward. These are simplicity, sharing, flexibility, trusted content and care supply chain compared to building where the underlying kernel primitives like namespaces and Seagraves the original Docker CLI was just amazing Docker engine. It's a magical experience for everyone. It really brought those innovations and put them in a world where anyone would use that, but that's not enough. We need to continue to innovate. And it was trying to get more done faster all the time. And there's a lot more we can do. We're here to take complexity away from deeply complicated underlying things and give developers tools that are just amazing and magical. One of the area we haven't done enough and make things magical enough that we're really planning around now is that, you know, Docker images, uh, they're the key parts of your application, but you know, how do I do something with an image? How do I, where do I attach volumes with this image? What's the API. Whereas the SDK for this image, how do I find an example or docs in an API driven world? Every bit of software should have an API and an API description. And our vision is that every container should have this API description and the ability for you to understand how to use it. And it's all a seamless thing from, you know, from your code to the cloud local and remote, you can, you can use containers in this amazing and exciting way. >>One thing I really noticed in the last year is that companies that started off remote fast have constant collaboration. They have zoom calls, apron all day terminals, shattering that always working together. Other teams are really trying to learn how to do this style because they didn't start like that. We used to walk around to other people's desks or share services on the local office network. And it's very difficult to do that anymore. You want sharing to be really simple, lightweight, and informal. Let me try your container or just maybe let's collaborate on this together. Um, you know, fast collaboration on the analysts, fast iteration, fast working together, and he wants to share more. You want to share how to develop environments, not just an image. And we all work by seeing something someone else in our team is doing saying, how can I do that too? I can, I want to make that sharing really, really easy. Ben's going to talk about this more in the interest of one minute. >>We know how you're excited by apple. Silicon and gravis are not excited because there's a new architecture, but excited because it's faster, cooler, cheaper, better, and offers new possibilities. The M one support was the most asked for thing on our public roadmap, EFA, and we listened and share that we see really exciting possibilities, usership arm applications, all the way from desktop to production. We know that you all use different clouds and different bases have deployed to, um, you know, we work with AWS and Azure and Google and more, um, and we want to help you ship on prime as well. And we know that you use huge number of languages and the containers help build applications that use different languages for different parts of the application or for different applications, right? You can choose the best tool. You have JavaScript hat or everywhere go. And re-ask Python for data and ML, perhaps getting excited about WebAssembly after hearing about a cube con, you know, there's all sorts of things. >>So we need to make that as easier. We've been running the whole month of Python on the blog, and we're doing a month of JavaScript because we had one specific support about how do I best put this language into production of that language into production. That detail is important for you. GPS have been difficult to use. We've added GPS suppose in desktop for windows, but we know there's a lot more to do to make the, how multi architecture, multi hardware, multi accelerator world work better and also securely. Um, so there's a lot more work to do to support you in all these things you want to do. >>How do we start building a tenor has applications, but it turns out we're using existing images as components. I couldn't assist survey earlier this year, almost half of container image usage was public images rather than private images. And this is growing rapidly. Almost all software has open source components and maybe 85% of the average application is open source code. And what you're doing is taking whole container images as modules in your application. And this was always the model with Docker compose. And it's a model that you're already et cetera, writing you trust Docker, official images. We know that they might go to 25% of poles on Docker hub and Docker hub provides you the widest choice and the best support that trusted content. We're talking to people about how to make this more helpful. We know, for example, that winter 69 four is just showing us as support, but the image doesn't yet tell you that we're working with canonical to improve messaging from specific images about left lifecycle and support. >>We know that you need more images, regularly updated free of vulnerabilities, easy to use and discover, and Donnie and Marie neuro, going to talk about that more this last year, the solar winds attack has been in the, in the news. A lot, the software you're using and trusting could be compromised and might be all over your organization. We need to reduce the risk of using vital open-source components. We're seeing more software supply chain attacks being targeted as the supply chain, because it's often an easier place to attack and production software. We need to be able to use this external code safely. We need to, everyone needs to start from trusted sources like photography images. They need to scan for known vulnerabilities using Docker scan that we built in partnership with sneak and lost DockerCon last year, we need just keep updating base images and dependencies, and we'll, we're going to help you have the control and understanding about your images that you need to do this. >>And there's more, we're also working on the nursery V2 project in the CNCF to revamp container signings, or you can tell way or software comes from we're working on tooling to make updates easier, and to help you understand and manage all the principals carrier you're using security is a growing concern for all of us. It's really important. And we're going to help you work with security. We can't achieve all our dreams, whether that's space travel or amazing developer products ever see without deep partnerships with our community to cloud is RA and the cloud providers aware most of you ship your occasion production and simple routes that take your work and deploy it easily. Reliably and securely are really important. Just get into production simply and easily and securely. And we've done a bunch of work on that. And, um, but we know there's more to do. >>The CNCF on the open source cloud native community are an amazing ecosystem of creators and lovely people creating an amazing strong community and supporting a huge amount of innovation has its roots in the container ecosystem and his dreams beyond that much of the innovation is focused around operate experience so far, but developer experience is really a growing concern in that community as well. And we're really excited to work on that. We also uses appraiser tool. Then we know you do, and we know that you want it to be easier to use in your environment. We just shifted Docker hub to work on, um, Kubernetes fully. And, um, we're also using many of the other projects are Argo from atheists. We're spending a lot of time working with Microsoft, Amazon right now on getting natural UV to ready to ship in the next few. That's a really detailed piece of collaboration we've been working on for a long term. Long time is really important for our community as the scarcity of the container containers and, um, getting content for you, working together makes us stronger. Our community is made up of all of you have. Um, it's always amazing to be reminded of that as a huge open source community that we already proud to work with. It's an amazing amount of innovation that you're all creating and where perhaps it, what with you and share with you as well. Thank you very much. And thank you for being here. >>Really excited to talk to you today and share more about what Docker is doing to help make you faster, make your team faster and turn your application delivery into something that makes you a 10 X team. What we're hearing from you, the developers using Docker everyday fits across three common themes that we hear consistently over and over. We hear that your time is super important. It's critical, and you want to move faster. You want your tools to get out of your way, and instead to enable you to accelerate and focus on the things you want to be doing. And part of that is that finding great content, great application components that you can incorporate into your apps to move faster is really hard. It's hard to discover. It's hard to find high quality content that you can trust that, you know, passes your test and your configuration needs. >>And it's hard to create good content as well. And you're looking for more safety, more guardrails to help guide you along that way so that you can focus on creating value for your company. Secondly, you're telling us that it's a really far to collaborate effectively with your team and you want to do more, to work more effectively together to help your tools become more and more seamless to help you stay in sync, both with yourself across all of your development environments, as well as with your teammates so that you can more effectively collaborate together. Review each other's work, maintain things and keep them in sync. And finally, you want your applications to run consistently in every single environment, whether that's your local development environment, a cloud-based development environment, your CGI pipeline, or the cloud for production, and you want that micro service to provide that consistent experience everywhere you go so that you have similar tools, similar environments, and you don't need to worry about things getting in your way, but instead things make it easy for you to focus on what you wanna do and what Docker is doing to help solve all of these problems for you and your colleagues is creating a collaborative app dev platform. >>And this collaborative application development platform consists of multiple different pieces. I'm not going to walk through all of them today, but the overall view is that we're providing all the tooling you need from the development environment, to the container images, to the collaboration services, to the pipelines and integrations that enable you to focus on making your applications amazing and changing the world. If we start zooming on a one of those aspects, collaboration we hear from developers regularly is that they're challenged in synchronizing their own setups across environments. They want to be able to duplicate the setup of their teammates. Look, then they can easily get up and running with the same applications, the same tooling, the same version of the same libraries, the same frameworks. And they want to know if their applications are good before they're ready to share them in an official space. >>They want to collaborate on things before they're done, rather than feeling like they have to officially published something before they can effectively share it with others to work on it, to solve this. We're thrilled today to announce Docker, dev environments, Docker, dev environments, transform how your team collaborates. They make creating, sharing standardized development environments. As simple as a Docker poll, they make it easy to review your colleagues work without affecting your own work. And they increase the reproducibility of your own work and decreased production issues in doing so because you've got consistent environments all the way through. Now, I'm going to pass it off to our principal product manager, Ben Gotch to walk you through more detail on Docker dev environments. >>Hi, I'm Ben. I work as a principal program manager at DACA. One of the areas that doc has been looking at to see what's hard today for developers is sharing changes that you make from the inner loop where the inner loop is a better development, where you write code, test it, build it, run it, and ultimately get feedback on those changes before you merge them and try and actually ship them out to production. Most amount of us build this flow and get there still leaves a lot of challenges. People need to jump between branches to look at each other's work. Independence. Dependencies can be different when you're doing that and doing this in this new hybrid wall of work. Isn't any easier either the ability to just save someone, Hey, come and check this out. It's become much harder. People can't come and sit down at your desk or take your laptop away for 10 minutes to just grab and look at what you're doing. >>A lot of the reason that development is hard when you're remote, is that looking at changes and what's going on requires more than just code requires all the dependencies and everything you've got set up and that complete context of your development environment, to understand what you're doing and solving this in a remote first world is hard. We wanted to look at how we could make this better. Let's do that in a way that let you keep working the way you do today. Didn't want you to have to use a browser. We didn't want you to have to use a new idea. And we wanted to do this in a way that was application centric. We wanted to let you work with all the rest of the application already using C for all the services and all those dependencies you need as part of that. And with that, we're excited to talk more about docket developer environments, dev environments are new part of the Docker experience that makes it easier you to get started with your whole inner leap, working inside a container, then able to share and collaborate more than just the code. >>We want it to enable you to share your whole modern development environment, your whole setup from DACA, with your team on any operating system, we'll be launching a limited beta of dev environments in the coming month. And a GA dev environments will be ID agnostic and supporting composts. This means you'll be able to use an extend your existing composed files to create your own development environment in whatever idea, working in dev environments designed to be local. First, they work with Docker desktop and say your existing ID, and let you share that whole inner loop, that whole development context, all of your teammates in just one collect. This means if you want to get feedback on the working progress change or the PR it's as simple as opening another idea instance, and looking at what your team is working on because we're using compose. You can just extend your existing oppose file when you're already working with, to actually create this whole application and have it all working in the context of the rest of the services. >>So it's actually the whole environment you're working with module one service that doesn't really understand what it's doing alone. And with that, let's jump into a quick demo. So you can see here, two dev environments up and running. First one here is the same container dev environment. So if I want to go into that, let's see what's going on in the various code button here. If that one open, I can get straight into my application to start making changes inside that dev container. And I've got all my dependencies in here, so I can just run that straight in that second application I have here is one that's opened up in compose, and I can see that I've also got my backend, my front end and my database. So I've got all my services running here. So if I want, I can open one or more of these in a dev environment, meaning that that container has the context that dev environment has the context of the whole application. >>So I can get back into and connect to all the other services that I need to test this application properly, all of them, one unit. And then when I've made my changes and I'm ready to share, I can hit my share button type in the refund them on to share that too. And then give that image to someone to get going, pick that up and just start working with that code and all my dependencies, simple as putting an image, looking ahead, we're going to be expanding development environments, more of your dependencies for the whole developer worst space. We want to look at backing up and letting you share your volumes to make data science and database setups more repeatable and going. I'm still all of this under a single workspace for your team containing images, your dev environments, your volumes, and more we've really want to allow you to create a fully portable Linux development environment. >>So everyone you're working with on any operating system, as I said, our MVP we're coming next month. And that was for vs code using their dev container primitive and more support for other ideas. We'll follow to find out more about what's happening and what's coming up next in the future of this. And to actually get a bit of a deeper dive in the experience. Can we check out the talk I'm doing with Georgie and girl later on today? Thank you, Ben, amazing story about how Docker is helping to make developer teams more collaborative. Now I'd like to talk more about applications while the dev environment is like the workbench around what you're building. The application itself has all the different components, libraries, and frameworks, and other code that make up the application itself. And we hear developers saying all the time things like, how do they know if their images are good? >>How do they know if they're secure? How do they know if they're minimal? How do they make great images and great Docker files and how do they keep their images secure? And up-to-date on every one of those ties into how do I create more trust? How do I know that I'm building high quality applications to enable you to do this even more effectively than today? We are pleased to announce the DACA verified polisher program. This broadens trusted content by extending beyond Docker official images, to give you more and more trusted building blocks that you can incorporate into your applications. It gives you confidence that you're getting what you expect because Docker verifies every single one of these publishers to make sure they are who they say they are. This improves our secure supply chain story. And finally it simplifies your discovery of the best building blocks by making it easy for you to find things that you know, you can trust so that you can incorporate them into your applications and move on and on the right. You can see some examples of the publishers that are involved in Docker, official images and our Docker verified publisher program. Now I'm pleased to introduce you to marina. Kubicki our senior product manager who will walk you through more about what we're doing to create a better experience for you around trust. >>Thank you, Dani, >>Mario Andretti, who is a famous Italian sports car driver. One said that if everything feels under control, you're just not driving. You're not driving fast enough. Maya Andretti is not a software developer and a software developers. We know that no matter how fast we need to go in order to drive the innovation that we're working on, we can never allow our applications to spin out of control and a Docker. As we continue talking to our, to the developers, what we're realizing is that in order to reach that speed, the developers are the, the, the development community is looking for the building blocks and the tools that will, they will enable them to drive at the speed that they need to go and have the trust in those building blocks. And in those tools that they will be able to maintain control over their applications. So as we think about some of the things that we can do to, to address those concerns, uh, we're realizing that we can pursue them in a number of different venues, including creating reliable content, including creating partnerships that expands the options for the reliable content. >>Um, in order to, in a we're looking at creating integrations, no link security tools, talk about the reliable content. The first thing that comes to mind are the Docker official images, which is a program that we launched several years ago. And this is a set of curated, actively maintained, open source images that, uh, include, uh, operating systems and databases and programming languages. And it would become immensely popular for, for, for creating the base layers of, of the images of, of the different images, images, and applications. And would we realizing that, uh, many developers are, instead of creating something from scratch, basically start with one of the official images for their basis, and then build on top of that. And this program has become so popular that it now makes up a quarter of all of the, uh, Docker poles, which essentially ends up being several billion pulse every single month. >>As we look beyond what we can do for the open source. Uh, we're very ability on the open source, uh, spectrum. We are very excited to announce that we're launching the Docker verified publishers program, which is continuing providing the trust around the content, but now working with, uh, some of the industry leaders, uh, in multiple, in multiple verticals across the entire technology technical spec, it costs entire, uh, high tech in order to provide you with more options of the images that you can use for building your applications. And it still comes back to trust that when you are searching for content in Docker hub, and you see the verified publisher badge, you know, that this is, this is the content that, that is part of the, that comes from one of our partners. And you're not running the risk of pulling the malicious image from an employee master source. >>As we look beyond what we can do for, for providing the reliable content, we're also looking at some of the tools and the infrastructure that we can do, uh, to create a security around the content that you're creating. So last year at the last ad, the last year's DockerCon, we announced partnership with sneak. And later on last year, we launched our DACA, desktop and Docker hub vulnerability scans that allow you the options of writing scans in them along multiple points in your dev cycle. And in addition to providing you with information on the vulnerability on, on the vulnerabilities, in, in your code, uh, it also provides you with a guidance on how to re remediate those vulnerabilities. But as we look beyond the vulnerability scans, we're also looking at some of the other things that we can do, you know, to, to, to, uh, further ensure that the integrity and the security around your images, your images, and with that, uh, later on this year, we're looking to, uh, launch the scope, personal access tokens, and instead of talking about them, I will simply show you what they look like. >>So if you can see here, this is my page in Docker hub, where I've created a four, uh, tokens, uh, read-write delete, read, write, read only in public read in public creeper read only. So, uh, earlier today I went in and I, I logged in, uh, with my read only token. And when you see, when I'm going to pull an image, it's going to allow me to pull an image, not a problem success. And then when I do the next step, I'm going to ask to push an image into the same repo. Uh, would you see is that it's going to give me an error message saying that they access is denied, uh, because there is an additional authentication required. So these are the things that we're looking to add to our roadmap. As we continue thinking about the things that we can do to provide, um, to provide additional building blocks, content, building blocks, uh, and, and, and tools to build the trust so that our DACA developer and skinned code faster than Mario Andretti could ever imagine. Uh, thank you to >>Thank you, marina. It's amazing what you can do to improve the trusted content so that you can accelerate your development more and move more quickly, move more collaboratively and build upon the great work of others. Finally, we hear over and over as that developers are working on their applications that they're looking for, environments that are consistent, that are the same as production, and that they want their applications to really run anywhere, any environment, any architecture, any cloud one great example is the recent announcement of apple Silicon. We heard from developers on uproar that they needed Docker to be available for that architecture before they could add those to it and be successful. And we listened. And based on that, we are pleased to share with you Docker, desktop on apple Silicon. This enables you to run your apps consistently anywhere, whether that's developing on your team's latest dev hardware, deploying an ARM-based cloud environments and having a consistent architecture across your development and production or using multi-year architecture support, which enables your whole team to collaborate on its application, using private repositories on Docker hub, and thrilled to introduce you to Hughie cower, senior director for product management, who will walk you through more of what we're doing to create a great developer experience. >>Senior director of product management at Docker. And I'd like to jump straight into a demo. This is the Mac mini with the apple Silicon processor. And I want to show you how you can now do an end-to-end arm workflow from my M one Mac mini to raspberry PI. As you can see, we have vs code and Docker desktop installed on a, my, the Mac mini. I have a small example here, and I have a raspberry PI three with an led strip, and I want to turn those LEDs into a moving rainbow. This Dockerfile here, builds the application. We build the image with the Docker, build X command to make the image compatible for all raspberry pies with the arm. 64. Part of this build is built with the native power of the M one chip. I also add the push option to easily share the image with my team so they can give it a try to now Dr. >>Creates the local image with the application and uploads it to Docker hub after we've built and pushed the image. We can go to Docker hub and see the new image on Docker hub. You can also explore a variety of images that are compatible with arm processors. Now let's go to the raspberry PI. I have Docker already installed and it's running Ubuntu 64 bit with the Docker run command. I can run the application and let's see what will happen from there. You can see Docker is downloading the image automatically from Docker hub and when it's running, if it's works right, there are some nice colors. And with that, if we have an end-to-end workflow for arm, where continuing to invest into providing you a great developer experience, that's easy to install. Easy to get started with. As you saw in the demo, if you're interested in the new Mac, mini are interested in developing for our platforms in general, we've got you covered with the same experience you've come to expect from Docker with over 95,000 arm images on hub, including many Docker official images. >>We think you'll find what you're looking for. Thank you again to the community that helped us to test the tech previews. We're so delighted to hear when folks say that the new Docker desktop for apple Silicon, it just works for them, but that's not all we've been working on. As Dani mentioned, consistency of developer experience across environments is so important. We're introducing composed V2 that makes compose a first-class citizen in the Docker CLI you no longer need to install a separate composed biter in order to use composed, deploying to production is simpler than ever with the new compose integration that enables you to deploy directly to Amazon ECS or Azure ACI with the same methods you use to run your application locally. If you're interested in running slightly different services, when you're debugging versus testing or, um, just general development, you can manage that all in one place with the new composed service to hear more about what's new and Docker desktop, please join me in the three 15 breakout session this afternoon. >>And now I'd love to tell you a bit more about bill decks and convince you to try it. If you haven't already it's our next gen build command, and it's no longer experimental as shown in the demo with built X, you'll be able to do multi architecture builds, share those builds with your team and the community on Docker hub. With build X, you can speed up your build processes with remote caches or build all the targets in your composed file in parallel with build X bake. And there's so much more if you're using Docker, desktop or Docker, CE you can use build X checkout tonus is talk this afternoon at three 45 to learn more about build X. And with that, I hope everyone has a great Dr. Khan and back over to you, Donnie. >>Thank you UA. It's amazing to hear about what we're doing to create a better developer experience and make sure that Docker works everywhere you need to work. Finally, I'd like to wrap up by showing you everything that we've announced today and everything that we've done recently to make your lives better and give you more and more for the single price of your Docker subscription. We've announced the Docker verified publisher program we've announced scoped personal access tokens to make it easier for you to have a secure CCI pipeline. We've announced Docker dev environments to improve your collaboration with your team. Uh, we shared with you Docker, desktop and apple Silicon, to make sure that, you know, Docker runs everywhere. You need it to run. And we've announced Docker compose version two, finally making it a first-class citizen amongst all the other great Docker tools. And we've done so much more recently as well from audit logs to advanced image management, to compose service profiles, to improve where you can run Docker more easily. >>Finally, as we look forward, where we're headed in the upcoming year is continuing to invest in these themes of helping you build, share, and run modern apps more effectively. We're going to be doing more to help you create a secure supply chain with which only grows more and more important as time goes on. We're going to be optimizing your update experience to make sure that you can easily understand the current state of your application, all its components and keep them all current without worrying about breaking everything as you're doing. So we're going to make it easier for you to synchronize your work. Using cloud sync features. We're going to improve collaboration through dev environments and beyond, and we're going to do make it easy for you to run your microservice in your environments without worrying about things like architecture or differences between those environments. Thank you so much. I'm thrilled about what we're able to do to help make your lives better. And now you're going to be hearing from one of our customers about what they're doing to launch their business with Docker >>I'm Matt Falk, I'm the head of engineering and orbital insight. And today I want to talk to you a little bit about data from space. So who am I like many of you, I'm a software developer and a software developer about seven companies so far, and now I'm a head of engineering. So I spend most of my time doing meetings, but occasionally I'll still spend time doing design discussions, doing code reviews. And in my free time, I still like to dabble on things like project oiler. So who's Oberlin site. What do we do? Portal insight is a large data supplier and analytics provider where we take data geospatial data anywhere on the planet, any overhead sensor, and translate that into insights for the end customer. So specifically we have a suite of high performance, artificial intelligence and machine learning analytics that run on this geospatial data. >>And we build them to specifically determine natural and human service level activity anywhere on the planet. What that really means is we take any type of data associated with a latitude and longitude and we identify patterns so that we can, so we can detect anomalies. And that's everything that we do is all about identifying those patterns to detect anomalies. So more specifically, what type of problems do we solve? So supply chain intelligence, this is one of the use cases that we we'd like to talk about a lot. It's one of our main primary verticals that we go after right now. And as Scott mentioned earlier, this had a huge impact last year when COVID hit. So specifically supply chain intelligence is all about identifying movement patterns to and from operating facilities to identify changes in those supply chains. How do we do this? So for us, we can do things where we track the movement of trucks. >>So identifying trucks, moving from one location to another in aggregate, same thing we can do with foot traffic. We can do the same thing for looking at aggregate groups of people moving from one location to another and analyzing their patterns of life. We can look at two different locations to determine how people are moving from one location to another, or going back and forth. All of this is extremely valuable for detecting how a supply chain operates and then identifying the changes to that supply chain. As I said last year with COVID, everything changed in particular supply chains changed incredibly, and it was hugely important for customers to know where their goods or their products are coming from and where they were going, where there were disruptions in their supply chain and how that's affecting their overall supply and demand. So to use our platform, our suite of tools, you can start to gain a much better picture of where your suppliers or your distributors are going from coming from or going to. >>So what's our team look like? So my team is currently about 50 engineers. Um, we're spread into four different teams and the teams are structured like this. So the first team that we have is infrastructure engineering and this team largely deals with deploying our Dockers using Kubernetes. So this team is all about taking Dockers, built by other teams, sometimes building the Dockers themselves and putting them into our production system, our platform engineering team, they produce these microservices. So they produce microservice, Docker images. They develop and test with them locally. Their entire environments are dockerized. They produce these doctors, hand them over to him for infrastructure engineering to be deployed. Similarly, our product engineering team does the same thing. They develop and test with Dr. Locally. They also produce a suite of Docker images that the infrastructure team can then deploy. And lastly, we have our R and D team, and this team specifically produces machine learning algorithms using Nvidia Docker collectively, we've actually built 381 Docker repositories and 14 million. >>We've had 14 million Docker pools over the lifetime of the company, just a few stats about us. Um, but what I'm really getting to here is you can see actually doctors becoming almost a form of communication between these teams. So one of the paradigms in software engineering that you're probably familiar with encapsulation, it's really helpful for a lot of software engineering problems to break the problem down, isolate the different pieces of it and start building interfaces between the code. This allows you to scale different pieces of the platform or different pieces of your code in different ways that allows you to scale up certain pieces and keep others at a smaller level so that you can meet customer demands. And for us, one of the things that we can largely do now is use Dockers as that interface. So instead of having an entire platform where all teams are talking to each other, and everything's kind of, mishmashed in a monolithic application, we can now say this team is only able to talk to this team by passing over a particular Docker image that defines the interface of what needs to be built before it passes to the team and really allows us to scalp our development and be much more efficient. >>Also, I'd like to say we are hiring. Um, so we have a number of open roles. We have about 30 open roles in our engineering team that we're looking to fill by the end of this year. So if any of this sounds really interesting to you, please reach out after the presentation. >>So what does our platform do? Really? Our platform allows you to answer any geospatial question, and we do this at three different inputs. So first off, where do you want to look? So we did this as what we call an AOI or an area of interest larger. You can think of this as a polygon drawn on the map. So we have a curated data set of almost 4 million AOIs, which you can go and you can search and use for your analysis, but you're also free to build your own. Second question is what you want to look for. We do this with the more interesting part of our platform of our machine learning and AI capabilities. So we have a suite of algorithms that automatically allow you to identify trucks, buildings, hundreds of different types of aircraft, different types of land use, how many people are moving from one location to another different locations that people in a particular area are moving to or coming from all of these different analyses or all these different analytics are available at the click of a button, and then determine what you want to look for. >>Lastly, you determine when you want to find what you're looking for. So that's just, uh, you know, do you want to look for the next three hours? Do you want to look for the last week? Do you want to look every month for the past two, whatever the time cadence is, you decide that you hit go and out pops a time series, and that time series tells you specifically where you want it to look what you want it to look for and how many, or what percentage of the thing you're looking for appears in that area. Again, we do all of this to work towards patterns. So we use all this data to produce a time series from there. We can look at it, determine the patterns, and then specifically identify the anomalies. As I mentioned with supply chain, this is extremely valuable to identify where things change. So we can answer these questions, looking at a particular operating facility, looking at particular, what is happening with the level of activity is at that operating facility where people are coming from, where they're going to, after visiting that particular facility and identify when and where that changes here, you can just see it's a picture of our platform. It's actually showing all the devices in Manhattan, um, over a period of time. And it's more of a heat map view. So you can actually see the hotspots in the area. >>So really the, and this is the heart of the talk, but what happened in 2020? So for men, you know, like many of you, 2020 was a difficult year COVID hit. And that changed a lot of what we're doing, not from an engineering perspective, but also from an entire company perspective for us, the motivation really became to make sure that we were lowering our costs and increasing innovation simultaneously. Now those two things often compete with each other. A lot of times you want to increase innovation, that's going to increase your costs, but the challenge last year was how to do both simultaneously. So here's a few stats for you from our team. In Q1 of last year, we were spending almost $600,000 per month on compute costs prior to COVID happening. That wasn't hugely a concern for us. It was a lot of money, but it wasn't as critical as it was last year when we really needed to be much more efficient. >>Second one is flexibility for us. We were deployed on a single cloud environment while we were cloud thought ready, and that was great. We want it to be more flexible. We want it to be on more cloud environments so that we could reach more customers. And also eventually get onto class side networks, extending the base of our customers as well from a custom analytics perspective. This is where we get into our traction. So last year, over the entire year, we computed 54,000 custom analytics for different users. We wanted to make sure that this number was steadily increasing despite us trying to lower our costs. So we didn't want the lowering cost to come as the sacrifice of our user base. Lastly, of particular percentage here that I'll say definitely needs to be improved is 75% of our projects never fail. So this is where we start to get into a bit of stability of our platform. >>Now I'm not saying that 25% of our projects fail the way we measure this is if you have a particular project or computation that runs every day and any one of those runs sale account, that is a failure because from an end-user perspective, that's an issue. So this is something that we know we needed to improve on and we needed to grow and make our platform more stable. I'm going to something that we really focused on last year. So where are we now? So now coming out of the COVID valley, we are starting to soar again. Um, we had, uh, back in April of last year, we had the entire engineering team. We actually paused all development for about four weeks. You had everyone focused on reducing our compute costs in the cloud. We got it down to 200 K over the period of a few months. >>And for the next 12 months, we hit that number every month. This is huge for us. This is extremely important. Like I said, in the COVID time period where costs and operating efficiency was everything. So for us to do that, that was a huge accomplishment last year and something we'll keep going forward. One thing I would actually like to really highlight here, two is what allowed us to do that. So first off, being in the cloud, being able to migrate things like that, that was one thing. And we were able to use there's different cloud services in a more particular, in a more efficient way. We had a very detailed tracking of how we were spending things. We increased our data retention policies. We optimized our processing. However, one additional piece was switching to new technologies on, in particular, we migrated to get lab CICB. >>Um, and this is something that the costs we use Docker was extremely, extremely easy. We didn't have to go build new new code containers or repositories or change our code in order to do this. We were simply able to migrate the containers over and start using a new CIC so much. In fact, that we were able to do that migration with three engineers in just two weeks from a cloud environment and flexibility standpoint, we're now operating in two different clouds. We were able to last night, I've over the last nine months to operate in the second cloud environment. And again, this is something that Docker helped with incredibly. Um, we didn't have to go and build all new interfaces to all new, different services or all different tools in the next cloud provider. All we had to do was build a base cloud infrastructure that ups agnostic the way, all the different details of the cloud provider. >>And then our doctors just worked. We can move them to another environment up and running, and our platform was ready to go from a traction perspective. We're about a third of the way through the year. At this point, we've already exceeded the amount of customer analytics we produce last year. And this is thanks to a ton more albums, that whole suite of new analytics that we've been able to build over the past 12 months and we'll continue to build going forward. So this is really, really great outcome for us because we were able to show that our costs are staying down, but our analytics and our customer traction, honestly, from a stability perspective, we improved from 75% to 86%, not quite yet 99 or three nines or four nines, but we are getting there. Um, and this is actually thanks to really containerizing and modularizing different pieces of our platform so that we could scale up in different areas. This allowed us to increase that stability. This piece of the code works over here, toxin an interface to the rest of the system. We can scale this piece up separately from the rest of the system, and that allows us much more easily identify issues in the system, fix those and then correct the system overall. So basically this is a summary of where we were last year, where we are now and how much more successful we are now because of the issues that we went through last year and largely brought on by COVID. >>But that this is just a screenshot of the, our, our solution actually working on supply chain. So this is in particular, it is showing traceability of a distribution warehouse in salt lake city. It's right in the center of the screen here. You can see the nice kind of orange red center. That's a distribution warehouse and all the lines outside of that, all the dots outside of that are showing where people are, where trucks are moving from that location. So this is really helpful for supply chain companies because they can start to identify where their suppliers are, are coming from or where their distributors are going to. So with that, I want to say, thanks again for following along and enjoy the rest of DockerCon.