(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, everyone. Welcome to theCUBE's coverage of the "AWS Startup Showcase", season two, episode one. I'm Lisa Martin, and I'm excited to be joined by Snyk, next in this episode. Liran Tal joins me, the director of developer advocacy. Liran, welcome to the program. >> Lisa, thank you for having me. This is so cool. >> Isn't it cool? (Liran chuckles) All the things that we can do remotely. So I had the opportunity to speak with your CEO, Peter McKay, just about a month or so ago at AWS re:Invent. So much growth and momentum going on with Snyk, it's incredible. But I wanted to talk to you about specifically, let's start with your role from a developer advocate perspective, 'cause Snyk is saying modern development is changing, so traditional AppSec gatekeeping doesn't apply anymore. Talk to me about your role as a developer advocate. >> It is definitely. The landscape is changing, both developer and security, it's just not what it was before, and what we're seeing is developers need to be empowered. They need some help, just working through all of those security issues, security incidents happening, using open source, building cloud native applications. So my role is basically about making them successful, helping them any way we can. And so getting that security awareness out, or making sure people are having those best practices, making sure we understand what are the frustrations developers have, what are the things that we can help them with, to be successful day to day. And how they can be a really good part of the organization in terms of fixing security issues, not just knowing about it, but actually being proactively on it. >> And one of the things also that I was reading is, Shift Left is not a new concept. We've been talking about it for a long time. But Snyk's saying it was missing some things and proactivity is one of those things that it was missing. What else was it missing and how does Snyk help to fix that gap? >> So I think Shift Left is a good idea. In general, the idea is we want to fix security issues as soon as we can. We want to find them. Which I think that is a small nuance that what's kind of missing in the industry. And usually what we've seen with traditional security before was, 'cause notice that, the security department has like a silo that organizations once they find some findings they push it over to the development team, the R&D leader or things like that, but until it actually trickles down, it takes a lot of time. And what we needed to do is basically put those developer security tools, which is what Snyk is building, this whole security platform. Is putting that at the hands and at the scale of, and speed of modern development into developers. So, for example, instead of just finding security issues in your open source dependencies, what we actually do at Snyk is not just tell you about them, but you actually open a poll request to your source codes version and management system. And through that we are able to tell you, now you can actually merge it, you can actually review it, you can actually have it as part of your day-to-day workflows. And we're doing that through so many other ways that are really helpful and actually remediating the problem. So another example would be the IDE. So we are actually embedding an extension within your IDEs. So, once you actually type in your own codes, that is when we actually find the vulnerabilities that could exist within your own code, if that's like insecure code, and we can tell you about it as you hit Command + S and you will save the file. Which is totally different than what SaaS tools starting up application security testing was before because, when things started, you usually had SaaS tools running in the background and like CI jobs at the weekend and in deltas of code bases, because they were so slow to run, but developers really need to be at speed. They're developing really fast. They need to deploy. One development is deployed to production several times a day. So we need to really enable developers to find and fix those security issues as fast as we can. >> Yeah, that speed that you mentioned is absolutely critical to their workflow and what they're expecting. And one of the unique things about Snyk, you mentioned, the integration into how this works within development workflow with IDE, CIDC, they get environment enabling them to work at speed and not have to be security experts. I imagine are two important elements to the culture of the developer environment, right? >> Correct, yes. It says, a large part is we don't expect developers to be security experts. We want to help them, we want to, again, give them the tools, give them the knowledge. So we do it in several ways. For example, that IDE extension has a really cool thing that's like kind of unique to it that I really like, and that is, when we find, for example, you're writing code and maybe there's a batch traversal vulnerability in the function that you just wrote, what we'll actually do when we tell you about it, it will actually tell you, hey, look, these are some other commits made by other open source projects where we found the same vulnerability and those commits actually fixed it. So actually giving you example cases of what potentially good code looks like. So if you think about it, like who knows what patch reversal is, but prototype pollution like many types of vulnerabilities, but at the same time, we don't expect developers to actually know, the deep aspects of security. So they're left off with, having some findings, but not really, they want to fix them, but they don't really have the expertise to do it. So what we're doing is we're bridging that gap and we're being helpful. So I think this is what really proactive security is for developers, that says helping them remediate it. And I can give like more examples, like the security database, it's like a wonderful place where we also like provide examples and references of like, where does their vulnerability come from if there's like, what's fogging in open-source package? And we highlight that with a lot of references that provide you with things, the pull requests that fixed date, or the issue with where this was discussed. You have like an entire context of what is the... What made this vulnerability happen. So you have like a little bit more context than just specifically, emerging some stuff and updating, and there's a ton more. I'm happy to like dive more into this. >> Well, I can hear your enthusiasm for it, a developer advocate it seems like you are. But talking about the burdens of the gaps that you guys are filling it also seems like the developers and the security folks that this is also a bridge for those teams to work better together. >> Correct. I think that is not siloed anymore. I think the idea of having security champions or having threat modeling activities are really, really good, or like insightful both like developers and security, but more than just being insightful, useful practices that organizations should actually do actually bringing a discussion together to actually creating a more cohesive environment for both of those kind of like expertise, development and security to work together towards some of these aspects of like just mitigating security issues. And one of the things that actually Snyk is doing in that, in bringing their security into the developer mindset is also providing them with the ability to prioritize and understand what policies to put in place. So a lot of the times security organizations actually, the security org wants to do is put just, guardrails to make sure that developers have a good leeway to work around, but they're not like doing things that like, they definitely shouldn't do that, like prior to bringing a big risk into today organizations. And that's what I think we're doing also like great, which is the fact that we're providing the security folks to like put the policies in place and then developers who actually like, work really well within those understand how to prioritize vulnerabilities is an important part. And we kind of like quantify that, we put like an urgency score that says, hey, you should fix this vulnerability first. Why? Because it has, first of all, well, you can upgrade really quickly. It has a fix right there. Secondly, there's like an exploit in the wild. It means potentially an attacker can weaponize this vulnerability and like attack your organizations, in an automated fashion. So you definitely want to put that put like a lead on that, on that broken window, if so to say. So we ended up other kind of metrics that we can quantify and put this as like an urgency score, which we called a priority score that helps again, developers really know what to fix first, because like they could get a scan of like hundreds of vulnerabilities, but like, what do I start first with? So I find that like very useful for both the security and the developers working together. >> Right, and especially now, as we've seen such changes in the last couple of years to the threat landscape, the vulnerabilities, the security issues that are impacting every industry. The ability to empower developers to not only work at the speed with which they are accustomed and need to work, but also to be able to find those vulnerabilities faster prioritize which ones need to be fixed. I mean, I think of Log4Shell, for example, and when the challenge is going on with the supply chain, that this is really a critical capability from a developer empowerment perspective, but also from a overall business health and growth perspective. >> Definitely. I think, first of all, like if you want to step just a step back in terms of like, what has changed. Like what is the landscape? So I think we're seeing several things happening. First of all, there's this big, tremendous... I would call it a trend, but now it's like the default. Like of the growth of open source software. So first of all as developers are using more and more open source and that's like a growing trend of have like drafts of this. And it's like always increasing across, by the way, every ecosystem go, rust, .net, Java, JavaScript, whatever you're building, that's probably like on a growing trend, more open source. And that is, we will talk about it in a second what are the risks there. But that is one trend that we're saying. The other one is cloud native applications, which is also worth to like, I think dive deep into it in terms of the way that we're building applications today has completely shifted. And I think what AWS is doing in that sense is also creating a tremendous shift in the mindset of things. For example, out of the cloud infrastructure has basically democratized infrastructure. I do not need to, own my servers and own my monitoring and configure everything out. I can actually write codes that when I deploy it, when something parses this and runs this, it actually creates servers and monitoring, logging, different kinds of things for me. So it democratize the whole sense of building applications from what it was decades ago. And this whole thing is important and really, really fast. It makes things scalable. It also introduces some rates. For example, some of these configuration. So there's a lot that has been changed. And in that landscape of like what modern developer is and I think in that sense, we kind of can need a lead to a little bit more, be helpful to developers and help them like avoid all those cases. And I'm like happy to dive into like the open source and the cloud native. That was like follow-ups on this one. >> I want to get into a little bit more about your relationship with AWS. When I spoke with Peter McKay for re:Invent, he talked about the partnership being a couple of years old, but there's some kind of really interesting things that AWS is doing in terms of leveraging, Snyk. Talk to me about that. >> Indeed. So Snyky integrates with almost, I think probably a lot of services, but probably almost all of those that are unique and related to developers building on top of the AWS platform. And for example, that would be, if you actually are building your code, it connects like the source code editor. If you are pushing that code over, it integrates with code commits. As you build and CIS are running, maybe code build is something you're using that's in code pipeline. That is something that you have like native integrations. At the end of the day, like you have your container registry or Lambda. If you're using like functions as a service for your obligations, what we're doing is integrating with all of that. So at the end of the day, you really have all of that... It depends where you're integrating, but on all of those points of integration, you have like Snyk there to help you out and like make sure that if we find on any of those, any potential issues, anything from like licenses to vulnerabilities in your containers or just your code or your open source code in those, they actually find it at that point and mitigate the issue. So this kind of like if you're using Snyk, when you're a development machine, it kind of like accompanies you through this journey all over what a CIC kind of like landscape looks like as an architectural landscape for development, kind of like all the way there. And I think what you kind of might be I think more interested, I think to like put your on and an emphasis would be this recent integration with the Amazon Inspector. Which is as it's like very pivotal parts on the AWS platform to provide a lot of, integrate a lot of services and provide you with those insights on security. And I think the idea that now that is able to leverage vulnerability data from the Snyk's security intelligence database that says that's tremendous. And we can talk about that. We'd look for shell and recent issues. >> Yeah. Let's dig into that. We've have a few minutes left, but that was obviously a huge issue in November of 2021, when obviously we're in a very dynamic global situation period, but it's now not a matter of if an organization is going to be hit by vulnerabilities and security threats. It's a matter of when. Talk to me about really how impactful Snyk was in the Log4Shell vulnerability and how you help customers evade probably some serious threats, and that could have really impacted revenue growth, customer satisfaction, brand reputation. >> Definitely. The Log4Shell is, well, I mean was a vulnerability that was disclosed, but it's probably still a major part and going to be probably for the foreseeable future. An issue for organizations as they would need to deal with us. And we'll dive in a second and figure out like why, but in like a summary here, Log4Shell was the vulnerability that actually was found in Java library called Log4J. A logging library that is so popular today and used. And the thing is having the ability to react fast to those new vulnerabilities being disclosed is really a vital part of the organizations, because when it is asking factful, as we've seen Log4Shell being that is when, it determines where the security tool you're using is actually helping you, or is like just an added thing on like a checkbox to do. And that is what I think made Snyk's so unique in the sense. We have a team of those folks that are really boats, manually curating the ecosystem of CVEs and like finding by ourselves, but also there's like an entire, kind of like an intelligence platform beyond us. So we get a lot of notifications on chatter that happens. And so when someone opens an issue on an open source repository says, Hey, I found an issue here. Maybe that's an XSS or code injection or something like that. We find it really fast. And we at that point, before it goes to CVE requirement and stuff like that through like a miter and NVD, we find it really fast and can add it to the database. So this has been something that we've done with Log4Shell, where we found that as it was disclosed, not on the open source, but just on the open source system, but it was generally disclosed to everyone at that point. But not only that, because look for J as the library had several iterations of fixes they needed. So they fixed one version. Then that was the recommendation to upgrade to then that was actually found as vulnerable. So they needed to fix the another time and then another time and so on. So being able to react fast, which is, what I think helped a ton of customers and users of Snyk is that aspect. And what I really liked in the way that this has been received very well is we were very fast on creating those command line tools that allow developers to actually find cases of the Log4J library, embedded into (indistinct) but not true a package manifest. So sometimes you have those like legacy applications, deployed somewhere, probably not even legacy, just like the Log4J libraries, like bundled into a net or Java source code base. So you may not even know that you're using it in a sense. And so what we've done is we've like exposed with Snyk CLI tool and a command line argument that allows you to search for all of those cases. Like we can find them and help you, try and mitigate those issues. So that has been amazing. >> So you've talked in great length, Liran about, and detail about how Snyk is really enabling and empowering developers. One last question for you is when I spoke with Peter last month at re:Invent, he talked about the goal of reaching 28 million developers. Your passion as a director of developer advocacy is palpable. I can feel it through the screen here. Talk to me about where you guys are on that journey of reaching those 28 million developers and what personally excites you about what you're doing here. >> Oh, yeah. So many things. (laughs) Don't know where to start. We are constantly talking to developers on community days and things like that. So it's a couple of examples. We have like this dev site community, which is a growing and kicking community of developers and security people coming together and trying to work and understand, and like, just learn from each other. We have those events coming up. We actually have this, "The Big Fix". It's a big security event that we're launching on February 25th. And the idea is, want to help the ecosystem secure security obligations, open source or even if it's closed source. We like help you fix that though that yeah, it's like helping them. We've launched this Snyk ambassadors program, which is developers and security people, CSOs are even in there. And the idea is how can we help them also be helpful to the community? Because they are like known, they are passionate as we are, on application security and like helping developers code securely, build securely. So we launching all of those programs. We have like social impact related programs and the way that we like work with organizations, like maybe non-profit maybe they just need help, like getting, the security part of things kind of like figured out, students and things like that. Like, there's like a ton of those initiatives all over the boards, helping basically the world be a little bit more secure. >> Well, we could absolutely use Snyk's help in making the world more secure. Liran it's been great talking to you. Like I said, your passion for what you do and what Snyk is able to facilitate and enable is palpable. And it was a great conversation. I appreciate that. And we look forward to hearing what transpires during 2022 for Snyk so you got to come back. >> I will. Thank you. Thank you, Lisa. This has been fun. >> All right. Excellent. Liran Tal, I'm Lisa Martin. You're watching theCUBE's second season, season two of the "AWS Startup Showcase". This has been episode one. Stay tuned for more great episodes, full of fantastic content. We'll see you soon. (upbeat music)

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

>> Narrator: From around the globe It's theCUBE with digital coverage of IBM Think 2021. Brought to you by IBM. >> Welcome back everyone to theCUBE's coverage of IBM Think 2021 virtual, I'm John Furrier, your host. I've got a great guest here Robin Hernandez, vice president Hybrid Cloud Management and Watson AIOps. Robin, great to see you. Thanks for coming on theCUBE. >> Thanks so much for having me, John. >> You know, Hybrid Cloud, the CEO of IBM Arvind loves Cloud. We know that we've talked to him all the time about it. And Cloud is now part of the entire DNA of the company. Hybrid Cloud is validated multi clouds around the corner. This is the underlying pinnings of the new operating system of business. And with that, that's massive change that we've seen IT move to large scale. You're seeing transformation, driving innovation, driving scale, and AI is the center of it. So AIOps is a huge topic. I want to jump right into it. Can you just tell me about your day to day IT operations teams what you guys are doing? How are you guys organized? How you guys bring in value to the customers? What are your teams responsible for? >> Yeah, so for a few years we've been working with our IT customers, our enterprise customers in this transformation that they're going through. As they move more workloads to cloud, and they still have some of their workloads on premise, or they have a strategy of using multiple public clouds, each of those cloud vendors have different tools. And so they're forced with, how do I keep up with the changing rate and pace of this technology? How do I build skills on a particular public cloud vendor when, you know, maybe six months from now we'll have another cloud vendor that will be introduced or another technology that will be introduced. And it's almost impossible for an it team to keep up with the rate and pace of the change. So we've really been working with IT operations in transforming their processes and their skills within their teams and that looking at what tools do they use to move to this cloud operations model. And then as part of that, how do they leverage the benefits of AI and make that practical and purposeful in this new mode of cloud operations >> And the trend that's been booming is this idea of a site reliability engineer. It's really an IT operations role. It's become kind of a new mix between engineering and IT and development. I mean, classic DevOps, we've seen, you know dev and ops, right? You got to operate the developers and the software modern apps are coming in that's infrastructure as course has been around for a while. But now as the materialization of things like Kubernetes and microservices, people are programming the infrastructure. And so the scale is there, and that's been around for a while. Now it's going to go to a whole enterprise level with containers and other things. How is the site reliability engineering persona if you will, or ITOps changed specifically because that's where the action is. And that's where you hear things like observability and I need more data, break down the silos. What's this all about? What's your view? >> Yeah, so site reliability engineering or SRE practices as we call it has really not changed the processes per se that IT has to do, but it's more accelerated at an enormous rate and pace. Those processes and the tools as you mentioned, the cloud native tools like Kubernetes have accelerated how those processes are executed. Everything from releasing new code and how they work with development to actually code the infrastructure and the policies in that development process to maintaining and observing over the life cycle of an application, the performance, the availability, the response time, and the customer experience. All of those processes that used to happen in silos with separate teams and sort of a waterfall approach, with SRE practices now, they're happening instantaneously. They're being scaled out. They're being... Failback is happening much more quickly so that applications didn't do not have outages. And the rate and pace of this has just accelerated so quickly. This is the transformation of what we call cloud operations. And we believe that as IT teams work more closely with developers and they moved towards this SRE model, that they cannot just do this with their personnel and changing skills and changing tools. They have to do this with modernized tools like AI. And this is where we are recommending applying AI to those processes so that you can then get automation out of the back end that you would not think about in a traditional IT operations, or even in an SRE practice. You have to leverage capabilities and new technologies like AI to even accelerate further. >> Let's unpack the AI operations piece because I think that's where I think I'm in hearing. I'd love you to clarify this because it becomes I think the key important point but also kind of confusing to some folks because IT operations people see that changing. You just pointed out why, honestly, the tools and the culture is changing, but AI becomes a scale point because of the automation piece you mentioned. How does that thread together? How does AIOps specifically change the customer's approach in terms of how they work with their teams and how that automation is being applied? 'Cause I think that's the key thread, right? 'Cause everyone kind of gets the cultural shifts and the tools, if they're not living it and putting it in place, but now they want to scale it. That's where automation comes in. Is that right? Is that the right way to think about it? What's your view on this? This is important. >> It's absolutely right. And I always like to talk about AI in other industries before we apply it to IT to help IT understand. Because a lot of times, IT looks at AI as a buzzword and they say, "Oh, you know, yes, sure. "This is going to help me." But if you think about... We've been doing AI for a long time at many different companies not just at IBM, but if you think about the other industries where we've applied it, healthcare in particular is so tangible for most people, right? It didn't replace a doctor but it helps a doctor see the things that would take them weeks and months of studying and analyzing different patients to say, "Hey, John, I think this may be a symptom "that we overlooked or didn't think about "or a diagnosis that we didn't think about," without manually looking at all this research. AI can accelerate that so rapidly for a doctor, the same notion for IT. If we apply AI properly to IT, we can accelerate things like remediating incidents or finding a performance problem that may take your eye months or weeks or even hours to find, AI applied properly find those issues and diagnose just like they could in healthcare it diagnoses issues correctly much more rapidly. >> Now again, I want to get your thoughts on something while you're here 'cause you've been in the business for many, many decades 20 years experience, you know, cloud cold, you know the new modern area you're managing it now. Clients are having a scenario where they, "Okay, I'm changing over the culture." I'm "Okay, I got some cloud, I got some public "and I got some hybrid and man, "we did some agile things. "We're provisioned, it's all done. "It's out there." And all of a sudden someone adds something new and it crashes (chuckles) And now I've got to get in, "Where's the risks? where's the security holes?" They're seeing this kind of day two operations as some people call, another buzz word but it's becoming more of, "Okay, we got it up and running "but we still now going to still push some code "and things are starting to break. "and that's net new thing." So it's kind of like they're out of their comfort zone. This is where I kind of see the AIOps evolving quickly because there's kind of a DevSecOps piece. There's also data involved, observability. How do you talk to that scenario? Where, okay, you sold me on cloud, I've been doing it. I did some projects. We're not been running. We got a production system and we added something new. Something maybe trivial and it breaks stuff? >> Yes. Yeah, so with the new cloud operations and SRE, the IT teams are much more responsible for business outcomes. And not just as you say, the application being deployed and the application being available, but the life cycle of that application and the results that it's bringing to the end users and the business. And what this means is that it needs to partner much more closely with development. And it is hard for them to keep up with the tools that are being used and the new code and the architectures of microservices that developers are using. So we like to apply AI on what we call the change risk management process. And so everyone's familiar with change management that means a new piece of code is being released. You have to maintain where that code is being released to was part of the application architecture and make sure that it's scaled out and rolled out properly within your enterprise policies. When we apply AI, we then apply what we call a risk factor to that change because we know so often, application outages occur not something new within the environment. So by applying AI, we can then give you a risk rating that says, "There's an 80% probability "that this change that you're about to roll out, "a code change is going to cause a problem "in this application." So it allows you to then go back and work with the development team and say, "Hey, how do we reduce this risk?" Or decide to take that calculated risk and put into the visibility of where those risks may occur. So this is a great example, change risk management of how applying AI can make you more intelligent in your decisions much more tied to the business and tied to the application release team. >> That's awesome. Well, I got you here on this point of change management. The term "Shift Left" has come up a lot in the industry. I'd love to get your quick definition of what that is in your mind. What does Shift Left mean for Ops teams with AIOps? >> Yeah, so in the early days of IT there was a hard line definitely between your development and IT team. It was kind of we always said throwing it over the fence, right? The developers would throw the code over the fence and say, good luck IT, you know, figure out how to deploy it where it needs to be deployed and cross your fingers that nothing bad happens. Well, Shift Left is really about a breaking down that fence. And if you think of your developers on your left-hand side you'd being the IT team, it's really shifting more towards that development team and getting involved in that code release process, getting involved in their CI/CD pipeline to make sure that all of your enterprise policies and what that code needs to run effectively in your enterprise application and architecture, those pieces are coded ahead of time with the developer. So it's really about partnering between it and development, shifting left to have a more collaboration versus throwing things over the fence and playing the blame game, which is what happens a lot in the early days IT. >> Yeah, and you get a smarter team out of it, great point. That's great insight. Thanks for sharing that. I think it's super relevant. That's the hot trend right now making dealers more productive, building security from the beginning. While they're doing it code it right in, make it a security proof if you will. I got to ask you one of the organizational questions as IBM leader. What are some of the roadblocks that you see in organizations that when they embrace AIOps, are trying to embrace AI ops are trying to scale it and how they can overcome those blockers. What are some of the things you're seeing that you could share with other folks that are maybe watching and trying to solve this problem? >> Yeah, so you know, AI in any industry or discipline is only as good as the data you feed it. AI is about learning from past trends and creating a normal baseline for what is normal in your environment. What is most optimal in your environment this being your enterprise application running in steady state. And so if you think back to the healthcare example, if we only have five or six pieces of patient data that we feed the AI, then the AI recommendation to the doctor is going to be pretty limited. We need a broad set of use cases across a wide demographic of people in the healthcare example, it's the same with IT, applying AI to IT. You need a broad set of data. So one of the roadblocks that we hear from many customers is, well I using an analytics tool already and I'm not really getting a lot of good recommendations or automation out of that analytics tool. And we often find it's because they're pulling data from one source, likely they're pulling data from performance metrics, performance of what's happening with the infrastructure, CPU utilization or memory utilization, storage utilization. And those are all good metrics, but without the context of everything else in your environment, without pulling in data from what's happening in your logs, pulling in data from unstructured data, from things like collaboration tools, what are your team saying? What are the customers saying about the experience with your application? You have to pull in many different data sets across IT and the business in order to make that AI recommendation the most useful. And so we recommend a more holistic true AI platform versus a very segregated data approach to applying and eating the analytics or AI engine. >> That's awesome, it's like a masterclass right there. Robin, great stuff. Great insight. We'll quickly wrap. I would love to you to take a quick minute to explain and share what are some of the use cases to get started and really get into AIOps system successes for people that want to explore more, dig in, and get into this fast, what are some use case, what's some low hanging fruit? What would you share? >> Yeah, we know that IT teams like to see results and they hate black boxes. They like to see into everything that's happening and understand deeply. And so this is one of our major focus areas as we do. We say, we're making AI purposeful for IT teams but some of the low hanging fruits, we have visions. And lots of our enterprise customers have visions of applying AI to everything from a customer experience of the application, costs management of the application and infrastructure in many different aspects. But some of the low hanging fruit is really expanding the availability and the service level agreements of your applications. So many people will say, you know I have a 93% uptime availability or an agreement with my business that this application will be up 93% of the time. Applying AI, we can increase those numbers to 99.9% of the time because it learns from past problems and it creates that baseline of what's normal in your environment. And then we'll tell you before an application outage occurs. So avoiding application outages, and then improving performance, recommendations and scalability. What's the number of users coming in versus your normal scale rate and automating that scalability. So, performance improvements and scalability is another low-hanging fruit area where many IT teams are starting. >> Yeah, I mean, why wouldn't you want to have the AIOps? They're totally cool, very relevant. You know, you're seeing hybrid cloud, standardized all across business. You've got to have that data and you got to have that incident management work there. Robin, great insight. Thank you for sharing. Robin Hernandez, vice president of Hybrid Cloud Management in Watson AIOps. Thanks for coming on theCUBE. >> Thank you so much for having me John. >> Okay, this theCUBE's coverage of IBM Think 2021. I'm John Furrier your host. Thanks for watching. (bright upbeat music)

(bright upbeat music) >> Narrator: From around the globe. It's theCUBE with digital coverage of IBM Think 2021. Brought to you by IBM. >> Welcome back everyone to theCUBE's coverage of IBM Think 2021 virtual, I'm John Furrier, your host. I've got a great guest here Robin Hernandez, vice president Hybrid Cloud Management and Watson AIOps. Robin, great to see you. Thanks for coming on theCUBE. >> Thanks so much for having me, John. >> You know, Hybrid Cloud, the CEO of IBM Arvind loves Cloud. We know that we've talked to him all the time about it. And Cloud is now part of the entire DNA of the company. Hybrid Cloud is validated multi clouds around the corner. This is the underlying pinnings of the new operating system of business. And with that, that's massive change that we've seen IT move to large scale. You're seeing transformation, driving innovation, driving scale, and AI is the center of it. So AIOps is a huge topic. I want to jump right into it. Can you just tell me about your day to day IT operations teams what you guys are doing? How are you guys organized? How you guys bring in value to the customers? What are your teams responsible for? >> Yeah, so for a few years we've been working with our IT customers, our enterprise customers in this transformation that they're going through. As they move more workloads to cloud, and they still have some of their workloads on premise, or they have a strategy of using multiple public clouds, each of those cloud vendors have different tools. And so they're forced with, how do I keep up with the changing rate and pace of this technology? How do I build skills on a particular public cloud vendor when, you know, maybe six months from now we'll have another cloud vendor that will be introduced or another technology that will be introduced. And it's almost impossible for an it team to keep up with the rate and pace of the change. So we've really been working with IT operations in transforming their processes and their skills within their teams and that looking at what tools do they use to move to this cloud operations model. And then as part of that, how do they leverage the benefits of AI and make that practical and purposeful in this new mode of cloud operations >> And the trend that's been booming is this idea of a site reliability engineer. It's really an IT operations role. It's become kind of a new mix between engineering and IT and development. I mean, classic DevOps, we've seen, you know dev and ops, right? You got to operate the developers and the software modern apps are coming in that's infrastructure as course has been around for a while. But now as the materialization of things like Kubernetes and microservices, people are programming the infrastructure. And so the scale is there, and that's been around for a while. Now it's going to go to a whole enterprise level with containers and other things. How is the site reliability engineering persona if you will, or ITOps changed specifically because that's where the action is. And that's where you hear things like observability and I need more data, break down the silos. What's this all about? What's your view? >> Yeah, so site reliability engineering or SRE practices as we call it has really not changed the processes to say that it has to do, but it's more accelerated at an enormous rate and pace. Those processes and the tools as you mentioned, the cloud native tools like Kubernetes have accelerated how those processes are executed. Everything from releasing new code and how they work with development to actually code the infrastructure and the policies in that development process to maintaining and observing over the life cycle of an application, the performance, the availability, the response time, and the customer experience. All of those processes that used to happen in silos with separate teams and sort of a waterfall approach, with SRA practices now, they're happening instantaneously. They're being scaled out. They're being... Failback is happening much more quickly so that applications didn't do not have outages. And the rate and pace of this has just accelerated so quickly. This is the transformation of what we call cloud operations. And we believe that as IT teams work more closely with developers and they moved towards this SRE model, that they cannot just do this with their personnel and changing skills and changing tools. They have to do this with modernized tools like AI. And this is where we are recommending applying AI to those processes so that you can then get automation out of the back end that you would not think about in a traditional IT operations, or even in an SRE practice. You have to leverage capabilities and new technologies like AI to even accelerate further. >> Let's unpack the AI operations piece because I think that's where I think I'm in hearing. I'd love you to clarify this because it becomes I think the key important point but also kind of confusing to some folks because IT operations people see that changing. You just pointed out why, honestly, the tools and the culture is changing, but AI becomes a scale point because of the automation piece you mentioned. How does that thread together? How does AIOps specifically change the customer's approach in terms of how they work with their teams and how that automation is being applied? 'Cause I think that's the key thread, right? 'Cause everyone kind of gets the cultural shifts and the tools, if they're not living it and putting it in place, but now they want to scale it. That's where automation comes in. Is that right? Is that the right way to think about it? What's your view on this? This is important. >> It's absolutely right. And I always like to talk about AI in other industries before we apply it to IT to help IT understand. Because a lot of times, IT looks at AI as a buzzword and they say, "Oh, you know, yes, sure. "This is going to help me." But if you think about... We've been doing AI for a long time at many different companies not just at IBM, but if you think about the other industries where we've applied it, healthcare in particular is so tangible for most people, right? It didn't replace a doctor but it helps a doctor see the things that would take them weeks and months of studying and analyzing different patients to say, "Hey, John, I think this may be a symptom "that we overlooked or didn't think about "or a diagnosis that we didn't think about," without manually looking at all this research. AI can accelerate that so rapidly for a doctor, the same notion for IT. If we apply AI properly to IT, we can accelerate things like remediating incidents or finding a performance problem that may take your eye months or weeks or even hours to find, AI applied properly find those issues and diagnose just like they could in healthcare it diagnoses issues correctly much more rapidly. >> Now again, I want to get your thoughts on something while you're here 'cause you've been in the business for many, many decades 20 years experience, you know, cloud cold, you know the new modern area you're managing it now. Clients are having a scenario where they, "Okay, I'm changing over the culture." I'm "Okay, I got some cloud, I got some public "and I got some hybrid and man, "we did some agile things. "We're provisioned, it's all done. "It's out there." And all of a sudden someone adds something new and it crashes (chuckles) And now I've got to get in, "Where's the risks? where's the security holes?" They're seeing this kind of day two operations as some people call, another buzz word but it's becoming more of, "Okay, we got it up and running "but we still now going to still push some code "and things are starting to break. "and that's net new thing." So it's kind of like they're out of their comfort zone. This is where I kind of see the AIOps evolving quickly because there's kind of a DevSecOps piece. There's also data involved, observability. How do you talk to that scenario? Where, okay, you sold me on cloud, I've been doing it. I did some projects. We're not been running. We got a production system and we added something new. Something maybe trivial and it breaks stuff? >> Yes. Yeah, so with the new cloud operations and SRE, the IT teams are much more responsible for business outcomes. And not just as you say, the application being deployed and the application being available, but the life cycle of that application and the results that it's bringing to the end users and the business. And what this means is that it needs to partner much more closely with development. And it is hard for them to keep up with the tools that are being used and the new code and the architectures of microservices that developers are using. So we like to apply AI on what we call the change risk management process. And so everyone's familiar with change management that means a new piece of code is being released. You have to maintain where that code is being released to was part of the application architecture and make sure that it's scaled out and rolled out properly within your enterprise policies. When we apply AI, we then apply what we call a risk factor to that change because we know so often, application outages occur not something new within the environment. So by applying AI, we can then give you a risk rating that says, "There's an 80% probability "that this change that you're about to roll out, "a code change is going to cause a problem "in this application." So it allows you to then go back and work with the development team and say, "Hey, how do we reduce this risk?" Or decide to take that calculated risk and put into the visibility of where those risks may occur. So this is a great example, change risk management of how applying AI can make you more intelligent in your decisions much more tied to the business and tied to the application release team. >> That's awesome. Well, I got you here on this point of change management. The term "Shift Left" has come up a lot in the industry. I'd love to get your quick definition of what that is in your mind. What does Shift Left mean for Ops teams with AIOps? >> Yeah, so in the early days of IT there was a hard line definitely between your development and IT team. It was kind of we always said throwing it over the fence, right? The developers would throw the code over the fence and say, good luck IT, you know, figure out how to deploy it where it needs to be deployed and cross your fingers that nothing bad happens. Well, Shift Left is really about a breaking down that fence. And if you think of your developers on your left-hand side you'd being the IT team, it's really shifting more towards that development team and getting involved in that code release process, getting involved in their CI/CD pipeline to make sure that all of your enterprise policies and what that code needs to run effectively in your enterprise application and architecture, those pieces are coded ahead of time with the developer. So it's really about partnering between it and development, shifting left to have a more collaboration versus throwing things over the fence and playing the blame game, which is what happens a lot in the early days IT. >> Yeah, and you get a smarter team out of it, great point. That's great insight. Thanks for sharing that. I think it's super relevant. That's the hot trend right now making dealers more productive, building security from the beginning. While they're doing it code it right in, make it a security proof if you will. I got to ask you one of the organizational questions as IBM leader. What are some of the roadblocks that you see in organizations that when they embrace AIOps, are trying to embrace AI ops are trying to scale it and how they can overcome those blockers. What are some of the things you're seeing that you could share with other folks that are maybe watching and trying to solve this problem? >> Yeah, so you know, AI in any industry or discipline is only as good as the data you feed it. AI is about learning from past trends and creating a normal baseline for what is normal in your environment. What is most optimal in your environment this being your enterprise application running in steady state. And so if you think back to the healthcare example, if we only have five or six pieces of patient data that we feed the AI, then the AI recommendation to the doctor is going to be pretty limited. We need a broad set of use cases across a wide demographic of people in the healthcare example, it's the same with IT, applying AI to IT. You need a broad set of data. So one of the roadblocks that we hear from many customers is, well I using an analytics tool already and I'm not really getting a lot of good recommendations or automation out of that analytics tool. And we often find it's because they're pulling data from one source, likely they're pulling data from performance metrics, performance of what's happening with the infrastructure, CPU utilization or memory utilization, storage utilization. And those are all good metrics, but without the context of everything else in your environment, without pulling in data from what's happening in your logs, pulling in data from unstructured data, from things like collaboration tools, what are your team saying? What are the customers saying about the experience with your application? You have to pull in many different data sets across IT and the business in order to make that AI recommendation the most useful. And so we recommend a more holistic true AI platform versus a very segregated data approach to applying and eating the analytics or AI engine. >> That's awesome, it's like a masterclass right there. Robin, great stuff. Great insight. We'll quickly wrap. I would love to you to take a quick minute to explain and share what are some of the use cases to get started and really get into AIOps system successes for people that want to explore more, dig in, and get into this fast, what are some use case, what's some low hanging fruit? What would you share? >> Yeah, we know that IT teams like to see results and they hate black boxes. They like to see into everything that's happening and understand deeply. And so this is one of our major focus areas as we do. We say, we're making AI purposeful for IT teams but some of the low hanging fruits, we have visions. And lots of our enterprise customers have visions of applying AI to everything from a customer experience of the application, costs management of the application and infrastructure in many different aspects. But some of the low hanging fruit is really expanding the availability and the service level agreements of your applications. So many people will say, you know I have a 93% uptime availability or an agreement with my business that this application will be up 93% of the time. Applying AI, we can increase those numbers to 99.9% of the time because it learns from past problems and it creates that baseline of what's normal in your environment. And then we'll tell you before an application outage occurs. So avoiding application outages, and then improving performance, recommendations and scalability. What's the number of users coming in versus your normal scale rate and automating that scalability. So, performance improvements and scalability is another low-hanging fruit area where many IT teams are starting. >> Yeah, I mean, why wouldn't you want to have the AIOps? They're totally cool, very relevant. You know, you're seeing hybrid cloud, standardized all across business. You've got to have that data and you got to have that incident management work there. Robin, great insight. Thank you for sharing. Robin Hernandez, vice president of Hybrid Cloud Management in Watson AIOps. Thanks for coming on theCUBE. >> Thank you so much for having me John. >> Okay, this theCUBE's coverage of IBM Think 2021. I'm John Furrier your host. Thanks for watching. (bright upbeat music)