>>Good afternoon, brilliant humans, and welcome back to the Cube. We're live in Detroit, Michigan at Cub Con, and I'm joined by John Furrier. John three exciting days buzzing. How you doing? >>That's great. I mean, we're coming down to the third day. We're keeping the energy going, but this segment's gonna be awesome. The CD foundation's doing amazing work. Developers are gonna be running businesses and workflows are changing. Productivity's the top conversation, and you're gonna start to see a coalescing of the communities who are continuous delivery, and it's gonna be awesome. >>And, and our next guess is an outstanding person to talk about this. We are joined by Stephen Chin, the chair of the CD Foundation. Steven, thanks so much for being here. >>No, no, my pleasure. I mean, this has been an amazing week quote that CubeCon with all of the announcements, all of the people who came out here to Detroit and, you know, fantastic. Like just walking around, you bump into all the right people here. Plus we held a CD summit zero day events, and had a lot of really exciting announcements this week. >>Gotta love the shirt. I gotta say, it's one of my favorites. Love the logos. Love the love the branding. That project got traction. What's the news in the CD foundation? I tried to sneak in the back. I got a little laid into your co-located event. It was packed. Everyone's engaged. It was really looked, look really cool. Give us the update. >>What's the news? Yeah, I know. So we, we had a really, really powerful event. All the key practitioners, the open source leads and folks were there. And one of, one of the things which I think we've done a really good job in the past six months with the CD foundation is getting back to the roots and focusing on technical innovation, right? This is what drives foundations, having strong projects, having people who are building innovation, and also bringing in a new innovation. So one of the projects which we added to the CD foundation this week is called Persia. So it's a, it's a decentralized package repository for getting open source libraries. And it solves a lot of the problems which you get when you have centralized infrastructure. You don't have the right security certificates, you don't have the right verification libraries. And these, these are all things which large companies provision and build out inside of their infrastructure. But the open source communities don't have the benefit of the same sort of really, really strong architecture. A lot of, a lot of the systems we depend upon. It's >>A good point, yeah. >>Yeah. I mean, if you think about the systems that developers depend upon, we depend upon, you know, npm, ruby Gems, Mayn Central, and these systems been around for a while. Like they serve the community well, right? They're, they're well supported by the companies and it's, it's, it's really a great contribution that they give us. But every time there's an outage or there's a security issue, guess, guess how many security issues that our, our research team found at npm? Just ballpark. >>74. >>So there're >>It's gotta be thousands. I mean, it's gotta be a lot of tons >>Of Yeah, >>They, they're currently up to 60,000 >>Whoa. >>Vulnerable, malicious packages in NPM and >>Oh my gosh. So that's a super, that's a jar number even. I know it was gonna be huge, but Holy mo. >>Yeah. So that's a software supply chain in actually right there. So that's, that's open source. Everything's out there. What's, how do, how does, how do you guys fix that? >>Yeah, so per peria kind of shifts the whole model. So when, when you think about a system that can be sustained, it has to be something which, which is not just one company. It has to be a, a, a set of companies, be vendor neutral and be decentralized. So that's why we donated it to the Continuous Delivery Foundation. So that can be that governance body, which, which makes sure it's not a single company, it is to use modern technologies. So you, you, you just need something which is immutable, so it can't be changed. So you can rely on it. It has to have a strong transaction ledger so you can see all of the history of it. You can build up your software, build materials off of it, and it, it has to have a strong peer-to-peer architecture, so it can be sustained long term. >>Steven, you mentioned something I want to just get back to. You mentioned outages and disruption. I, you didn't, you didn't say just the outages, but this whole disruption angle is interesting if something happens. Talk about the impact of the developer. They stalled, inefficiencies create basically disruption. >>No, I mean, if, if, so, so if you think about most DevOps teams in big companies, they support hundreds or thousands of teams and an hour of outage. All those developers, they, they can't program, they can't work. And that's, that's a huge loss of productivity for the company. Now, if you, if you take that up a level when MPM goes down for an hour, how many millions of man hours are wasted by not being able to get your builds working by not being able to get your codes to compile. Like it's, it's >>Like, yeah, I mean, it's almost hard to fathom. I mean, everyone's, It's stopped. Exactly. It's literally like having the plug pulled >>Exactly on whenever you're working on, That's, that's the fundamental problem we're trying to solve. Is it, it needs to be on a, like a well supported, well architected peer to peer network with some strong backing from big companies. So the company is working on Persia, include J Frog, which who I work for, Docker, Oracle. We have Deploy hub, Huawei, a whole bunch of other folks who are also helping out. And when you look at all of those folks, they all have different interests, but it's designed in a way where no single party has control over the network. So really it's, it's a system system. You, you're not relying upon one company or one logo. You're relying upon a well-architected open source implementation that everyone can rely >>On. That's shared software, but it's kind of a fault tolerant feature too. It's like, okay, if something happens here, you have a distributed piece of it, decentralized, you're not gonna go down. You can remediate. All right, so where's this go next? I mean, cuz we've been talking about the role of developer. This needs to be a modern, I won't say modern upgrade, but like a modern workflow or value chain. What's your vision? How do you see that? Cuz you're the center of the CD foundation coming together. People are gonna be coalescing multiple groups. Yeah. >>What's the, No, I think this is a good point. So there, there's a, a lot of different continuous delivery, continuous integration technologies. We're actually, from a Linux Foundation standpoint, we're coalescing all the continued delivery events into one big conference >>Next. You just made an announcement about this earlier this week. Tell us about CD events. What's going on, what's in, what's in the cooker? >>Yeah, and I think one of the big announcements we had was the 0.1 release of CD events. And CD events allows you to take all these systems and connect them in an event scalable, event oriented architecture. The first integration is between Tecton and Capin. So now you can get CD events flowing cleanly between your, your continuous delivery and your observability. And this extends through your entire DevOps pipeline. We all, we all need a standards based framework Yep. For how we get all the disparate continuous integration, continuous delivery, observability systems to, to work together. That's also high performance. It scales with our needs and it, it kind of gives you a future architecture to build on top of. So a lot of the companies I was talking with at the CD summit Yeah. They were very excited about not only using this with the projects we announced, but using this internally as an architecture to build their own DevOps pipelines on. >>I bet that feels good to hear. >>Yeah, absolutely. Yeah. >>Yeah. You mentioned Teton, they just graduated. I saw how many projects have graduated? >>So we have two graduated projects right now. We have Jenkins, which is the first graduated project. Now Tecton is also graduated. And I think this shows that for Tecton it was, it was time, the very mature project, great support, getting a lot of users and having them join the set of graduated projects. And the continuous delivery foundation is a really strong portfolio. And we have a bunch of other projects which also are on their way towards graduation. >>Feels like a moment of social proof I bet. >>For you all. Yeah, yeah. Yeah. No, it's really good. Yeah. >>How long has the CD Foundation been around? >>The CD foundation has been around for, i, I won't wanna say the exact number of years, a few years now. >>Okay. >>But I, I think that it, it was formed because what we wanted is we wanted a foundation which was purpose built. So CNCF is a great foundation. It has a very large umbrella of projects and it takes kind of that big umbrella approach where a lot of different efforts are joining it, a lot of things are happening and you can get good traction, but it produces its own bottlenecks in process. Having a foundation which is just about continuous delivery caters to more of a DevOps, professional DevOps audience. I think this, this gives a good platform for best practices. We're working on a new CDF best practices Yeah. Guide. We're working when use cases with all the member companies. And it, it gives that thought leadership platform for continuous delivery, which you need to be an expert in that area >>And the best practices too. And to identify the issues. Because at the end of the day, with the big thing that's coming out of this is velocity and more developers coming on board. I mean, this is the big thing. More people doing more. Yeah. Well yeah, I mean you take this open source continuous thunder away, you have more developers coming in, they be more productive and then people are gonna even either on the DevOps side or on the straight AP upside. And this is gonna be a huge issue. And the other thing that comes out that I wanna get your thoughts on is the supply chain issue you talked about is hot verifications and certifications of code is such big issue. Can you share your thoughts on that? Because Yeah, this is become, I won't say a business model for some companies, but it's also becoming critical for security that codes verified. >>Yeah. Okay. So I, I think one of, one of the things which we're specifically doing with the Peria project, which is unique, is rather than distributing, for example, libraries that you developed on your laptop and compiled there, or maybe they were built on, you know, a runner somewhere like Travis CI or GitHub actions, all the libraries being distributed on Persia are built by the authorized nodes in the network. And then they're, they're verified across all of the authorized nodes. So you nice, you have a, a gar, the basic guarantee we're giving you is when you download something from the Peria network, you'll get exactly the same binary as if you built it yourself from source. >>So there's a lot of trust >>And, and transparency. Yeah, exactly. And if you remember back to like kind of the seminal project, which kicked off this whole supply chain security like, like whirlwind it was SolarWinds. Yeah. Yeah. And the exact problem they hit was the build ran, it produced a result, they modified the code of the bill of the resulting binary and then they signed it. So if you built with the same source and then you went through that same process a second time, you would've gotten a different result, which was a malicious pre right. Yeah. And it's very hard to risk take, to take a binary file Yep. And determine if there's malicious code in it. Cuz it's not like source code. You can't inspect it, you can't do a code audit. It's totally different. So I think we're solving a key part of this with Persia, where you're freeing open source projects from the possibility of having their binaries, their packages, their end reduces, tampered with. And also upstream from this, you do want to have verification of prs, people doing code reviews, making sure that they're looking at the source code. And I think there's a lot of good efforts going on in the open source security foundation. So I'm also on the governing board of Open ssf >>To Do you sleep? You have three jobs you've said on camera? No, I can't even imagine. Yeah. Didn't >>You just spin that out from this open source security? Is that the new one they >>Spun out? Yeah, So the Open Source Security foundation is one of the new Linux Foundation projects. They, they have been around for a couple years, but they did a big reboot last year around this time. And I think what they really did a good job of now is bringing all the industry players to the table, having dialogue with government agencies, figuring out like, what do we need to do to support open source projects? Is it more investment in memory, safe languages? Do we need to have more investment in, in code audits or like security reviews of opensource projects. Lot of things. And all of those things require money investments. And that's what all the companies, including Jay Frogger doing to advance open source supply chain security. I >>Mean, it's, it's really kind of interesting to watch some different demographics of the developers and the vendors and the customers. On one hand, if you're a hardware person company, you have, you talk zero trust your software, your top trust, so your trusted code, and you got zero trust. It's interesting, depending on where you're coming from, they're all trying to achieve the same thing. It means zero trust. Makes sense. But then also I got code, I I want trust. Trust and verified. So security is in everything now. So code. So how do you see that traversing over? Is it just semantics or what's your view on that? >>The, the right way of looking at security is from the standpoint of the hacker, because they're always looking for >>Well said, very well said, New >>Loop, hope, new loopholes, new exploits. And they're, they're very, very smart people. And I think when you, when you look some >>Of the smartest >>Yeah, yeah, yeah. I, I, I work with, well former hackers now, security researchers, >>They converted, they're >>Recruited. But when you look at them, there's like two main classes of like, like types of exploits. So some, some attacker groups. What they're looking for is they're looking for pulse zero days, CVEs, like existing vulnerabilities that they can exploit to break into systems. But there's an increasing number of attackers who are now on the opposite end of the spectrum. And what they're doing is they're creating their own exploits. So, oh, they're for example, putting malicious code into open source projects. Little >>Trojan horse status. Yeah. >>They're they're getting their little Trojan horses in. Yeah. Or they're finding supply chain attacks by maybe uploading a malicious library to NPM or to pii. And by creating these attacks, especially ones that start at the top of the supply chain, you have such a large reach. >>I was just gonna say, it could be a whole, almost gives me chills as we're talking about it, the systemic, So this is this >>Gnarly nation state attackers, like people who wanted serious >>Damages. Engineered hack just said they're high, highly funded. Highly skilled. Exactly. Highly agile, highly focused. >>Yes. >>Teams, team. Not in the teams. >>Yeah. And so, so one, one example of this, which actually netted quite a lot of money for the, for the hacker who exposed it was, you guys probably heard about this, but it was a, an attack where they uploaded a malicious library to npm with the same exact namespace as a corporate library and clever, >>Creepy. >>It's called a dependency injection attack. And what happens is if you, if you don't have the right sort of security package management guidelines inside your company, and it's just looking for the latest version of merging multiple repositories as like a, like a single view. A lot of companies were accidentally picking up the latest version, which was out in npm uploaded by Alex Spearson was the one who did the, the attack. And he simultaneously reported bug bounties on like a dozen different companies and netted 130 k. Wow. So like these sort of attacks that they're real Yep. They're exploitable. And the, the hackers >>Complex >>Are finding these sort of attacks now in our supply chain are the ones who really are the most dangerous. That's the biggest threat to us. >>Yeah. And we have stacker ones out there. You got a bunch of other services, the white hat hackers get the bounties. That's really important. All right. What's next? What's your vision of this show as we end Coan? What's the most important story coming outta Coan in your opinion? And what are you guys doing next? >>Well, I, I actually think this is, this is probably not what most hooks would say is the most exciting story to con, but I find this personally the best is >>I can't wait for this now. >>So, on, on Sunday, the CNCF ran the first kids' day. >>Oh. >>And so they had a, a free kids workshop for, you know, underprivileged kids for >>About, That's >>Detroit area. It was, it was taught by some of the folks from the CNCF community. So Arro, Eric hen my, my older daughter, Cassandra's also an instructor. So she also was teaching a raspberry pie workshop. >>Amazing. And she's >>Here and Yeah, Yeah. She's also here at the show. And when you think about it, you know, there's always, there's, there's, you know, hundreds of announcements this week, A lot of exciting technologies, some of which we've talked about. Yeah. But it's, it's really what matters is the community. >>It this is a community first event >>And the people, and like, if we're giving back to the community and helping Detroit's kids to get better at technology, to get educated, I think that it's a worthwhile for all of us to be here. >>What a beautiful way to close it. That is such, I'm so glad you brought that up and brought that to our attention. I wasn't aware of that. Did you know that was >>Happening, John? No, I know about that. Yeah. No, that was, And that's next generation too. And what we need, we need to get down into the elementary schools. We gotta get to the kids. They're all doing robotics club anyway in high school. Computer science is now, now a >>Sport, in my opinion. Well, I think that if you're in a privileged community, though, I don't think that every school's doing robotics. And >>That's why Well, Cal Poly, Cal Poly and the universities are stepping up and I think CNCF leadership is amazing here. And we need more of it. I mean, I'm, I'm bullish on this. I love it. And I think that's a really great story. No, >>I, I am. Absolutely. And, and it just goes to show how committed CNF is to community, Putting community first and Detroit. There has been such a celebration of Detroit this whole week. Stephen, thank you so much for joining us on the show. Best Wishes with the CD Foundation. John, thanks for the banter as always. And thank you for tuning in to us here live on the cube in Detroit, Michigan. I'm Savannah Peterson and we are having the best day. I hope you are too.

[Music] welcome back to aws storage day 2022 i'm dave vellante and we're pleased to have back on thecube edname the gm of aws file storage ed how you doing good to see you i'm good dave good good to see you as well you know we've been tracking aws storage for a lot of years 16 years actually we we've seen the evolution of services of course we started with s3 and object and saw that expand the block and file and and now the pace is actually accelerating and we're seeing aws make more moves again today and block an object but what about file uh it's one format in the world and the day wouldn't really be complete without talking about file storage so what are you seeing from customers in terms of let's start with data growth how are they dealing with the challenges what are those challenges if you could address you know specifically some of the issues that they're having that would be great and then later we're going to get into the role that cloud file storage plays take it away well dave i'm definitely increasingly hearing customers talk about the challenges in managing ever-growing data sets and they're especially challenged in doing that on-premises when we look at the data that's stored on premises zettabytes of data the fastest growing data sets consist of unstructured data that are stored as files and many cups have tens of petabytes or hundreds of petabytes or even exabytes of file data and this data is typically growing 20 30 percent a year and in reality on-premises models really designed to handle this amount of data in this type of growth and i'm not just talking about keeping up with hardware purchases and hardware floor space but a big part of the challenge is labor and talent to keep up with the growth they're seeing companies managing storage on-prem they really need an unprecedented number of skilled resources to manage the storage and these skill sets are in really high demand and they're in short supply and then another big part of the challenge that customers tell me all the time is that that operating at scale dealing with these ever-growing data sets at scale is really hard and it's not just hard in terms of the the people you need and the skill sets that you need but operating at scale presents net new challenges so for example it becomes increasingly hard to know what data you have and what storage media your data stored on when you have a massive amount of data that's spanning hundreds of thousands or uh thousands of applications and users and it's growing super fast each year and at scale you start seeing edge technical issues get triggered more commonly impacting your availability or your resiliency or your security and you start seeing processes that used to work when you were a much smaller scale no longer work it's just scale is hard it's really hard and then finally companies are wanting to do more with their fast growing data sets to get insights from it and they look at the machine learning and the analytics and the processing services and the compute power that they have at their fingertips on the cloud and having that data be in silos on-prem can really limit how they get the most out of their data you know i've been covering glad you brought up the skills gap i've been covering that quite extensively with my colleagues at etr you know our survey partner so that's a really important topic and we're seeing it across the board i mean really acute in cyber security but for sure just generally in i.t and frankly ceos they don't want to invest in training people to manage storage i mean it wasn't that long ago that managing loans was a was a talent and that's of course nobody does that anymore but they'd executives would much rather apply skills to get value from data so my specific question is what can be done what is aws doing to address this problem well with the growth of data that that we're seeing it it's just it's really hard for a lot of it teams to keep up with just the infrastructure management part that's needed so things like deploying capacity and provisioning resources and patching and conducting compliance reviews and that stuff is just table stakes the asks on these teams to your point are growing to be much bigger than than those pieces so we're really seeing fast uptake of our amazon fsx service because it's such an easy path for helping customers with these scaling challenges fsx enables customers to launch and to run and to scale feature rich and highly performant network attached file systems on aws and it provides fully managed file storage which means that we handle all of the infrastructure so all of that provisioning and that patching and ensuring high availability and customers simply make api calls to do things like scale up their storage or change their performance level at any point or change a backup policy and a big part of why fsx has been so feeling able to customers is it really enables them to to choose the file system technology that powers their storage so we provide four of the most popular file system technologies we provide windows file server netapp ontap open zfs and luster so that storage and application admins can use what they're familiar with so they essentially get the full capabilities and even the management clis that they're used to and that they've built workflows and applications around on-premises but they get along with that of course the benefits of fully managed elastic cloud storage that can be spin up and spun spin down and scaled on demand and performance changed on demand etc and what storage and application admins are seeing is that fsx not only helps them keep up with their scale and growth but it gives them the bandwidth to do more of what they want to do supporting strategic decision making helping their end customers figure out how they can get more value from their data identifying opportunities to reduce cost and what we realize is that for for a number of storage and application admins the cloud is is a different environment from what they're used to and we're making it a priority to help educate and train folks on cloud storage earlier today we talked about aws storage digital badges and we announced a dedicated file badge that helps storage admins and professionals to learn and demonstrate their aws skills in our aws storage badges you can think of them as credentials that represent cloud computing learning that customers can add to their repertoire add to their resume as they're embarking on this cloud journey and we'll be talking more in depth on this later today especially around the file badge which i'm very excited about so a couple things there that i wanted to comment on i mean i was there for the netapp you know your announcement we've covered that quite extensively this is just shows that it's not a zero-sum game necessarily right it's a win-win-win for customers you've got your you know specific aws services you've got partner services you know customers want want choice and then the managed service model you know to me is a no-brainer for most customers we learned this in the hadoop years i mean it just got so complicated then you saw what happened with the managed services around you know data lakes and lake houses it's just really simplified things for customers i mean there's still some customers that want to do it yourself but a managed service for the file storage sounds like a really easy decision especially for those it teams that are overburdened as we were talking about before and i also like you know the education component is nice touch too you get the badge thing so that's kind of cool so i'm hearing that if the fully managed file storage service is a catalyst for cloud adoption so the question is which workloads should people choose to move into the cloud where's the low friction low risk sweet spot ed well that's one of the first questions that customers ask when they're about to embark on their cloud journey and i wish i could give a simple or a single answer but the answer is really it varies and it varies per customer and i'll give you an example for some customers the cloud journey begins with what we call extending on-premises workloads into the cloud so an example of that is compute bursting workloads where customers have data on premises and they have some compute on premises but they want to burst their processing of that data to the cloud because they really want to take advantage of the massive amount of compute that they get on aws and that's common with workloads like visual effects ringer chip design simulation genomics analysis and so that's an example of extending to the cloud really leveraging the cloud first for your workloads another example is disaster recovery and that's a really common example customers will use a cloud for their secondary or their failover site rather than maintaining their their second on-prem location and so that's a lot of customers start with some of those workloads by extending to the cloud and then there's there's a lot of other customers where they've made the decision to migrate most or all of their workloads and they're not they're skipping the whole extending step they aren't starting there they're instead focused on going all in as fast as possible because they really want to get to the full benefits of the cloud as fast as possible and for them the migration journey is really it's a matter of sequencing sequencing which specific workloads to move and when and what's interesting is we're increasingly seeing customers prioritizing their most important and their most mission-critical applications ahead of their other workloads in terms of timing and they're they're doing that to get their workloads to benefit from the added resilience they get from running on the cloud so really it really does uh depend dave yeah thank you i mean that's pretty pretty good description of the options there and i i just come something you know bursting obviously i love those examples you gave around genomics chip design visual effects rendering the dr piece is again very common sort of cloud you know historical you know sweet spots for cloud but then the point about mission critical is interesting because i hear a lot of customers especially with the digital transformation push wanting to change their operating model i mean on the one hand not changing things put it in the cloud the lift and shift you have to change things low friction but then once they get there they're like wow we can do a lot more with the cloud so that was really helpful those those examples now last year at storage day you released a new file service and then you followed that up at re-event with another file service introduction sometimes i can admit i get lost in the array of services so help us understand when a customer comes to aws with like an nfs or an smb workload how do you steer them to the right managed service you know the right horse for the right course yeah well i'll start by saying uh you know a big part of our focus has been in providing choice to customers and what customers tell us is that the spectrum of options that we provide to them really helps them in their cloud journey because there really isn't a one-size-fits-all file system for all workloads and so having these options actually really helps them to to be able to move pretty easily to the cloud um and so my answer to your question about uh where do we steer a customer when they have a file workload is um it really depends on what the customer is trying to do and uh in many cases where they're coming from so i'll walk you through a little bit of of of how we think about this with customers so for storage and application admins who are extending existing workloads to the cloud or migrating workloads to aws the easiest path generally is to move to an fsx file system that provides the same or really similar underlying file system engine that they use on premises so for example if you're running a netapp appliance on premises or a windows file server on premises choosing that option within fsx provides the least effort for a customer to lift their application and their data set and they'll get the full safe set of capabilities that they're used to they'll get the performance profiles that they're used to but of course they'll get all the benefits of the cloud that i was talking about earlier like spin up and spin down and fully managed and elastic capacity then we also provide open source file systems within the fsx family so if you're a customer and you're used to those or if you aren't really wedded to a particular file system technology these are really good options and they're built on top of aws's latest infrastructure innovations which really allows them to provide pretty significant price and performance benefits to customers so for example the file system file servers for these offerings are powered by aws's graviton family of processors and under the hood we use storage technology that's built on top of aws's scalable reliable datagram transport protocol which really optimizes for for speed on the cloud and so for those two open source file systems we have open zfs and that provides a really powerful highly performant nfs v3 and v4 and 4.1 and 4.2 file system built on a fast and resilient open source linux file system it has a pretty rich set of capabilities it has things like point-to-time snapshots and in-place data cloning and our customers are really using it because of these capabilities and because of its performance for a pretty broad set of enterprise i.t workloads and vertically focused workloads like within the financial services space and the healthcare life sciences space and then luster is a scale-out file system that's built on the world's most popular high-performance file system which is the luster open source file system and customers are using it for compute intensive workloads where they're throwing tons of compute at massive data sets and they need to drive tens or hundreds of gigabytes per second of throughput it's really popular for things like machine learning training and high performance computing big data analytics video rendering and transcoding so really those scale out compute intensive workloads and then we have a very different type of customer very different persona and this is the individual that we call the aws builder and these are folks who are running cloud native workloads they leverage a broad spectrum of aws's compute and analytic services and they have really no history of on-prem examples are data scientists who require a file share for training sets research scientists who are performing analysis on lab data developers who are building containerized or serverless workloads and cloud practitioners who need a simple solution for storing assets for their cloud workflows and and these these folks are building and running a wide range of data focused workloads and they've grown up using services like lambda and building containerized workloads so most of these individuals generally are not storage experts and they look for storage that just works s3 and consumer file shares uh like dropbox are their reference point for how cloud storage works and they're indifferent to or unaware of bio protocols like smb or nfs and performing typical nas administrative tasks is just not it's not a natural experience for them it's not something they they do and we built amazon efs to meet the needs of that group it's fully elastic it's fully serverless spreads data across multiple availability zones by default it scales infinitely it works very much like s3 so for example you get the same durability and availability profile of s3 you get intelligent tiering of colder data just like you do on s3 so that service just clicks with cloud native practitioners it's it's intuitive and it just works there's mind-boggling the number of use cases you just went through and this is where it's so you know it's you know a lot of times people roll their eyes oh here's amazon talking about you know customer obsession again but if you don't stay close to your customers there's no way you could have predicted when you're building these services how they were going to be put to use the only way you can understand it is watch what customers do with it i loved the conversation about graviton we've written about that a lot i mean nitro we've written about that how it's you've completely rethought virtualization the security components in there the hpc luster piece and and the efs for data scientists so really helpful there thank you i'm going to change uh topics a little bit because there's been this theme that you've been banging on at storage day putting data to work and i tell you it's a bit of a passion of mine ed because frankly customers have been frustrated with the return on data initiatives it's been historically complicated very time consuming and expensive to really get value from data and often the business lines end up frustrated so let's talk more about that concept and i understand you have an announcement that fits with this scene can you tell us more about that absolutely today we're announcing a new service called amazon file cache and it's a service on aws that accelerates and simplifies hybrid workflows and specifically amazon file cache provides a high speed cache on aws that makes it easier to process file data regardless of where the data is stored and amazon file cache serves as a temporary high performance storage location and it's for data that's stored in on-premise file servers or in file systems or object stores in aws and what it does is it enables enterprises to make these dispersed data sets available to file based applications on aws with a unified view and at high speeds so think of sub millisecond latencies and and tens or hundreds of gigabytes per second of throughput and so a really common use case it supports is if you have data stored on premises and you want to burst the processing workload to the cloud you can set up this cache on aws and it allows you to have the working set for your compute workload be cached near your aws compute so what you would do as a customer when you want to use this is you spin up this cache you link it to one or more on-prem nfs file servers and then you mount this cache to your compute instances on aws and when you do this all of your on-prem data will appear up automatically as folders and files on the cache and when your aws compute instances access a file for the first time the cache downloads the data that makes up that file in real time and that data then would reside on the cache as you work with it and when it's in the cache your application has access to that data at those sub millisecond latencies and at up to hundreds of gigabytes per second of throughput and all of this data movement is done automatically and in the background completely transparent to your application that's running on the compute instances and then when you're done with your workload with your data processing job you can export the changes and all the new data back to your on-premises file servers and then tear down the cache another common use case is if you have a compute intensive file-based application and you want to process a data set that's in one or more s3 buckets you can have this cache serve as a really high speed layer that your compute instances mount as a network file system you can also place this cache in front of a mix of on-prem file servers and s3 buckets and even fsx file systems that are on aws all of the data from these locations will appear within a single name space that clients that mount the cache have access to and those clients get all the performance benefits of the cache and also get a unified view of their data sets and and to your point about listening to customers and really paying attention to customers dave we built this service because customers asked us to a lot of customers asked us to actually it's a really helpful enable enabler for a pretty wide variety of cloud bursting workloads and hybrid workflows ranging from media rendering and transcoding to engineering design simulation to big data analytics and it really aligns with that theme of extend that we were talking about earlier you know i often joke that uh aws has the best people working on solving the speed of light problem so okay but so this idea of bursting as i said has been a great cloud use case from the early days and and bringing it to file storage is very sound and approach with file cache looks really practical um when is the service available how can i get started you know bursting to aws give us the details there yeah well stay tuned we we announced it today at storage day and it will be generally available later this year and once it becomes available you can create a cache via the the aws management console or through the sdks or the cli and then within minutes of creating the cache it'll be available to your linux instances and your instances will be able to access it using standard file system mount commands and the pricing model is going to be a pretty familiar one to cloud customers customers will only pay for the cash storage and the performance they need and they can spin a cash up and use it for the duration of their compute burst workload and then tear it down so i'm really excited that amazon file cache will make it easier for customers to leverage the agility and the performance and the cost efficiency of aws for processing data no matter where the data is stored yeah cool really interested to see how that gets adopted ed always great to catch up with you as i said the pace is mind-boggling it's accelerating in the cloud overall but storage specifically so by asking us can we take a little breather here can we just relax for a bit and chill out uh not as long as customers are asking us for more things so there's there's more to come for sure all right ed thanks again great to see you i really appreciate your time thanks dave great catching up okay and thanks for watching our coverage of aws storage day 2022 keep it right there for more in-depth conversations on thecube your leader in enterprise and emerging tech coverage [Music] you

(upbeat music) >> Hey, guys and girls, welcome back to New York City. Lisa Martin and John Furrier are live with theCUBE at AWS Summit 22, here in The Big Apple. We're excited to be talking about security next. James Arlen joins us, the CISO at Aiven. James, thanks so much for joining us on theCUBE today. >> Absolutely, it's good to be here. >> Tell the audience a little bit about Aiven, what you guys do, what you deliver, and what some of those differentiators are. >> Oh, Aiven. Aiven is a fantastic organization. I'm actually really lucky to work there. It's a database as a service, managed databases, all open source. And we're capital S, serious about open source. So 10 different open source database products delivered as a platform, all managed services, and the game is really about being the most performant, secure, and compliant database as a service on the market, friction free for your developers. You don't need people worrying about how to run databases. You just want to be able to say, here, take care of my data for me. And that's what we do. And that's actually the differentiator. We just take care of it for you. >> Take care of it for you, I like that. >> So they download the open source. They could do it on their own. So all the different projects are out there. >> Yeah, absolutely. >> What do you guys bringing to the table? You said the managed service, can you explain that. >> Yeah, the managed service aspect of it is, really, you could install the software yourself. You can use Postgres or Apache Kafka or any one of the products that we support. Absolutely you can do it yourself. But is that really what you do for a living, or do you develop software, or do you sell a product? So we take and do the hard work of running the systems, running the equipment. We take care of backups, high availability, all the security and compliance things around access and certifications, all of those things that are logging, all of that stuff that's actually difficult to do, well and consistently, that's all we do. >> Talk about the momentum, I see you guys were founded in what? 2016? >> Yes. >> Just in May of '22, raised $210 million in series D funding. >> Yes. >> Talk about the momentum and also from your perspective, all of the massive changes in security. >> It's very interesting to work for a company where you're building more than 100% growth year over year. It's a powers of two thing. Going from one to two, not so scary, two to four, not so scary. 512 to 1024, it's getting scary. (Lisa chuckles) 1024 to 2048, oh crap! I've been with Aiven for just almost two years now, and we are less than 70 when I started, and we're near 500 now. So, explosive growth is very interesting, but it's also that, you're growing within a reasonable burn rate boundary as well. And what that does from a security perspective, is it leaves you in the position that I had. I walked in and I was the first actual CISO. I had a team of four, I now have a team of 40. Because it turns out that like a lot of things in life, as you start unpacking problems, they're kind of fractal. You unpack the problem, you're like oh, well I did deal with that problem, but now I got another problem that I got to deal with. And so there's, it's not turtles all the way down. >> There's a lot of things going on and other authors, survive change. >> And there's fundamental problems that are still not fixed. And yet we treat them like they're fixed. And so we're doing a lot of hard work to make it so that we don't have to do hard work ongoing. >> And that's the value of the managed service. >> Yes. >> Okay, so talk about competition. Obviously, we had ETR on which is Enterprise Research Firm that we trust, we like. And we were looking at the data with the headwinds in the market, looking at the different players like got Amazon has Redshift, Snowflake, and you got Azure Sequence. I think it's called one of those products. The money that's being shifted from on premise data where the old school data warehouse like terra data and whatnot, is going first to Snowflake, then to Azure, then to AWS. Yes, so that points to snowflake being kind of like the bell of the ball if you will, in terms of from a data cloud. >> Absolutely. >> How do you compete with them? What's the pitch 'Cause that seemed to be a knee-jerk reaction from the industry. 'Cause snowflake is hot. They have a good value product. They have a smart team, Databrick is out there too. >> Yeah I mean... >> how do you guys compete against all that. >> So this is that point where you're balancing the value of a specific technology, or a specific technology vendor. And am I going to be stuck with them? So I'm tying my future to their future. With open source, I'm tying my future to the common good right. The internet runs on open source. It doesn't run on anything closed. And so I'm not hitching my wagon to something that I don't control. I'm hitching it to something where, any one of our customers could decide. I'm not getting the value I need from Aiven anymore. I need to go. And we provide you with the tools necessary, to move from our open source managed service to your own. Whether you go on-prem or you run it yourself, on a cloud service provider, move your data to you because it's your data. It's not ours. How can I hold your data? It's like weird extortion ransoming thing. >> Actually speaking, I mean enterprise, it's a big land grab 'cause with cloud you're horizontally scalable. It's a beautiful thing, open source is booming. It's going in Aiven, every day it's just escalating higher and higher. >> Absolutely. >> It is the software business. So open is open. Integration and scale seems to be the competitive advantage. >> Yeah. >> Right. So, how do you guys compete with that? Because now you got open source. How do you offer the same benefits without the lock in, or what's the switching costs? How do you guys maintain that position of not saying the same thing in Snowflake? >> Because all of the biggest data users and consumers tend to give away their data products. LinkedIn gave away their data product. Uber gave away their data product, Facebook gave away their data product. And we now use those as community solutions. So, if the product works for something the scale of LinkedIn, or something the scale of Uber. It will probably work for you too. And scale is just... >> Well Facebook and LinkedIn, they gave away the product to own the data to use against you. >> But it's the product that counts because you need to be able to manipulate data the way they manipulate data, but with yours. >> So low latency needs to work. So horizontally, scalable, fees, machine learning. That's what we're seeing. How do you make that available? Customers want on architecture? What do you recommend? Control plane, data plane, how do you think about that? >> It's interesting. There's architectural reasons to think about it in terms like that. And there's other good architectural reasons to not think about it. There's sort of this dividing line in the cloud, where your cloud service provider, takes over and provides you with the opportunity to say, I don't know. And I don't care >> As long as it's secure >> As long as it's secure absolutely. But there's sort of that water line idea, where if it's below the water line, let somebody else deal. >> What is in the table stakes? 'Cause I like that approach. I think that's a good value proposition. Store it, what boxes have to be checked? Compliance, secure, what are some of the boxes? >> You need to make sure that you've taken care of all of the same basics if you are still running it. Remember you can't absolve yourself of your duty to your customer. You're still on the hook. So, you have to have backups. You have to have access control. You have to understand who's administering it, and how and what they're doing. Good logging, good comprehension there. You have to have anomaly detection, secure operations. You have to have all those compliance check boxes. Especially if you're dealing with regulated data type like PCI data or HIPAA health data or you know what there's other countries besides the United States, there's other kinds of of compliance obligations there. So you have to make sure that you've got all that taken into account. And remember that, like I said, you can't absolve yourself with those things. You can share responsibilities. But you can't walk away from that responsibility. So you still have to make sure that you validate that your vendor knows what they're talking about. >> I wanted to ask you about the cybersecurity skills gap. So I'm kind of giving a little segue here, because you mentioned you've been with Aiven for about two years. >> Almost. >> Almost two years. You've started with a team of four. You've grown at 10X in less than two years. How have you accomplished that, considering we're seeing one of the biggest skills shortages in cyber in history. >> It's amazing, you see this show up in a lot of job Ads, where they ask for 10 years of experience in something that's existed for three years. (John Furrier laughs) And it's like okay, well if I just be logical about this I can hire somebody at less than the skill level that I need today, and bring them up to that skill level. Or I can spend the same amount of time, hoping that I'll find the magical person that has that set of skills that I need. So I can solve the problem of the skills gap by up-skilling the people that I hire. Which is strangely contrary to how this thing works. >> The other thing too, is the market's evolving so fast that, that carry up and pulling someone along, or building and growing your own so to speak is workable. >> It also really helps us with a bunch of sustainability goals. It really helps with anything that has to do with diversity and inclusion, because I can bring forward people who are never given a chance. And say, you know what? You don't have that magical ticket in life, but damn you know what you're talking about? >> It's a classic pedigree. I went to this school, I studied this degree. There's no degree if have to stop a hacker using state of the art malware. (John Furrier laughs) >> Exactly. What I do today as a job, didn't exist when I was in post-secondary at all. >> So when you hire, what do you look for? I mean obviously problem solving. What's your kind of algorithm for hiring? >> Oh, that's a really interesting question. The quickest sort of summary of it is, I'm looking for not a jerk. >> Not a jerk. >> Yeah. >> Okay. >> Because it turns out that the quality that I can't fix in a candidate, is I can't fix whether or not they're a jerk, but I can up-skill them, I can educate them. I can teach them of a part of the world that they've not had any interaction with. But if they're not going to work with the team, if they're going to be, look at me, look at me. If they're going to not have that moment of, I have this great job, and I get to work today. And that's awesome. (Lisa Martin laughs) That's what I'm trying to hire for. >> The essence of this teamwork is fundamental. >> Collaboration. >> Cooperation. >> Curiosity. >> That's the thing yeah, absolutely. >> And everybody? >> Those things, oh absolutely. Those things are really, really hard to interview for. And they're impossible to fix after the fact. So that's where you really want to put the effort. 'Cause I can teach you how to use a computer. I mean it's hard, but it's not that hard. >> Yeah, yeah, yeah. >> Well I love the current state of data management. Good overview, you guys are in the good position. We love open source. Been covering it for, since theCUBE started. It continues to redefine more and more the industry. It is the software industry. Now there's no debate about that. If people want to have that debate, that's kind of waste of time, but there are other ways that are happening. So I have to ask you. As things are going forward with innovation. Okay, if opensource is going to be the software industry. Where's the value? >> That's a fun question wow? >> Is it going to be in the community? Is it the integration? Is it the scale? If you're open and you have low switching costs... >> Yeah so, when you look at Aiven's commitment to open source, a huge part of that is our open source project office, where we contribute back to those core products, whether it's parts of the Apache Foundation, or Postgres, or whatever. We contribute to those, because we have staff who work on those products. They don't work on our stuff. They work on those. And it's like the opposite of a zero sum game. It's more like Nash equilibrium. If you ever watch that movie, "A beautiful mind." That great idea of, you don't have to have winners and losers. You can have everybody loses a little bit but everybody wins a little bit. >> Yeah and that's the open the ethos. >> And that's where it gets tied up. >> Another follow up on that. The other thing I want to get your reaction on is that, now in this modern era of open source, almost all corporations are part of projects. I mean if you're an entrepreneur and you want to get funding it's pretty simple. You start open source project. How many stars you get on GitHub guarantees it's a series C round, pretty much. So open source now has got this new thing going on, where it's not just open source folks who believe in it It's an operating model. What's the dynamic of corporations being part of the system. It used to be, oh what's the balance between corporate and influence, now it's standard. What's your reaction? >> They can do good and they can do harm. And it really comes down to why are you in it? So if you look at the example of open search, which is one of the data products that we operate in the Aiven system. That's a collaboration between Aiven. Hey we're an awesome company, but we're nowhere near the size of AWS. And AWS where we're working together on it. And I just had this conversation with one of the attendees here, where he said, "Well AWS is going to eat your story there. "You're contributing all of this "to the open search platform. "And then AWS is going to go and sell it "and they're going to make more money." And I'm like yep, they are. And I've got staff who work for the organization, who are more fulfilled because they got to deliver something that's used by millions of people. And you think about your jobs. That moment of, (sighs) I did a cool thing today. That's got a lot of value in it. >> And part of something. >> Exactly. >> As a group. >> 100%. >> Exactly. >> And we end up with a product that's used by millions. Some of it we'll capture, because we do a better job running than the AWS does, but everybody ends up winning out of the backend. Again, everybody lost a little, but everybody also won. And that's better than that whole, you have to lose so that I can win. At zero something, that doesn't work. >> I think the silo conversations are coming, what's the balance between siloing something and why that happens. And then what's going to be freely accessible for data. Because the real time information is based upon what you can access. "Hey Siri, what's the weather. "We had a guest on earlier." It says, oh that's a data query. Well, if the weather is, the data weathers stored in a database that's out here and it can't get to the response on the app. Yeah, that's not good, but the data is available. It just didn't get delivered. >> Yeah >> Exactly. >> This is an example of what people are realizing now the consequences of this data, collateral damage or economy value. >> Yeah, and it's understanding how data fits in your environment. And I don't want to get on the accountants too hard, but the accounting organizations, AICPA and ISAE and others, they haven't really done a good job of helping you understand data as an asset, or data as a liability. I hold a lot of customer data. That's a liability to me. It's going to blow up in my face. We don't talk about the income that we get from data, Google. We don't talk about the expense of regenerating that data. We talk about, well what happens if you lose it? I don't know. And we're circling the drain around fiduciary responsibility, and we know how to do this. If you own a manufacturing plant, or if you own a fleet of vehicles you understand the fiduciary duty of managing your asset. But because we can't touch it, we don't do a good job of it. >> How far do you think are people getting into the point where they actually see that asset? Because I think it's out of sight out of mind. Now there's consequences, there's now it's public companies might have to do filings. It's not like sustainability and data. Like, wait a minute, I got to deal with these things. >> It's interesting, we got this great benefit of the move to cloud computing, and the move to utility style computing. But we took away that. I got to walk around and pet my computers. Like oh! This is my good database. I'm very proud of you. Like we're missing that piece now. And when you think about the size of data centers, we become detached from that, you don't really think about, Aiven operates tens of thousands of machines. It would take entire buildings to hold them all. You don't think about it. So how do you recreate that visceral connection to your data? Well, you need to start actually thinking about it. And you need to do some of that tokenization. When was the last time you printed something out, like you get a report and happens to me all the time with security reports. Look at a security report and it's like 150 page PDF. Scroll, scroll, scroll, scroll. Print it out, stump it on the table in front of you. Oh, there's gravitas here. There's something here. Start thinking about those records, count them up, and then try to compare that to something in the real world. My wife is a school teacher, kindergarten to grade three, and tokenizing math is how they teach math to little kids. You want to count something? Here's 10 things, count them. Well, you've got 60,000 customer records, or you have 2 billion data points in your IOT database, tokenize that, what does 2 billion look like? What does $1 million look like in the form of $100 dollars bills on a pallet? >> Wow. >> Right. Tokenize that data, create that visceral connection with it, and then talk about it. >> So when you say tokenized, you mean like token as in decentralization token? >> No, I mean create like a totem or an icon of it. >> Okay, got it. >> A thing you can hold holy. If you're a token company. >> Not token as in Token economics and Crypto. >> If you're a mortgage company, take that customer record for one of your customers, print it out and hold the file. Like in a Manila folder, like it's 1963. Hold that file, and then say yes. And you're explaining to somebody and say yes, and we have 3 million of these. If we printed them all out, it would take up a room this size. >> It shows the scale. >> Right. >> Right. >> Exactly, create that connection back to the human level of interaction with data. How do you interact with a terabyte of data, but you do. >> Right. >> But once she hits upgrade from Google drive. (team laughs) >> What's a terabyte right? We don't hold that anymore. >> Right, right. >> Great conversation. >> Recreate that connection. Talk about data that way. >> The visceral connection with data. >> Follow up after this event. We'd love to dig more and love the approach. Love open source, love what you're doing there. That's a very unique approach. And it's also an alternative to some of the other vast growing plus your valuations are very high too. So you're not like a... You're not too far away from these big valuations. So congratulations. >> Absolutely. >> Yeah excellent, I'm sure there's lots of work to do, lots of strategic work to do with that round of funding. But also lots of opportunity, that it's going to open up, and we know you don't hire jerks. >> I don't >> You have a whole team of non jerks. That's pretty awesome. Especially 40 of 'em. That's impressive James.| >> It is. >> Congratulations to you on what you've accomplished in the course of the team. And thank you for sharing your insights with John and me today, we appreciate it. >> Awesome. >> Thanks very much, it's been great. >> Awesome, for John furrier, I'm Lisa Martin and you're watching theCube, live in New York city at AWS Summit NYC 22, John and I will be right back with our next segment, stick around. (upbeat music)

>> Welcome back to New York City everybody. This is The Cube's coverage of MongoDB World 2022, Dev Ittycheria, here is the president and CEO of MongoDB. Thanks for spending some time with us. >> It's Great to be here Dave, thanks for having me. >> You're very welcome. So your keynotes this morning, I was hearkening back to Steve Ballmer, running around the stage screaming, developers, developers, developers. You weren't jumping around like a madman, but the message was the same. And you've not deviated from that message. I remember when it was 10th Gen, so you've been consistent. >> Yes. >> Why is Mongo DB so alluring to developers? >> Yeah, because I would say the reason we're so popular Dave is that our whole business was founded on the ethos, so making developers incredibly productive. Just getting the infrastructure out of the way so that the developers is really focused on what's important and that's building great applications that transform their business. And the way you do that is you look at where they spend most of the time. and they spend most of the time working with data. How do you present data, the right data, the right time, at the right place, and the right way. And when you remove the friction of working with data, you unleash so much more productivity, which people just say, oh my goodness, I can move so much faster. Product leaders can get products out the door faster than the competitors. Senior level executives can seize new opportunities or respond to new threats. And that was so profound during COVID when everyone had to think about pivoting their business. >> When you came to MongoDB, why did you choose this company? What was it that excited you about it? >> I get that question a lot. I would say conventional wisdom would suggest that MongoDB was not a great choice. There weren't that many companies who were very successful in open source, Red Hat was the only one. No one had really built a deep technology company in New York city. They say, you got to do it in the valley. And database companies need a lot of capital. Now turns out that raising capital of this past decade was a lot easier, but it still takes a lot of time, and a lot of capitals, you have to have a lot of patience. When I did my diligence, I was actually a VC before I joined MongoDB. The whole next generation database segment was really taking off. And actually I looked at some competing investments to MongoDB, and when I did my diligence, it was clear even then. And this is circa 2012, that MongoDB is way ahead in terms of customer attraction, commercials, and even kind of developer mind share. And so I ended up passing those investments. and then lo and behold, I got a call from a very senior executive recruiter who said, Dev, you got to take a meeting with MongoDB, there's something really interesting going on. And they had raised a lot of capital and they had just not been able to kind of really execute in terms of the opportunity. And they realized they needed to make a change. And so one thing led to another. One of the things that really actually convinced me, is when I did my diligence, I realized the customers they had loved MongoDB. They just really weren't executing on all cylinders. And I always believe you never bet against a company whose customers love the product. And said, that's something here. The second thing I would say is open source. Yes, is true that open source was not very successful, but that was open source 1.0. Open source 2.0, the technology is much better than the commercial options. And so that convinced me. And then New York, I lived in New York a big part of my life. I think New York's a fabulous place to build a business. There's so much talent, your customers are right... You walk out the door, there's customers all over the place. And getting to Europe is very easy, Almost like flying to the west coast. So it's a very central place to build a business. >> And it's easier to fix execution, wouldn't you say? And maybe even go to market than it is to fix a product that customers really don't love. >> Correct, it's much easier to fix leadership issues, culture issues, execution issues. Nailing product market fit is very, very hard. And there were signs, there's still some issues, there's still some rough spots, but there a lot of signs that this company was very, very close, and that's why I took the bet. >> And this is before there was that huge influx of capital into the separating compute from storage and the whole cloud thing, which is interesting. Because you take a company like Cloudera, they got caught up in that and got kind of washed over. And I guess you could argue Hortonworks did too, and they could have dead ended both. And then that just didn't work. But it's interesting to see Mongo, the market kind of came to you. And that really does speak to the product. It wasn't a barrier for you. You guys have obviously a lot of work to get into the cloud with Atlas, but it seemed like a natural fit with the product. It wasn't like a complete fork. >> Well, I think the challenge that we had was we had a lot of adoption, but we had tough time commercializing the business. And at some point I had to tell the all employees, it's great that we have all these people who are using MongoDB, but if you don't start generating revenue, our investors are going to get tired of subsidizing this company. So I had to try and change the culture. And as you imagine, the engineers didn't really like the salespeople, the salespeople thought the engineers didn't really want to make any money. And what I said, like, let's all galvanize around customers and let's make them really excited and try and create a lot of value. And so we just put a lot more discipline in terms of how we prosecuted deals. We put a lot more discipline in terms of what are the problems we're trying to solve. And one thing led to another, we started building the business brick by brick. And one of the things that became clear for me was that the old open source model of trying to find that happy medium between what you give away and what you charge for, is always a tough game. Like because finding that where the paywall is, if you give away too much new features, you don't make any money. If you don't give away enough, you don't have any adoption. So you're caught in this catch-22. The best way to monetize open source, is open source as a service. And we saw Amazon do that frankly. We learned a lot from how Amazon did that. And one of the advantages that MongoDB had that I didn't fully appreciate when I joined the company, but I was very grateful. It is that they had a much more restrictive license. Which we ended up actually changing and made it even more restrictive, which allowed us to perfect ourselves from being cannibalized by the cloud providers, so that we could build our own business using our own IP that we had invested in and create a cloud service. >> That was a huge milestone. And of course you have great relationships with all the cloud providers, but it got contentious there for a while, but, you give the cloud providers an inch, they're going to take a mile. That's just the way, they're aggressive like that. But thank you for going through the history with me a little bit, because when you go back to the IPO, IPO was 2017, right? >> Correct. >> I always tell young investors, my kids especially, don't buy a stock at IPO, you're going to have a better chance, but the window from Mongo was very narrow. So, you didn't really get a much better chance a little bit. And then it's been a rocket ship since then. Sure, there's been some volatility, but you look at some of the big IPOs, like Facebook, or Snap, or even Snowflake, there was better opportunities. But you guys have executed really, really well. That's part of your ethos in your management team. And it came across on the earnings call recently. >> Yep. >> It was very optimistic, yet at the same time you set cautious tones and you got, I think high marks. >> Yes. >> For some of that caution but that execution. So talk about where you feel the business is today given the economic uncertainty? >> Well, what I'd say is we feel really good about the long term. We feel like the secular trends are really in our favor. Software's fundamentally transforming every industry. And people want to use modern software to either automate inefficient processes, enable new capabilities, drive better customer experiences. And the level of performance and scale you need for today's modern applications is profoundly different than applications yesterday. So we think we're well positioned for that. What we said on the earnings call was that we started seeing a moderation of growth, slight moderation of growth in our low end of the business in Europe. It was in our self-serve business and in the SMB space for the NQ1, towards the end of Q1. And we saw a little bit of that show up in the self-serve business in may in Q2. And that's why while we raised guidance, we basically quantified the impact, which is roughly about 30 to 35 million for the year, based on what we saw. And in that assumption, we assumed like... We just can't assume it's going to only be at the low in the market, probably some effect at the enterprise market. Maybe not as much, but there'll be some effect. So we need to factor that in. And we wanted to help kind of investors have some sort of framework to think about what the impact is. We don't want to be one of those companies that said absolutely nothing. And we don't want to be one of those companies that just waves the hand, but then it wasn't really that useful for investors. >> Yeah, I thought it was substantive. You talked about those market trends, you cited three things. The developers recognize that there are limits to legacy RDBMS. You talked about the, what I call point solutions creep. And then the document model is the best for developers. >> Great. >> And when the conversation turned to consumption, everybody's concerned about consumption obviously. You said... My take, somewhat insulated from that because you're running mission critical apps. It's not discretionary. My question to you is, should we rethink the definition of mission-critical? You think of Oracle mission critical running a bank. Mission -critical today in this digital world seems to be different, is that fair? >> Gosh, when's the last time you ever saw a website down? Like if you're running like any kind of digital channel, or engaging with the customers, or your partners, or your suppliers, you need to be up all the time. And so you need a very resilient, highly available data platform. It needs to be highly performance as you add more users, you need to be scale. And we saw a lot of that when COVID hit. Like companies had to completely repovit. And we talked about some examples where like a health and beauty retailer who was all kind of basically retail, had to suddenly pivot to e-commerce strategy. We've had streaming and gaming companies suddenly saw this massive influx of data that they scaled their operations very, very quickly. So I would say anytime you're engaging with customers, customers they're so used to the kind of the consumer facing applications. I almost joke like slow is the old down. If you're not performant, it doesn't matter. They're going to abandon you and go somewhere else. So if you're an e-commerce site and you're not performing well and not serving up the right skews, depending on what they're looking for, they're going to go somewhere else. >> So it's a click away. You talk about a hundred billion TAM, maybe that's even undercounted as you start to bring new capabilities in there. But there's no lack of market for you. >> Correct. >> How do you think about the market opportunity? >> Well, we believe... Again, software is transforming so many industries. IDC says that 715 million applications will be built over the next two to three years by 2025. To put that number of perspective, that's more apps that will be built the next three to four years than were built in the last 40. The rate and pace of innovation is as exploding. And people are building custom applications. Yes, Workday, Salesforce, other companies, commercial companies are great companies, but my competitors can use Workday or Salesforce, some of those commercial companies. That doesn't gimme a competitive advantage, what gives me a competitive advantage is building custom software that better engage my customers, that transforms my business in adding new capabilities or drives more efficiency. And the applications are only getting smarter. And so you're seeing that innovation explode and that plays to our strength. People need platforms like MongoDB to build the next generation of applications. >> So Atlas is now roughly 60% of your business, think is growing at 85%. So it's at least the midterm future. But my question to you is, is it the future? 'Cause when we start to think about the edge, it's not necessarily the cloud. You're not going to be able to go that round trip and the latency. And we had Verizon on earlier, talking about what they're doing with 5G, and the Mobile Edge. Is Mongo positioning for that edge? And is our definition of cloud changing? Where it's not just OnPrem and across clouds, but it's also out to the edge, this continuous experience. >> So I'll make two points. One, definitely we believe the applications of the future will be mobile first or purely mobile. Because one with the advent of 5G, the distinction between mobile and web is going to blur, with a hundred times faster networking speeds. But the second point I make is that how that shows up on our revenue on our income table will look like Atlas. Because we don't charge nothing for the end point, it's basically driving consumption of the back end. And so we've introduced a bunch of very, very sophisticated capabilities to synchronized data from the edge to the backend and vice versa with things like flexible sync. So we see so many customers now using that capability, whether you're field service technicians, whether you're a mobile first company, et cetera. So that will drive Atlas revenue. So on an income statement, it'll look like Atlas, but we're obviously addressing those broader set of mobile needs. >> You talk a lot about product market fit former VC, of course, Mark Andreen says, product market fit you kind of know when you see it, your hair's on fire, you can't buy a service. How do you know when you have product market fit? >> Well, one, we have the luxury of lots of customers. So they tell us pretty clearly when they're happy, and we can see that by usage behavior. Now the other benefit of a cloud service, is we can see the level of activity. We can see the level of engagement. We can see how much data they're consuming. We can see all the actions they're taking. So you get the fidelity of feedback you get from Atlas versus someone doing something behind their own firewall. And you kind of call 'em and check in on them is very, very different. So that level of insight gives us visibility in terms of what products and features have been used, gives us a sense how things going well, or is there something awry. Maybe they have misconfigured something or they don't know how to use some capabilities. So the level of engagement that we can have with a customer using a service is so much different. And so we've really invested in our customer success organization. So the byproduct of that is that our retention rates are also very, very strong. Because you have such better information about what's happening in terms of your customers. >> See retention in real time. You've been somewhat... Is just so hard to say this 'cause you're growing at 50% a year. But you're somewhat conservative about the pace of hiring for go to market. And I'm curious as to how you think about scaling, especially when you introduce new products. Atlas is several years ago. But as you extend your capabilities and add new products, how do you decide when to scale? >> So it's a constant process. We've been quite aggressive in scaling organization for a couple reasons. One, we have very low market share, so the market's vastly under penetrated. We still don't have reps in every NFL sitting in the United States, which just kind of crazy. There's other parts of the world that we are just still vastly under penetrated in. But we also look at how those organizations are doing. So if we see a team really killing it, we're going to deploy more resources. Because one, it tells us there's more opportunity there, and there's a strong team there. If we see a team that maybe is struggling a little bit, we'll try and uncover. Rather than just applying more resources in, we'll try and uncover what are the issues and make sure we stabilize the organization and then devote resources. It's all in the measure of like being very disciplined about where we deploy our resources, to get those kind of returns. And on the product side, we obviously go through a very iterative process and kind of do rank order all the projects and what we think the expected returns are. Obviously, we look at the customer feedback, we look at what our strategic priorities are. And that informs what projects we fund and what projects kind of are below the line. And we do that over and over again every quarter. So every quarter we revisit the business, we have a very QBR centric culture. So we're constantly checking in and seeing how the business is operating. And then we make those investment decisions. In general, we've been investing very aggressively in terms of expanding our reach around the world. >> It seems like, well, with Mongo, your product portfolios... From an outside observer standpoint, it seems like you've always had pretty good product market fit. But I was curious, in your VC days, would you ever encourage companies to scale go to market prior to having confidence in product market fit? Or did you always see those as sequential activities? >> Well, I think the challenge is this part it's analysis part is judgment. So you don't necessarily have to have perfect product market fit to start investing. But you also don't want to plow a bunch of resources and realize the product doesn't work and then how you're burning through a lot of cash. So there's a little bit of art to the process. When I joined MongoDB, I could tell that we had a strong engineering team. They knew how to build high quality products, but we just struggled with commercialization. The culture wasn't great across the company. And we had some leadership challenges. So that's when I joined, I kind of focused on those things and tried to bring the organization together. And slowly we started chipping away and making people feel like they were winners. And once you start winning, that becomes contagious. And then the nice thing is when you start winning, you get a lot more customer feedback. That feedback helps you refine your products even more, which then adds... It's like the flywheel effect that starts taking off. >> So it seems the culture's working now. Do you have a favorite product from the announcements today? >> Well, I really like our foray to analytics. And essentially what we're seeing is really two big trends. One you're seeing applications get smarter. What applications are doing is really automating a lot of processes and rather than someone having to press a button. Based on analytics, you can automate a lot of decision making. So that's one theme that we're seeing as applications get smarter. The second theme is that people want more and more insight in terms of what's happening. And the source of that is insights is your operational database. Because that's where you're having transactions, that's where you know what products are selling, that's where you know what customers are buying. So people want more and more real time data versus waiting to take that data, put it somewhere else and then run reports and then get some update at the end of the night or maybe at the week. So that's driving a lot of really interesting use cases. And especially when you marry in things like time series use cases where you're collecting a lot of data people want to see trend analysis what's happening. Which I think it's a very exciting area. We introduced a very cool feature called Queryable Encryption, which basically... The problem with encrypting data, is you can't really query it because my definition's encrypted. >> Yeah, you're right. >> But obviously data security is very important. What we announced, is we're using very sophisticated cryptography. People can query the data, but they don't have really access to the data. So it really protects you from like data breaches or malicious users accessing your data, but you still can kind of make that data usable. So that was a very interesting announcer that we made today. >> Sounds like magic without the performance hit. >> Yes. >> You can do that. Dev, thanks so much for coming in The Cube. Congratulations on all activity, bumper sticker on day one. >> Oh, it's super exciting. The energy was palpable, 3,300 people in the room, lots of customers, lots of users. We had lots of investors here as well for our investor day, have a dinner tonight with a bunch of senior execs, so it's been a busy day. >> Future is bright for MongoBD. Dev, thanks for so much for coming on The Cube. And thanks for watching, this is Dave Vellante and we'll see you next time. (upbeat music)

(upbeat music) >> Announcer: TheCUBE presents KubeCon and CloudNativeCon Europe, 2022. Brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain, a KubeCon, CloudNativeCon Europe, 2022. I'm your host, Keith Townsend alongside Paul Gillon, Senior Editor, Enterprise Architecture for SiliconANGLE. We are, I think at the half point way point this to be fair we've talked to a lot of folks in open source in general. What's the difference between open source communities and these closed source communities that we attend so so much? >> Well open source is just it's that it's open it's anybody can contribute. There are a set of rules that manage how your contributions are reflected in the code base. What has to be shared, what you can keep to yourself but the it's an entirely different vibe. You know, you go to a conventional conference where there's a lot of proprietary being sold and it's all about cash. It's all about money changing hands. It's all about doing the deal. And open source conferences I think are more, they're more transparent and yeah money changes hands, but it seems like the objective of the interaction is not to consummate a deal to the degree that it is at a more conventional computer conference. >> And I think that can create an uneven side effect. And we're going to talk about that a little bit with, honestly a friend of mine Alex Ellis, founder of OpenFaaS. Alex welcome back to the program. >> Thank you, good to see Keith. >> So how long you've been doing OpenFaaS? >> Well, I first had this idea that serverless and function should be run on your own hardware back in 2016. >> Wow and I remember seeing you at DockerCon EU, was that in 2017? >> Yeah, I think that's when we first met and Simon Foskett took us out to dinner and we got chatting. And I just remember you went back to your hotel room after the presentation. You just had your iPhone out and your headphones you were talking about how you tried to OpenWhisk and really struggled with it and OpenFaaS sort of got you where you needed to be to sort of get some value out of the solution. >> And I think that's the magic of these open source communities in open source conferences that you can try stuff, you can struggle with it, come to a conference either get some advice or go in another direction and try something like a OpenFaaS. But we're going to talk about the business perspective. >> Yeah. >> Give us some, like give us some hero numbers from the project. What types of organizations are using OpenFaaS and what are like the download and stars all those, the ways you guys measure project success. >> So there's a few ways that you hear this talked about at KubeCon specifically. And one of the metrics that you hear the most often is GitHub stars. Now a GitHub star means that somebody with their laptop like yourself has heard of a project or seen it on their phone and clicked a button that's it. There's not really an indication of adoption but of interest. And that might be fleeting and a blog post you might publish you might bump that up by 2000. And so OpenFaaS quite quickly got a lot of stars which encouraged me to go on and do more with it. And it's now just crossed 30,000 across the whole organization of about 40 different open source repositories. >> Wow that is a number. >> Now you are in ecosystem where Knative is also taken off. And can you distinguish your approach to serverless or FaaS to Knatives? >> Yes so, Knative isn't an approach to FaaS. That's simply put and if you listen to Aikas Ville from the Knative project, he was working inside Google and wished that Kubernetes would do a little bit more than what it did. And so he started an initiative with some others to start bringing more abstractions like Auto Scaling, revision management so he can have two versions of code and and shift traffic around. And that's really what they're trying to do is add onto Kubernetes and make it do some of the things that a platform might do. Now OpenFaaS started from a different angle and frankly, two years earlier. >> There was no Kubernetes when you started it. >> It kind of led in the space and and built out that ecosystem. So the idea was, I was working with Lambda and AWS Alexa skills. I wanted to run them on my own hardware and I couldn't. And so OpenFaaS from the beginning started from that developer experience of here's my code, run it for me. Knative is a set of extensions that may be a building block but you're still pretty much working with Kubernetes. We get calls come through. And actually recently I can't tell you who they are but there's a very large telecommunications provider in the US that was using OpenFaaS, like yourself heard of Knative and in the hype they switched. And then they switched back again recently to OpenFaaS and they've come to us for quite a large commercial deal. >> So did they find Knative to be more restrictive? >> No, it's the opposite. It's a lot less opinionated. It's more like building blocks and you are dealing with a lot more detail. It's a much bigger system to manage, but don't get me wrong. I mean the guys are very friendly. They have their sort of use cases that they pursue. Google's now donated the project to CNCF. And so they're running it that way. Now it doesn't mean that there aren't FaaS on top of it. Red Hat have a serverless product VMware have one. But OpenFaaS because it owns the whole stack can get you something that's always been very lean, simple to use to the point that Keith in his hotel room installed it and was product with it in an evening without having to be a Kubernetes expert. >> And that is and if you remember back that was very anti-Kubernetes. >> Yes. >> It was not a platform I thought that was. And for some of the very same reasons, I didn't think it was very user friendly. You know, I tried open with I'm thinking what enterprise is going to try this thing, especially without the handholding and the support needed to do that. And you know, something pretty interesting that happened as I shared this with you on Twitter, I was having a briefing by a big microprocessor company, one of the big two. And they were showing me some of the work they were doing in Cloud-native and the way that they stretch test the system to show me Auto Scaling. Is that they bought up a OpenFaaS what is it? The well text that just does a bunch of, >> The cows maybe. >> Yeah the cows. That does just a bunch of texts. And it just all, and I'm like one I was amazed at is super simple app. And the second one was the reason why they discovered it was because of that simplicity is just a thing that's in your store that you can just download and test. And it was open fast. And it was this big company that you had no idea that was using >> No >> OpenFaaS. >> No. >> How prevalent is that? That you're always running into like these surprises of who's using the solution. >> There are a lot of top tier companies, billion dollar companies that use software that I've worked on. And it's quite common. The main issue you have with open source is you don't have like the commercial software you talked about, the relationships. They don't tell you they're using it until it breaks. And then they may come in incognito with a personal email address asking for things. What they don't want to do often is lend their brands or support you. And so it is a big challenge. However, early on, when I met you, BT, live person the University of Washington, and a bunch of other companies had told us they were using it. We were having discussions with them took them to Kubecon and did talks with them. You can go and look at them in the video player. However, when I left my job in 2019 to work on this full time I went to them and I said, you know, use it in production it's useful for you. We've done a talk, we really understand the business value of how it saves you time. I haven't got a way to fund it and it won't exist unless you help they were like sucks to be you. >> Wow that's brutal. So, okay let me get this right. I remember the story 2019, you leave your job. You say I'm going to do OpenFaaS and support this project 100% of your time. If there's no one contributing to the project from a financial perspective how do you make money? I've always pitched open source because you're the first person that I've met that ran an open source project. And I always pitched them people like you who work on it on their side time. But they're not the Knatives of the world, the SDOs, they have full time developers. Sponsored by Google and Microsoft, etc. If you're not sponsored how do you make money off of open source? >> If this is the million dollar question, really? How do you make money from something that is completely free? Where all of the value has already been captured by a company and they have no incentive to support you build a relationship or send you money in any way. >> And no one has really figured it out. Arguably Red Hat is the only one that's pulled it off. >> Well, people do refer to Red Hat and they say the Red Hat model but I think that was a one off. And we quite, we can kind of agree about that in a business. However, I eventually accepted the fact that companies don't pay for something they can get for free. It took me a very long time to get around that because you know, with open source enthusiast built a huge community around this project, almost 400 people have contributed code to it over the years. And we have had full-time people working on it on and off. And there's some people who really support it in their working hours or at home on the weekends. But no, I had to really think, right, what am I going to offer? And to begin with it would support existing customers weren't interested. They're not really customers because they're consuming it as a project. So I needed to create a product because we understand we buy products. Initially I just couldn't find the right customers. And so many times I thought about giving up, leaving it behind, my family would've supported me with that as well. And they would've known exactly why even you would've done. And so what I started to do was offer my insights as a community leader, as a maintainer to companies like we've got here. So Casting one of my customers, CSIG one of my customers, Rancher R, DigitalOcean, a lot of the vendors you see here. And I was able to get a significant amount of money by lending my expertise and writing content that gave me enough buffer to give the doctors time to realize that maybe they do need support and go a bit further into production. And over the last 12 months, we've been signing six figure deals with existing users and new users alike in enterprise. >> For support >> For support, for licensing of new features that are close source and for consulting. >> So you have proprietary extensions. Also that are sort of enterprise class. Right and then also the consulting business, the support business which is a proven business model that has worked >> Is a proven business model. What it's not a proven business model is if you work hard enough, you deserve to be rewarded. >> Mmh. >> You have to go with the system. Winter comes after autumn. Summer comes after spring and you, it's no point saying why is it like that? That's the way it is. And if you go with it, you can benefit from it. And that's what the realization I had as much as I didn't want to do it. >> So you know this community, well you know there's other project founders out here thinking about making the leap. If you're giving advice to a project founder and they're thinking about making this leap, you know quitting their job and becoming the next Alex. And I think this is the perception that the misperception out there. >> Yes. >> You're, you're well known. There's a difference between being well known and well compensated. >> Yeah. >> What advice would you give those founders >> To be. >> Before they make the leap to say you know what I'm going to do my project full time. I'm going to lean on the generosity of the community. So there are some generous people in the community. You've done some really interesting things for individual like contributions etc but that's not enough. >> So look, I mean really you have to go back to the MBA mindset. What problem are you trying to solve? Who is your target customer? What do they care about? What do they eat and drink? When do they go to sleep? You really need to know who this is for. And then customize a journey for them so that they can come to you. And you need some way initially of funneling those people in qualifying them because not everybody that comes to a student or somebody doing a PhD is not your customer. >> Right, right. >> You need to understand sales. You need to understand a lot about business but you can work it out on your way. You know, I'm testament to that. And once you have people you then need something to sell them that might meet their needs and be prepared to tell them that what you've got isn't right for them. 'cause sometimes that's the one thing that will build integrity. >> That's very hard for community leaders. It's very hard for community leaders to say, no >> Absolutely so how do you help them over that hump? I think of what you've done. >> So you have to set some boundaries because as an open source developer and maintainer you want to help everybody that's there regardless. And I think for me it was taking some of the open source features that companies used not releasing them anymore in the open source edition, putting them into the paid developing new features based on what feedback we'd had, offering support as well but also understanding what is support. What do you need to offer? You may think you need a one hour SLA for a fix probably turns out that you could sell a three day response time or one day response time. And some people would want that and see value in it. But you're not going to know until you talk to your customers. >> I want to ask you, because this has been a particular interest of mine. It seems like managed services have been kind of the lifeline for pure open source companies. Enabling these companies to maintain their open source roots, but still have a revenue stream of delivering as a service. Is that a business model option you've looked at? >> There's three business models perhaps that are prevalent. One is OpenCore, which is roughly what I'm following. >> Right. >> Then there is SaaS, which is what you understand and then there's support on pure open source. So that's more like what Rancher does. Now if you think of a company like Buoyant that produces Linkerd they do a bit of both. So they don't have any close source pieces yet but they can host it for you or you can host it and they'll support you. And so I think if there's a way that you can put your product into a SaaS that makes it easier for them to run then you know go for it. However, we've OpenFaaS, remember what is the core problem we are solving, portability So why lock into my cloud? >> Take that option off the table, go ahead. >> It's been a long journey and I've been a fan since your start. I've seen the bumps and bruises and the scars get made. If you're open source leader and you're thinking about becoming as famous as Alex, hey you can do that, you can put in all the work become famous but if you want to make a living, solve a problem, understand what people are willing to pay for that problem and go out and sell it. Valuable lessons here on theCUBE. From Valencia, Spain I'm Keith Townsend along with Paul Gillon and you're watching theCUBE the leader in high-tech coverage. (Upbeat music)

(upbeat music) >> Welcome to theCUBE. I'm Dave Nicholson, and this is part of the continuing conversation about Managing Risk in the Digital Supply Chain. I have with me today Vincent Danen, vice president of product security from Red Hat and Luke Hines security engineering lead from the office of the CTO at Red Hat. Gentlemen, welcome to theCUBE. >> Thank you. >> Great to be here. >> So let's just start out and dive right into this, Vincent, what is the software or digital supply chain? What are we talking about? Yeah, that's a good question. Software supply chain is basically the software that an end user would get from a vendor or in our case, we're talking about open source, so upstream. It is the software that comes in that is part of your package, operating system, applications. It could be something that you get from one vendor, multiple vendors. So we look at in the example of Red Hat, we are one part of the customer's software supply chain. >> So it's interesting that it's coming in from different areas. Do we have a sense for the ratio of kind of commercial software versus open source software that makes up an enterprise today? >> I think that's a really hard thing to answer and I think every enterprise or every company would have a little bit different. Depends if you have an open source vendor that you choose, you may get a significant amount of software from them. Certainly you're not going to get it all. As an example, Red Hat provides thousands of open source packages. We certainly can't provide all of them. There are millions that are out there. So when you're looking at a specific application that you're building, chances are, you could be running that on a managed platform or an enterprise supply platform, but there are going to be packages that you're going to be obtaining from other sources in other communities as well in order to power your applications. >> So, Luke, that sounds like a kind of a vague situation we're looking at in terms of where all of our software is coming from. So what do we need to know about our software supply chain in that context? What do we need to understand? Before we even get anywhere near the idea of securing it, what are some of the issues that arise from that? >> Yeah, so Vincent's touchpoint is a very wide range in ecosystem, multiple sources when we're talking about open source. So essentially awareness is key really. I think a lot of people are really not aware of the sources that they're drawing from to create their own supply chain. So there's multiple supply chains. You can be somebody like Red Hat that the provide software, and then people will leverage Red Hats for their own supply chain. And then you have the cloud provider and they have their own source of software. So I think that the key thing is the awareness of how much you rely upon that ecosystem before we look at the security of the supply chain. It's really understanding your supply chain. >> And just to follow up on that. So can you... I'm sort of checking my own level of understanding on this subject. When you talk about open source code, you're talking about a code base that is often maintained essentially by volunteers, isn't that correct? >> A mix of volunteers and paid professionals where a company has an interest in the open source project, but predominantly I would say it's... Well, I'm not entirely sure, but volunteers make up a substantial part of the ecosystem that is for sure. So it's a mix really. Some people do it because they enjoy writing software. They want to share software. Other people also enjoy working software, but they're in the position that a company pays for them to work on that software. So it's a mix of both. >> Vincent, give us a reminder of reminder of why this is important from a little bit of a higher level. Step back from the data center view of things, from the IT view of things, just from a societal perspective, Vincent, what happens when we don't secure our digital supply chain? What are the things that are put at risk? >> Okay, well, there's a significant number of things that are placed at risk, the security of the enterprise itself. So your own customer data, your own internal corporate data is place at risk if there were a supply chain breach. But further to that for a software provider, and I think that in a lot of cases, most companies today are software providers or software developers. You actually put your own customers at risk as well, not just their data, but their actual... The things that they're working on, any workloads that they may have, an order that they might place as an example. So there's a number of areas where you want to have the security of that supply chain and the software components that you have figured out. You want to be on top of that because there is that risk that trickles down when it comes to an event. I mean, we've seen that with breaches earlier this year, one company is breached multiple companies end up being breached as a result of that. So it's really important. I think we all have a part to play in that I always view it as it's not just about the company itself. So I mean, speaking from a Red Hat perspective, I don't look at it as we're just securing Red Hat, we're securing our customers, and then we're also doing that for their customers as well, because they're writing software that's running on the software that we're providing to them. So there is this trickle down effect that comes, and so I think that every link in that chain, I mean, it's wonderful that it's called a supply chain. It's only as strong as its weakest link. So our view is how do we strengthen every link in that chain? And we're one part of it, but we're kind of looking a little broader, what can we do upstream and how can we help our customers to ensure the security of their part in that supply chain? >> Yeah, I want to talk about that in a broad sense, but let's see if we can get a little bit more specific in terms of what some of the chains look like because it's not just really one chain when you think about it, there's the idea of inherent flaws that can be caught and then there are the things that bad actors might be doing to leverage those flaws. So you've got all of these different things that are converging. So first and Vincent, if you want to toss this to Luke back and forth, it's up to you guys. What about this issue of inherent flaws in code? We referenced this idea of the maintainer community. What are best practices for locking that down to make sure that there aren't inherent flaws or security risks? >> I'll take a stab at it, and then I'll let Luke follow up with maybe some of the technologies that Red Hat provides. And again, speaking to Red Hat as part of that chain. When we're talking about inherent risk, there's a vulnerability that's present upstream. We pull that software to Red Hat. We package it as a component of one of the pieces of software that we provide to our customers. It's our responsibility to pay attention to those upstream potential vulnerabilities, potential risks, and correct them in our code. So that might be taking a patch from upstream, applying it to our software, might be grabbing the latest version from upstream, whatever the case might be, but it's our responsibility to provide that protection for that software to actually remediate that risk, and then our customers can then install the update and apply the mitigation themselves. If we take a look at it from, when we're looking at multiple suppliers where you'd asked earlier about, what part of it is Red Hat and what part of it is self-service open source? When you look at that, the work that Red Hat's doing there as a commercial provider of open source and end user for that little bit that they're going to grab themselves, that Red Hat doesn't provide, it's going to have to do all of those things as well. They're going to have to pay attention to that risk from upstream. They're going to have to pay attention to any potential vulnerabilities and pull that in to figure out, do I need to patch? Where do I need to patch it? And that's something we didn't really touch on was an inventory of the software that you have in place. I mean, you don't know that you need to fix something. You don't even know that it's running. So, I mean, there's a lot of considerations there where you have to pay attention to a lot of sources. Certainly there's metadata, automation, all of these things that make it easier, but it doesn't absolve us of the responsibility across the board to pay attention to these things, whether you're grabbing it from upstream directly or from the vendor. And it's the vendor's responsibility to then be paying attention to things upstream. >> Yeah, so Luke, I want you to kind of riff on that from the perspective that let's just assume that Vincent was just primarily talking about the idea that, okay, we've established that this code is solid and we've got gold copy of it and we know it's okay. There aren't inherent problems in the code as far as we can tell. Well, that's fine. I'm a developer. I go out to pull code and to use. How do I know if it's not been tampered with? How do I know if it's in fact the code that was validated during this process before? What do you do about that? >> So there's several methods there, but I just like to loop back to that point, because I think this is really interesting around, so if you look at a software supply chain, this is a mix of humans and machines, and both have flaws, probably humans a bit more. And a supply chain, you have developers. You have code reviewers, you have your systems administrators that set up the systems, and then you have your machine actors. So you've got your build systems, the various machines that are part of that supply chain. Now the humans, there's a as an attack factor there 'cause typically they will have some sort of identity, which they leverage for access to the supply chain. So quite often a developer's identity can be compromised. So a lot of the time people will have a corporate account that gives them some sort of single sign on access to multiple systems. So the developers are coming and this could be somebody in the community as well. Their account is compromised, then they're able to easily backdoor systems. So that's one aspect. And then there is machines as well. There's the whole premise of machines software not being up to date. So when the latest nasty vulnerability is released, machines are updated, then the machines have their flaws. They can be exploited. So I would say it's not just a technical problem. There is a humanistic element to this as well around protecting your supply chain. And I would say a really good perspective to carry when you're looking to, how do I secure my supply chain is treat it like you would a production system. So what do I mean by that? When we put something into production and we've got this very long legacy of treating it with a very strict security context around who can access that people, okay. How much it's upgraded and it's patched? And we seem to not have this same perception around our supply chain and our build systems, the integrity of those, the access of those, the policy around the access and so forth. So that's one giveaway that I would say is a real key focus that you should have is treat it like a production system. Be very mindful about what you're bringing in, who can access it because it is the keys to the kingdom, because if somebody compromises your supply chain, your build systems and so forth, they can compromise the whole chain because the chain is only as strong as the weakest link. So that's what I draw upon it. And around the verifications, there is multiple technologies that you can leverage. So Red Hat, we've got a very robust sign in system that we use so that you can be sure that the packages that we get you have non-repudiation that they've been produced by Red Hat. When you update your system, that's automatically looked after. And there are other systems as well, there's other new technologies that are starting to get a foothold around the provenance of aspects of your build system. So when you're pulling in from these multiple sources of open source communities, you can have some provenance around what you're putting in as well. And yeah, I don't want to bite share too much on the technologies, but there's some exciting stuff starting to happen there as well. >> So let's look at an example of something, because I think it's important to understand all of these different aspects. Recently, I think actually still in the news, we found that some logging software distributed by Apache that's widely used in people's websites to gather information about... To help from a security perspective and to help developers improve things that are going on in websites. A vulnerability was discovered. I guess, first Alibaba, some folks were reported it directly to some folks at Apache and the Apache Organization. And then of all people, some folks from Minecraft mentioned it in a blog. That seems like a crazy way to find out about something that's a critical flaw. Now we're looking at this right now with hindsight. So with hindsight, what could we have done to not be in the circumstances that we're in right now? Vincent, I'll toss that to you first, but again, if Luke is more appropriate, let us know. >> No, it's a great question, and it's a hard question. >> How did you let this happen, Vincent? How did you let this happen? >> It wasn't me, I promise. (Dave laughs) >> What I mean, it's a challenging question I mean, and there's a number of areas where we focused on a lot of what we perceived as critical software. So it comes to web server applications, DNS, a number of the kind of the critical infrastructure that powers the internet. Right or wrong. Do we look at logging software as a critical piece of that? Well, maybe, maybe we should, right? Logging is definitely important as part of an incident response or just an awareness of what's going on. So, I mean, yeah, it probably should have been considered critical software, but I mean, it's open source, right? So there's a number of different logging applications. I imagine now we're scrutinizing those a little bit more, but looking beforehand, how do you determine what's critical until an event like this happens, and it's unfortunate that it happens. And I like to think of these as learning opportunities, and certainly not just for Red Hat, but for this (talking over each other) >> Certainly this is not... Yeah, this is not an indictment of our entire industry. We are all in this together and learning every day. It just highlights how complex the situation is that we're dealing with, right? >> It really is. And I mean, a lot of what we're looking at now is how do we get tools into the hands of developers who can catch some of these things earlier. And there's a lot of commercial offerings, there's a lot of open source tools that are available and being produced that are going to help with these sorts of situations moving forward. But I mean, all the tools on the planet aren't going to help if they're not being used. So, I mean, there has to be an education and an incentive for these developers, particularly, maybe in some upstream communities where they are labors of love and they're passionate projects they're not sponsored or backed by a corporation who's paying for these tools, to be able to use some of them and move that forward. I think that looking at things now, there is work to be done. Obviously there's always going to be work to be done. Not all of these tools, and we have to recognize this, they're not all perfect. They're not going to catch everything. These tools could have been... I mean, I don't know if they were running these tools or not, they could have been, and the tool simply could not have picked them up. So part of it is the proactive part. We talk a lot about shift left and moving these things earlier into the development process and that's great, and we should do it. It certainly should never be seen as a silver bullet or a replacement for a good response. And I think the really important thing to highlight with respect to this, and I mean, this touches on the supply chain issue as well, companies, especially those who never maybe saw themselves as a software development company really have to figure out and understand how to do appropriate response. Part of that is awareness, what do you have installed? Part of it is sources of information. Like how do I find out about a new vulnerability or a potential vulnerability? And then it's just the speed to respond. We know that a number of companies they have, maybe it's a Patch Tuesday, maybe it's a patch 26th of the month, maybe it's patch day of the quarter, we have to learn how to respond to these things quickly so that we can apply these mitigations and these fixes as quickly as possible to them protect ourselves and protect the end users or customers that we have, or to keep the kids from using some backdoors in Minecraft is the word. >> (laughs) Yeah. Look, this is an immensely important subject. To wrap us up on this, Luke, I'd like you to pretend that you just got into an elevator in a moderately tall building, and you have 60 seconds to share with me someone who already trusts you, you don't have to convince me of your credentials or anything. I trust you. What tools specifically do you need me to be running, tools and processes. You've got 60 seconds to say, Dave, if you're not doing these things right now, you're unnecessarily vulnerable. So ready, and go, Luke. >> So automatically update all packages. Always stay up-to-date so that when an issue does hit, you're not having to go back 10 versions and work your way forward. That's the key thing. Ensure that everything you pull in, you're not going to have 100%, but have a very strict requirement that there is non-repudiation, is signed content, so you can verify that it's not being tampered with. For your developers that are producing code, run static, dynamic analysis, API fuzzes, all of these sorts of tools. They will find some vulnerabilities for you. Be part of communities. Be part of communities, help chop the wood and carry the water because the log for Jay, the thing is that was found because it was in the open. If it wasn't any open, it wouldn't have been found. And I've been in this business for a long time. Software developers will always write bugs. I do. Some of them will be security bugs. That's never going to change. So it's not about stopping something that's inevitable. It's about being prepared to react accordingly in our right and correct manner when it does happen so that you can mitigate against those risks. >> Well, we're here on the 35th floor. That was amazing. Thank you, Luke. Vincent, you were in the elevator also listening in on this conversation. Did we miss anything? >> No, I mean, the only thing I'll say is that it's really helpful to partner with an enterprise open source provider, be it Red Hat or anybody else. I don't want to toot our own horn. They do a lot of that work on your behalf that you don't have to do. A lot of the things that Luke was talking about, those providers do, so you don't have to. And that's where you.. I liked that you talked about, hey, you don't have to convince me that I'm trusted, or that I trust you. Trust those vendors. They're literally here to do a lot of that heavy lifting for you and trust the process. Yeah, it's a very, very good point. And I know that sometimes it's hard to get to that point where you are the trusted advisor. Both of you certainly are. And with that, I would like to thank you very much for an interesting conversation. Gentlemen, let's keep in touch. You're always welcome on theCUBE. Luke, second time, getting a chance to talk to you on theCUBE personally. Fantastic. With that, I would like to thank everyone for joining this very special series on theCUBE. Managing risk in the digital supply chain is a critical topic to keep on top of. Thanks for tuning into theCUBE. We'll be back soon. I'm Dave Nicholson saying, thanks again. (upbeat music)

(upbeat music) >> Hello, and welcome back to AWS Startup Showcase, I'm John Furrier, your host. This is the Hero panel, the AWS Heroes. These are folks that have a lot of experience in Open Source, having fun building great projects and commercializing the value and best practices of Open Source innovation. We've got some great guests here. Liz Rice, Chief Open Source Officer, Isovalent. CUBE alumni, great to see you. Brian LeRoux, who is the Co-founder and CTO of begin.com. Erica Windisch who's an Architect for Developer Experience. AWS Hero, also CUBE alumni. Casey Lee, CTO Gaggle. Doing some great stuff in ed tech. Great collection of experts and experienced folks doing some fun stuff, welcome to this conversation this CUBE panel. >> Hi. >> Thanks for having us. >> Hello. >> Let's go down the line. >> I don't normally do this, but since we're remote and we have such great guests, go down the line and talk about why Open Source is important to you guys. What projects are you currently working on? And what's the coolest thing going on there? Liz we'll start with you. >> Okay, so I am very involved in the world of Cloud Native. I'm the chair of the technical oversight committee for the Cloud Native Computing Foundation. So that means I get to see a lot of what's going on across a very broad range of Cloud Native projects. More specifically, Isovalent. I focus on Cilium, which is it's based on a technology called EBPF. That is to me, probably the most exciting technology right now. And then finally, I'm also involved in an organization called OpenUK, which is really pushing for more use of open technologies here in the United Kingdom. So spread around lots of different projects. And I'm in a really fortunate position, I think, to see what's happening with lots of projects and also the commercialization of lots of projects. >> Awesome, Brian what project are you working on? >> Working project these days called Architect. It's a Open Source project built on top of AWSM. It adds a lot of sugar and terseness to the SM experience and just makes it a lot easier to work with and get started. AWS can be a little bit intimidating to people at times. And the Open Source community is stepping up to make some of that bond ramp a little bit easier. And I'm also an Apache member. And so I keep a hairy eyeball on what's going on in that reality all the time. And I've been doing this open-source thing for quite a while, and yeah, I love it. It's a great thing. It's real science. We get to verify each other's work and we get to expand and build on human knowledge. So that's a huge honor to just even be able to do that and I feel stoked to be here so thanks for having me. >> Awesome, yeah, and totally great. Erica, what's your current situation going on here? What's happening? >> Sure, so I am currently working on developer experience of a number of Open Source STKS and CLI components from my current employer. And previously, recently I left New Relic where I was working on integrating with OpenTelemetry, as well as a number of other things. Before that I was a maintainer of Docker and of OpenStack. So I've been in this game for a while as well. And I tend to just put my fingers in a lot of little pies anywhere from DVD players 20 years ago to a lot of this open telemetry and monitoring and various STKs and developer tools is where like Docker and OpenStack and the STKs that I work on now, all very much focusing on developer as the user. >> Yeah, you're always on the wave, Erica great stuff. Casey, what's going on? Do you got some great ed techs happening? What's happening with you? >> Yeah, sure. The primary Open Source project that I'm contributing to right now is ACT. This is a tool I created a couple of years back when GitHub Actions first came out, and my motivation there was I'm just impatient. And that whole commit, push, wait time where you're testing out your pipelines is painful. And so I wanted to build a tool that allowed developers to test out their GitHub Actions workflows locally. And so this tool uses Docker containers to emulate, to get up action environment and gives you fast feedback on those workflows that you're building. Lot of innovation happening at GitHub. And so we're just trying to keep up and continue to replicate those new features functionalities in the local runner. And the biggest challenge I've had with this project is just keeping up with the community. We just passed 20,000 stars, and it'd be it's a normal week to get like 10 PRs. So super excited to announce just yesterday, actually I invited four of the most active contributors to help me with maintaining the project. And so this is like a big deal for me, letting the project go and bringing other people in to help lead it. So, yeah, huge shout out to those folks that have been helping with driving that project. So looking forward to what's next for it. >> Great, we'll make sure the SiliconANGLE riders catch that quote there. Great call out. Let's start, Brian, you made me realize when you mentioned Apache and then you've been watching all the stuff going on, it brings up the question of the evolution of Open Source, and the commercialization trends have been very interesting these days. You're seeing CloudScale really impact also with the growth of code. And Liz, if you remember, the Linux Foundation keeps making projections and they keep blowing past them every year on more and more code and more and more entrance coming in, not just individuals, corporations. So you starting to see Netflix donates something, you got Lyft donate some stuff, becomes a project company forms around it. There's a lot of entrepreneurial activity that's creating this new abstraction layers, new platforms, not just tools. So you start to see a new kickup trajectory with Open Source. You guys want to comment on this because this is going to impact how fast the enterprise will see value here. >> I think a really great example of that is a project called Backstage that's just come out of Spotify. And it's going through the incubation process at the CNCF. And that's why it's front of mind for me right now, 'cause I've been working on the due diligence for that. And the reason why I thought it was interesting in relation to your question is it's spun out of Spotify. It's fully Open Source. They have a ton of different enterprises using it as this developer portal, but they're starting to see some startups emerging offering like a hosted managed version of Backstage or offering services around Backstage or offering commercial plugins into Backstage. And I think it's really fascinating to see those ecosystems building up around a project and different ways that people can. I'm a big believer. You cannot sell the Open Source code, but you can sell other things that create value around Open Source projects. So that's really exciting to see. >> Great point. Anyone else want to weigh in and react to that? Because it's the new model. It's not the old way. I mean, I remember when I was in college, we had the Pirate software. Open Source wasn't around. So you had to deal under the table. Now it's free. But I mean the old way was you had to convince the enterprise, like you've got a hard knit, it builds the community and the community manage the quality of the code. And then you had to build the company to make sure they could support it. Now the companies are actually involved in it, right? And then new startups are forming faster. And the proof points are shorter and highly accelerated for that. I mean, it's a whole new- >> It's a Cambrian explosion, and it's great. It's one of those things that it's challenging for the new developers because they come in and they're like, "Whoa, what is all this stuff that I'm supposed to figure out?" And there's no right answer and there's no wrong answer. There's just tons of it. And I think that there's a desire for us to have one sort of well-known trot and happy path, that audience we're a lot better with a more diverse community, with lots of options, with lots of ways to approach these problems. And I think it's just great. A challenge that we have with all these options and all these Cambrian explosion of projects and all these competing ideas, right now, the sustainability, it's a bit of a tricky question to answer. We know that there's a commercialization aspect that helps us fund these projects, but how we compose the open versus the commercial source is still a bit of a tricky question and a tough one for a lot of folks. >> Erica, would you chime in on that for a second. I want to get your angle on that, this experience and all this code, and I'm a new person, I'm an existing person. Do I get like a blue check mark and verify? I mean, these are questions like, well, how do you navigate? >> Yeah, I think this has been something happening for a while. I mean, back in the early OpenStack days, 2010, for instance, Rackspace Open Sourcing, OpenStack and ANSU Labs and so forth, and then trying, having all these companies forming in creating startups around this. I started at a company called Cloudccaling back in late 2010, and we had some competitors such as Piston and so forth where a lot of the ANSUL Labs people went. But then, the real winners, I think from OpenStack ended up being the enterprises that jumped in. We had Red Hat in particular, as well as HP and IBM jumping in and investing in OpenStack, and really proving out a lot of... not that it was the first time, but this is when we started seeing billions of dollars pouring into Open Source projects and Open Source Foundations, such as the OpenStack Foundation, which proceeded a lot of the things that we now see with the Linux Foundation, which was then created a little bit later. And at the same time, I'm also reflecting a little bit what Brian said because there are projects that don't get funded, that don't get the same attention, but they're also getting used quite significantly. Things like Log4j really bringing this to the spotlight in terms of projects that are used everywhere by everything with significant outsized impacts on the industry that are not getting funded, that aren't flashy enough, that aren't exciting enough because it's just logging, but a vulnerability in it brings every everything and everybody down and has possibly billions of dollars of impact to our industry because nobody wanted to fund this project. >> I think that brings up the commercialization point about maybe bringing a venture capital model in saying, "Hey, that boring little logging thing could be a key ingredient for say solving some observability problems so I think let's put some cash." Again then we'd never seen that before. Now you're starting to see that kind of a real smart investment thesis going into Open Source projects. I mean, Promethease, Crafter, these are projects that turned off companies. This is turning up companies. >> A decade ago, there was no money in Dev tools that I think that's been fully debunked now. They used to be a concept that the venture community believed, but there's just too much evidence to the contrary, the companies like Cash Court, Datadog, the list goes on and on. I think the challenge for the Open Source (indistinct) comes back to foundations and working (indistinct) these developers make this code safe and secure. >> Casey, what's your reaction to all of this? You've got, so a project has gained some traction, got some momentum. There's a lot of mission critical. I won't say white spaces, but the opportunities in the big cloud game happening. And there's a lot of, I won't say too many entrepreneurial, but there's a lot of community action happening that's precommercialization that's getting traction. How does this all develop naturally and then vector in quickly when it hits? >> Yeah, I want to go back to the Log4j topic real quick. I think that it's a great example of an area that we need to do better at. And there was a cool article that Rob Pike wrote describing how to quantify the criticality. I think that's sort of quantifying criticality was the article he wrote on how to use metrics, to determine how valuable, how important a piece of Open Source is to the community. And we really need to highlight that more. We need a way to make it more clear how important this software is, how many people depend on it and how many people are contributing to it. And because right now we all do that. Like if I'm going to evaluate an Open Source software, sure, I'll look at how many stars it has and how many contributors it has. But I got to go through and do all that work myself and come up with. It would be really great if we had an agreed upon method for ranking the criticality of software, but then also the risk, hey, that this is used by a ton of people, but nobody's contributing to it anymore. That's a concern. And that would be great to potential users of that to signal whether or not it makes sense. The Open Source Security Foundation, just getting off the ground, they're doing some work in this space, and I'm really excited to see where they go with that looking at ways to stop score critically. >> Well, this brings up a good point while we've got everyone here, let's take a plug and plug a project you think that's not getting the visibility it needs. Let's go through each of you, point out a project that you think people should be looking at and talking about that might get some free visibility here. Anyone want to highlight projects they think should be focused more on, or that needs a little bit of love? >> I think, I mean, particularly if we're talking about these sort of vulnerability issues, there's a ton of work going on, like in the Secure Software Foundation, other foundations, I think there's work going on in Apache somewhere as well around the bill of material, the software bill of materials, the Secure Software supply chain security, even enumerating your dependencies is not trivial today. So I think there's going to be a ton of people doing really good work on that, as well as the criticality aspect. It's all like that. There's a really great xkcd cartoon with your software project and some really big monolithic lumps. And then, this tiny little piece in a very important point that's maintained by somebody in his bedroom in Montana or something and if you called it out. >> Yeah, you just opened where the next lightening and a bottle comes from. And this is I think the beauty of Open Source is that you get a little collaboration, you get three feet in a cloud of dust going and you get some momentum, and if it's relevant, it rises to the top. I think that's the collective intelligence of Open Source. The question I want to ask that the panel here is when you go into an enterprise, and now that the game is changing with a much more collaborative and involved, what's the story if they say, hey, what's in it for me, how do I manage the Open Source? What's the current best practice? Because there's no doubt I can't ignore it. It's in everything we do. How do I organize around it? How do I build around it to be more efficient and more productive and reduce the risk on vulnerabilities to managing staff, making sure the right teams in place, the right agility and all those things? >> You called it, they got to get skin in the game. They need to be active and involved and donating to a sustainable Open Source project is a great way to start. But if you really want to be active, then you should be committing. You should have a goal for your organization to be contributing back to that project. Maybe not committing code, it could be committing resources into the darks or in the tests, or even tweeting about an Open Source project is contributing to it. And I think a lot of these enterprises could benefit a lot from getting more active with the Open Source Foundations that are out there. >> Liz, you've been actively involved. I know we've talked personally when the CNCF started, which had a great commercial uptake from companies. What do you think the current state-of-the-art kind of equation is has it changed a little bit? Or is it the game still the same? >> Yeah, and in the early days of the CNCF, it was very much dominated by vendors behind the project. And now we're seeing more and more membership from end-user companies, the kind of enterprises that are building their businesses on Cloud Native, but their business is not in itself. That's not there. The infrastructure is not their business. And I think seeing those companies, putting money in, putting time in, as Brian says contributing resources quite often, there's enough money, but finding the talent to do the work and finding people who are prepared to actually chop the wood and carry the water, >> Exactly. >> that it's hard. >> And if enterprises can find peoples to spend time on Open Source projects, help with those chores, it's hugely valuable. And it's one of those the rising tide floats all the boats. We can raise security, we can reduce the amount of dependency on maintain projects collectively. >> I think the business models there, I think one of the things I'll react to and then get your guys' comments is remember which CubeCon it was, it was one of the early ones. And I remember seeing Apple having a booth, but nobody was manning. It was just an Apple booth. They weren't doing anything, but they were recruiting. And I think you saw the transition of a business model where the worry about a big vendor taking over a project and having undue influence over it goes away because I think this idea of participation is also talent, but also committing that talent back into the communities as a model, as a business model, like, okay, hire some great people, but listen, don't screw up the Open Source piece of it 'cause that's a critical. >> Also hire a channel, right? They can use those contributions to source that talent and build the reputation in the communities that they depend on. And so there's really a lot of benefit to the larger organizations that can do this. They'll have a huge pipeline of really qualified engineers right out the gate without having to resort to cheesy whiteboard interviews, which is pretty great. >> Yeah, I agree with a lot of this. One of my concerns is that a lot of these corporations tend to focus very narrowly on certain projects, which they feel that they depend greatly, they'll invest in OpenStack, they'll invest in Docker, they'll invest in some of the CNCF projects. And then these other projects get ignored. Something that I've been a proponent of for a little bit for a while is observability of your dependencies. And I don't think there's quite enough projects and solutions to this. And it sounds maybe from lists, there are some projects that I don't know about, but I also know that there's some startups like Snyk and so forth that help with a little bit of this problem, but I think we need more focus on some of these edges. And I think companies need to do better, both in providing, having some sort of solution for observability of the dependencies, as well as understanding those dependencies and managing them. I've seen companies for instance, depending on software that they actively don't want to use based on a certain criteria that they already set projects, like they'll set a requirement that any project that they use has a code of conduct, but they'll then use projects that don't have codes of conduct. And if they don't have a code of conduct, then employees are prohibited from working on those projects. So you've locked yourself into a place where you're depending on software that you have instructed, your employees are not allowed to contribute to, for certain legal and other reasons. So you need to draw a line in the sand and then recognize that those projects are ones that you don't want to consume, and then not use them, and have observability around these things. >> That's a great point. I think we have 10 minutes left. I want to just shift to a topic that I think is relevant. And that is as Open Source software, software, people develop software, you see under the hood kind of software, SREs developing very quickly in the CloudScale, but also you've got your classic software developers who were writing code. So you have supply chain, software supply chain challenges. You mentioned developer experience around how to code. You have now automation in place. So you've got the development of all these things that are happening. Like I just want to write software. Some people want to get and do infrastructure as code so DevSecOps is here. So how does that look like going forward? How has the future of Open Source going to make the developers just want to code quickly? And the folks who want to tweak the infrastructure a bit more efficient, any views on that? >> At Gaggle, we're using AWS' CDK, exclusively for our infrastructure as code. And it's a great transition for developers instead of writing Yammel or Jason, or even HCL for their infrastructure code, now they're writing code in the language that they're used to Python or JavaScript, and what that's providing is an easier transition for developers into that Infrastructure as code at Gaggle here, but it's also providing an opportunity to provide reusable constructs that some Devs can build on. So if we've got a very opinionated way to deploy a serverless app in a database and do auto-scaling behind and all stuff, we can present that to a developer as a library, and they can just consume it as it is. Maybe that's as deep as they want to go and they're happy with that. But then they want to go deeper into it, they can either use some of the lower level constructs or create PRs to the platform team to have those constructs changed to fit their needs. So it provides a nice on-ramp developers to use the tools and languages they're used to, and then also go deeper as they need. >> That's awesome. Does that mean they're not full stack developers anymore that they're half stack developers they're taking care of for them? >> I don't know either. >> We'll in. >> No, only kidding. Anyway, any other reactions to this whole? I just want to code, make it easy for me, and some people want to get down and dirty under the hood. >> So I think that for me, Docker was always a key part of this. I don't know when DevSecOps was coined exactly, but I was talking with people about it back in 2012. And when I joined Docker, it was a part of that vision for me, was that Docker was applying these security principles by default for your application. It wasn't, I mean, yes, everybody adopted because of the portability and the acceleration of development, but it was for me, the fact that it was limiting what you could do from a security angle by default, and then giving you these tuna balls that you can control it further. You asked about a project that may not get enough recognition is something called DockerSlim, which is designed to optimize your containers and will make them smaller, but it also constraints the security footprint, and we'll remove capabilities from the container. It will help you build security profiles for app armor and the Red Hat one. SELinux. >> SELinux. >> Yeah, and this is something that I think a lot of developers, it's kind of outside of the realm of things that they're really thinking about. So the more that we can automate those processes and make it easier out of the box for users or for... when I say users, I mean, developers, so that it's straightforward and automatic and also giving them the capability of refining it and tuning it as needed, or simply choosing platforms like serverless offerings, which have these security constraints built in out of the box and sometimes maybe less tuneable, but very strong by default. And I think that's a good place for us to be is where we just enforced these things and make you do things in a secure way. >> Yeah, I'm a huge fan of Kubernetes, but it's not the right hammer for every nail. And there are absolutely tons of applications that are better served by something like Lambda where a lot more of that security surface is taken care of for the developer. And I think we will see better tooling around security profiling and making it easier to shrink wrap your applications that there are plenty of products out there that can help you with this in a cloud native environment. But I think for the smaller developer let's say, or an earlier stage company, yeah, it needs to be so much more straightforward. Really does. >> Really an interesting time, 10 years ago, when I was working at Adobe, we used to requisition all these analysts to tell us how many developers there were for the market. And we thought there was about 20 million developers. If GitHub's to be believed, we think there is now around 80 million developers. So both these groups are probably wrong in their numbers, but the takeaway here for me is that we've got a lot of new developers and a lot of these new developers are really struck by a paradox of choice. And they're typically starting on the front end. And so there's a lot of movement in the stack moved towards the front end. We saw that at re:Invent when Amazon was really pushing Amplify 'cause they're seeing this too. It's interesting because this is where folks start. And so a lot of the obstructions are moving in that direction, but maybe not always necessarily totally appropriate. And so finding the right balance for folks is still a work in progress. Like Lambda is a great example. It lets me focus totally on just business logic. I don't have to think about infrastructure pretty much at all. And if I'm newer to the industry, that makes a lot of sense to me. As use cases expand, all of a sudden, reality intervenes, and it might not be appropriate for everything. And so figuring out what those edges are, is still the challenge, I think. >> All right, thank you very much for coming on the CUBE here panel. AWS Heroes, thanks everyone for coming. I really appreciate it, thank you. >> Thank you. >> Thank you. >> Okay. >> Thanks for having me. >> Okay, that's a wrap here back to the program and the awesome startups. Thanks for watching. (upbeat music)

>>Welcome everyone to the cubes presentation of the AWS startup showcase open cloud innovations. This is season two episode one of the ongoing series and we're covering exciting and innovative startups from the AWS ecosystem. Today. We're going to focus on the open source community. I'm your host, Dave Vellante. And right now we're going to talk about open source security and mitigating risk in light of a recent discovery of a zero day flaw in log for J a Java logging utility and a related white house executive order that points to the FTC pursuing companies that don't properly secure consumer data as a result of this vulnerability and with me to discuss this critical issue and how to more broadly address software supply chain risk is Don Fisher. Who's the CEO of tide lift. Thank you for coming on the program, Donald. >>Thanks for having me excited to be here. Yeah, pleasure. >>So look, there's a lot of buzz. You open the news, you go to your favorite news site and you see this, you know, a log for J this is an, a project otherwise known as logged for shell. It's this logging tool. My understanding is it's, it's both ubiquitous and very easy to exploit. Maybe you could explain that in a little bit more detail. And how do you think this vulnerability is going to affect things this year? >>Yeah, happy to, happy to dig in a little bit in orient around this. So, you know, just a little definitions to start with. So log for J is a very widely used course component that's been around for quite a while. It's actually an amazing piece of technology log for J is used in practically every serious enterprise Java application over the last 10 going on 20 years. So it's, you know, log for J itself is fantastic. The challenge that organization organizations have been facing relate to a specific security vulnerability that was discovered in log for J and that has been given this sort of brand's name as it happens these days. Folks may remember Heartbleed around the openness to sell vulnerability some years back. This one has been dubbed logged for shell. And the reason why it was given that name is that this is a form of security vulnerability that actually allows attackers. >>You know, if a system is found that hasn't been patched to remediate it, it allows hackers to get full control of a, of a system of a server that has the software running on it, or includes this log for J component. And that means that they can do anything. They can access, you know, private customer data on that system, or really do anything and so-called shell level access. So, you know, that's the sort of definitions of what it is, but the reason why it's important is in the, in the small, you know, this is a open door, right? It's a, if, if organizations haven't patched this, they need to respond to it. But one of the things that's kind of, you know, I think important to recognize here is that this log for J is just one of literally thousands of independently created open source components that flow into the applications that almost every organization built and all of them all software is going to have security vulnerabilities. And so I think that log for J is, has been a catalyst for organizations to say, okay, we've got to solve this specific problem, but we all also have to think ahead about how is this all gonna work. If our software supply chain originates with independent creators across thousands of projects across the internet, how are we going to put a better plan in place to think ahead to the next log for J log for shell style incident? And for sure there will be more >>Okay. So you see this incident as a catalyst to maybe more broadly thinking about how to secure the, the digital supply chain. >>Absolutely. Yeah, it's a, this is proving a point that, you know, a variety of folks have been making for a number of years. Hey, we depend, I mean, honestly these days more than 70% of most applications, most custom applications are comprised of this third party open source code. Project's very similar in origin and governance to log for J that's just reality. It's actually great. That's an amazing thing that the humans collaborating on the internet have caused to be possible that we have this rich comments of open source software to build with, but we also have to be practical about it and say, Hey, how are we going to work together to make sure that that software as much as possible is vetted to ensure that it meets commercial standards, enterprise standards ahead of time. And then when the inevitable issues arise like this incident around the log for J library, that we have a great plan in place to respond to it and to, you know, close the close the door on vulnerabilities when they, when they show up. >>I mean, you know, when you listen to the high level narrative, it's easy to point fingers at organizations, Hey, you're not doing enough now. Of course the U S government has definitely made attempts to emphasize this and, and shore up in, in, in, in, in push people to shore up the software supply chain, they've released an executive order last may, but, but specifically, I mean, it's just a complicated situation. So what steps should organizations really take to make sure that they don't fall prey to these future supply chain attacks, which, you know, are, as you pointed out are inevitable. >>Yeah. I mean, it's, it's a great point that you make that the us federal government has taken proactive steps starting last year, 2021 in the fallout of the solar winds breach, you know, about 12 months ago from the time that we're talking, talking here, the U S government actually was a bit ahead of the game, both in flagging the severity of this, you know, area of concern and also directing organizations on how to respond to it. So the, in May, 2021, the white house issued an executive order on cybersecurity and it S directed federal agencies to undertake a whole bunch of new measures to ensure the security of different aspects of their technology and software supply chain specifically called out open source software as an area where they put, you know, hard requirements around federal agencies when they're acquiring technology. And one of the things that the federal government that the white house cybersecurity executive order directed was that organizations need to start with creating a list of the third-party open source. >>That's flowing into their applications, just that even have a table of contents or an index to start working with. And that's, that's called a, a software bill of materials or S bomb is how some people pronounce that acronym. So th the federal government basically requires federal agencies to now create Nessbaum for their applications to demand a software bill of materials from vendors that are doing business with the government and the strategy there has been to expressly use the purchasing power of the us government to level up industry as a whole, and create the necessary incentives for organizations to, to take this seriously. >>You know, I, I feel like the solar winds hack that you mentioned, of course it was widely affected the government. So we kind of woke them up, but I feel like it was almost like a stuck set Stuxnet moment. Donald were very sophisticated. I mean, for the first time patches that were supposed to be helping us protect, now we have to be careful with them. And you mentioned the, the bill of its software, bill of materials. We have to really inspect that. And so let's get to what you guys do. How do you help organizations deal with this problem and secure their open source software supply chain? >>Yeah, absolutely happy to tell you about, about tide lift and, and how we're looking to help. So, you know, the company, I co-founded the company with a couple of colleagues, all of whom are long-term open source folks. You know, I've been working in around commercializing open source for the last 20 years that companies like red hat and, and a number of others as have my co-founders the opportunity that we saw is that, you know, while there have been vendors for some of the traditional systems level, open source components and stacks like Linux, you know, of course there's red hat and other vendors for Linux, or for Kubernetes, or for some of the databases, you know, there's standalone companies for these logs, for shell style projects, there just hasn't been a vendor for them. And part of it is there's a challenge to cover a really vast territory, a typical enterprise that we inspect has, you know, upwards of 10,000 log for shell log for J like components flowing into their application. >>So how do they get a hand around their hands around that challenge of managing that and ensuring it needs, you know, reasonable commercial standards. That's what tide lifts sets out to do. And we do it through a combination of two elements, both of which are fairly unique in the market. The first of those is a purpose-built software solution that we've created that keeps track of the third-party open source, flowing into your applications, inserts itself into your DevSecOps tool chain, your developer tooling, your application development process. And you can kind of think of it as next to the point in your release process, where you run your unit test to ensure the business logic in the code that your team is writing is accurate and sort of passes tests. We do a inspection to look at the state of the third-party open source packages like Apache log for J that are flowing into your, into your application. >>So there's a software element to it. That's a multi-tenant SAS service. We're excited to be partnered with, with AWS. And one of the reasons why we're here in this venue, talking about how we are making that available jointly with AWS to, to drink customers deploying on AWS platforms. Now, the other piece of the, of our solution is really, really unique. And that's the set of relationships that Tyler has built directly with these independent open source maintainers, the folks behind these open source packages that organizations rely on. And, you know, this is where we sort of have this idea. Somebody is making that software in the first place, right? And so would those folks be interested? Could we create a set of aligned incentives to encourage them, to make sure that that software meets a bunch of enterprise standards and areas around security, like, you know, relating to the log for J vulnerability, but also other complicated parts of open source consumption like licensing and open source license, accuracy, and compatibility, and also maintenance. >>Like if somebody looking after the software going forward. So just trying to basically invite open source creators, to partner with us, to level up their packages through those relationships, we get really, really clean, clear first party data from the folks who create, maintain the software. And we can flow that through the tools that I described so that end organizations can know that they're building with open source components that have been vetted to meet these standards, by the way, there's a really cool side effect of this business model, which is that we pay these open source maintainers to do this work with us. And so now we're creating a new income stream around what previously had been primarily a volunteer activity done for impact in this universe of open source software. We're helping these open source maintainers kind of GoPro on an aspect of what they do around open source. And that means they can spend more time applying more process and tools and methodology to making that open source software even better. And that's good for our customers. And it's good for everyone who relies on open source software, which is really everyone in society these days. That's interesting. I >>Was going to ask you what's their incentive other than doing the right thing. Can you give us an example of, of maybe a example of an open source maintainer that you're working with? >>Yeah. I mean, w we're working with hundreds of open source maintainers and a few of the key open source foundations in different areas across JavaScript, Java PHP, Ruby python.net, and, you know, like examples of categories of projects that we're working with, just to be clear, are things like, you know, web frameworks or parser libraries or logging libraries, like a, you know, log for J and all the other languages, right? Or, you know, time and date manipulation libraries. I mean, they, these are sort of the, you know, kind of core building blocks of applications and individually, they, you know, they may seem like, you know, maybe a minor, a minor thing, but when you multiply them across how many applications these get used in and log for J is a really, really clarifying case for folks to understand this, you know, what can seemingly a small part of your overall application estate can have disproportionate impact on, on your operations? As we saw with many organizations that spent, you know, a weekend or a week, or a large part of the holidays, scrambling to patch and remediate this, a single vulnerability in one of those thousands of packages in that case log. >>Okay, got it. So you have this two, two headed, two vectors that I'm going to call it, your ecosystem, your relationship with these open source maintainers is kind of a, that just didn't happen overnight, and it develop those relationships. And now you get first party data. You monetize that with a software service that is purpose built as the monitor of the probe that actually tracks that third, third party activity. So >>Exactly right. Got it. >>Okay. So a lot of companies, Donald, I mean, this is, like I said before, it's a complicated situation. You know, a lot of people don't have the skillsets to deal with this. And so many companies just kind of stick their head in the sand and, you know, hope for the best, but that's not a great strategy. What are the implications for organizations if they don't really put the tools and processes into place to manage their open source, digital supply chain. >>Yeah. Ignoring the problem is not a viable strategy anymore, you know, and it's just become increasingly clear as these big headline incidents that happened like Heartbleed and solar winds. And now this logged for shell vulnerability. So you can, you can bet on that. Continuing into the future and organizations I think are, are realizing the ones that haven't gotten ahead of this problem are realizing this is a critical issue that they need to address, but they have help, right. You know, the federal government, another action beyond that cybersecurity executive order that was directed at federal agencies early last year, just in the last week or so, the FTC of the U S federal trade commission has made a much more direct warning to private companies and industry saying that, you know, issues like this log for J vulnerability risk exposing private, you know, consumer data. That is one of the express mandates of the FTC is to avoid that the FTC has said that this is, you know, bears on both the federal trade commission act, as well as the Gramm-Leach-Bliley act, which relates to consumer data privacy. >>And the FTC just came right out and said it, they said they cited the $700 million settlements that Equifax was subject to for their data breach that also related to open source component, by the way, that that had not been patched by, by Equifax. And they said the FTC intents to use its full legal authority to pursue companies that failed to take reasonable steps, to protect consumer data from exposure as a result of log for J or similar known vulnerabilities in the future. So the FTC is saying, you know, this is a critical issue for consumer privacy and consumer data. We are going to enforce against companies that do not take reasonable precautions. What are reasonable precautions? I think it's kind of a mosaic of solutions, but I'm glad to say tide lift is contributing a really different and novel solution to the mix that we hope will help organizations contend with this and avoid that kind of enforcement action from FTC or other regulators. >>Well, and the good news is that you can tap a tooling like tide lift in the cloud as a service and you know, much easier today than it was 10 or 15 years ago to, to resolve, or at least begin to demonstrate that you're taking action against this problem. >>Absolutely. There's new challenges. Now I'm moving into a world where we build on a foundation of independently created open source. We need new solutions and new ideas, and that's a, you know, that's part of what we're, we're, we're showing up with from the tide lift angle, but there's many other elements that are going to be necessary to provide the full solution around securing the open source supply chain going forward. >>Well, Donald Fisher of tide lift, thanks so much for coming to the cube and best of luck to your organization. Thanks for the good work that you guys do. >>Thanks, Dave. Really appreciate your partnership on this, getting the word out and yeah, thanks so much for today. >>Very welcome. And you are watching the AWS startup showcase open cloud innovations. Keep it right there for more action on the cube, your leader in enterprise tech coverage.

(upbeat music) >> Welcome to theCUBE. I'm Dave Nicholson, and this is part of the continuing conversation about Managing Risk in the Digital Supply Chain. I have with me today Vincent Danen, vice president of product security from Red Hat and Luke Hines security engineering lead from the office of the CTO at Red Hat. Gentlemen, welcome to theCUBE. >> Thank you. >> Great to be here. >> So let's just start out and dive right into this, Vincent, what is the software or digital supply chain? What are we talking about? Yeah, that's a good question. Software supply chain is basically the software that an end user would get from a vendor or in our case, we're talking about open source, so upstream. It is the software that comes in that is part of your package, operating system, applications. It could be something that you get from one vendor, multiple vendors. So we look at in the example of Red Hat, we are one part of the customer's software supply chain. >> So it's interesting that it's coming in from different areas. Do we have a sense for the ratio of kind of commercial software versus open source software that makes up an enterprise today? >> I think that's a really hard thing to answer and I think every enterprise or every company would have a little bit different. Depends if you have an open source vendor that you choose, you may get a significant amount of software from them. Certainly you're not going to get it all. As an example, Red Hat provides thousands of open source packages. We certainly can't provide all of them. There are millions that are out there. So when you're looking at a specific application that you're building, chances are, you could be running that on a managed platform or an enterprise supply platform, but there are going to be packages that you're going to be obtaining from other sources in other communities as well in order to power your applications. >> So, Luke, that sounds like a kind of a vague situation we're looking at in terms of where all of our software is coming from. So what do we need to know about our software supply chain in that context? What do we need to understand? Before we even get anywhere near the idea of securing it, what are some of the issues that arise from that? >> Yeah, so Vincent's touchpoint is a very wide range in ecosystem, multiple sources when we're talking about open source. So essentially awareness is key really. I think a lot of people are really not aware of the sources that they're drawing from to create their own supply chain. So there's multiple supply chains. You can be somebody like Red Hat that the provide software, and then people will leverage Red Hats for their own supply chain. And then you have the cloud provider and they have their own source of software. So I think that the key thing is the awareness of how much you rely upon that ecosystem before we look at the security of the supply chain. It's really understanding your supply chain. >> And just to follow up on that. So can you... I'm sort of checking my own level of understanding on this subject. When you talk about open source code, you're talking about a code base that is often maintained essentially by volunteers, isn't that correct? >> A mix of volunteers and paid professionals where a company has an interest in the open source project, but predominantly I would say it's... Well, I'm not entirely sure, but volunteers make up a substantial part of the ecosystem that is for sure. So it's a mix really. Some people do it because they enjoy writing software. They want to share software. Other people also enjoy working software, but they're in the position that a company pays for them to work on that software. So it's a mix of both. >> Vincent, give us a reminder of reminder of why this is important from a little bit of a higher level. Step back from the data center view of things, from the IT view of things, just from a societal perspective, Vincent, what happens when we don't secure our digital supply chain? What are the things that are put at risk? >> Okay, well, there's a significant number of things that are placed at risk, the security of the enterprise itself. So your own customer data, your own internal corporate data is place at risk if there were a supply chain breach. But further to that for a software provider, and I think that in a lot of cases, most companies today are software providers or software developers. You actually put your own customers at risk as well, not just their data, but their actual... The things that they're working on, any workloads that they may have, an order that they might place as an example. So there's a number of areas where you want to have the security of that supply chain and the software components that you have figured out. You want to be on top of that because there is that risk that trickles down when it comes to an event. I mean, we've seen that with breaches earlier this year, one company is breached multiple companies end up being breached as a result of that. So it's really important. I think we all have a part to play in that I always view it as it's not just about the company itself. So I mean, speaking from a Red Hat perspective, I don't look at it as we're just securing Red Hat, we're securing our customers, and then we're also doing that for their customers as well, because they're writing software that's running on the software that we're providing to them. So there is this trickle down effect that comes, and so I think that every link in that chain, I mean, it's wonderful that it's called a supply chain. It's only as strong as its weakest link. So our view is how do we strengthen every link in that chain? And we're one part of it, but we're kind of looking a little broader, what can we do upstream and how can we help our customers to ensure the security of their part in that supply chain? >> Yeah, I want to talk about that in a broad sense, but let's see if we can get a little bit more specific in terms of what some of the chains look like because it's not just really one chain when you think about it, there's the idea of inherent flaws that can be caught and then there are the things that bad actors might be doing to leverage those flaws. So you've got all of these different things that are converging. So first and Vincent, if you want to toss this to Luke back and forth, it's up to you guys. What about this issue of inherent flaws in code? We referenced this idea of the maintainer community. What are best practices for locking that down to make sure that there aren't inherent flaws or security risks? >> I'll take a stab at it, and then I'll let Luke follow up with maybe some of the technologies that Red Hat provides. And again, speaking to Red Hat as part of that chain. When we're talking about inherent risk, there's a vulnerability that's present upstream. We pull that software to Red Hat. We package it as a component of one of the pieces of software that we provide to our customers. It's our responsibility to pay attention to those upstream potential vulnerabilities, potential risks, and correct them in our code. So that might be taking a patch from upstream, applying it to our software, might be grabbing the latest version from upstream, whatever the case might be, but it's our responsibility to provide that protection for that software to actually remediate that risk, and then our customers can then install the update and apply the mitigation themselves. If we take a look at it from, when we're looking at multiple suppliers where you'd asked earlier about, what part of it is Red Hat and what part of it is self-service open source? When you look at that, the work that Red Hat's doing there as a commercial provider of open source and end user for that little bit that they're going to grab themselves, that Red Hat doesn't provide, it's going to have to do all of those things as well. They're going to have to pay attention to that risk from upstream. They're going to have to pay attention to any potential vulnerabilities and pull that in to figure out, do I need to patch? Where do I need to patch it? And that's something we didn't really touch on was an inventory of the software that you have in place. I mean, you don't know that you need to fix something. You don't even know that it's running. So, I mean, there's a lot of considerations there where you have to pay attention to a lot of sources. Certainly there's a metadata automation, all of these things that make it easier, but it doesn't absolve us of the responsibility across the board to pay attention to these things, whether you're grabbing it from upstream directly or from the vendor. And it's the vendor's responsibility to then be paying attention to things upstream. >> Yeah, so Luke, I want you to kind of riff on that from the perspective that let's just assume that Vincent was just primarily talking about the idea that, okay, we've established that this code is solid and we've got gold copy of it and we know it's okay. There aren't inherent problems in the code as far as we can tell. Well, that's fine. I'm a developer. I go out to pull code and to use. How do I know if it's not been tampered with? How do I know if it's in fact the code that was validated during this process before? What do you do about that? >> So there's several methods there, but I just like to loop back to that point, because I think this is really interesting around, so if you look at a software supply chain, this is a mix of humans and machines, and both have flaws, probably humans a bit more. And a supply chain, you have developers. You have code reviewers, you have your systems administrators that set up the systems, and then you have your machine actors. So you've got your build systems, the various machines that are part of that supply chain. Now the humans, there's a as an attack factor there 'cause typically they will have some sort of identity, which they leverage for access to the supply chain. So quite often a developer's identity can be compromised. So a lot of the time people will have a corporate account that gives them some sort of single sign on access to multiple systems. So the developers are coming and this could be somebody in the community as well. Their account is compromised, then they're able to easily backdoor systems. So that's one aspect. And then there is machines as well. There's the whole premise of machines software not being up to date. So when the latest nasty vulnerability is released, machines are updated, then the machines have their flaws. They can be exploited. So I would say it's not just a technical problem. There is a humanistic element to this as well around protecting your supply chain. And I would say a really good perspective to carry when you're looking to, how do I secure my supply chain is treat it like you would a production system. So what do I mean by that? When we put something into production and we've got this very long legacy of treating it with a very strict security context around who can access that people, okay. How much it's upgraded and it's patched? And we seem to not have this same perception around our supply chain and our build systems, the integrity of those, the access of those, the policy around the access and so forth. So that's one giveaway that I would say is a real key focus that you should have is treat it like a production system. Be very mindful about what you're bringing in, who can access it because it is the keys to the kingdom, because if somebody compromises your supply chain, your build systems and so forth, they can compromise the whole chain because the chain is only as strong as the weakest link. So that's what I draw upon it. And around the verifications, there is multiple technologies that you can leverage. So Red Hat, we've got a very robust sign in system that we use so that you can be sure that the packages that we get you have non-repudiation that they've been produced by Red Hat. When you update your system, that's automatically looked after. And there are other systems as well, there's other new technologies that are starting to get a foothold around the provenance of aspects of your build system. So when you're pulling in from these multiple sources of open source communities, you can have some provenance around what you're putting in as well. And yeah, I don't want to bite share too much on the technologies, but there's some exciting stuff starting to happen there as well. >> So let's look at an example of something, because I think it's important to understand all of these different aspects. Recently, I think actually still in the news, we found that some logging software distributed by Apache that's widely used in people's websites to gather information about... To help from a security perspective and to help developers improve things that are going on in websites. A vulnerability was discovered. I guess, first Alibaba, some folks were reported it directly to some folks at Apache and the Apache Organization. And then of all people, some folks from Minecraft mentioned it in a blog. That seems like a crazy way to find out about something that's a critical flaw. Now we're looking at this right now with hindsight. So with hindsight, what could we have done to not be in the circumstances that we're in right now? Vincent, I'll toss that to you first, but again, if Luke is more appropriate, let us know. >> No, it's a great question, and it's a hard question. >> How did you let this happen, Vincent? How did you let this happen? >> It wasn't me, I promise. (Dave laughs) >> What I mean, it's a challenging question I mean, and there's a number of areas where we focused on a lot of what we perceived as critical software. So it comes to web server applications, DNS, a number of the kind of the critical infrastructure that powers the internet. Right or wrong. Do we look at logging software as a critical piece of that? Well, maybe, maybe we should, right? Logging is definitely important as part of an incident response or just an awareness of what's going on. So, I mean, yeah, it probably should have been considered critical software, but I mean, it's open source, right? So there's a number of different logging applications. I imagine now we're scrutinizing those a little bit more, but looking beforehand, how do you determine what's critical until an event like this happens, and it's unfortunate that it happens. And I like to think of these as learning opportunities, and certainly not just for Red Hat, but for this (talking over each other) >> Certainly this is not... Yeah, this is not an indictment of our entire industry. We are all in this together and learning every day. It just highlights how complex the situation is that we're dealing with, right? >> It really is. And I mean, a lot of what we're looking at now is how do we get tools into the hands of developers who can catch some of these things earlier. And there's a lot of commercial offerings, there's a lot of open source tools that are available and being produced that are going to help with these sorts of situations moving forward. But I mean, all the tools on the planet aren't going to help if they're not being used. So, I mean, there has to be an education and an incentive for these developers, particularly, maybe in some upstream communities where they are labors of love and they're passionate projects they're not sponsored or backed by a corporation who's paying for these tools, to be able to use some of them and move that forward. I think that looking at things now, there is work to be done. Obviously there's always going to be work to be done. Not all of these tools, and we have to recognize this, they're not all perfect. They're not going to catch everything. These tools could have been... I mean, I don't know if they were running these tools or not, they could have been, and the tool simply could not have picked them up. So part of it is the proactive part. We talk a lot about shift left and moving these things earlier into the development process and that's great, and we should do it. It certainly should never be seen as a silver bullet or a replacement for a good response. And I think the really important thing to highlight with respect to this, and I mean, this touches on the supply chain issue as well, companies, especially those who never maybe saw themselves as a software development company really have to figure out and understand how to do appropriate response. Part of that is awareness, what do you have installed? Part of it is sources of information. Like how do I find out about a new vulnerability or a potential vulnerability? And then it's just the speed to respond. We know that a number of companies they have, maybe it's a Patch Tuesday, maybe it's a patch 26th of the month, maybe it's patch day of the quarter, we have to learn how to respond to these things quickly so that we can apply these mitigations and these fixes as quickly as possible to them protect ourselves and protect the end users or customers that we have, or to keep the kids from using some backdoors in Minecraft is the word. >> (laughs) Yeah. Look, this is an immensely important subject. To wrap us up on this, Luke, I'd like you to pretend that you just got into an elevator in a moderately tall building, and you have 60 seconds to share with me someone who already trusts you, you don't have to convince me of your credentials or anything. I trust you. What tools specifically do you need me to be running, tools and processes. You've got 60 seconds to say, Dave, if you're not doing these things right now, you're unnecessarily vulnerable. So ready, and go, Luke. >> So automatically update all packages. Always stay up-to-date so that when an issue does hit, you're not having to go back 10 versions and work your way forward. That's the key thing. Ensure that everything you pull in, you're not going to have 100%, but have a very strict requirement that there is non-repudiation, is signed content, so you can verify that it's not being tampered with. For your developers that are producing code, run static, dynamic analysis, API fuzzes, all of these sorts of tools. They will find some vulnerabilities for you. Be part of communities. Be part of communities, help chop the wood and carry the water because the log for Jay, the thing is that was found because it was in the open. If it wasn't any open, it wouldn't have been found. And I've been in this business for a long time. Software developers will always write bugs. I do. Some of them will be security bugs. That's never going to change. So it's not about stopping something that's inevitable. It's about being prepared to react accordingly in our right and correct manner when it does happen so that you can mitigate against those risks. >> Well, we're here on the 35th floor. That was amazing. Thank you, Luke. Vincent, you were in the elevator also listening in on this conversation. Did we miss anything? >> No, I mean, the only thing I'll say is that it's really helpful to partner with an enterprise open source provider, be it Red Hat or anybody else. I don't want to toot our own horn. They do a lot of that work on your behalf that you don't have to do. A lot of the things that Luke was talking about, those providers do, so you don't have to. And that's where you.. I liked that you talked about, hey, you don't have to convince me that I'm trusted, or that I trust you. Trust those vendors. They're literally here to do a lot of that heavy lifting for you and trust the process. Yeah, it's a very, very good point. And I know that sometimes it's hard to get to that point where you are the trusted advisor. Both of you certainly are. And with that, I would like to thank you very much for an interesting conversation. Gentlemen, let's keep in touch. You're always welcome on theCUBE. Luke, second time, getting a chance to talk to you on theCUBE personally. Fantastic. With that, I would like to thank everyone for joining this very special series on theCUBE. Managing risk in the digital supply chain is a critical topic to keep on top of. Thanks for tuning into theCUBE. We'll be back soon. I'm Dave Nicholson saying, thanks again. (upbeat music)

>>Hello, and welcome back to the cubes coverage of coop con cloud native con 2021. We're here in person at a real event. I'm John farrier host of the cube, but Dave Nicholson, Michael has got great guests here. Two founders of brand new startup, one week old cable on ASCII and Dave Lawrence, uh, with chain guard, former Google employees, open source community members decided to start a company with five other people on total five total. Congratulations. Welcome to the cube. >>Thank you. Thank you for >>Having us. So tell us like a product, you know, we know you don't have a price. So take us through the story because this is one of those rare moments. We got great chance to chat with you guys just a week into the new forms company and the team. What's the focus, what's the vision. >>How far back do you want to go with this story >>And why you left Google? So, you know, we're a gin and tonics. We get a couple of beers I can do that. We can do that. Let's just take over the world. >>Yeah. So we both been at Google, uh, for awhile. Um, the last couple of years we've been really worried about and focused on open-source security risk and supply chain security in general and software. Um, it's been a really interesting time as you probably noticed, uh, to be in that space, but it wasn't that interesting two years ago or even a year and a half ago. Um, so we were doing a bunch of this work at Google and the open source. Nobody really understood it. People kind of looked at us funny at talks and conferences. Um, and then beginning of this year, a bunch of attacks started happening, uh, things in the headlines like solar winds, solar winds attack, like you say, it attack all these different ransomware things happening. Uh, companies and governments are getting hit with supply chain attacks. So overnight people kind of started caring and being really worried about the stuff that we've been doing for a while. So it was a pretty cool thing to be a part of. And it seemed like a good time to start a company and keep your >>Reaction to this startup. How do you honestly feel, I suppose, feeling super excited. Yeah. >>I am really excited. I was in stars before Google. So then I went to Google where there for seven, I guess, Dan, a little bit longer, but I was there for seven years on the product side. And then yeah, we, we, the open source stuff, we were really there for protecting Google and we both came from cloud before that working on enterprise product. So then sorta just saw the opportunity, you know, while these companies trying to scramble and then sort of figure out how to better secure themselves. So it seemed like a perfect, >>The start-up bug and you back in the start up, but it's the timing's perfect. I got to say, this is a big conversation supply chain from whether it's components and software now, huge attack vector, people are taking advantage of it super important. So I'm really glad you're doing it. But first explain to the folks watching what is supply chain software? What's the challenge? What is the, what is the supply chain security challenge or problem? >>Sure. Yeah, it's the metaphor of software supply chain. It's just like physical supply chain. That's where the name came from. And it, it really comes down to how the code gets from your team's keyboard, your team's fingers on those keyboards into your production environment. Um, and that's just the first level of it. Uh, cause nobody writes all of the code. They use themselves. We're here at cloud native con it's hundreds of open source vendors, hundreds of open libraries that people are reusing. So your, your trust, uh, radius and your attack radius extends to not just your own companies, your own developers, but to everyone at this conference. And then everyone that they rely on all the way out. Uh, it's quite terrifying. It's a surface, the surface area explode pretty quickly >>And people are going and the, and the targeting to, because everyone's touching the code, it's open. It's a lot of action going on. How do you solve the problem? What is the approach? What's the mindset? What's the vision on the problems solving solutions? >>Yeah, that's a great question. I mean, I think like you said, the first step is awareness. Like Dan's been laughing, he's been, he felt like a crazy guy in the corner saying, you know, stop building software underneath your desk and you know, getting companies, >>Hey, we didn't do, why don't you tell them? I was telling him for five years. >>Yeah. But, but I think one of his go-to lines was like, would you pick up a thumb drive off the side of the street and plug it into your computer? Probably not. But when you download, you know, an open source package or something, that's actually can give you more privileges and production environments and it's so it's pretty scary. Um, so I think, you know, for the last few years we've been working on a number of open source projects in this space. And so I think that's where we're going to start is we're going to look at those and then try to grow out the community. And we're, we're watching companies, even like solar winds, trying to piece these parts together, um, and really come up with a better solution for themselves. >>Are there existing community initiatives or open source efforts that are underway that you plan to participate in or you chart? Are you thinking of charting a new >>Path? >>Oh, it's that looks like, uh, Thomas. Yeah, the, the SIG store project we kicked off back in March, if you've covered that or familiar with that at all. But we kicked that off back in March of 2021 kind of officially we'd look at code for awhile before then the idea there was to kind of do what let's encrypted, uh, for browsers and Webster, um, security, but for code signing and open source security. So we've always been able to get code signing certificates, but nobody's really using them because they're expensive. They're complicated, just like less encrypted for CAS. They made a free one that was automated and easy to use for developers. And now people do without thinking about it in six stores, we tried to do the same thing for open source and just because of the headlines that were happening and all of the attacks, the momentum has just been incredible. >>Is it a problem that people just have to just get on board with a certain platform or tool or people have too many tools, they abandoned them there, their focus shifts is there. Why what's the, what's the main problem right now? >>Well, I think, you know, part of the problem is just having the tools easy enough for developers are going to want to use them and it's not going to get in our way. I think that's going to be a core piece of our company is really nailing down the developer experience and these toolings and like the co-sign part of SIG store that he was explaining, like it's literally one command line to sign, um, a package, assign a container and then one line to verify on the other side. And then these organizations can put together sort of policies around who they trust and their system like today it's completely black box. They have no idea what they're running and takes a re >>You have to vape to rethink and redo everything pretty much if they want to do it right. If they just kind of fixing the old Europe's sold next solar with basically. >>Yeah. And that's why we're here at cloud native con when people are, you know, the timing is perfect because people are already rethinking how their software gets built as they move it into containers and as they move it into Kubernetes. So it's a perfect opportunity to not just shift to Kubernetes, but to fix the way you build software from this, >>What'd you say is the most prevalent change mindset change of developers. Now, if you had to kind of, kind of look at it and say, okay, current state-of-the-art mindset of a developer versus say a few years ago, is it just that they're doing things modularly with more people? Or is it more new approaches? Is there a, is there a, >>I think it's just paying attention to your building release process and taking it seriously. This has been a theme for, since I've been in software, but you have these very fancy production data centers with physical security and all these levels of, uh, Preston prevention and making sure you can't get in there, but then you've got a Jenkins machine that's three years old under somebody's desk building the code that goes into there. >>It gets socially engineered. It gets at exactly. >>Yeah. It's like the, it's like the movies where they, uh, instead of breaking into jail, they hide in the food delivery truck. And it's, it's that, that's the metaphor that I like perfectly. The fence doesn't work. If your truck, if you open the door once a week, it doesn't matter how big defenses. Yeah. So that's >>Good Dallas funny. >>And I, I think too, like when I used to be an engineer before I joined Google, just like how easy it is to bring in a third party package or something, you know, you need like an image editing software, like just go find one off the internet. And I think, you know, developers are slowly doing a mind shift. They're like, Hey, if I introduce a new dependency, you know, there's going to be, I'm going to have to maintain this thing and understand >>It's a little bit of a decentralized view too. Also, you got a little bit of that. Hey, if you sign it, you own it. If it tracks back to you, okay, you are, your fingerprints are, if you will, or on that chain of >>Custody and custody. >>Exactly. I was going to say, when I saw chain guard at first of course, I thought that my pant leg riding a bike, but then of course the supply chain things coming in, like on a conveyor belt, conveyor, conveyor belt. But that, that whole question of chain of custody, it isn't, it isn't as simple as a process where someone grabs some code, embeds it in, what's going on, pushes it out somewhere else. That's not the final step typically. Yeah. >>So somebody else grabs that one. And does it again, 35 more times, >>The one, how do you verify that? That's yeah, it seems like an obvious issue that needs to be addressed. And yet, apparently from what you're telling us for quite a while, people thought you were a little bit in that, >>And it's not just me. I mean, not so Ken Thompson of bell labs and he wrote the book >>He wrote, yeah, it was a seatbelt that I grew >>Up on in the eighties. He gave a famous lecture called uh, reflections on trusting trust, where he pranked all of his colleagues at bell labs by putting a back door in a compiler. And that put back doors into every program that compiled. And he was so clever. He even put it in, he made that compiler put a backdoor into the disassembler to hide the back door. So he spent weeks and, you know, people just kind of gave up. And I think at that point they were just like, oh, we can't trust any software ever. And just forgot about it and kept going on and living their lives. So this is a 40 year old problem. We only care about it now. >>It's totally true. A lot of these old sacred cows. So I would have done life cycles, not really that relevant anymore because the workflows are changing. These new Bev changes. It's complete dev ops is taken over. Let's just admit it. Right. So if we have ops is taken over now, cloud native apps are hitting the scene. This is where I think there's a structural industry change, not just the community. So with that in mind, how do you guys vector into that in terms of a market entry? What's just thinking around product. Obviously you got a higher, did you guys raise some capital in process? A little bit of a capital raise five, no problem. Todd market, but product wise, you've got to come in, get the beachhead. >>I mean, we're, we're, we're casting a wide net right now and talking to as many customers like we've met a lot of these, these customer potential customers through the communities, you know, that we've been building and we did a supply chain security con helped with that event, this, this Monday to negative one event and solar winds and Citibank were there and talking about their solutions. Um, and so I think, you know, and then we'll narrow it down to like people that would make good partners to work with and figure out how they think they're solving the problem today. And really >>How do you guys feel good? You feel good? Well, we got Jerry Chen coming off from gray lock next round. He would get a term sheet, Jerry, this guy's got some action on it in >>There. Probably didn't reply to him on LinkedIn. >>He's coming out with Kronos for him. He just invested 200 million at CrossFit. So you guys should have a great time. Congratulations on the leap. I know it's comfortable to beat Google, a lot of things to work on. Um, and student startups are super fun too, but not easy. None of the female or, you know, he has done it before, so. Right. Cool. What do you think about today? Did the event here a little bit smaller, more VIP event? What's your takeaway on this? >>It's good to be back in person. Obviously we're meeting, we've been associating with folks over zoom and Google meets for a while now and meeting them in person as I go, Hey, no hard to recognize behind the mask, but yeah, we're just glad to sort of be back out in a little bit of normalization. >>Yeah. How's everything in Austin, everyone everyone's safe and good over there. >>Yeah. It's been a long, long pandemic. Lots of ups and downs, but yeah. >>Got to get the music scene back. Most of these are comes back in the house. Everything's all back to normal. >>Yeah. My hair doesn't normally look like this. I just haven't gotten a haircut since this also >>You're going to do well in this market. You got a term sheet like that. Keep the hair, just to get the money. I think I saw your LinkedIn profile and I was wondering it's like, which version are we going to get? Well, super relevant. Super great topic. Congratulations. Thanks for coming on. Sharing the story. You're in the queue. Great jumper. Dave Nicholson here on the cube date, one of three days we're back in person of course, hybrid event. Cause the cube.net for all more footage and highlights and remote interviews. So stay tuned more coverage after this short break.

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

>>Good morning. Good, absolute and good evening to all >>those who are listening to this presentation. >>I am rather to Saxena and I manage the platform >>solutions and the thought body operating systems team in the compute workload and solutions group within HP compute >>today I'm >>going to discuss about containers >>and what containers >>do for you >>as a customer >>and why >>should you consider h PE container solutions >>for transforming your business? >>Let's talk about how some of >>the trends seen >>in the industry are impacting the >>customer's day >>in and >>day out and what is it that >>they really need >>cloud services >>and continue your ization, increase operational flexibility, agility and >>speed. >>But non native >>apps seem >>to be a serious issue. >>These legacy apps >>and architecture slow the >>development team, >>making it much harder to meet competitive demand >>and cost pressures. It administrators are >>looking for a way to quickly deploy and manage the resources there. Developers need. >>They want to release more >>updates more quickly. Digital transformation has really shifted >>its focus >>from operations. Two applications, it's all >>about gaining the agility to deploy code faster >>developers want the >>flexibility to choose from a variety of >>Os or containerized ab stacks and to have fast access >>to the resources >>they need. And Ceos >>and line >>of business owners need visibility >>into cost >>and usage so they can optimize their >>spend and drive >>higher utilization of >>their resources. >>So let's define what >>is container technology. >>Container >>technology is a method used to package >>an application >>and software. >>It is a game changer. >>Let's take a closer look at at a couple of >>examples within each area. In the area of cost savings, we achieve savings by reducing the virtualized footprint and by reducing administrative overhead >>through the introduction >>of CIA >>CD pipelines. >>In terms of agility, >>this helps you become more a child by enabling >>your workload portability. It also >>shortens development >>life cycle while increasing the frequency >>of application updates. Within innovation, container platform technologies >>provides >>centralized >>images and source code >>through standard >>repositories, decoupling of application dependencies >>and use of templates >>leading to enhancing >>collaboration. This kick starts your innovation >>container technology would bring >>these benefits to enterprise it and accelerate the transformation of business. >>H. P. E has the proven >>architecture and expertise for the introduction >>of container technology. >>Apps and >>data are no longer centralized in >>the data center. >>They live >>everywhere at the edge, >>in Carlos, >>in the cloud and >>in the data center. This creates >>enormous complexity for application operability >>performance >>and security >>customers are looking >>for a way >>to simplify >>speed and scale their apps and that's driving a rise in container adoption. >>Managing these >>distributed environments requires different skill sets, >>tools and processes >>to manage both >>traditional and cloud environments. >>It is complex >>and time consuming >>all of these workloads are also very >>data dependent Ai >>data analytics and that modernization are the key entry points for >>HB >>Admiral to >>intercept the transformation budget. >>A study from I. T. >>C. Found that >>More than 50 of enterprises are leveraging containers >>to modernize legacy applications >>as is >>without re architect in them. >>These containers are often then deployed >>in on premise cloud environments using kubernetes and Docker. Re implementing legacy applications >>as >>cloud native microservices >>has proven >>more difficult >>than expected, >>held back by the scarcity of the experienced Microsoft >>talent to do that work. >>As a result, only half >>of the new containers deployed leverage microservices >>for cloud native apps. one key element of the >>HB approach is to reduce the effort >>required to >>continue to rise these existing applications. >>One platform for non cloud native and cloud >>native apps >>is the H P E. S. Moral >>container platform. >>Hp Green Lake brings the >>true cloud >>experience to your cloud >>native and non cloud native apps without >>costly. Re factoring with cloud services for containers through Hve Green Lake >>continue rising. >>Non cloud native apps, >>improves >>efficiency, >>increases agility >>and provides >>application affordability. >>Simple applications can take about three months >>while complex once >>up to a year to re factor >>with cloud services for >>containers through HP Green Lake >>customers can save this time and get the benefits >>With 100 open source kubernetes right away with HP >>Asmal >>container platform, non cloud native state fel. Enterprise apps can be deployed in containers without >>costly re factoring >>enabling customers to bring speed and agility >>to non cloud native apps >>with ease. Hp Green Lake is a >>single platform for war clothes and helps customers avoid the cost of moving data and apps and run walk clothes >>securely from the edge >>call occasions >>and data centers >>while meeting the needs for the agency, >>data sovereignty >>and >>regulatory compliance >>with unique type. The >>HBs milk container platform >>provides a container management control plane >>with the fully integrated >>Hve Admiral data fabric. >>The HBs real container platform >>integrates a high performance distributed >>file, an >>object storage. >>These turnkey >>pre configured >>cloud connected >>solutions >>are delivered in >>As little as 14 days and managed for you by HP. E and our partners so >>customers do not need to skill up on kubernetes. >>The key differentiators >>for H. >>B. S. Merrill are providing a complete >>solution that addresses >>a broad set of applications and a consistent multi cloud deployment and management platform. It solves the data integrity >>and application recovery issues >>central >>to business critical >>on >>premise applications. >>It maintains the commitment to open source to ensure customers >>can take >>advantages of future developments >>with these distributions. >>It reduces >>development effort and moves application development >>to self service. >>Now let us look at >>some customer success stories with HBs Merrill. Here is a >>customer who modernize >>their existing legacy applications. >>There were a lot of blind >>spots in the system and the >>utilization >>Was just about 10%. By transitioning to containers, they >>were able to get >>50 >>eight times faster in just performance, reducing a significant >>portion of the cost of >>the customers deployment, significant >>reduction in infrastructure >>footprint resulting >>in lower TCO >>and with HB Green Lake, they received cloud agility >>at a fraction >>of the cost of the alternatives. This customer is expanding its efforts into machine >>learning and >>analytics technologies >>for decision support in areas >>of ingesting and processing large data sets. >>They are enabling data science >>and >>such based applications >>on large >>and low late in data sets using a combination of >>patch >>and streaming transformation processes. >>These data sets support both offline and in line machine learning, deep learning training >>and model execution >>to deploy these >>environments at >>scale and >>move from >>experimentation >>to >>production. They need to connect the dots between their devops teams and the data science teams >>walking on machine learning >>and analytics from an inch for such a standpoint. They're using containers >>and kubernetes >>to drive greater agility >>and flexibility as well as cost savings and efficiency >>as they are >>operationalized. >>These machine >>learning deep learning >>and analytic initiatives. >>This includes >>automated configuration of software stacks and the deployment of data pipeline bills >>in containers. >>The developers >>selected kubernetes >>as the container >>orchestration engine for the enterprise >>and is using H >>P E S, real container >>platform >>for their machine learning >>deep learning and analytic war clothes. This customer had a growing demand for >>data scientists >>and their goals >>were >>to gain continuous insights into existing and new customers >>and develop innovative products >>and get them to >>market faster amongst others. >>The greater >>infrastructure utilization >>on premises resulted in >>significant cost savings Around $6 million three years >>and significantly improved environment >>provisioning time >>From 9 to 18 months to just about 30 minutes. And along those lines, >>there are many >>more examples >>of customer success stories across various industries >>that proved >>transitioning >>to the HP. Es. >>Moral container >>solutions can be >>a total game changer by the way. HB also >>provides container solutions on with various software vendors. >>This customer >>was eager to >>embrace a giant abb development techniques >>that would allow them >>to become more a child >>scalable >>and affordable, helping to deliver >>an exceptional customer service >>and avoid vendor lock in HB. partnered with >>them to deploy >>red hat, open shift running on HP hardware, >>which became a new container >>based devoPS >>platform, effectively >>running on bare metal for >>minimal resource >>overheads and maximum performance. >>The customer now had a platform >>that was capable of supporting >>their virtualization and continue realization ambitions. >>Now let us see how HB Green Lake can help >>you reduce costs, >>risk and time you get speed, time >>to value >>with >>pre integrated hardware, >>software and services the HP ES moral platform to >>design and build >>container based >>services and cell service, catalog and marketplace for rapid >>provisioning >>of these services, >>you get lower risk to the business >>with >>fully managed by contained by HP >>container experts. >>Proactive resolution >>of incidents, >>active capacity management to scale with demand, you can reduce costs >>by avoiding >>upfront capital expense >>and over >>provisioning with pay per use model >>intuitive dashboard for >>cluster costs and storage. >>HB also has a huge >>differentiator when it >>comes to security. >>The HBs. Silicon Root >>of Trust >>secures your >>data at the microcode level >>inside the processor itself, ensuring >>that your digital assets >>remain protected and secure >>with your continued authorization strategy >>built on the world's >>most >>secure industry standard servers, >>you'll be able to >>fully concentrate your resources on your modernization efforts. >>Additionally, >>you can enjoy >>benefits such as HP >>form where threat detection >>along with the with other best in class >>innovations from H B such as malware detection >>and Form where recovery. Your HP servers >>are protected >>from >>silicon to >>software >>and at every touch >>point in between >>preventing bad >>actors from gaining access to containers or infrastructure. >>H B E can help accelerate >>your transformation >>using >>three pillars. >>Hp Green Lake, >>you can deploy >>any workload as a service >>with >>HP Green Lake Services, >>you can now bring >>cloud >>speed >>agility and as a >>service model >>to wear your >>apps and data are today transform the >>way you do business >>with one experience >>And one operating model >>across your distributed clouds >>for apps >>and data >>at the edge in coal occasions >>and in your data center. HB point Next services >>with over >>11,000 >>I'd projects conducted >>And 1.4 million >>customer interactions each year. >>HB point X Services, >>15,000 plus experts and its vast >>ecosystem of solution >>partners and channel partners >>are uniquely able to help you at every stage >>of your digital transformation because we address >>some of the biggest >>areas that can slow you down. >>We bring together technology >>and expertise >>to help you drive >>your business forward >>and last but not the least. >>Hp Financial services, >>flexible investment >>capacity are key >>considerations >>for businesses >>to drive digital transformation initiatives >>in order to forge a path forward. You need >>access two flexible >>payment options >>that allow you to match icty costs >>to usage. >>From helping release >>capital from existing infrastructure, two different payments >>and providing >>pre owned tech >>to relieve capacities. Train >>HP Financial >>services unlocks the value of the customer's entire >>estate from >>edge >>to cloud >>to end user >>with multi vendor >>solutions consistently and sustainably >>around the world. HB Fs >>makes I'd >>investment >>force multiplier, >>not a stumbling block. >>H B S. Moral >>and HB compute are the >>ideal choice >>for your container Ization strategy, >>combining familiar silver hardware >>with a container platform that has been >>optimized for the environment. >>This combination is >>particularly cost effective, >>allowing you to capitalize on existing hardware skills >>as you focus >>on developing innovative >>containerized solutions. >>H beef Admiral >>fits your existing infrastructure and provides potential to scale as required. >>And with that, >>I conclude this session and I hope >>you found this valuable. There are many resources available at hp dot >>com that you can use >>to your benefit. Thank you once again.

>>from around the globe. It's the Cube with digital coverage of AWS reinvent 2020 sponsored by Intel and AWS. Yeah, husband. Welcome back to the cubes. Live coverage of AWS reinvent 2020. We're not in person this year. We're virtual This is the Cube Virtual. I'm John for your host of the Cube. Roger Barker, the General Manager AWS Robotics and Autonomous Service. And a lot of other cool stuff was on last year. Always. Speed Racer. You got the machines. Now you have real time Robotics hitting, hitting seen Andy Jassy laid out a huge vision and and data points and announcements around Industrial this I o t it's kind of coming together. Roger, great to see you. And thanks for coming on. I want to dig in and get your perspective. Thanks for joining the Cube. >>Good to be here with you again today. >>Alright, so give us your take on the announcements yesterday and how that relates to the work that you're doing on the robotic side at a w s. And where where does this go from? You know, fun to real world to societal impact. Take us through. What? You how you see that vision? >>Yeah, sure. So we continue to see the story of how processing is moving to the edge and cloud services, or augmenting that processing at the edge with unique and new services. And he talked about five new industrial machine learning services yesterday, which are very relevant to exactly what we're trying to do with AWS robot maker. Um, a couple of them monitor on, which is for equipment monitoring for anomalies. And it's a whole solution, from an edge device to a gateway to a service. But we also heard about look out for equipment, which is if a customer already has their own censors. It's a service that can actually back up that that sensor on their on the device to actually get identify anomalies or potential failures. And we saw look out for video, which allows customers to actually use their camera and and build a service to detect anomalies and potential failures. When A. W s robot maker, we have Ross Cloud Service extensions, which allow developers to connect their robot to these services and so increasingly, that combination of being able to put sensors and processing at the edge, connecting it back with the cloud where you could do intelligent processing and understand what's going on out in the environment. So those were exciting announcements. And that story is going to continue to unfold with new services. New sensors we can put on our robots to again intelligently process the data and control these robots and industrial settings. >>You know, this brings up a great point. And, you know, I wasn't kidding. Was saying fun to real world. I mean, this is what's happening. Um, the use cases air different. You look at you mentioned, um, you know, monitor on lookout. But those depend Panorama appliance. You had computer vision, machine learning. I mean, these are all new, cool, relevant use cases, but they're not like static. It's not like you're going to see them. Just one thing is like the edge has very diverse and sometimes mostly purpose built for the edge piece. So it's not like you could build a product. Okay, fits everywhere. Talk about that dynamic and why the robotics piece has to be agile. And what do you guys doing to make that workable? Because, you know, you want purpose built. The purpose built implies supply chain years. in advance. It implies slow and you know, how do you get the trust? How do you get the security? Take us through that, please. >>So to your point, um, no single service is going to solve all problems, which is why AWS has has released a number of just primitives. Just think about Kinesis video or Aiken. Stream my raw video from an edge device and build my own machine learning model in the cloud with sage maker that will process that. Or I could use recognition. So we give customers these basic building blocks. But we also think about working customer backward. What is the finished solution that we could give a customer that just works out of the box? And the new services we heard about we heard about yesterday were exactly in that latter category. Their purpose built. They're ready to be used or trained for developers to use and and with very little customization that necessary. Um, but the point is, is that is that these customers that are working these environments, the business questions change all the time, and so they need actually re program a robot on the fly, for example, with a new mission to address the new business need that just arose is a dynamic, which we've been very tuned into since we first started with a device robo maker. We have a feature for a fleet management, which allows a developer to choose any robot that's out in their fleet and take the software stack a new software stack tested in simulation and then redeploy it to that robot so it changes its mission. And this is a This is a dialogue we've been seeing coming up over the last year, where roboticists are starting to educate their company that a robot is a device that could be dynamically program. At any point in time, they contest their application and simulation while the robots out in the field verify it's gonna work correctly and simulation and then change the mission for that robot. Dynamically. One of my customers they're working with Woods Hole Institute is sending autonomous underwater robots out into the ocean to monitor wind farms, and they realized the mission may change may change based on what they find out. If the wind farm with the equipment with their autonomous robot, the robot itself may encounter an issue and that ability because they do have connective ity to change the mission dynamically. First Testament, of course, in simulation is completely changing the game for how they think about robots no longer a static program at once, and have to bring it back in the shop to re program it. It's now just this dynamic entity that could test and modify it any time. >>You know, I'm old enough to know how hard that really is to pull off. And this highlights really kind of how exciting this is, E. I mean, just think about the idea of hardware being dynamically updated with software in real time and or near real time with new stacks. I mean, just that's just unheard of, you know, because purpose built has always been kind of you. Lock it in, you deploy it. You send the tech out there this kind of break fixed kind of mindset. Let's changes everything, whether it's space or underwater. You've been seeing everything. It's software defined, software operated model, so I have to ask you First of all, that's super awesome. Anyway, what's this like for the new generation? Because Andy talked on stage and in in my one On one way I had with him. He talked about, um, and referring to land in some of these new things. There's a new generation of developer. So you gotta look at these young kids coming out of school to them. They don't understand what how hard this is. They just look at it as lingua frank with software defined stuff. So can you share some of the cutting edge things that are coming out of these new new the new talent or the new developers? Uh, I'm sure the creativity is off the charts. Can you share some cool, um, use cases? Share your perspective? >>Absolutely. I think there's a couple of interesting cases to look at. One is, you know, roboticists historically have thought about all the processing on the robot. And if you say cloud and cloud service, they just couldn't fathom that reality that all the processing has cannot has to be, you know, could be moved off of the robot. Now you're seeing developers who are looking at the cloud services that we're launching and our cloud service extensions, which give you a secure connection to the cloud from your robot. They're starting to realize they can actually move some of that processing off the robot that could lower the bomb or the building materials, the cost of the robot. And they can have this dynamic programming surface in the cloud that they can program and change the behavior of the robot. So that's a dialogue we've seen coming over the last couple years, that rethinking of where the software should live. What makes sense to run on the robot? And what should we push out to the cloud? Let alone the fact that if you're aggregating information from hundreds of robots, you can actually build machine learning models that actually identify mistakes a single robot might make across the fleet and actually use that insight to actually retrain the models. Push new applications down, pushing machine learning models down. That is a completely different mindset. It's almost like introducing distributed computing to roboticists that you actually think this fabric of robots and another, more recent trend we're seeing that were listening very closely to customers is the ability to use simulation and machine learning, specifically reinforcement. Learning for a robot actually try different tasks up because simulations have gotten so realistic with the physics engines and the rendering quality that is almost nearly realistic for a camera. The physics are actually real world physics, so that you can put a simulation of your robot into a three D simulated world and allow it to bumble around and make mistakes while trying to perform the task that you frankly don't know how to write the code for it so complex and through reinforcement, learning, giving rewards signals if it does something right or punishment or negative rewards signals. If it does something wrong, the machine learning algorithm will learn to perform navigation and manipulation tasks, which again the programmer simply didn't have to write a line of code for other than creating the right simulation in the right set of trials >>so that it's like reversing the debugging protocol. It's like, Hey, do the simulations. The code writes itself. Debug it on the front end. It rights itself rather than writing code, compiling it, debugging it, working through the use cases. I mean, it's pretty different. >>It is. It's really a new persona. When we started out, not only are you taking that roboticist persona and again introduced him to the cloud services and distributed computing what you're seeing machine learning scientists with robotics experience is actually rising. Is a new developer persona that we have to pay attention to him. We're talking to right now about what they what they need from our service. >>Well, Roger, I get I'm getting tight on time here. I want one final question before we break. How does someone get involved with Amazon? And I'll see you know, whether it's robotics and new areas like space, which is verging, there's a lot of action, a lot of interest. Um, how does someone engaged with Amazon to get involved, Whether I'm a student or whether I'm a professional, I want a code. What's what's the absolutely, >>absolutely, so certainly reinvent. We have several sessions that reinvent on AWS robo maker. Our team is there, presenting and talking about our road map and how people can get engaged. There is, of course, the remarks conference, which will be happening next year, hopefully to get engaged. Our team is active in the Ross Open Source Community and Ross Industrial, which is happening in Europe later in December but also happens in the Americas, where were present giving demos and getting hands on tutorials. We're also very active in the academic research in education arena. In fact, we just released open source curriculum that any developer could get access to on Get Hub for Robotics and Ross, as well as how to use robo maker that's freely available. Eso There's a number of touch points and, of course, I'd be welcome to a field. Any request for people to learn more or just engage with our team? >>Arthur Parker, general manager. It is robotics and also the Autonomous Systems Group at AWS Amazon Web services. Great stuff, and this is really awesome insight. Also, you know it za candy For the developers, it's the new generation of people who are going to get put their teeth into some new science and some new problems to solve. With software again, distributed computing meets robotics and hardware, and it's an opportunity to change the world literally. >>It is an exciting space. It's still Day one and robotics, and we look forward to seeing the car customers do with our service. >>Great stuff, of course. The Cube loves this country. Love robots. We love autonomous. We love space programming all this stuff, totally cutting edge cloud computing, changing the game at many levels with the digital transformation just a cube. Thanks for watching

>> Presenter: From around the globe, it's theCUBE, with coverage of KubeCon and CloudNativeCon North America 2020 Virtual. Brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Hey, welcome back everybody, Jeff Frick here with theCUBE. We're coming to you from our Palo Alto Studios with our ongoing coverage of KubeCon + CloudNativeCon 2020, the digital version. It would have been the North American version but obviously everything is digital. So we're excited, we've been coming back here for years and we've got a founder of CNCF and also a practitioner, really great opportunity to get some insight from someone who's out in the field and putting this stuff into work. So we're joined in this next segment by Ken Owens. He is the Vice President of Software Development Engineering for MasterCard, and he's a founding member of the CNCF, The Cloud Native Computing Foundation. Ken, great to see you. >> Yeah, great. Thank you for having me, I have, I've enjoyed theCUBE over the years and I'm glad to be a part of it again. >> Yeah, so we're, we're psyched to have you on, and I think it's the first time I've got to talk to you. I think you might've been on in LA a couple of years ago, or I was kind of drifting around that show. I don't think I was a it was on the set that day, but before we jump into kind of what's going on now, you were a founding member of CNCF. So let's take a step back and kind of share your perspective as to kind of where we are now from where this all began and kind of this whole movement around Cloud Native. Certainly it's a good place to be. >> Yeah, yeah definitely. It's been a great ride. In our industry, we go through these sort of timeframes every decade or so, where something big kind of comes along and you get involved in and you participate in it. And it gets to be a lot of fun and it either dies or it evolves into something else, right? And with CloudNativeCon Cloud Native itself, this concept of just how difficult it was to really move with the type of agility and the type of speed that developers in the enterprise really need to move at. It was just, it was hard to get there with just traditional infrastructure, traditional ways of doing configurations of doing management of infrastructure and it really needed something different and something to kind of help, it was called orchestration of course but at the time we didn't know it was called orchestration right. We knew we needed things like service mesh, but they weren't called service meshes then. There were more like control planes. And how do you, how do you custom create all of these different pieces? And the great thing about the CNCF is that we, when we started it, we had very simple foundational principles we wanted to follow right. One was, we wanted to have end users involved. A lot of foundations as become very vendor-driven and very vendor-centric. And you kind of lose your, your core base of the practitioners as you call us right? The guys who actually need to solve problems they're trying to make a living solving problems for the industry, not just for selling products, right? And so it was important that we get those end users involved and that, and that's probably the biggest changes. It's a great technology body. We had great technologists, great engineers and the foundation but we also have a huge over 150 end users that have engaged and been very involved and contributing to the end users things of the community, contributing to the foundation now. And it's been awesome to see that come to fruition over the last three years. >> Yeah, it certainly part of the magic of open source, that's been so, so transformative. And we've seen that obviously with servers and Linux and what what that did, but we've been talking a lot lately too about kind of the anniversary of the of the Agile Manifesto and kind of the Agile Movement and really changing the prioritization around change and really making change a first class citizen as opposed to kind of a nightmare I don't want to deal with and really building systems and ways of doing things that adopt that. I want to just to pull up the Cloud Native definition 'cause I think it's interesting. We talk about Cloud Native a lot and you guys actually wrote some words down and I think it's worth reading them that Cloud Native Technologies empower organizations to build and run scalable applications in dynamic environments. Dynamic environments is such a key piece to this puzzle because it used to be, this is your infrastructure person, you've got to build something that fits into this. Now with an app-centric world has completely flipped over and the application developer doesn't have to worry about the environment anymore, right? It's spin it up and make it available to me when I need it. A really different way of thinking about things than kind of this static world. >> Definitely and then that was the big missing piece for all those years was how do you get to this dynamic environment, right, that embraces change and embraces risk to some extent. Not risk like you heard in the past with risk avoidance is so important to have, right. It's really more, how do you embrace risk and fail earlier in the process, learn earlier in the process so that when you get to production you're not failing, you're not having to worry about failure because you cut as much as you could in the earlier phases of your development life cycle. And that's been set, like you said that dynamic piece has just been such the difference. I think in why it's been taken off. >> Yeah. >> And industry this last five years now that we've been around. >> Yeah, for sure. So then the next one well, I'm just going to go through them 'cause there's three main tenants of this thing. These techniques and techniques enabled loosely coupled systems that allow engineers to make high impact changes frequently and predictably with minimum toil. I mean, those are, those are really hard challenges in a classic waterfall way with PRDs and MRDs and everything locked down in a big, giant Gantt chart that fills half of the half the office to actually be able to have loosely coupled systems. Again a really interesting concept versus hardwired, connected systems. Now you're talking about APIs and systems all connecting. Really different way to think about development and how do you build applications. >> Yeah and the interesting thing there is the very first definition we came up with five plus years ago was containers, containerized workloads, right? And being technologist, everyone focused on those words containers and containerized and then everything had to be a container, right? And to your point, that isn't what we're trying to do, right? We're trying to create services that are just big enough to support whatever is needed for that service to support and be able to scale those up and down independently of other dependent systems that may have different requirements associated with what they have to do, right. And it was more about that keeping those highly efficient type of patterns in mind of spinning up and spinning down things that don't have impact or cause impact to other larger components around them was really the key not containers or containerized. >> Right. >> Obviously that's one of the patterns you could follow to create those types of services and those patterns, but there is nothing that guarantees it has to be a container that can do that. Lots of BMS today and lots of Bare Metal Servers can have a similar function. They're just not going to be as dynamic as you may want them to be in other environments. >> Right and then the third tenant, three of three is fostering sustainable ecosystem of open source vendor neutral projects, democratizing state-of-the-art patterns to make these innovations accessible for everyone. So just the whole idea of democratization of technology, democratization of data, democratization of tools, to do something with the data to find the insight democratization of the authority to execute on those decisions once you get going on that, I mean the open source and kind of this democratization to enable a broad distribution of power to more than just mahogany row, huge fundamental shift in the way people think about things. And really even still today, as everyone's trying to move their organizations to be more data-centric in the way they operate, it is really all about the democratization and getting that information and the tools and the ability to do something with it to as broad a group of people as you can. And that's even before we talk about open source development and the power of again, as you said, bringing in this really active community who want to contribute. It's a really interesting way that open source works. It's such a fun thing to watch, and I'm not a developer from the outside, but to see people get excited about helping other people. I think that's probably the secret to the whole thing that really taps into. >> Yeah, it is. And open source, there were discussions about open source for 20 plus years trying to get more into open source contributing to open source in an enterprise mindset, right? And it could never really take off 'cause it's not really the foundation or the platforms or the capabilities needed to do that. And now to your point, open source was really the underlying engine that is making all of this possible. Without open source and some of those early days of trying to get more open source and understanding of open source in the enterprise, I think we'd still be trying to get adoption but open source had just gotten to that point where everyone wanted to do more with open source. The CNCF comes along and said, here's the set of democratized, we're not going to have kingmakers in this organization. We're going to have a lot of open solutions, a lot of good options for companies to look at, and we're not going to lock you in to anything. 'Cause that's another piece of that open source model, right. Open source still can lock you in, right. But if you have open choices within open source, there's less, lock-in potential and locking isn't really a horrible thing. It's just one of those tenants you don't want to be tied too tightly to any one solution or one hope, open source even program because that could 'cause issues of that minimal toil we talked about, right. If you have a lot of dependencies and a lot of, I always joked about OpenStack but if I have to email two guys, if I find an issue in OpenStack about security that's not really a great security model that I can tell my customers I have your security covered, right? So, you want to get away from emails and having to ask for help, if you see a big security issue you want to just address it right then and fix it fast. >> Right, right. So much to unpack there. And for those that don't follow you, you've done a ton of presentations. You've got a ton of great content out of the internet with deep technical dives, into some of this stuff and the operational challenges in your philosophies but good keeping it kind of high level here. 'Cause one of the themes that comes up over and over in some of the other stuff I saw from you is really about asking the right questions. And we hear this time and time again, that the way to get the right answer first you got to frame the question right. And you talk quite extensively about asking the why and asking the how. I wonder if you can unpack that a little bit as to why those two questions are so important and how do you ask them in a way that doesn't piss everybody off or scare them away when you're at a big company like MasterCard that has a lot of personal information, you're in the finance industry, you got ton of regulation but still you're asking how and you're asking why. >> Yeah, definitely. And those, those are two questions that I keep coming back to in the industry because they are, they're not asked enough in my opinion. I think they, for the reasons you brought up those there's too much pushback or there's, you don't want to be viewed as someone who's being difficult, right? And there maybe other reasons why you don't want to ask that but I like to ask the why first because it, you kind of have to understand what's the problem you're trying to solve. And it kind of goes back to my engineering background, I think right. I love to solve problems and one of my early days and you might have heard this on one of my, my interviews, right. But in my early days, I was trying to fix a problem that I was on an advanced engineering team. And I was tier four support in a large Telco. And for months we had this issue with one of our large oil based companies and no one could solve it. And I was on call the night that they called in. And I asked the guy a simple question, tell me which lights you see on this DHUC issue? Which is a piece of equipment that sits between a ATM network and a regular Sonnet network. So we're watching, I'm asking them as kind of find out where in this path, there's a problem. And the guy tells me where there's no lights on. And I'm like well, plug in the power and let me know when it boots up and then let's try another test. And that was the problem. So my, the cleaning crew would come through and unplugged it. And so I learned early on in my crew that if you don't ask those simple questions, you just assume that everything's working almost nine times out of 10, it's the simple, easy solution to a problem. You're just too busy thinking of all the complex things that could go wrong and trying to solve all the hard problems first. And so I really try to help people think about, ask the why questions, ask, why is this important? Why do we need to do this now? Why, what would happen if we don't do this? If we did it this other way, what's the downside of doing it this other way? Really think through your options, 'cause it may take you 20, 30 minutes to kind of do a good analysis of a problem, but then your solution you're not going to spend weeks trying to troubleshoot when it doesn't work because you put the time upfront to think about it. So that's sort of the main reason why I like to ask the why and the how, because it forces you to think outside of your normal, my job is to take this cog and put it over here and fix this, right. And you don't want to be in that, that mode when you're solving complex problems because you overlook or you miss the simple things. >> Right. So you don't like the 'cause we've always done it that way? (both laughing) >> I do not. And I hear that a lot everywhere I've been in the industry and anywhere, any company you have those, this is the way we've always done it. >> Yeah, yeah. Just like the way we've always traveled, right. And the way we've always been educated and the way we've always consumed entertainment. It's like really? I wanted to (indistinct) >> I have learned though that there's a good, I like to understand the reason behind why we've always done it that way. So I do always ask that question. >> Right. >> I don't turn around on someone and get mad at them and you say, Oh, we can't we have to do it differently. I don't have the mindset of let's throw that out the window because I realized that over time something happened. It's like when I had younger kids, I always laugh because they put these warnings on those whatever they call them at the kids stand up in them. >> Right, the little, the little (indistinct) >> Don't put them on top of the stairs right. These stupid little statements are written on there. And I always thought I was dumb. And if somebody told me, well that's because somebody put their kid near the pool and they drown. >> Right, right. >> You have to kind of point out the obvious to people and so, >> Yeah. >> I don't think it's that dangerous of a situation and in the work environment, but hopefully we're not making the same mistakes that have been prevented by not allowing just the, not because we've done it this way before modeled it to go forward. >> Right, right now we have a rule around here too. There's a reason we have every rules is because somebody blew it at some point in time. That's why we have the rule that I want to shift gears a little bit and talk about automation, right? 'Cause automation is such a big and important piece of this whole story especially as these systems scale, scale, scale. And we know that people are prone to errors. I mean, I had seen that story about the cleaner accidentally unplugging things. We all know that people fat fingers, copy and paste is not used as universally as it should be. But I wonder if you could share, how important automation is. And I know you've talked a lot about how people should think about automate automation and prioritizing automation and helping use automation to both make people more productive but also to prioritize what the people should be working on as well as lowering the error rate on stuff that they probably shouldn't be doing anyway. >> Exactly, yeah automation to me is, as you've heard me say before is it's something that is probably almost as big of a key tenet as open source should be, right? It's one of those foundational things that it really helps you to get rid of some of that churn and some of the toil that you run into in a production environment where you're trying to always figure out what went wrong and why did this system not work on this point in time and this day and this deployment, and it's almost to your point always a fat finger, someone deleted an IP address from the IPAM system. There's all kinds of errors that you can people can tell you about that have happened. But to the root of your question is automation needs to be thought about from three different primary areas in my view, in my experience. The first one is the infrastructure as code, software defined infrastructure, right. So the networking teams and the storage teams and the security teams are probably the furthest behind in adopting automation in in their jobs, right. And their jobs are probably the most critical pieces of the infrastructure, right? And so those are, those are pieces that I really highly encouraged them to think about how can they automate those areas. The second piece is I think is equally as important as the infrastructure piece is the application side. When I first joined multiple enterprises in the past, the test coverage is in the low 10's to 20%, right. And your test coverage is a direct correlation to how well your application is going to behave and production in terms of failures, right? So if you have low test coverage, you're going to have high failure rates. It's sort of over over all types of industries every study has shown that, right. So getting your test coverage up and testing the right things not just testing to have test coverage right. >> But actually. >> Right, right. >> Thinking through your user stories and acceptance criteria and having good test is really, really important. So you have those two bookends, right. And in between, I think it's important that you look at how you connect to these services, these distributed systems we talked about in the opening right. If you fully automate your infrastructure and fully automate your application development and delivery, that's great. But if in the middle you have this gooey middle that doesn't really connect well doesn't really have the automation in place to ensure that your certificates are there that your security is in place. That middle piece can become really a problem from a security and from a availability issue. And so those those are the two pieces that I say really focus on is that gooey middle and then that infrastructure piece is really the two keys. >> Right, right. You've got another group of words that you use a lot. I want you to give us a little bit more color behind it. And that's talking to people to tell them that they need to spend more time on investigation. They need to do more experimentation. And then and the one that really popped out to me was it was retro to retrospective to not necessarily a postmortem which I thought is interesting. You say retrospective versus the postmortem, because this is an ongoing process for continuous improvement. And then finally, what seems drop dead dumb obvious is to iterate and deliver. But I wonder if you can share a little bit more color on how important it is to experiment and to investigate and to have those retrospectives. >> Yeah definitely. And then it kind of goes back to that culture we want to create in a Cloud Native world, right. We want to be open to thinking about how we can solve problems better, how we can have each iteration we want, to look at, how do we have a less toil, have less issues. How do we improve the, I liked kind of delight in your experience, how do you make your developers and your customers specific, but specifically how do you make your customers so happy with your service? And when you think about those sort of areas, right. You want to spend some portion of your time dedicated to how do I look at and investigate better ways of doing things or more improvements around the way my customer experience is being delivered. Asking your customers questions, right. You'd be surprised how how many customers don't ever get asked for their opinion on how something works, right. And they want to be asked, they'd love to give you feedback. It doesn't necessarily mean you're going to go do it that next iteration, right? The old adage I like to use is if Henry Ford had listened to his customers he would have tried to breed a faster horse, right? And so you have to kind of think about what you want to try to deliver as a product and as an organization but at the same time, that input is important. And I think, I say carve it out, because if you don't, we're so busy today and there's so much going on in our lives. If you don't dedicate and carve out some of that time and protect that time, you will never get to that, right. It's always a, I'll get to that next year. Maybe our next iteration I'll try, right. And so it's important to really hold that time as sacred and spend time every week, every couple of weeks, whatever it works out in the schedule, but actually put that in your calendar and block out that time and use it to really look at what's possible, what's relevant, what kind of improvements you can have. I think those are really the key the key takeaways I can have from that piece of it. And then, the last one you asked about, which I think is so important, is the retrospective, right. Always trying to get better and better at what you do is, is an engineer's goal, right? We never liked to fail. We never liked to do something twice, right? We don't want to, we want to learn the first time we make a mistake and not make it over and over again. So that those retrospectives and improving on what you're doing iteratively. And to the point you brought up and I like to bring this up a lot, 'cause I've been part not at MasterCard, but at other companies parts of companies that would talk a great game come up with great stories, say here's our plan. And then when we get ready to go to deliver it, we go and we reinvestigate the plan and see if there's a better plan. And then we get to a point where we're ready to go execute. And then we go back and start all over again, right. And you've got to deliver iteratively, if you don't, you're the point I like to always make is you're never going to be ready, right. It's like, when are you ready to have kids? You never ready to have kids, right. You just have to go and you'll learn as you go. You know so. >> Right, right, I love that. Well again, Ken, you have so much great stuff out there for technical people that want to dive in deep? So I encourage them just to do a simple YouTube or excuse me, YouTube search or Google search but I want to give you the last word. One word, I'm going to check the transcript when this thing is over that you've used probably more than any other word while we've been talking for the last few minutes is toil. And I think it's really interesting that it brings up and really highlights your empathy towards what you're trying to help developers avoid and what you're trying to help teams avoid so that they can be more productive. You keep saying, avoid the toil, get out of the toil, get out of this kind of crap that inhibits people from getting their job done and being creative and being inventive and being innovative. Where does that come from? And I just love that you keep reinforce it and just kind of your final perspective as we wrap on 2020 and another year of CNCF and clearly containers and Kubernetes and Cloud Native is continues to be on fire and on a tear. I just wonder if you can share a little bit of your perspective as a founding member as we kind of come to the end of 2020. >> Yeah definitely. Thanks again for having me. It's been a great, great discussion. I am a developer by background, by trade today, I still develop. I still contribute to open source and I've had this mantra pretty much my entire career that you have to get into the weeds and understand what everyone's experiencing in order to figure out how to solve the problems, right. You can't be in an ivory tower and look down and say, Oh, there's a problem, I'm going to go fix that. It just doesn't work that way. And most problems you try to solve in that model will be problems that no other team has really experienced. And there not going to be help, they're not going to be thankful that you solved the problem they don't have, right? They want you to solve a problem that they have. And so I think that that's sort of a key for the reason why I spent so much time talking about that as I live it every day. I understand it. I talk with my development community and with a broader community of developers at MasterCard and understand the pains that they're going through and try to help them every day with coming up with ways to help make their lives a lot easier. So it's important to me and to to all organizations out there and in all of the, in the world. So, CNCF its been great. It's still growing. I'm always looking for end users. I'd love to talk to you. Well, you can reach out to, to the CNCF if you'd like to learn more, our website has information on how to get connected to the end user community. We community within the CNCF that is not, it's a private community. So you don't have to worry about your information being shared. If you don't want people to know you belong to the community, you don't have to list that information. If you want to list it, you're welcome to list it. There's no expectations on you to contribute to open source, but we do encourage you to contribute, and are here to support that end user community any way we can. So thanks again for having us and looking forward to, to a great show in North America. >> All right well, thank you, Ken, for sharing your information sharing the insight, sharing the knowledge really appreciate it and great to catch up. All right. He's Ken, I'm Jeff. You're watching theCUBE with our ongoing coverage of KubeCon + CloudNativeCon 2020 North America Digital. Thanks for watching. We'll see you next time. (gentle music)