(energetic music plays) >> Lisa: Hey everyone, we're so glad you're here with us. theCUBE is covering Cloud Native Security Con 23. Lisa Martin here with John Furrier. This is our second day of coverage of the event. We've had some great conversations with a lot of intellectual, exciting folks, as you know cuz you've been watching. John and I are very pleased to welcome back one of our alumni to theCUBE Taylor Dolezal joins us the head of ecosystem at CNCF. Taylor, welcome back to theCUBE. Great to see you. >> Taylor: Hey everybody, great to see you again. >> Lisa: So you are on the ground in Seattle. We're jealous. We've got fomo as John would say. Talk to us about, this is a inaugural event. We were watching Priyanka keynote yesterday. Seemed like a lot of folks there, 72 sessions a lot of content, a lot of discussions. What's the buzz, what's the reception of this inaugural event from your perspective? >> Taylor: So it's been really fantastic. I think the number one thing that has come out of this conference so far is that it's a wonderful chance to come together and for people to see one another. It's, it's been a long time that we've kind of had that opportunity to be able to interact with folks or you know, it's just a couple months since last Cube Con. But this is truly a different vibe and it's nice to have that focus on security. We're seeing a lot of folks within different organizations work through different problems and then finally have a vendor neutral space in which to talk about all of those contexts and really raise everybody up with all this new knowledge and new talking points, topics, and different facets of knowledge. >> John: Taylor, we were joking on our yesterday's summary of the keynotes, Dave Vellante and I, and the guests, Lisa and I, about the CNCF having an event operating system, you know, very decoupled highly cohesive events, strung together beautifully through the Linux Foundation, you know, kind of tongue in cheek but it was kind of fun to play on words because it's a very technical community. But the business model of, of hackers is booming. The reality of businesses booming and Cloud Native is the preferred developer environment for the future application. So the emphasis, it's very clear that this is a good move to do and targeting the community around security's a solid move. Amazon's done it with reinforce and reinvent. We see that Nice segmentation. What's the goal? Because this is really where it connects to Cube Con and Cloud Native Con as well because this shift left there too. But here it's very much about hardcore Cloud Native security. What's your positioning on this? Am I getting it right or is there is that how you guys see it? >> Taylor: Yeah, so, so that's what we've see that's what we were talking about as well as we were thinking on breaking this event out. So originally this event was a co-located event during the Cube Con windows in both Europe and North America. And then it just was so consistently popular clearly a topic that people wanted to talk, which is good that people want to talk of security. And so when we saw this massive continued kind of engagement, we wanted to break this off into its own conference. When we were going through that process internally, like you had mentioned the events team is just phenomenal to work with and they, I love how easy that they make it for us to be able to do these kinds of events too though we wanted to talk through how we differentiate this event from others and really what's changed for us and kind of how we see this space is that we didn't really see any developer-centric open source kinds of conferences. Ones that were really favoring of the developer and focus on APIs and ways in which to implement these things across all of your workloads within your organization. So that's truly what we're looking to go for here during these, all of these sessions. And that's how it's been playing out so far which has been really great to see. >> John: Taylor, I want to ask you on the ecosystem obviously the built-in ecosystem at CNCF.IO with Cube Cons Cloud Cons there, this is a new ecosystem opportunity to add more people that are security focused. Is their new entrance coming into the fold and what's been the reaction? >> Taylor: So short answer is yes we've seen a huge uptick across our vendor members and those are people that are creating Cloud offerings and selling those and working with others to implement them as well as our end users. So people consuming Cloud Native projects and using them to power core parts of their business. We have gotten a lot of data from groups like IBM and security, IBM security and put 'em on institute. They gave us a cost of data breach report that Priyanka mentioned and talked about 43% of those organizations haven't started or in the early stages of updating security practices of their cloud environments and then here on the ground, you know, talking through some best practices and really sharing those out as well. So it's, I've gotten to hear pieces and parts of different conversations and and I'm certain we'll hear more about those soon but it's just really been great to, to hear everybody with that main focus of, hey, there's more that we can do within the security space and you know, let's let's help one another out on that front just because it is such a vast landscape especially in the security space. >> Lisa: It's a huge landscape. And to your point earlier, Taylor it's everyone has the feeling that it's just so great to be back together again getting folks out of the silos that they've been operating in for such a long time. But I'd love to get some of your, whatever you can share in terms of some of the Cloud Native security projects that you've heard about over the last day or so. Anything exciting that you think is really demonstrating the value already and this inaugural event? >> Taylor: Yes, so I I've been really excited to hear a lot of, personally I've really liked the talks around EBPF. There are a whole bunch of projects utilizing that as far as runtime security goes and actually getting visibility into your workloads and being able to see things that you do expect and things that you don't expect and how to remediate those. And then I keep hearing a lot of talks about open policy agents and projects like Caverno around you know, how do we actually automate different policies or within regulated industries, how do we actually start to solve those problems? So I've heard even more around CNCF projects and other contexts that have come up but truly most of them have been around the telemetry space EBPF and, and quite a few others. So really great to, to see all those projects choosing something to bind to and making it that much more accessible for folks to implement or build on top of as well. >> John: I love the reference you guys had just the ChatGPT that was mentioned in the keynote yesterday and also the reference to Dan Kaminsky who was mentioned on the reference to DNS and Bind, lot of root level security going on. It seems like this is like a Tiger team event where all the top alpha security gurus come together, Priyanka said, experts bottoms up, developer first practitioners, that's the vibe. Is that kind of how you guys want it to be more practitioners hardcore? >> Taylor: Absolutely, absolutely. I think that when it comes to security, we really want to help. It's definitely a grassroots movement. It's great to have the people that have such a deep understanding of certain security, just bits of knowledge really when it comes to EBPF. You know, we have high surveillance here that we're talking things through. Falco is here with Sysdig and so it it's great to have all of these people here, though I have seen a good spread of folks that are, you know, most people have started their security journey but they're not where they want to be. And so people that are starting at a 2 0 1, 3 0 1, 4 0 1 level of understanding definitely seeing a good spread of knowledge on that front. But it's really, it's been great to have folks from all varying experiences, but then to have the expertise of the folks that are writing these specifications and pushing the boundaries of what's possible with security to to ensure that we're all okay and updated on that front too, I think was most notable yesterday. Like you had said >> Lisa: Sorry Taylor, when we think of security, again this is an issue that, that organizations in every industry face, nobody is immune to this. We can talk about the value in it for the hackers in terms of ransomware alone for example. But you mentioned a stat that there's a good amount of organizations that are really either early in their security journeys or haven't started yet which kind of sounds a bit scary given the landscape and how much has changed in the last couple of years. But it sounds like on the good news front it isn't too late for organizations. Talk a little bit about some of the recommendations and best practices for those organizations who are behind the curve knowing that the next attack is going to happen. >> Taylor: Absolutely. So fantastic question. I think that when it comes to understanding the fact that people need to implement security and abide by best practices, it's like I I'm sure that many of us can agree on that front, you know, hopefully all of us. But when it comes to actually implementing that, that's I agree with you completely. That's where it's really difficult to find where where do I start, where do I actually look at? And there are a couple of answers on that front. So within the CNTF ecosystem we have a technical action group security, so tag security and they have a whole bunch of working groups that cover different facets of the Cloud Native experience. So if you, for example, are concerned about runtime security or application delivery concerns within there, those are some really good places to find people knowledgeable about, that even when the conference isn't going on to get a sense of what's going on. And then TAG security has also published recently version two of their security report which is free accessible online. They can actually look through that, see what some of the recent topics are and points of focus and of interest are within our community. There are also other organizations like Open SSF which is taking a deeper dive into security. You know, initially kind of having a little bit more of an academic focus on that space and then now getting further into things around software bill materials or SBOMs supply chain security and other topics as well. >> John: Well we love you guys doing this. We think it's very big deal. We think it's important. We're starting to see events post COVID take a certain formation, you know joking aside about the event operating systems smaller events are happening, but they're tied together. And so this is key. And of course the critical need is our businesses are under siege with threats, ransomware, security challenges, that's IT moves to Cloud Native, not everyone's moved over yet. So that's in progress. So there's a huge business imperative and the hackers have a business model. So this isn't like pie in the sky, this is urgent. So, that being said, how do you see this developing from who should attend the next one or who are you looking for to be involved to get input from you guys are open arms and very diverse and great great culture there, but who are you looking for? What's the makeup persona that you hope to attract and nurture and grow? >> Taylor: Absolutely. I, think that when it comes to trying the folks that we're looking for the correct answer is it varies you know, from, you know, you're asking Priyanka or our executive director or Chris Aniszczyk our CTO, I work mostly with the end users, so for me personally I really want to see folks that are operating within our ecosystem and actually pulling these down, these projects down and using them and sharing those stories. Because there are people creating these projects and contributing to them might not always have an idea of how they're used or how they can be exploited too. A lot of these groups that I work with like Mercedes or Intuit for example, they're out there in the world using these, these projects and getting a sense for, you know, what can come up. And by sharing that knowledge I think that's what's most important across the board. So really looking for those stories to be told and novel ways in which people are trying to exploit security and attacking the supply chain, or building applications, or just things we haven't thought about. So truly that that developer archetype is really helpful to have the consumers, the end users, the folks that are actually using these. And then, yeah, and I'm truly anywhere knowledgeable about security or that wants to learn more >> John: Super important, we're here to help you scale those stories up whatever you need, send them our way. We're looking forward to getting those. This is a super important movement getting the end users who are on the front lines bringing it back into the open, building, more software, making it secure and verified, all super important. We really appreciate the mission you guys are on and again we're here to help. So send those stories our way. >> Taylor: Cool, cool. We couldn't do it without you. Yeah, just everyone contributing, everyone sharing the news. This is it's people, people is the is the true operating system of our ecosystem. So really great to, really great to share. >> Lisa: That's such a great point Taylor. It is all about people. You talked about this event having a different vibe. I wanted to learn a little bit more about that as we, as we wrap up because there's so much cultural change that's required for organizations to evolve their security practices. And so people of course are at the center of culture. Talk a little bit about why that vibe is different and do you think that yeah, it's finally time. Everyone's getting on the same page here we're understanding, we're learning from each other. >> Taylor: Yes. So, so to kind of answer that, I think it's really a focus on, there's this term shift left and shift right. And talking about where do we actually put security in the mix as it comes to people adopting this and and figuring out where things go. And if you keep shifting at left, that meaning that the developers should care more deeply about this and a deeper understanding of all of these, you know, even if it's, even if they don't understand how to put it together, maybe understand a little bit about it or how these topics and, and facets of knowledge work. But you know, like with anything, if you shift everything off to one side or the other that's also not going to be efficient. You know, you want a steady stream of knowledge flowing throughout your whole organization. So I think that that's been something that has been a really interesting topic and, and hearing people kind of navigate and try to get through, especially groups that have had, you know, deployed an app and it's going to be around for 40 years as well. So I think that those are some really interesting and unique areas of focus that I've come up on the floor and then in a couple of the sessions here >> Lisa: There's got to be that, that balance there. Last question as we wrap the last 30 seconds or so what are you excited about given the success and the momentum of day one? What excites you about what's ahead for us on day two? >> Taylor: So on day two, I'm really, it's, there's just so many sessions. I think that it was very difficult for me to, you know pick which one I was actually going to go see. There are a lot of favorites that I had kind of doubled up at each of the time so I'm honestly going to be in a lot of the sessions today. So really excited about that. Supply chain security is definitely one that's close to my heart as well but I'm really curious to see what new topics, concepts or novel ideas people have to kind of exploit things. Like one for example is a package is out there it's called Browser Test but somebody came up with one called Bowser Test. Just a very simple misname and then when you go and run that it does a fake kind of like, hey you've been exploited and just even these incorrect name attacks. That's something that is really close and dear to me as well. Kind of hearing about all these wild things people wouldn't think about in terms of exploitation. So really, really excited to hear more stories on that front and better protect myself both at home and within the Cloud Community as I stand these things up. >> Lisa: Absolutely you need to clone yourself so that you can, there's so many different sessions. There needs to be multiple versions of Taylor that you can attend and then you can all get together and talk about and learn. But that's actually a really good problem to have as we mentioned when we started 72 sessions yesterday and today. Lots of great content. Taylor, we thank you for your participation. We thank you for bringing the vibe and the buzz of the event to us and we look forward as well to hearing and seeing what day two brings us today. Thank you so much for your time Taylor. >> Taylor: Thank you for having me. >> John: All right >> Lisa: Right, for our guest and John Furrier, I'm Lisa Martin. You're watching theCube's Day two coverage of Cloud Native Security Con 23. (energetic music plays)

(upbeat music) >> Hello, everyone, from Palo Alto, Lisa Martin here. This is The Cube's coverage of CloudNativeSecurityCon, the inaugural event. I'm here with John Furrier in studio. In Boston, Dave Vellante joins us, and our guest, Liz Rice, one of our alumni, is joining us from Seattle. Great to have everyone here. Liz is the Chief Open Source officer at Isovalent. She's also the Emeritus Chair Technical Oversight Committee at CNCF, and a co-chair of this new event. Everyone, welcome Liz. Great to have you back on theCUBE. Thanks so much for joining us today. >> Thanks so much for having me, pleasure. >> So CloudNativeSecurityCon. This is the inaugural event, Liz, this used to be part of KubeCon, it's now its own event in its first year. Talk to us about the importance of having it as its own event from a security perspective, what's going on? Give us your opinions there. >> Yeah, I think security was becoming so- at such an important part of the conversation at KubeCon, CloudNativeCon, and the TAG security, who were organizing the co-located Cloud Native Security Day which then turned into a two day event. They were doing this amazing job, and there was so much content and so much activity and so much interest that it made sense to say "Actually this could stand alone as a dedicated event and really dedicate, you know, all the time and resources of running a full conference, just thinking about cloud native security." And I think that's proven to be true. There's plenty of really interesting talks that we're going to see. Things like a capture the flag. There's all sorts of really good things going on this week. >> Liz, great to see you, and Dave, great to see you in Boston Lisa, great intro. Liz, you've been a CUBE alumni. You've been a great contributor to our program, and being part of our team, kind of extracting that signal from the CNCF cloud native world KubeCon. This event really kind of to me is a watershed moment, because it highlights not only security as a standalone discussion event, but it's also synergistic with KubeCon. And, as co-chair, take us through the thought process on the sessions, the experts, it's got a practitioner vibe there. So we heard from Priyanka early on, bottoms up, developer first. You know KubeCon's shift left was big momentum. This seems to be a breakout of very focused security. Can you share the rationale and the thoughts behind how this is emerging, and how you see this developing? I know it's kind of a small event, kind of testing the waters it seems, but this is really a directional shift. Can you share your thoughts? >> Yeah I'm just, there's just so many different angles that you can consider security. You know, we are seeing a lot of conversations about supply chain security, but there's also runtime security. I'm really excited about eBPF tooling. There's also this opportunity to talk about how do we educate people about security, and how do security practitioners get involved in cloud native, and how do cloud native folks learn about the security concepts that they need to keep their deployments secure. So there's lots of different groups of people who I think maybe at a KubeCon, KubeCon is so wide, it's such a diverse range of topics. If you really just want to focus in, drill down on what do I need to do to run Kubernetes and cloud native applications securely, let's have a really focused event, and just drill down into all the different aspects of that. And I think that's great. It brings the right people together, the practitioners, the experts, the vendors to, you know, everyone can be here, and we can find each other at a smaller event. We are not spread out amongst the thousands of people that would attend a KubeCon. >> It's interesting, Dave, you know, when we were talking, you know, we're going to bring you in real quick, because AWS, which I think is the bellweather for, you know, cloud computing, has now two main shows, AWS re:Invent and re:Inforce. Security, again, broken out there. you see the classic security events, RSA, Black Hat, you know, those are the, kind of, the industry kind of mainstream security, very wide. But you're starting to see the cloud native developer first with both security and cloud native, kind of, really growing so fast. This is a major trend for a lot of the ecosystem >> You know, and you hear, when you mention those other conferences, John you hear a lot about, you know, shift left. There's a little bit of lip service there, and you, we heard today way more than lip service. I mean deep practitioner level conversations, and of course the runtime as well. Liz, you spent a lot of time obviously in your keynote on eBPF, and I wonder if you could share with the audience, you know, why you're so excited about that. What makes it a more effective tool compared to other traditional methods? I mean, it sounds like it simplifies things. You talked about instrumenting nodes versus workloads. Can you explain that a little bit more detail? >> Yeah, so with eBPF programs, we can load programs dynamically into the kernel, and we can attach them to all kinds of different events that could be happening anywhere on that virtual machine. And if you have the right knowledge about where to hook into, you can observe network events, you can observe file access events, you can observe pretty much anything that's interesting from a security perspective. And because eBPF programs are living in the kernel, there's only one kernel shared amongst all of the applications that are running on that particular machine. So you don't- you no longer have to instrument each individual application, or each individual pod. There's no more need to inject sidecars. We can apply eBPF based tooling on a per node basis, which just makes things operationally more straightforward, but it's also extremely performant. We can hook these programs into events that typically very lightweight, small programs, kind of, emitting an event, making a decision about whether to drop a packet, making a decision about whether to allow file access, things of that nature. There's super fast, there's no need to transition between kernel space and user space, which is usually quite a costly operation from performance perspective. So eBPF makes it really, you know, it's taking the security tooling, and other forms of tooling, networking and observability. We can take these tools into the kernel, and it's really efficient there. >> So Liz- >> So, if I may, one, just one quick follow up. You gave kind of a space age example (laughs) in your keynote. When, do you think a year from now we'll be able to see, sort of, real world examples in in action? How far away are we? >> Well, some of that is already pretty widely deployed. I mean, in my keynote I was talking about Cilium. Cilium is adopted by hundreds of really big scale deployments. You know, the users file is full of household names who've been using cilium. And as part of that they will be using network policies. And I showed some visualizations this morning of network policy, but again, network policy has been around, pretty much since the early days of Kubernetes. It can be quite fiddly to get it right, but there are plenty of people who are using it at scale today. And then we were also looking at some runtime security detections, seeing things like, in my example, exfiltrating the plans to the Death Star, you know, looking for suspicious executables. And again, that's a little bit, it's a bit newer, but we do have people running that in production today, proving that it really does work, and that eBPF is a scalable technology. It's, I've been fascinated by eBPF for years, and it's really amazing to see it being used in the real world now. >> So Liz, you're a maintainer on the Cilium project. Talk about the use of eBPF in the Cilium project. How is it contributing to cloud native security, and really helping to change the dials on that from an efficiency, from a performance perspective, as well as a, what's in it for me as a business perspective? >> So Cilium is probably best known as a networking plugin for Kubernetes. It, when you are running Kubernetes, you have to make a decision about some networking plugin that you're going to use. And Cilium is, it's an incubating project in the CNCF. It's the most mature of the different CNIs that's in the CNCF at the moment. As I say, very widely deployed. And right from day one, it was based on eBPF. And in fact some of the people who contribute to the eBPF platform within the kernel, are also working on the Cilium project. They've been kind of developed hand in hand for the last six, seven years. So really being able to bring some of that networking capability, it required changes in the kernel that have been put in place several years ago, so that now we can build these amazing tools for Kubernetes operators. So we are using eBPF to make the networking stack for Kubernetes and cloud native really efficient. We can bypass some of the parts of the network stack that aren't necessarily required in a cloud native deployment. We can use it to make these incredibly fast decisions about network policy. And we also have a sub-project called Tetragon, which is a newer part of the Cilium family which uses eBPF to observe these runtime events. The things like people opening a file, or changing the permissions on a file, or making a socket connection. All of these things that as a security engineer you are interested in. Who is running executables who is making network connections, who's accessing files, all of these operations are things that we can observe with Cilium Tetragon. >> I mean it's exciting. We've chatted in the past about that eBPF extended Berkeley Packet Filter, which is about the Linux kernel. And I bring that up Liz, because I think this is the trend I'm trying to understand with this event. It's, I hear bottoms up developer, developer first. It feels like it's an under the hood, infrastructure, security geek fest for practitioners, because Brian, in his keynote, mentioned BIND in reference the late Dan Kaminsky, who was, obviously found that error in BIND at the, in DNS. He mentioned DNS. There's a lot of things that's evolving at the silicone, kernel, kind of root levels of our infrastructure. This seems to be a major shift in focus and rightfully so. Is that something that you guys talk about, or is that coincidence, or am I just overthinking this point in terms of how nerdy it's getting in terms of the importance of, you know, getting down to the low level aspects of protecting everything. And as we heard also the quote was no software secure. (Liz chuckles) So that's up and down the stack of the, kind of the old model. What's your thoughts and reaction to that? >> Yeah, I mean I think a lot of folks who get into security really are interested in these kind of details. You know, you see write-ups of exploits and they, you know, they're quite often really involved, and really require understanding these very deep detailed technical levels. So a lot of us can really geek out about the details of that. The flip side of that is that as an application developer, you know, as- if you are working for a bank, working for a media company, you're writing applications, you shouldn't have to be worried about what's happening at the kernel level. This might be kind of geeky interesting stuff, but really, operationally, it should be taken care of for you. You've got your work cut out building business value in applications. So I think there's this interesting, kind of dual track going on almost, if you like, of the people who really want to get involved in those nitty gritty details, and understand how the underlying, you know, kernel level exploits maybe working. But then how do we make that really easy for people who are running clusters to, I mean like you said, nothing is ever secure, but trying to make things as secure as they can be easily, and make things visual, make things accessible, make things, make it easy to check whether or not you are compliant with whatever regulations you need to be compliant with. That kind of focus on making things usable for the platform team, for the application developers who deliver apps on the platform, that's the important (indistinct)- >> I noticed that the word expert was mentioned, I mentioned earlier with Priyanka. Was there a rationale on the 72 sessions, was there thinking around it or was it kind of like, these are urgent areas, they're obvious low hanging fruit. Was there, take us through the selection process of, or was it just, let's get 72 sessions going to get this (Liz laughs) thing moving? >> No, we did think quite carefully about how we wanted to, what the different focus areas we wanted to include. So we wanted to make sure that we were including things like governance and compliance, and that we talk about not just supply chain, which is clearly a very hot topic at the moment, but also to talk about, you know, threat detection, runtime security. And also really importantly, we wanted to have space to talk about education, to talk about how people can get involved. Because maybe when we talk about all these details, and we get really technical, maybe that's, you know, a bit scary for people who are new into the cloud native security space. We want to make sure that there are tracks and content that are accessible for newcomers to get involved. 'Cause, you know, given time they'll be just as excited about diving into those kind of kernel level details. But everybody needs a place to start, and we wanted to make sure there were conversations about how to get started in security, how to educate other members of your team in your organization about security. So hopefully there's something for everyone. >> That education piece- >> Liz, what's the- >> Oh sorry, Dave. >> What the buzz on on AI? We heard Dan talk about, you know, chatGPT, using it to automate spear phishing. There's always been this tension between security and speed to market, but CISOs are saying, "Hey we're going to a zero trust architecture and that's helping us move faster." Will, in your, is the talk on the floor, AI is going to slow us down a little bit until we figure it out? Or is it actually going to be used as an offensive defensive tool if I can use that angle? >> Yeah, I think all of the above. I actually had an interesting chat this morning. I was talking with Andy Martin from Control Plane, and we were talking about the risk of AI generated code that attempts to replicate what open source libraries already do. So rather than using an existing open source package, an organization might think, "Well, I'll just have my own version, and I'll have an AI write it for me." And I don't, you know, I'm not a lawyer so I dunno what the intellectual property implications of this will be, but imagine companies are just going, "Well you know, write me an SSL library." And that seems terrifying from a security perspective, 'cause there could be all sorts of very slightly different AI generated libraries that pick up the same vulnerabilities that exist in open source code. So, I think we're going to go through a pretty interesting period of vulnerabilities being found in AI generated code that look familiar, and we'll be thinking "Haven't we seen these vulnerabilities before? Yeah, we did, but they were previously in handcrafted code and now we'll see the same things being generated by AI." I mean, in the same way that if you look at an AI generated picture and it's got I don't know, extra fingers, or, you know, extra ears or something that, (Dave laughs) AI does make mistakes. >> So Liz, you talked about the education, the enablement, the 72 sessions, the importance of CloudNativeSecurityCon being its own event this year. What are your hopes and dreams for the practitioners to be able to learn from this event? How do you see the event as really supporting the growth, the development of the cloud native security community as a whole? >> Yeah, I think it's really important that we think of it as a Cloud Native Security community. You know, there are lots of interesting sort of hacker community security related community. Cloud native has been very community focused for a long time, and we really saw, particularly through the tag, the security tag, that there was this growing group of people who were, really wanted to work at that intersection between security and cloud native. And yeah, I think things are going really well this week so far, So I hope this is, you know, the first of many additions of this conference. I think it will also be interesting to see how the balance between a smaller, more focused event, compared to the giant KubeCon and cloud native cons. I, you know, I think there's space for both things, but whether or not there will be other smaller focus areas that want to stand alone and justify being able to stand alone as their own separate conferences, it speaks to the growth of cloud native in general that this is worthwhile doing. >> Yeah. >> It is, and what also speaks to, it reminds me of our tagline here at theCUBE, being able to extract the signal from the noise. Having this event as a standalone, being able to extract the value in it from a security perspective, that those practitioners and the community at large is going to be able to glean from these conversations is something that will be important, that we'll be keeping our eyes on. >> Absolutely. Makes sense for me, yes. >> Yeah, and I think, you know, one of the things, Lisa, that I want to get in, and if you don't mind asking Dave his thoughts, because he just did a breaking analysis on the security landscape. And Dave, you know, as Liz talking about some of these root level things, we talk about silicon advances, powering machine learning, we've been covering a lot of that. You've been covering the general security industry. We got RSA coming up reinforced with AWS, and as you see the cloud native developer first, really driving the standards of the super cloud, the multicloud, you're starting to see a lot more application focus around latency and kind of controlling that, These abstraction layer's starting to see a lot more growth. What's your take, Dave, on what Liz and- is talking about because, you know, you're analyzing the horses on the track, and there's sometimes the old guard security folks, and you got open source continuing to kick butt. And even on the ML side, we've been covering some of these foundation models, you're seeing a real technical growth in open source at all levels and, you know, you still got some proprietary machine learning stuff going on, but security's integrating all that. What's your take and your- what's your breaking analysis on the security piece here? >> I mean, to me the two biggest problems in cyber are just the lack of talent. I mean, it's just really hard to find super, you know, deep expertise and get it quickly. And I think the second is it's just, it's so many tools to deal with. And so the architecture of security is just this mosaic and a mess. That's why I'm excited about initiatives like eBPF because it does simplify things, and developers are being asked to do a lot. And I think one of the other things that's emerging is when you- when we talk about Industry 4.0, and IIoT, you- I'm seeing a lot of tools that are dedicated just to that, you know, slice of the world. And I don't think that's the right approach. I think that there needs to be a more comprehensive view. We're seeing, you know, zero trust architectures come together, and it's going to take some time, but I think that you're going to definitely see, you know, some rethinking of how to architect security. It's a game of whack-a-mole, but I think the industry is just- the technology industry is doing a really really good job of, you know, working hard to solve these problems. And I think the answer is not just another bespoke tool, it's a broader thinking around architectures and consolidating some of those tools, you know, with an end game of really addressing the problem in a more comprehensive fashion. >> Liz, in the last minute or so we have your thoughts on how automation and scale are driving some of these forcing functions around, you know, taking away the toil and the muck around developers, who just want stuff to be code, right? So infrastructure as code. Is that the dynamic here? Is this kind of like new, or is it kind of the same game, different kind of thing? (chuckles) 'Cause you're seeing a lot more machine learning, a lot more automation going on. What's, is that having an impact? What's your thoughts? >> Automation is one of the kind of fundamental underpinnings of cloud native. You know, we're expecting infrastructure to be written as code, We're expecting the platform to be defined in yaml essentially. You know, we are expecting the Kubernetes and surrounding tools to self-heal and to automatically scale and to do things like automated security. If we think about supply chain, you know, automated dependency scanning, think about runtime. Network policy is automated firewalling, if you like, for a cloud native era. So, I think it's all about making that platform predictable. Automation gives us some level of predictability, even if the underlying hardware changes or the scale changes, so that the application developers have something consistent and standardized that they can write to. And you know, at the end of the day, it's all about the business applications that run on top of this infrastructure >> Business applications and the business outcomes. Liz, we so appreciate your time talking to us about this inaugural event, CloudNativeSecurityCon 23. The value in it for those practitioners, all of the content that's going to be discussed and learned, and the growth of the community. Thank you so much, Liz, for sharing your insights with us today. >> Thanks for having me. >> For Liz Rice, John Furrier and Dave Vellante, I'm Lisa Martin. You're watching the Cube's coverage of CloudNativeSecurityCon 23. (electronic music)

(upbeat music) >> Hello, welcome everyone to "theCUBE" presentation of the AWS Startup Showcase, this is Season Two, Episode Four of the ongoing series covering exciting startups from the AWS ecosystem. Here to talk about Cyber Security. I'm your host John Furrier here joined by two great "CUBE" alumnus, Liz Rice who's the chief open source officer at Isovalent, and Mark Nunnikhoven who's the distinguished cloud strategist at Lacework. Folks, thanks for joining me today. >> Hi. Pleasure. >> You're in the U.K. Mark, welcome back to the U.S, I know you were overseas as well. Thanks for joining in this panel to talk about set the table for the Cybersecurity Showcase. You guys are experts out in the field. Liz we've had many conversations with the rise of open source, and all the innovations coming from out in the open source community. Mark, we've been going and covering the events, looking at all the announcements we're kind of on this next generation security conversation. It's kind of a do over in progress, happening every time we talk security in the cloud, is what people are are talking about. Amazon Web Services had reinforced, which was more of a positive vibe of, Hey, we're all on it together. Let's participate, share information. And they talk about incidents, not breaches. And then, you got Black Hat just happened, and they're like, everyone's getting hacked. It's really interesting as we report that. So, this is a new market that we're in. People are starting to think differently, but still have to solve the same problems. How do you guys see the security in the cloud era unfolding? >> Well, I guess it's always going to be an arms race. Isn't it? Everything that we do to defend cloud workloads, it becomes a new target for the bad guys, so this is never going to end. We're never going to reach a point where everything is completely safe. But I think there's been a lot of really interesting innovations in the last year or two. There's been a ton of work looking into the security of the supply chain. There's been a ton of new tooling that takes advantage of technology that I'm really involved with and very excited about called eBPF. There's been a continuation of this new generation of tooling that can help us observe when security issues are happening, and also prevent malicious activities. >> And it's on to of open source activity. Mark, scale is a big factor now, it's becoming a competitive advantage on one hand. APIs have made the cloud great. Now, you've got APIs being hacked. So, all the goodness of cloud has been great, but now we've got next level scale, it's hard to keep up with everything. And so, you start to see new ways of doing things. What's your take? >> Yeah, it is. And everything that's old is new again. And so, as you start to see data and business workloads move into new areas, you're going to see a cyber crime and security activity move with them. And I love, Liz calling out eBPF and open source efforts because what we've really seen to contrast that sort of positive and negative attitude, is that as more people come to the security table, as more developers, as more executives are aware, and the accessibility of these great open source tools, we're seeing that shift in approach of like, Hey, we know we need to find a balance, so let's figure out where we can have a nice security outcome and still meet our business needs, as opposed to the more, let's say to be polite, traditional security view that you see at some other events where it's like, it's this way or no way. And so, I love to see that positivity and that collaboration happening. >> You know, Liz, this brings up a good point. We were talking at our Super Cloud Event we had here when we were discussing the future of how cloud's emerging. One of the conversations that Adrian Cockcroft brought up, who's now retired from AWS, former with Netflix. Adrian being open source fan as well. He was pointing out that every CIO or CISO will buy an abstraction layer. They love the dream. And vendors sell the dream, so to speak. But the reality it's not a lot of uptake because it's complex, And there's a lot of non-standard things per vendor. Now, we're in an era where people are looking for some standardization, some clean, safe ways to deploy. So, what's the message to CSOs, and CIOs, and CXOs out there around eBPF, things like that, that are emerging? Because it's almost top down, was the old way, now as bottoms up with open source, you're seeing the shift. I mean, it's complete flipping the script of how companies are buying? >> Yeah. I mean, we've seen with the whole cloud native movement, how people are rather than having like ETF standards, we have more of a defacto collaborative, kind of standardization process going on. So, that things like Kubernetes become the defacto standard that we're all using. And then, that's helping enterprises be able to run their workloads in different clouds, potentially in their own data centers as well. We see things like EKS anywhere, which is allowing people to run their workloads in their data center in exactly the same way as they're running it in AWS. That sort of leveling of the playing field, if you like, can help enterprises apply the same tooling, and that's going to always help with security if you can have a consistent approach wherever you are running your workload. >> Well, Liz's take a minute to explain eBPF. The Berkeley packet filtering technology, people know from Trace Dumps and whatnot. It's kind of been around for a while, but what is it specifically? Can you take a minute to explain eBPF, and what does that mean for the customer? >> Yeah. So, you mentioned the packet filtering acronym. And honestly, these days, I tell people to just forget that, because it means so much more for. What eBPF allows you to do now, is to run custom programs inside the kernel. So, we can use that to change the way that the kernel behaves. And because the kernel has visibility over every process that's running across a machine, a virtual machine or a bare metal machine, having security tooling and observability tooling that's written using eBPF and sitting inside the kernel. It has this great perspective and ability to observe and secure what's happening across that entire machine. This is like a step change in the capabilities really of security tooling. And it means we don't have to rely on things like kernel modules, which traditionally people have been quite worried about with good reason. eBPF is- >> From a vulnerability standpoint, you mean, right? From a reliability. >> From a vulnerability standpoint, but even just from the point of view that kernel modules, if they have bugs in them, a bug in the kernel will bring the machine to a halt. And one of the things that's different with eBPF, is eBPF programs go through a verification process that ensures that they're safe to run that, but happens dynamically and ensures that the program cannot crash, will definitely run to completion. All the memory access is safe. It gives us this very sort of reassuring platform to use for building these kernel-based tools. >> And what's the bottom line for the customer and the benefit to the organization? >> I think the bottom line is this new generation of really powerful tools that are very high performance. That have this perspective across the whole set of workloads on a machine. That don't need to rely on things like a CCAR model, which can add to a lot of complexity that was perfectly rational choice for a lot of security tools and observability tools. But if you can use an abstraction that lives in the kernel, things are much more efficient and much easier to deploy. So, I think that's really what that enterprise is gaining, simpler to deploy, easier to manage, lower overhead set of tools. >> That's the dream they want. That's what they want. Mark, this is whether the trade offs that comes up. We were talking about the supercloud, and all kinds. Even at AWS, you're going to have supercloud, but you got super hackers as well. As innovation happens on one side, the hackers are innovating on the other. And you start to see a lot of advances in the lower level, AWS with their Silicon and strategies are continuing to happen and be stronger, faster, cheaper, better down the lower levels at the network lay. All these things are innovating, but this is where the hackers are going too, right? So, it's a double edge sword? >> Yeah, and it always will be. And that's the challenge of technology, is sort of the advancement for one, is an advancement for all. But I think, while Liz hit the technical aspects of the eBPF spot on, what I'm seeing with enterprises, and in general with the market movement, is all of those technical advantages are increasing the confidence in some of this security tooling. So, the long sort of anecdote or warning in security has always been things like intrusion prevention systems where they will look at network traffic and drop things they think bad. Well, for decades, people have always deployed them in detect-only mode. And that's always a horrible conversation to have with the board saying, "Well, I had this tool in place that could have stopped the attack, but I wasn't really confident that it was stable enough to turn on. So, it just warned me that it had happened after the fact." And with the stability and the performance that we're seeing out of things based on technologies like eBPF, we're seeing that confidence increase. So, people are not only deploying this new level of tooling, but they're confident that it's actually providing the security it promised. And that's giving, not necessarily a leg up, but at least that level of parody with that push forward that we're seeing, similar on the attack side. Because attackers are always advancing as well. And I think that confidence and that reliability on the tooling, can't be underestimated because that's really what's pushing things forward for security outcomes. >> Well, one of the things I want get your both perspective on real quick. And you kind of segue into this next set of conversations, is with DevOps success, Dev and Ops, it's kind of done, right? We're all happy. We're seeing DevOps being so now DevSecOps. So, CSOs were like kind of old school. Buy a bunch of tools, we have a vendor. And with cloud native, Liz, you mentioned this earlier, accelerating the developers are even driving the standards more and more. So, shifting left is a security paradigm. So, tooling, Mark, you're on top of this too, it's tooling versus how do I organize my team? What are the processes? How do I keep the CICD pipeline going, higher velocity? How can I keep my app developers programming faster? And as Adrian Cockcroft said, they don't really care about locking, they want to go faster. It's the ops teams that have to deal with everything. So, and now security teams have to deal with the speed and velocity. So, you're seeing a new kind of step function, ratchet game where ops and security teams who are living DevOps, are still having to serve the devs, and the devs need more help here. So, how do you guys see that dynamic in security? Because this is clearly the shift left's, cloud native trend impacting the companies. 'Cause now it's not just shifting left for developers, it has a ripple effect into the organization and the security posture. >> We see a lot of organizations who now have what they would call a platform team. Which is something similar to maybe what would've been an ops team and a security team, where really their role is to provide that platform that developers can use. So, they can concentrate on the business function that they don't have to really think about the underlying infrastructure. Ideally, they're using whatever common definition for their applications. And then, they just roll it out to a cloud somewhere, and they don't have to think about where that's operating. And then, that platform team may have remit that covers, not just the compute, but also the networking, the common set of tooling that allows people to debug their applications, as well as securing them. >> Mark, this is a big discussion because one, I love the team, process collaboration. But where's the team? We've got a skills gap going on too, right? So, in all this, there's a lot of action happening. What's your take on this dynamic of tooling versus process collaboration for security success? >> Yeah, it's tough. And I think what we're starting to see, and you called it out spot on, is that the developers are all about dynamic change and rapid change, and operations, and security tend to like stability, and considered change in advance. And the business needs that needle to be threaded. And what we're seeing is sort of, with these new technologies, and with the ideas of finally moving past multicloud, into, as you guys call supercloud, which I absolutely love is a term. Let's get the advantage of all these things. What we're seeing, is people have a higher demand for the outputs from their tooling, and to find that balance of the process. I think it's acknowledged now that you're not going to have complete security. We've gotten past that, it's not a yes or no binary thing. It's, let's find that balance in risk. So, if we are deploying tooling, whether that's open source, or commercial, or something we built ourselves, what is the output? And who is best to take action on that output? And sometimes that's going to be the developers, because maybe they can just fix their architecture so that it doesn't have a particular issue. Sometimes that's going to be those platform teams saying like, "Hey, this is what we're going to apply for everybody, so that's a baseline standard." But the good news, is that those discussions are happening. And I think people are realizing that it's not a one size-fits-all. 10 years ago was sort of like, "Hey, we've got a blueprint and everyone does this." That doesn't work. And I think that being out in the open, really helps deliver these better outcomes. And because it isn't simple, it's always going to be an ongoing discussion. 'Cause what we decide today, isn't going to be the same thing in a week from now when we're sprint ahead, and we've made a whole bunch of changes on the platform and in our code. >> I think the cultural change is real. And I think this is hard for security because you got so much current action happening that's really important to the business. That's hard to just kind of do a reset without having any collateral damage. So, you kind of got to mitigate and manage all the current situation, and then try to build a blueprint for the future and transform into a kind of the next level. And it kind of reminds me of, I'm dating myself. But back in the days, you had open source was new. And the common enemy was proprietary, non-innovative old guard, kind of mainframe mini computer kind of proprietary analysis, proprietary everything. Here, there is no enemy. The clouds are doing great, right? They're leaning in open source is at all time high and not stopping, it's it's now standard. So, open is not a rebel. It's not the rebel anymore, it's the standard. So, you have the innovation happening in open source, Liz, and now you have large scale cloud. And this is a cultural shift, right? How people are buying, evaluating product, and implementing solutions. And I when I say new, I mean like new within the decades or a couple decades. And it's not like open source is not been around. But like we're seeing new things emerge that are pretty super cool in the sense that you have projects defining standards, new things are emerging. So, the CIO decision making process on how to structure teams and how to tackle security is changing. Why IT department? I mean, just have a security department and a Dev team. >> I think the fact that we are using so much more open source software is a big part of this cultural shift where there are still a huge ecosystem of vendors involved in security tools and observability tools. And Mark and I both represent vendors in those spaces. But the rise of open source tools, means that you can start with something pretty powerful that you can grow with. As you are experimenting with the security tooling that works for you, you don't have to pay a giant sum to get a sort of black box. You can actually understand the open source elements of the tooling that you are going to use. And then build on that and get the enterprise features when you need those. And I think that cultural change makes it much easier for people to work security in from the get go, and really, do that shift left that we've been talking about for the last few years. >> And I think one of the things to your point, and not only can you figure out what's in the open source code, and then build on top of it, you can also leave it too. You can go to something better, faster. So, the switching costs are a lot lower than a lock in from a vendor, where you do all the big POCs and the pilots. And, Mark, this is changing the game. I mean, I would just be bold enough to say, IT is going to be irrelevant in the sense of, if you got DevOps and it works, and you got security teams, do you really need IT 'cause the DevOps is the IT? So, if everyone goes to the cloud operations, what does IT even mean? >> Yeah, and it's a very valid point. And I think what we're seeing, is where IT is still being successful, especially in large companies, is sort of the economy of scale. If you have enough of the small teams doing the same thing, it makes sense to maybe take one tool and scale it up because you've got 20 teams that are using it. So, instead of having 20 teams run it, you get one team to run it. On the economic side, you can negotiate one contract if it's a purchase tool. There is still a place for it, but I think what we're seeing and in a very positive way, is that smaller works better when it comes to this. Because really what the cloud has done and what open source continues to do, is reduce the barrier to entry. So, a team of 10 people can build something that it took a 1000 people, a decade ago. And that's wonderful. And that opens up all these new possibilities. We can work faster. But we do need to rethink it at reinforce from AWS. They had a great track about how they're approaching it from people side of things with their security champion's idea. And it's exactly about this, is embedding high end security talent in the teams who are building it. So, that changes the central role, and the central people get called in for big things like an incident response, right? Or a massive auditor reviews. But the day-to-day work is being done in context. And I think that's the real key, is they've got the context to make smarter security decisions, just like the developers and the operational work is better done by the people who are actually working on the thing, as opposed to somebody else. Because that centralized thing, it's just communication overhead most of the time. >> Yeah. I love chatting with you guys because here's are so much experts on the field. To put my positive hat on around IT, remember the old argument of, "Oh, automation's, technology's going to kill the bank teller." There's actually more tellers now than ever before. So, the ATM machine didn't kill that. So, I think IT will probably reform from a human resource perspective. And I think this is kind of where the CSO conversation comes full circle, Liz and Mark, because, okay, let's assume that this continues the trajectory to open source, DevOps, cloud scale, hybrid. It's a refactoring of personnel. So, you're going to have DevOps driving everything. So, now the IT team becomes a team. So, most CSOs we talk to are CXOs, is how do I deploy my teams? How do I structure things, my investment in people, and machines and software in a way that I get my return? At the end of the day, that's what they live for, and do it securely. So, this is the CISO's kind of thought process. How do you guys react to that? What's the message to CISOs? 'Cause they have a lot of companies to look at here. And in the marketplace, they got to spend some money, they got to get a return, they got to reconfigure. What's your advice? Liz, what's your take? Then we'll go to Mark. >> That's a really great question. I think cloud skills, cloud engineering skills, cloud security skills have never been more highly valued. And I think investing in training people to understand cloud that there are tons of really great resources out there to help ramp people up on these skills. The CNCF, AWS, there's tons of organizations who have really great courses and exams, and things that people can do to really level up their skills, which is fantastic right from a grassroots level, through to the most widely deployed global enterprise. I think we're seeing a lot of people are very excited, develop these skills. >> Mark, what's your take for the CSO, the CXO out there? They're scratching their head, they're going, "Okay, I need to invest. DevOps is happening. I see the open source, I'm now got to change over. Yeah, I lift and shift some stuff, now I got to refactor my business or I'm dead." What's your advice? >> I think the key is longer term thinking. So, I think where people fell down previously, was, okay, I've got money, I can buy tools, roll 'em out. Every tool you roll out, has not just an economic cost, but a people cost. As Liz said, those people with those skills are in high demand. And so, you want to make sure that you're getting the most value out of your people, but your tooling. So, as you're investing in your people, you will need to roll out tools. But they're not the answer. The answer is the people to get the value out of the tools. So, hold your tools to a higher standard, whether that's commercial, open source, or something from the CSP, to make sure that you're getting actionable insights and value out of them that your people can actually use to move forward. And it's that balance between the two. But I love the fact that we're finally rotating back to focus more on the people. Because really, at the end of the day, that's what's going to make it all work. >> Yeah. The hybrid work, people processes. The key, the supercloud brings up the conversation of where we're starting to see maturation into OPEX models where CapEx is a gift from the clouds. But it's not the end of bilk. Companies are still responsible for their own security. At the end of the day, you can't lean on AWS or Azure. They have infrastructure and software, but at the end of the day, every company has to maintain their own. Certainly, with hybrid and edge coming, it's here. So, this whole concept of IT, CXO, CIO, CSO, CSO, I mean, this is hotter than ever in terms of like real change. What's your reaction to that? >> I was just reading this morning that the cost of ensuring against data breaches is getting dramatically more expensive. So, organizations are going to have to take steps to implement security. You can't just sort of throw money at the problem, you're going to actually have to throw people and technology at the problem, and take security really seriously. There is this whole ecosystem of companies and folks who are really excited about security and here to help. There's a lot of people interested in having that conversation to help those CSOs secure their deployments. >> Mark, your reaction? >> Yeah. I think, anything that causes us to question what we're doing is always a positive thing. And I think everything you brought up really comes down to remembering that no matter what, and no matter where, your data is always your data. And so, you have some level of responsibility, and that just changes depending on what system you're using. And I think that's really shifting, especially in the CSO or the CSO mindset, to go back to the basics where it used to be information security and not just cyber security. So, whether that information and that data is sitting on my desk physically, in a system in our data center, or in the cloud somewhere. Looking holistically, and that's why we could keep coming back to people. That's what it's all about. And when you step back there, you start to realize there's a lot more trade offs. There's a lot more levers that you can work on, to deliver the outcome you want, to find that balance that works for you. 'Cause at the end of the day, security is just all about making sure that whatever you built and the systems you're working with, do what you want them to do, and only what you want them to do. >> Well, Liz and Mark, thank you so much for your expert perspective. You're in the trenches, and really appreciate your time and contributing with "theCUBE," and being part of our Showcase. For the last couple of minutes, let's dig into some of the things you're working on. I know network policies around Kubernetes, Liz, EKS anywhere has been fabulous with Lambda and Serverless, you seeing some cool things go on there. Mark, you're at Lacework, very successful company. And looking at a large scale observability, signaling and management, all kinds of cool things around native cloud services and microservices. Liz, give us an update. What's going on over there at Isovalent? >> Yeah. So, Isovalent is the company behind Cilium Networking Project. Its best known as a Kubernetes networking plugin. But we've seen huge amount of adoption of cilium, it's really skyrocketed since we became an incubating project in the CNCF. And now, we are extending to using eBPF to not just do networking, but incredibly in depth observability and security observability have a new sub project called Tetragon, that gives you this amazing ability to see out of policy behavior. And again, because it's using eBPF, we've got the perspective of everything that's happening across the whole machine. So, I'm really excited about the innovations that are happening here. >> Well, they're lucky to have you. You've been a great contributor to the community. We've been following your career for very, very long time. And thanks for everything that you do, really appreciate it. Thanks. >> Thank you. >> Mark, Lacework, we we've following you guys. What are you up to these days? You know, we see you're on Twitter, you're very prolific. You're also live tweeting all the events, and with us as well. What's going on over there at Lacework? And what's going on in your world? >> Yeah. Lacework, we're still focusing on the customer, helping deliver good outcomes across cloud when it comes to security. Really looking at their environments and helping them understand, from their data that they're generating off their systems, and from the cloud usage as to what's actually happening. And that pairs directly into the work that I'm doing, the community looking at just security as a practice. So, a lot of that pulling people out of the technology, and looking at the process and saying, "Hey, we have this tech for a reason." So, that people understand what they need in place from a skill set, to take advantage of the great work that folks like Liz and the community are doing. 'Cause we've got these great tools, they're outputting all this great insights. You need to be able to take actions on top of that. So, it's always exciting. More people come into security with a security mindset, love it. >> Well, thanks so much for this great conversation. Every board should watch this video, every CSO, CIO, CSO. Great conversation, thanks for unpacking and making something very difficult, clear to understand. Thanks for your time. >> Pleasure. >> Thank you. >> Okay, this is the AWS Startup Showcase, Season Two, Episode Four of the ongoing series covering the exciting startups from the AWS ecosystem. We're talking about cybersecurity, this segment. Every quarter episode, we do a segment around a category and we go deep, we feature some companies, and talk to the best people in the industry to help you understand that. I'm John Furrier your host. Thanks for watching. (upbeat music)

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

(upbeat music playing) >> Narrator: From theCUBE's studios in Palo Alto in Boston, connecting with thought leaders all around the world. This is a CUBE conversation. >> Hello, everyone, welcome to this CUBE conversation. I'm John Ferry, host of theCUBE. We're doing a content series called leading with observability. And this segment is network observability for distributed services. And we have CUBE alumni Mike Cohen, head of product management for network monitoring at Splunk. Mike, great to see you. It's been a while, going back to the open stack days, red hat summit. Now here talking about observability with Splunk. Great to see you. >> Thanks a lot for having me. >> So the world's right now observability is at the center of all the conversations from monitoring, investing infrastructure, on premises cloud and also cyber security. A lot of conversations, a lot of, broad reaching implications observability. You're at the head of product management, network observability at Splunk. This is where the conversation's going getting down at the network layer, getting down into the, as the packets move around. This is becoming important. Why is this the trend? What's the situation? >> Yeah, so we're seeing a couple of different trends that are really driving how people think about observability, right? One of them is this huge migration towards public cloud architecture. And you're running, you're running on an infrastructure that you don't own yourself. The other one is around how people are rebuilding and refactoring applications around service-based architectures scale-out models, cloud native paradigms. And both of these things is, they're really introducing a lot of new complexity into the applications and really increasing the service area of where problems can occur. And what this means is when you actually have gaps in visibility or places where you have a separate tool, you know, analyzing parts of your system. It really makes it very hard to debug when things go wrong and to figure out where problems occur. And really what we've seen is that, you know people really need an integrated solution to observability. And one that can really span from what your user is seeing but all the way to the deepest backend services. Where are the problems in some of the core in your infrastructure that you're operating? So that you can really figure out where, where problems occur. And really network observability is playing a critical role in kind of filling in one of those critical gaps. >> You know, you think about the 10 years past decade we've been on this wave. It feels like now more than ever, it's an inflection point because of how awesome cloud native has become from a value standpoint. Value creation, time to market all those things that you know why people are investing in modern applications. But then as you build out your architecture and your, your infrastructure to make that happen there's more things happening. Everything as a service creates new dependencies new things to document. This is an opportunity, certainly on one hand on the other hand, it's a technical challenge. So, you know, balancing out, technical dead end or deploying new stuff, you got to monitor it all. Right, monitoring has turned into observability which is just code word for cloud scale monitoring, I guess. I mean, is that how you see it? I mean, how could you, how do you talk about this? Because it's certainly a major shift happening right now and this transition is pretty obvious. >> Yeah. Yeah, no, absolutely. And we've, you know, we've seen a lot of new interests into the network visibility, network monitoring space. And really, again, the drivers of that, like you know, network infrastructure is actually becoming increasingly opaque as you move towards, you know public cloud. You know, kind of public cloud environments. And it's been sort of a fun thing to blame the network. And say, look Oh it's the network we don't know what's going on. But you know, it's not always the network. Sometimes it is, sometimes it isn't. You actually need to understand where these problems are really occurring to actually have the right level of visibility in your systems. But the other way we've started talking to people thinking about this is. The network has an empowering capability an untapped resource. That you can actually get new data about your distributed systems. You know, SREs are struggling to understand these complex environments, but by. You know with the capabilities we've seen and started taking advantage of things like EBPF and monitoring from the OS. We can actually get visibility into how processes and containers communicate and that can give us insights into our system. It's a new source of data that actually has not existed in the past. That is now available to help us with the broader observability problem. >> You mentioned SRE, Site Reliable Engineers, as it's known Google kind of pioneered this. It's become a kind of a standard persona in large scale kind of infrastructure, cloud environments and what not like massive scale. Are you seeing SREs, now that role become more mainstream in enterprises? I mean, cause some enterprises might not call on the SRE medical on the cloud architect. I mean, what can you just help as you know, if you could tie that together cause it is certainly happening. Is it becoming a proliferating? >> For sure, absolutely Yeah. No absolutely, I think SREs, you know, the title may vary across organizations as you point out. And sometimes the exact layout of you know, the organizational breakdown varies. But this role of someone who really cares about keeping the system up you know, and you know, caring for it and scaling it out and thinking about its architecture is now a really critical role. And sometimes that role sits alongside, it sits alongside developers who are writing the code. And this is really happening in almost every organization that, that we're dealing with today. It is becoming a mainstream occurrence. >> Yeah, it's interesting, I'm going to ask you a question about what businesses are missing when they think about how to, think about observability but since you brought up that, that piece. It's almost as if kubernetes created this kind of demarcation between the line. Between half the stack and the top of the half and bottom half of the stack. Where you can do a lot of engineering underneath the second half of the stack or the bottom of the stack up to say kubernetes and then above that you could just be infrastructure as code application developer. So it's almost, it's almost kind of like leveled out with nice lanes there. I mean, I'm oversimplifying it, but I mean how do you react to that? Do you see that evolving too? Because it's all seems cleaner now. It's like you're engineering below Kubernetes or above it. >> Oh, absolutely. It's definitely one of the ways you see sort of the deepest engagement in. As folks go towards Kubernetes, they start embracing containers. They you know, they start building microservices. You'll see development teams really accelerate the pace of innovation that they have, you know, in in their environment. And that's really the, you know kind of the driver behind this. So, you know, we do see that, that sort of rebuilding refactoring as some of the most, some of the biggest drivers behind, these initiatives. >> What are businesses missing around observability? Cause it seems to be, first of all a very overfunded segment, a lot of new startups coming in. A lot of security vendors over here, you're seeing network folks moving in. What's almost becoming a fabric feature piece of things. What is that mean to businesses? What, what are businesses missing or getting? How are people evaluating observability? How do you see that? >> Yeah. So I'll, for sure, I'll talk. I'll start initially to talk generically about it but then I'll talk a little bit about network areas specifically, right? That's I think one of the, one of the things people are realizing they need in observability is this approach as an integrated suite. So having a disparate set of tools can make it very hard for SREs to actually take advantage of all those tools, use the data within them to solve meaningful problems. And I think what we're, you know, what we're seeing as we've been talking to more people in the industry. They really want something that can bring all that data together and build it into an insight that can help them solve a problem more quickly. Right, so that, you know, I think that's the broader context of what's going on. And I think that's driving some of the work we're doing on the network side. Because, network is a powerful new data set that we can combine with other aspects of what people have already been doing in observability. >> What do you think about programmability? That's been a big topic, when you start to get into that kind of mindset. You're almost making the the software defined aspect come in here heavily. How does that play in, how do you what's your vision around, you know making the network adaptable, programmable, measurable, fully, fully surveilled? >> Yeah, yeah. So I think we'll work, well again, what we're focused on is the capabilities you can have in using, using the network as a means of visibility and observability for, for its systems. Networks are becoming highly flexible. A lot of people, once they get into a cloud environment they have a very rich set of networking capabilities. But what they want to be able to do is use that as a way of getting visibility into the system. So, to talk for, I can talk for a minute or two about some of the capabilities we're exposing. Use it in network observer, network observability. One of them is just being able to visual, visualize and optimize a service architecture. So really seeing what's connecting to what automatically. So we've been using a technology called EBPF, the Extended Berkeley Packet Filter. Part of everyone's Linux operating system, right? You know, you're running Linux you basically have this already. And it gives you an interesting touch point to observe the behavior of every processing container automatically. When you can actually see, with very little overhead what they're doing and correlate that with data from systems like Kubernetes to understand how distributed systems behave. To see how things connect to two other things. We can use this to build a complete service map of the system in seconds, automatically without developers having to do any additional work. Without having, without forcing anyone to change their code. They can get visibility across an entire system automatically. >> That's like the original value proposition of Splunk. When it came out, it was just a great tool for Splunk and the data from logs. Now, as data becomes more complex you're still instrumenting and those are critical services. And they're now microservices, the trends at the top of the stack and on, at the network layer. The network layer has always been a hard nut to crack. I got to ask you why now? Why do you feel, you mentioned earlier that everyone used to blame the network. Oh, it's not my problem. You really can't finger point when you start getting into full instrumentation of the, of the traffic patterns and the underlying processes. So it seems to be good magic going on here. What's the core issue? What are the, what's the, what's going on here? Why is it, why is it now? >> Mike: Yeah. >> Why is the time now? >> Yeah. So, yeah, well. So unreliable networks, slow network, DNS problems. These have always been present in systems. The problem is they're actually becoming exacerbated because people have less visibility into, into them. But also as you have these distributed systems the failure modes are getting more complex. So you'll actually have some of the longest, most challenging troubleshooting problems are these network issues, which tend to be transient which tend to bounce around the systems. They tend to cause other unrelated alerts to happen. Inside your application stack with multiple teams, troubleshooting the wrong problems that don't really exist. So, the network has actually caused some of the most painful outages that the teams, the teams see. And when these outages happen, what you really need to be able to know is, is it truly a network problem or is it something in another part of my system? If I'm running a distributed service, what, you know, which services are affected? Because that's the language now my team thinks about. As you mentioned now, they're in kubernetes. They're trying to think which Kubernetes services are actually going, affected by a potential network outage that I'm worried about? The other aspect is figuring out the scope of the impact. So, are there a couple instances in my cloud provider that aren't doing well? Is an entire availability zone, having problems? Is there a region of the, of the world that, that's an issue? Understanding the scope of this problem will actually help me as an SRE decide what the right mitigation is. And, you know, and by limiting it as much as possible, it can actually help me better hit my SLA. Because I won't have to hit something with a huge hammer when a really small one might solve the problem. >> Yeah, this is one of the things that comes up. Almost just hearing you talk I'm seeing how it could be complex for the customer just documenting the dependencies. I mean, as services come online someone of them are going to be very dynamic not just at the network, both the application level, we mentioned Kubernetes. And you've got service meshes and microservices. You're going to start to see the need to be tracking all this stuff. And that's a big, that's a big part of what's going on with the, with your suite right now. The ability to help there. How are you guys helping people do that? >> Yeah, absolutely. So, you know, just understanding dependencies is, you know, is one of the key aspects of these distributed systems. You know, this began as a simple problem. You have a monolithic application it kind of runs on one machine. You understand its behavior. Once you start moving towards microservices it's very easy for that to change from. Look, we have a handful of microservices to we have hundreds, to we have thousands and they can be running across thousands or tens of thousands of machines as you get bigger. And understanding that environment can become a major challenge and teams' role. They'll end up with the handwritten diagram that has the behavior of their services broken out. Or they'll find out that there's an interaction that they didn't expect to have happened. And that may be the source of an issue. So, you know, one of the capabilities we have using network monitoring out of the operating system with EBPF. Is, we can actually automatically discover every connection that's made. So if you're able to watch the sockets they're created in licks, you can actually see how containers interact with each other. Then you can use that to build automatic service dependency diagrams. So without the user having to change the code, to change anything about their system. You can automatically discover those dependencies and you'll find things you didn't expect. You'll find things that change over time, that weren't well-documented. And these are the critical, the critical level of understanding you need to get to and use the environment. >> Yeah. You know, it's interesting you mentioned that you might've missed them in the past. People have that kind of feeling at the network either because they weren't tracking it well or they used a different network tool. I mean, just packet loss by itself is one, service and host health is another. And if you could track everything, then you got to build it. So I got, so I love, love this direction. My question really is more of, okay how do you operationalize it? Okay, I'm a operator, am I getting alerts? Do I, does it just auto discover? How does this all work from a user, usability standpoint? How do I? >> Yeah. >> What are the key features that unlock, what gets unlocked from that, that kind of instrumentation? >> Yeah, well again, when you do this estimation correctly. It can be really, it can be automatic, right? You can actually put an agent that might run in one of your, on your instances collecting data based on the, that the traffic and the interactions that occur without you having to take any action that's really the Holy grail. And that's where some of the best value of these systems emerge. It just works out of the box. And then it'll pull data from other systems like your cloud provider from your Kubernetes environment and use that to build a picture of what's going on. And that's really where this is, where these systems get super valuable is they actually just, they just work without you having to do a ton of work behind the scenes. >> So Mike, I got to ask you a final question. Explain the distributed services aspect of observability. What should people walk away with from a main concept standpoint and how does it apply to their environment? What should they be thinking about? What is it and what's the real story there? >> Yeah, so I think the way we're thinking about this is. How can you turn, the network from a liability to a strength in the, in your, in these distributed environments, right? So, what it can, you know, by observing data at the network level and, out of the operating system. You can actually use it to automatically construct service maps. To learn about your system, improve the insight and understanding you have of your, of your complex systems. You can identify network problems that are occurring. You can understand how you're utilizing aspects of the network. It can drive things like, costs, cost optimization in your environment. So you can actually get better insights and, be able to troubleshoot problems better and handle the blame game of, is the network really the problem that I'm seeing or is it occurring somewhere else in my application? And though, that's really critical in these complex distributed environments. And critically you can do it in a way that doesn't actually add overhead to your development team. You don't have to change the code. You don't have to, take on a complex engineering task. You just, you can actually deploy agents. that'll act, that'll be able to collect this data automatically. >> Awesome, and take that complexity away and automate, help people get the job done. Great, great stuff. Mike, thanks for coming on theCUBE. Leading with observability, I'm John Ferry with theCUBE. Thanks for watching. >> Mike: Yeah, thanks a lot. (gentle music playing)