(upbeat music) >> Welcome back. We're winding down theCUBE's coverage of Red Hat Summit 2022. We're here at the Seaport in Boston. It's been two days of a little different Red Hat Summit. We're used to eight, 9,000 people. It's much smaller event this year, fewer developers or actually in terms of the mix, a lot more suits this year, which is kind of interesting to see that evolution and a big virtual audience. And I love the way, the keynotes we've noticed are a lot tighter. They're pithy, on time, they're not keeping us in the hall for three hours. So we appreciate that kind of catering to the virtual audience. Dave Vellante here with my co-host, Paul Gillin. As to say things are winding down, there was an analyst event here today, that's ended, but luckily we have Jim Mercer here as a research director at IDC. He's going to share maybe some of the learnings from that event today and this event overall, we're going to talk about DevSecOps. And Kirsten Newcomer is director of security, product management and hybrid platforms at Red Hat. Folks, welcome. >> Thank you. >> Thank you. >> Great to see you. >> Great to be here. >> Security's everywhere, right? You and I have spoken about the supply chain hacks, we've done some sort of interesting work around that and reporting around that. I feel like SolarWinds created a new awareness. You see these moments, it's Stuxnet, or WannaCry and now is SolarWinds very insidious, but security, Red Hat, it's everywhere in your portfolio. Maybe talk about the strategy. >> Sure, absolutely. We feel strongly that it's really important that security be something that is managed in a holistic way present throughout the application stack, starting with the operating system and also throughout the life cycle, which is partly where DevSecOps comes in. So Red Hat has kind of had a long history here, right? Think SELinux and Red Hat Enterprise Linux for mandatory access control. That's been a key component of securing containers in a Kubernetes environment. SELinux has demonstrated the ability to prevent or mitigate container escapes to the file system. And we just have continued to work up the stack as we go, our acquisition of stack rocks a little over a year ago, now known as Red Hat Advanced Cluster Security, gives us the opportunity to really deliver on that DevSecOps component. So Kubernetes native security solution with the ability to both help shift security left for the developers by integrating in the supply chain, but also providing a SecOps perspective for the operations and the security team and feeding information between the two to really try and do that closed infinity loop and then an additional investment more recently in sigstore and some technologies. >> Interesting. >> Yeah, is interesting. >> Go ahead. >> But Shift Left, explain to people what you mean by Shift Left for people might not be familiar with that term. >> Fair enough. For many, many years, right, IT security has been something that's largely been part of an operations environment and not something that developers tended to need to be engaged in with the exception of say source code static analysis tools. We started to see vulnerability management tools get added, but even then they tend to come after the application has been built. And I even ran a few years ago, I ran into a customer who said my security team won't let me get this information early. So Shift Left is all about making sure that there are security gates in the app dev process and information provided to the developer as early as possible. In fact, even in the IDE, Red Hat code ready dependency analytics does that, so that the developers are part of the solution and don't have to wait and get their apps stalled just before it's ready to go into deployment. >> Thank you. You've also been advocating for supply chain security, software supply chain. First of all, explain what a software supply chain is and then, what is unique about the security needs of that environment? >> Sure. And the SolarWinds example, as Dave said, really kind of has raised awareness around this. So just like we use the term supply chain, most people given kind of what's been happening with the pandemic, they've started hearing that term a lot more than they used to, right? So there's a supply chain to get your groceries, to the grocery store, food to the grocery store. There's a supply chain for manufacturing, where do the parts come for the laptops that we're all using, right? And where do they get assembled? Software has a supply chain also, right? So for years and even more so now, developers have been including open source components into the applications they build. So some of the supplies for the applications, the components of those applications, they can come from anywhere in the world. They can come from a wide range of open source projects. Developers are adding their custom code to that. All of this needs to be built together, delivered together and so when we think about a supply chain and the SolarWinds hack, right, there are a couple of elements of supply chain security that are particularly key. The executive order from May of last year, I think was partly in direct response to the SolarWinds hack. And it calls out that we need a software bill of materials. Now again, in manufacturing that's something folks are used to, I actually had the opportunity to contribute to the software package data exchange format, SPDX when it was first started, I've lost track of when that was. But an S-bomb is all about saying, what are all of those components that I'm delivering in my solution? It might be an application layer. It might be the host operating system layer, but at every layer. And if I know what's in what I'm delivering, I have the opportunity to learn more information about those components to track where does Log4Shell, right? When the Log4j or Spring4Shell, which followed shortly thereafter. When those hit, how do I find out which solutions that I'm running have the vulnerable components in them and where are they? The software bill of materials helps with that but you also have to know where, right. And that's the Ops side. I feel like I missed a piece of your question. >> No, it's not a silver bullet though, to your point and Log4j very widely used, but let's bring Jim into the conversation. So Jim, we've been talking about some of these trends, what's your focus area of research? What are you seeing as some of the mega trends in this space? >> I mean, I focus in DevOps and DevSecOps and it's interesting just talking about trends. Kirsten was mentioning the open source and if you look back five, six, seven years ago and you went to any major financial institution, you asked them if they use an open source. Oh, no. >> True. >> We don't use that, right. We wrote it all here. It's all from our developers-- >> Witchcraft. >> Yeah, right, exactly. But the reality is, they probably use a little open source back then but they didn't realize it. >> It's exactly true. >> However, today, not only are they not on versed to open source, they're seeking it out, right. So we have survey data that kind of indicates... A survey that was run kind of in late 2021 that shows that 70% of those who responded said that within the next two years 90% of their applications will be made up of open source. In other words, the content of an application, 10% will be written by themselves and 90% will come from other sources. So we're seeing these more kind of composite applications. Not, everybody's kind of, if you will, at that 90%, but applications are much more composite than they were before. So I'm pulling in pieces, but I'm taking the innovation of the community. So I not only have the innovation of my developers, but I can expand that. I can take the innovation to the community and bring that in and do things much quicker. I can also not have my developers worry about things that, maybe just kind of common stuff that's out there that might have already been written. In other words, just focus on the business logic, don't focus on, how to get orders or how to move widgets and those types of things that everybody does 'cause that's out there in open source. I'll just take that, right. I'll take it, somebody's perfected it, better than I'll ever do. I'll take that in and then I'll just focus and build my business logic on top of that. So open source has been a boom for growth. And I think we've heard a little bit of that (Kirsten laughs) in the last two days-- >> In the Keynotes. >> From Red Hat, right. But talking about the software bill of materials, and then you think about now I taking all that stuff in, I have my first level open source that I took in, it's called it component A. But behind component A is all these transitive dependencies. In other words, open source also uses open source, right? So there's this kind of this, if you will, web or nest, if you want to call it that, of transitive dependencies that need to be understood. And if I have five, six layers deep, I have a vulnerability in another component and I'm over here. Well, guess what? I picked up that vulnerability, right. Even though I didn't explicitly go for that component. So that's where understanding that software bill of materials is really important. I like to explain it as, during the pandemic, we've all experienced, there was all this contact tracing. It was a term where all came to mind. The software bill of materials is like the contact tracing for your open source, right. >> Good analogy. >> Anything that I've come in contact with, just because I came in contact with it, even though I didn't explicitly go looking for COVID, if you will, I got it, right. So in the same regard, that's how I do the contact tracing for my software. >> That 90% figure is really striking. 90% open source use is really striking, considering that it wasn't that long ago that one of the wraps on open source was it's insecure because anybody can see the code, therefore anybody can see the vulnerabilities. What changed? >> I'll say that, what changed is kind of first, the understanding that I can leapfrog and innovate with open source, right? There's more open source content out there. So as organizations had to digitally transform themselves and we've all heard the terminology around, well, hey, with the pandemic, we've leapfrog up five years of digital transformation or something along those lines, right? Open source is part of what helps those teams to do that type of leapfrog and do that type of innovation. You had to develop all of that natively, it just takes too long, or you might not have the talent to do it, right. And to find that talent to do it. So it kind of gives you that benefit. The interesting thing about what you mentioned there was, now we're hearing about all these vulnerabilities, right, in open source, that we need to contend with because the bad guys realize that I'm taking a lot of open source and they're saying, geez, that's a great way to get myself into applications. If I get myself into this one open source component, I'll get into thousands or more applications. So it's a fast path into the supply chain. And that's why it's so important that you understand where your vulnerabilities are in the software-- >> I think the visibility cuts two ways though. So when people say, it's insecure because it's visible. In fact, actually the visibility helps with security. The reality that I can go see the code, that there is a community working on finding and fixing vulnerabilities in that code. Whereas in code that is not open source it's a little bit more security by obscurity, which isn't really security. And there could well be vulnerabilities that a good hacker is going to find, but are not disclosed. So one of the other things we feel strongly about at Red Hat, frankly, is if there is a CVE that affects our code, we disclose that publicly, we have a public CVE database. And it's actually really important to us that we share that, we think we share way more information about issues in our code than most other users or consumers of open source and we work that through the broad community as well. And then also for our enterprise customers, if an issue needs to be fixed, we don't just fix it in the most recent version of the open source. We will backport that fix. And one of the challenges, if you're only addressing the most recent version, that may not be well tested, it might have other bugs, it might have other issues. When we backport a security vulnerability fix, we're able to do that to a stable version, give the customers the benefit of all the testing and use that's gone on while also fixing. >> Kirsten, can you talk about the announcements 'cause everybody's wondering, okay, now what do I do about this? What technology is there to help me? Obviously this framework, you got to follow the right processes, skill sets, all that, not to dismiss that, that's the most important part, but the announcements that you made at Red Hat Summit and how does the StackRox acquisition fit into those? >> Sure. So in particular, if we stick with DevSecOps a minute, but again, I'll do. Again for me, DevSecOps is the full life cycle and many people think of it as just that Shift Left piece. But for me, it's the whole thing. So StackRox ACS has had the ability to integrate into the CI/CD pipeline before we bought them. That continues. They don't just assess for vulnerabilities, but also for application misconfigurations, excess proof requests and helm charts, deployment YAML. So kind of the big, there are two sort of major things in the DevSecOps angle of the announcement or the supply chain angle of the announcement, which is the investment that we've been making in sigstore, signing, getting integrity of the components, the elements you're deploying is important. I have been asked for years about the ability to sign container images. The reality is that the signing technology and Red Hat signs everything we ship and always have, but the signing technology wasn't designed to be used in a CI/CD pipeline and sigstore is explicitly designed for that use case to make it easy for developers, as well as you can back it with full CO, you can back it with an OIDC based signing, keyless signing, throw away the key. Or if you want that enterprise CA, you can have that backing there too. >> And you can establish that as a protocol where you must. >> You can, right. So our pattern-- >> So that would've helped with SolarWinds. >> Absolutely. >> Because they were putting in malware and then taking it out, seeing what happened. My question was, could sigstore help? I always evaluate now everything and I'm not a security expert, but would this have helped with SolarWinds? A lot of times the answer is no. >> It's a combination. So a combination of sigstore integrated with Tekton Chains. So we ship Tekton, which is a Kubernetes supply chain pipeline. As OpenShift pipelines, we added chains to that. Chains allows you to attest every step in your pipeline. And you're doing that attestation by signing those steps so that you can validate that those steps have not changed. And in fact, the folks at SolarWinds are using Tekton Chains. They did a great talk in October at KubeCon North America on the changes they've made to their supply chain. So they're using both Tekton Chains and sigstore as part of their updated pipeline. Our pattern will allow our customers to deploy OpenShift, advanced cluster manager, advanced cluster security and Quay with security gates in place. And that include a pipeline built on Tekton with Tekton Chains there to sign those steps in the pipeline to enable signing of the code that's moving through that pipeline to store that signature in Quay and to validate the image signature upon deployment with advanced cluster security. >> So Jim, your perspective on this, Red Hat's, I mean, you care about security, security's everywhere, but you're not a security company. You follow security companies. There's like far too many of them. CISOs all say my number one challenge is lack of talent, but I have all these tools to deal with. You see new emerging companies that are doing pretty well. And then you see a company that's highly respected, like an Okta screw up the communications on a pretty benign hack. Actually, when you peel the onion on that, it's just this mess (chuckles) and it doesn't seem like it's going to get any simpler. Maybe the answer is companies like Red Hat kind of absorbing that and taking care of it. What do you see there? I mean, maybe it's great for business 'cause you've got so many companies. >> There's a lot of companies and there's certainly a lot of innovation out there and unique ways to make security easier, right. I mean, one of the keys here is to be able to make security easier for developers, right. One of the challenges with adopting DevSecOps is if DevSecOps creates a lot of friction in the process, it's hard to really... I can do it once, but I can't keep doing that and get the same kind of velocity. So I need to take the friction out of the process. And one of the challenges a lot of organizations have, and I've heard this from the development side, but I've also heard it from the InfoSec side, right. Because I take inquiry for people on InfoSec, and they're like, how do I get these developers to do what I want? And part of the challenge they have is like, I got these teams using these tools. I got those teams using those tools. And it's a similar challenge that we saw on DevOps where there's just too many, if you will, too many dang tools, right. So that is a challenge for organizations is, they're trying to kind of normalize the tools. Interestingly, we did a survey, I think around last August or something. And one of the questions was around, where do you want your security? Where do you want to get your DevSecOps security from, do you want to get it from individual vendors? Or do you want to get it from like, your platforms that you're using and deploying changes in Kubernetes. >> Great question. What did they say? >> The majority of them, they're hoping they can get it built into the platform. That's really what they want. And you see a lot of the security vendors are trying to build security platforms. Like we're not just assess tool, we're desk, we're this, whatever. And they're building platforms to kind of be that end-to-end security platform, trying to solve that problem, right, to make it easier to kind of consume the product overall, without a bunch of individual tools along the way. But certainly tool sprawl is definitely a challenge out there. Just one other point around the sigstore stuff which I love. Because that goes back to the supply chain and talking about digital providence, right. Understanding where things... How do I validate that what I gave you is what you thought it was, right. And what I like about it with Tekton Chains is because there's a couple things. Well, first of all, I don't want to just sign things after I built the binary. Well, I mean, I do want to sign it, but I want to just sign things once, right. Because all through the process, I think of it as a manufacturing plant, right. I'm making automobiles. If I check the quality of the automobile at one stage and I don't check it to the other, things have changed, right. How do I know that I did something wasn't compromised, right. So with sigstore kind of tied in with Tekton Chains, kind of gives me that view. And the other aspect I like it about is, this kind of transparency in the log, right-- >> The report component. >> Exactly. So I can see what was going on. So there is some this kind of like public scrutiny, like if something bad happened, you could go back and see what happened there and it wasn't as you were expected. >> As with most discussions on this topic, we could go for an hour because it's really important. And thank you guys for coming on and sharing your perspectives, the data. >> Our pleasure. >> And keep up the good work. Kirsten, it's on you. >> Thanks so much. >> The IDC survey said it, they want it in platforms. You're up. >> (laughs) That's right. >> All right. Good luck to both you. >> Thank you both so much. >> All right. And thank you for watching. We're back to wrap right after this short break. This is Dave Vellante for Paul Gill. You're watching theCUBE. (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)

>> Announcer: Live from San Francisco, it's theCUBE, covering Red Hat SUMMIT 2018, brought to you by Red Hat. >> Okay welcome back everyone. We are here live in San Francisco at Moscone West. This is theCube's exclusive coverage of Red Hat SUMMIT 2018. I'm John Furrier, co-host of theCube. This week John Troyer, guest analyst, he's the co-founder of TechReckoning, an advisory and consulting firm around community. Our next guest Matt Hicks, Senior Vice President of Engineering at Red Hat. He's going to give us all the features, and specs of the road map, and all the priorities. Thanks for coming on. >> Hey, thanks guys. >> John: He's like, "I'm not." >> So thanks for comin' on, obviously a successful show for you guys, congratulations. >> Matt: Thank you Paul Cormier was on earlier talking about some of the bets you guys made and it's all open source, so those bets are all part of the community, with the community. But certainly there's a big shift happening, we're seeing it now with containers, and Kubernetes really showing the way, giving customers clear line of sight of where things are startin' to fall in the stack. Obviously you got infrastructure and application development all under a DevOps kind of concept, so congratulations. >> Thank you, thank you, it's been fun, it's been, I think Paul shared this a couple weeks, we started OpenShift in 2011, so it's pretty cool to be here now, 2018, and just see how far that's come in terms of how many customers using it, how successful they've been with it. So that's, it's been great. >> Yeah we always like to talk on theCube, we love talkin' to product people and engineers because we always say the cloud is like an operating system. It's just all over the place, decentralized network, distributing computing, these are concepts that have been around. A lot of the Red Hat DNA comes from systems, you have SELinux operating system, that you offer for free but also have services around it. It's a systems problem as we look at the cloud, cloud economics. So when you go look at some of the product and engineering priorities, how do you guys keep that goin'? What are some of the guiding principles that you guys have with your team? Obviously open-source, being in up-stream projects, but as you guys have to build this out in realtime, what are some of the principles that you guys have? >> That's a great, that's a great question. I'll try to cover it on two areas. I think the first for us is workload compatibility, where you get down into the, building that new apps is great, it's fun, a lot of people can do it, and that's an exciting area. The customers also, they have to deal with apps they built over 10 plus years, and so in everything we design, we try to make sure we can address both of those use cases. I think that's one of the reasons, yeah we talk about OpenShift and how coupled it is to RHEL and Linux. It's for that you can take anything that runs on RHEL, run it in a container on OpenShift, stateful, not stateful. That's one really key design principle. The other one, and this we've actually experienced ourselves, of the roles and responsibilities separation. We run an OpenShift host environment publicly, I joke, like anyone that gives me an email address, I'll run their code and my operations team doesn't have to know what's inside of the containers. They have a really clear boundary which is make the infrastructure infinitely available for them, and know that you can run anything on that environment. So that separation, you know when customers talk about DevOps, and getting to agile, I think that's almost as critical as the technology itself, is letting them be able to do that. >> Yeah, that's been a real theme here at the show, I've certainly noticed. Sure there were technology demos up on stage, but also a lot of talk about culture, about process or anti-planning maybe, or you know helping people. The role of Red Hat with OpenShift and the full stack all the way down is bigger now than it was, just when it was just Linux. So I mean, is it you and your team, I mean your in engineering as you work with the open source communities, surely it seems like you're having to deal with a much broader scope of responsibilities. >> Yeah, that's true. I started in Red Hat when it was just Linux and part of it is, you know Linux is big, and it's complex, and that in and of itself is a pretty broad community. But these days it is, we get to work with customers that are transforming their business and that touches everything from how they're organizationally structured, how we make teams work together, how I make the developers happy with their rate of innovation and the security team still comfortable with what they're changing. I love it, like it is, you know and we open source at our core, so I fell like, I'm an open source guy. I always have been. You're seeing open source drive a much wider scope of change then I ever have before. >> Let's talk about functionality product-wise, 'cause again we interviewed Jim Whitehurst yesterday and we had Denise Dumas on as well, on the RHEL side, and we talked about security. These things going on, and with OpenShift, and with Kubernetes, and containers, it makes your job harder. You got to do more right? So talk about what does that mean for you guys and how does that translate to the customer impact because it's more complicated. There's abstraction layers that are abstracting away the complexity. The complexity is not going away, it's just being abstracted away. This is harder on engineering. How are you handling that and what's your approach? >> So I've looked at it as a great opportunity for us. I've been working with Linux for a long time and I was a big fan when we introduced SELinux, and for a long time moving from traditional Linux hosting to operations teams wanting to turn on SELinux, it's been a really tough climb. It's, it'll break things, and they're not comfortable with it. They know they need that layer of security, but turning it on has been a challenge. Then go to cgroups, or different namespaces, and they're not going to get there. With OpenShift, the vast majority of OpenShift deployments, under the covers we run with SELinux on by default, customize policies, everything's in control groups, containers uses Linux namespaces. So you get a level of workload isolation that it was unimaginable you know five, 10 years ago, and I love that aspect, 'cause you start with one aspect of security, you get much, much stronger. So it's our ability to, you know we know all the levers and knobs in Linux itself, and we get to turn 'em all and pull 'em all so, >> I want to put you on the spot, I want to, and it's not an insult to you guys at all. But we've heard some hallway conversations. You know just in a joking way 'cause everyone loves Linux, open source, we all love that. But they say, nothings perfect either. No software actually runs all the time great. So one customer said, I won't say the name, "When OpenShift fails, it fails big." Meaning there's, it's very reliable but it's taking on a lot of heaving lifting. There's a lot of things going on in there, 'cause that's, 'cause it's Linux, when it breaks, it breaks a lot, and I know you're tryin' to avoid that. But my point is, is that just as these are important components. How do you make that completely bullet proof? How do you guys stay on top of it so that thinks don't break? I'm not saying they do all the time. I'm just saying it's common. It was more an order of magnitude kind of thing. >> Yeah, yeah, no, well I think it's a coupla things. So we invested in OpenShift Online and OpenShift Dedicated and those were new for Red Hat, and for running hosting environments, so we could learn a lot of the nuances of how do you, OpenShift Online is roughly a single environment, how do we make that never break as a whole. A user might do something in their app and make their app break. How do we not make the whole break? The second challenge I think we've hit is just skills in the market of it's not necessarily an easy system there are lots of moving pieces there. The deal with Azure and the partnership there, having managed service offerings I think is really going to help users get into, I have a highly available environment, I don't have to worry about SED replication or those components but I can still get the benefits. And then I think over time as people learn the technology, they know how to utilize it well, we'll see, we'll see less and less of the it catastrophically failed because I didn't know that I could make it highly available. Those are always painful to me, where it's you know, >> John: That's education. >> Yeah >> So Matt, there's a clear conversation here. Very clarity of roles and responsibilities even in the stack. I think even as recently as a year or two ago, people were having conversations about the role of OpenStack, versus Kubernetes, and you were getting kind of weird, like what's on top of what? And even in terms of, you know other parts of the stack, I mean here it's clear, very clear, you know OpenStack is about infrastructure, OpenShift you know on top of it, and even in terms of virtualization, containers versus VMs. The conversation this year seems more clear. As an engineer, you know and an engineering leader, were the, did the engineering teams rolling their eyes going well we knew how this was going to work out all along, or did you all also kind of come along on that journey the last couple years? >> I think seeing the customer use cases refined a little bit while education builds those has been great. We always, like we're engineers, we like clear separation and what each products good at, so for us it's fantastic. You know OpenStack is great at managing metal. One of my favorite demonstrations was using OpenStack Director to on a, you know boot machines, put OSs on 'em, and leave OpenShift running, and be able to share network and storage clients with OpenStack. Those things are, you know they're great for me as an engineering lead because we're doing that once as well as we can, but it's nice in engineering if you get to optimize each side of the stack. So I think I have seen the customers understanding, as they've done more with OpenStack, and they've done more with OpenShift, they know which product they want to use, what for. That has helped us accelerate the engineering work towards it. >> You mention skills, skills gaps, and skills in general. How is the hiring going? Is there a new kind of DevOps rockstar out there? Is there a new kind of profile? Is there pieces of the stack that you want certain skills for? Is there generalism? Are the roles in engineering changing? If you could just add some color to that conversation around, you know cause we're talkin' about engineering now. It used to be called software engineering when I graduated, and then you became a developer. I don't know which ones better, but you know to me this is real engineering going on, which is using software development techniques. So what's the skills situation? >> For us I think, it is nice that you're seeing a lot of gravitation to Linux at the host level, and Kubernetes has helped, just at the distributed system level, so obviously skills there play pretty well in general. I would say what we have seen is there has been a stronger increase in having operational skills as well as development skills, and it's a spectrum. You're still going to have operational experts and algorithmic experts, but the blended role where you do know what it takes to run an application in production to some extent, or you do know something about infrastructure and development. I certainly look for that on our teams because that's, where customers I've seen struggle for years and years is in the handoff in the shift between, everyone can write functional apps, they usually struggle getting them into production. And it's really neither teams fault, it's in that translation and these platforms help bridge that. People that have some skills on either side have become incredibly valuable in that. >> John: So that's were the DevOps action is right, the overlay. >> It really is yeah. >> So thinking about network as the networking growth with DevOps. DevOps has always been infrastructure as code. And it all comes to, there's to many, many, I don't want to talk about it. It's always the network that gets beat on the most, I need better latency. And so networking software to find networking is not a new concept, self-defined data centers are out there. What's new in networking that you could point to that's part of this new wave? >> Two geeky things that might not have been noticed. One is the work we've done on Ansible networking has been stunningly popular to me, and that was just this simplicity of Ansible just needs us to sage in a minimal set of dependencies. Most switches out there can actually, they have SSH running, and having automation of switches in the actual gear itself was surprisingly not unified. And Ansible was able to fit that niche where you could remotely configure switches and that has grown and exploded. Because if you think of the, I'm going to do a DevOps workflow but now I need to actually change routing or bleed something, you're often talking to switches, and being able to couple that in has been, it has been fun to watch, so I've loved that aspect. The other portion when we combine OpenShift on OpenStack the courier work which we've talked about some, is, you know OpenShift often described as it consumes infrastructure that OpenStack provides, and the one exception was usually the networking tier. It was like we have to run an overlay network on it. When we run OpenShift on OpenStack it can actually utilize OpenStack's networking to be able to try that instead of doing it's own overlay. That is critical at the larger scale. >> John: So the policy comes in handy there is that, or configurations, where's the benefit? >> Both on network topology, which do you have two teams that are building different structures that may collide in the night. So it gets it from two teams down to one, and then the second is just the knock controls in isolation, it's done once. It's been nice for me on the engineering side where we'd put a ton of effort in the OpenStack community, we put a ton of effort in Kubernetes and the OpenShift communities, and we're able to pretty nicely combine those. We know 'em both really well. >> So take us through some inside baseball at Red Hat. What's going on internally within' your group. I want to probe on developer and software engineers productivity. If the quote DevOps works, the test is the freeing up their time from doing mundane tasks, and you got cool things like you said about the network things, pretty positive. This is going to free up some intellectual capital from engineering. So okay if that's true, I'm assuming it's true, if it's not then say it's not true, but it sounds like it's probably going to be true for you. What are your guys working on, what's next? So can you share some of what, 'cause you guys are doing your own thing, you're using your own software. Is that intellectual capital being freed up on the developers side? Are they doing some more programming? Are you seeing some more creativity? What are they doing with that free time, free time, extra intellectual cycles? >> All our excesses, I'll tell Paul that. He was up before me. Like, Ops team barely has to work anymore. >> There in there clipping coupons at the beach you know. It's all running, we're busy. >> So a good creative example, and this was I think the second demo we showed. Red Hat Insights has been in the market for a while and that was our, can we glean enough information from systems to get ahead of a support issue, and this year we showed the, it's not just known fixes, you know we match it to a knowledgebase article. But can we interpret fixes from peer analysis and you know machine learning type techniques? That's a classic example where we use the creativity and free time, and say you know what that stack internally runs on OpenShift, running on OpenStack, using Red Hat storage, and we're applying some of, you know TensorFlow and other capabilities to do that. That was probably my favorite example at SUMMIT where if we weren't getting more efficient at what we worked on, we wouldn't of been able to stand up that stack ourselves, much less execute to it, and show it live in SUMMIT, doing the analysis across a hybrid cloud. >> But this is the whole point of DevOps. This the whole purpose, being highly productive, to use those intellectual cycle times to build stuff, solve problems. >> Yeah absolutely. >> Not provision servers or networks. Awesome, well thanks for coming on theCUBE, really appreciate it. >> Matt: Thank you guys. >> What's the priorities for you guys this year? What's the focus? Share your plans for the year. >> You know I think it's similar to the last thing we showed today. We really want to make customers feel like they can deploy hybrid cloud. Whether it's compute, applications, they have the services they need, down to storage, it works. They're on premise. They know we're going to have the best combination we can. This year is a stay ahead of people on that path, make sure their successful with it. >> We'll see you guys at OpenStack SUMMIT, Vancouver. Thanks for comin' on, Matt Hicks, Senior Vice-President of Engineering at Red Hat. I'm John Furrier, John Troyer, Stay with us, we're day three of three days of live coverage here in San Francisco, Red Hat SUMMIT 2018. Stay with us, we'll be right back after this short break. (digital music)