(calm music) >> Hi everybody. We're here at VeeamON 2022. This is day two of the CUBE's continuous coverage. I'm Dave Vellante. My co-host is Dave Nicholson. A ton of energy. The keynotes, day two keynotes are all about products at Veeam. Veeam, the color of green, same color as money. And so, and it flows in this ecosystem. I'll tell you right now, Michael Cade is here. He's the senior technologist for product strategy at Veeam. Michael, fresh off the keynotes. >> Yeah, yeah. >> Welcome. Danny Allen's keynote was fantastic. I mean, that story he told blew me away. I can't wait to have him back. Stay tuned for that one. But we're going to talk about protecting containers, Kasten. You guys got announcements of Kasten by Veeam, you call it K10 version five, I think? >> Yeah. So just rolled into 5.0 release this week. Now, it's a bit different to what we see from a VBR release cycle kind of thing, cause we're constantly working on a two week sprint cycle. So as much as 5.0's been launched and announced, we're going to see that trickling out over the next couple of months until we get round to Cube (indistinct) and we do all of this again, right? >> So let's back up. I first bumped into Kasten, gosh, it was several years ago at VeeamON. Like, wow this is a really interesting company. I had deep conversations with them. They had a sheer, sheer cat grin, like something was going on and okay finally you acquire them, but go back a little bit of history. Like why the need for this? Containers used to be ephemeral. You know, you didn't have to persist them. That changed, but you guys are way ahead of that trend. Talk a little bit more about the history there and then we'll get into current day. >> Yeah, I think the need for stateful workloads within Kubernetes is absolutely grown. I think we just saw 1.24 of Kubernetes get released last week or a couple of weeks ago now. And really the focus there, you can see, at least three of the big ticket items in that release are focused around storage and data. So it just encourages that the community is wanting to put these data services within that. But it's also common, right? It's great to think about a stateless... If you've got stateless application but even a web server's got some state, right? There's always going to be some data associated to an application. And if there isn't then like, great but that doesn't really work- >> You're right. Where'd they click, where'd they go? I mean little things like that, right? >> Yeah. Yeah, exactly. So one of the things that we are seeing from that is like obviously the requirement to back up and put in a lot of data services in there, and taking full like exposure of the Kubernetes ecosystem, HA, and very tiny containers versus these large like virtual machines that we've always had the story at Veeam around the portability and being able to move them left, right, here, there, and everywhere. But from a K10 point of view, the ability to not only protect them, but also move those applications or move that data wherever they need to be. >> Okay. So, and Kubernetes of course has evolved. I mean the early days of Kubernetes, they kept it simple, kind of like Veeam actually. Right? >> Yeah. >> And then, you know, even though Mesosphere and even Docker Swarm, they were trying to do more sophisticated cluster management. Kubernetes has now got projects getting much more complicated. So more complicated workloads mean more data, more critical data means more protection. Okay, so you acquire Kasten, we know that's a small part of your business today but it's going to be growing. We know this cause everybody's developing applications. So what's different about protecting containers? Danny talks about modern data protection. Okay, when I first heard that, I'm like, eh, nice tagline, but then he peel the onion. He explains how in virtualization, you went from agents to backing up of VMware instance, a virtual instance. What's different about containers? What constitutes modern data protection for containers? >> Yeah, so I think the story that Danny tells as well, is so when we had our physical agents and virtualization came along and a lot of... And this is really where Veeam was born, right, we went into the virtualization API, the VMware API, and we started leveraging that to be more storage efficient. The admin overhead around those agents weren't there then, we could just back up using the API. Whereas obviously a lot of our competition would use agents still and put that resource overhead on top of that. So that's where Veeam initially got the kickstart in that world. I think it's very similar to when it comes to Kubernetes because K10 is deployed within the Kubernetes cluster and it leverages the Kubernetes API to pull out that data in a more efficient way. You could use image based backups or traditional NAS based backups to protect some of the data, and backup's kind of the... It's only one of the ticks in the boxes, right? You have to be able to restore and know what that data is. >> But wait, your competitors aren't as fat, dumb and happy today as they were back then, right? So it can't... They use the same APIs and- >> Yeah. >> So what makes you guys different? >> So I think that's testament to the Kubernetes and the community behind that and things like the CSI driver, which enables the storage vendors to take that CSI abstraction layer and then integrate their storage components, their snapshot technologies, and other efficiency models in there, and be able to leverage that as part of a universal data protection API. So really that's one tick in the box and you're absolutely right, there's open source tools that can do exactly what we're doing to a degree on that backup and recovery. Where it gets really interesting is the mobility of data and how we're protecting that. Because as much as stateful workloads are seen within the Kubernetes environments now, they're also seen outside. So things like Amazon RDS, but the front end lives in Kubernetes going to that stateless point. But being able to protect the whole application and being very application aware means that we can capture everything and restore wherever we want that to go as well. Like, so the demo that I just did was actually a Postgres database in AWS, and us being able to clone or migrate that out into an EKS cluster as a staple set. So again, we're not leveraging RDS at that point, but it gives us the freedom of movement of that data. >> Yeah, I want to talk about that, what you actually demoed. One of the interesting things, we were talking earlier, I didn't see any CLI when you were going through the integration of K10 V5 and V12. >> Yeah. >> That was very interesting, but I'm more skeptical of this concept, of the single pane of glass and how useful that is. Who is this integration targeting? Are you targeting the sort of traditional Veeam user who is now adding as a responsibility, the management of protecting these Kubernetes environments? Or are you at the same time targeting the current owners of those environments? Cause I know you talk about shift left and- >> Yeah. >> You know, nobody needs Kubernetes if you only have one container and one thing you're doing. So at some point it's all about automation, it's about blueprints, it's about getting those things in early. So you get up, you talk about this integration, who cares about that kind of integration? >> Yeah, so I think it's a bit of both, right? So we're definitely focused around the DevOps focused engineer. Let's just call it that. And under an umbrella, the cloud engineer that's looking after Kubernetes, from an application delivery perspective. But I think more and more as we get further up the mountain, CIS admin, obviously who we speak to the tech decision makers, the solutions architects systems engineers, they're going to inherit and be that platform operator around the Kubernetes clusters. And they're probably going to land with the requirement around data management as well. So the specific VBR centralized management is very much for the backup admin, the infrastructure admin or the cloud based engineer that's looking after the Kubernetes cluster and the data within that. Still we speak to app developers who are conscious of what their database looks like, because that's an external data service. And the biggest question that we have or the biggest conversation we have with them is that the source code, the GitHub or the source repository, that's fine, that will get your... That'll get some of the way back up and running, but when it comes to a Postgres database or some sort of data service, oh, that's out of the CI/CD pipeline. So it's whether they're interested in that or whether that gets farmed out into another pre-operations, the traditional operations team. >> So I want to unpack your press release a little bit. It's full of all the acronyms, so maybe you can help us- >> Sure. >> Cipher. You got security everywhere enhance platform hardening, including KMS. That's key- >> Yeah, key management service, yeah. >> System, okay. With AWS, KMS and HashiCorp vault. Awesome, love to see HashiCorp company. >> Yeah. >> RBAC objects in UI dashboards, ransomware attacks, AWS S3. So anyway, security everywhere. What do you mean by that? >> So I think traditionally at Veeam, and continue that, right? From a security perspective, if you think about the failure scenario and ransomware's, the hot topic, right, when it comes to security, but we can think about security as, if we think about that as the bang, right, the bang is something bad's happen, fire, flood, blood, type stuff. And we tend to be that right hand side of that, we tend to be the remediation. We're definitely the one, the last line of defense to get stuff back when something really bad happens. And I think what we've done from a K10 point of view, is not only enhance that, so with the likes of being able to... We're not going to reinvent the wheel, let's use the services that HashiCorp have done from a HashiCorp vault point of view and integrate from a key management system. But then also things like S3 or ransomware prevention. So I want to know if something bad's happened and Kasten actually did something more generic from a Veeam ONE perspective, but one of the pieces that we've seen since we've then started to send our backups to an immutable object storage, is let's be more of that left as well and start looking at the preventative tasks that we can help with. Now, we're not going to be a security company, but you heard all the way through Danny's like keynote, and probably when he is been on here, is that it's always, we're always mindful of that security focus. >> On that point, what was being looked for? A spike in CPU utilization that would be associated with encryption? >> Yeah, exactly that. >> Is that what was being looked- >> That could be... Yeah, exactly that. So that could be from a virtual machine point of view but from a K10, and it specifically is that we're going to look at the S3 bucket or the object storage, we're going to see if there's a rate of change that's out of the normal. It's an abnormal rate. And then with that, we can say, okay, that doesn't look right, alert us through observability tools, again, around the cloud native ecosystem, Prometheus Grafana. And then we're going to get insight into that before the bang happens, hopefully before the bang. >> So that's an interesting when we talk about adjacencies and moving into this area of security- >> We're talking to Zeus about that too. >> Exactly. That's that sort of creep where you can actually add value. It's interesting. >> So, okay. So we talked about shift left, get that, and then expanded ecosystem, industry leading technologies. By the way, one of them is the Red Hat Marketplace. And I think, I heard Anton's... Anton was amazing. He is the head of product management at Veeam. Is been to every VeeamON. He's got family in Ukraine. He's based in Switzerland. >> Yeah. >> But he chose not to come here because he's obviously supporting, you know, the carnage that's going on in Ukraine. But anyway, I think he said the Red Hat team is actually in Ukraine developing, you know, while the bombs are dropping. That's amazing. But anyway, back to our interview here, expanded ecosystem, Red Hat, SUSE with Rancher, they've got some momentum. vSphere with Tanzu, they're in the game. Talk about that ecosystem and its importance. >> Yeah, and I think, and it goes back to your point around the CLI, right? Is that it feels like the next stage of Kubernetes is going to be very much focused towards the operator or the operations team. The CIS admin of today is going to have to look after that. And at the moment it's all very command line, it's all CLI driven. And I think the marketplace is OpenShift, being our biggest foothold around our customer base, is definitely around OpenShift. But things like, obviously we are a longstanding alliance partner with VMware as well. So their Tanzu operations actually there's support for TKGS, so vSphere Tanzu grid services is another part of the big release of 5.0. But all three of those and the common marketplace gives us a UI, gives us a way of being able to see and visualize that rather than having to go and hunt down the commands and get our information through some- >> Oh, some people are going to be unhappy about that. >> Yeah. >> But I contend the human eye has evolved to see in color for a very good reason. So I want to see things in red, yellow, and green at times. >> There you go, yeah. >> So when we hear a company like Veeam talk about, look we have no platform agenda, we don't care which cloud it's in. We don't care if it's on-prem or Google Azure, AWS. We had Wasabi on, we have... Great, they got an S3 compatible, you know, target, and others as well. When we hear them, companies like you, talk about that consistent experience, single pane of glass that you're skeptical of, maybe cause it's technically challenging, one of the things, we call it super cloud, right, that's come up. Danny and I were riffing on that the other day and we'll do that more this afternoon. But it brings up something that we were talking about with Zeus, Dave, which is the edge, right? And it seems like Kubernetes, and we think about OpenShift. >> Yeah. >> We were there last week at Red Hat Summit. It's like 50% of the conversation, if not more, was the edge. Right, and really true edge, worst cases, use cases. Two weeks ago we were at Dell Tech, there was a lot of edge talk, but it was retail stores, like Lowe's. Okay, that's kind of near edge, but the far edge, we're talking space, right? So seems like Kubernetes fits there and OpenShift, you know, particularly, as well as some of the others that we mentioned. What about edge? How much of what you're doing with container data protection do you see as informing you about the edge opportunity? Are you seeing any patterns there? Nobody's really talking about it in data protection yet. >> So yeah, large scale numbers of these very small clusters that are out there on farms or in wind turbines, and that is definitely something that is being spoken about. There's not much mention actually in this 5.0 release because we actually support things like K3s,(indistinct), that all came in 4.5, but I think, to your first point as well, David, is that, look, we don't really care what that Kubernetes distribution is. So you've got K3s lightweight Kubernetes distribution, we support it, because it uses the same native Kubernetes APIs, and we get deployed inside of that. I think where we've got these large scale and large numbers of edge deployments of Kubernetes and that you require potentially some data management down there, and they might want to send everything into a centralized location or a more centralized location than a farm shed out in the country. I think we're going to see a big number of that. But then we also have our multi cluster dashboard that gives us the ability to centralize all of the control plane. So we don't have to go into each individual K10 deployment to manage those policies. We can have one big centralized management multi cluster dashboard, and we can set global policies there. So if you're running a database and maybe it's the same one across all of your different edge locations, where you could just set one policy to say I want to protect that data on an hourly basis, a daily basis, whatever that needs to be, rather than having to go into each individual one. >> And then send it back to that central repository. So that's the model that you see, you don't see the opportunity, at least at this point in time, of actually persisting it at the edge? >> So I think it depends. I think we see both, but again, that's the footprint. And maybe like you mentioned about up in space having a Kubernetes cluster up there. You don't really want to be sending up a NAS device or a storage device, right, to have to sit alongside it. So it's probably, but then equally, what's the art of the possible to get that back down to our planet, like as part of a consistent copy of data? >> Or even a farm or other remote locations. The question is, I mean, EVs, you know, we believe there's going to be tons of data, we just don't.. You think about Tesla as a use case, they don't persist a ton of their data. Maybe if a deer runs across, you know, the front of the car, oh, persist that, send that back to the cloud. >> I don't want anyone knowing my Tesla data. I'll tell you that right now. (all laughing) >> Well, there you go, that one too. All right, well, that's future discussion, we're still trying to squint through those patterns. I got so many questions for you, Michael, but we got to go. Thanks so much for coming to theCUBE. >> Always. >> Great job on the keynote today and good luck. >> Thank you. Thanks for having me. >> All right, keep it right there. We got a ton of product talk today. As I said, Danny Allan's coming back, we got the ecosystem coming, a bunch of the cloud providers. We have, well, iland was up on stage. They were just recently acquired by 11:11 Systems. They were an example today of a cloud service provider. We're going to unpack it all here on theCUBE at VeeamON 2022 from Las Vegas at the Aria. Keep it right there. (calm music)

>>Hello, and welcome back to the live cube coverage here in San Francisco, California, the cube live coverage. Two days, day two of a summit 2022, a summit New York city coming up in the summer. We'll be there as well. Events are back. I'm the host, John fur, the cube got great guest here, Johnny Dallas with Ze. Um, here's on the cube. We're gonna talk about his background. Uh, little trivia here. He was the youngest engineer ever worked at Amazon at the age. 17 had to get escorted into reinvent in Vegas cause he was underage <laugh> with security, all good stories. Now the CEO of gonna called Ze know DevOps kind of focus, managed service, a lot of cool stuff, John, welcome to the cube. >>Thanks John. Great. >>So tell a story. You were the youngest engineer at AWS. >>I was, yes. So I used to work at a company called Bebo. I got started very young. I started working when I was about 14, um, kind of as a software engineer. And when I, uh, was about 16, I graduated out of high school early. Um, worked at this company, Bebo running all of the DevOps at that company. Um, I went to reinvent in about 2018 to give a talk about some of the DevOps software I wrote at that company. Um, but you know, as many of those things are probably familiar with reinvent happens in a casino and I was 16, so I was not able to actually go into the casino on my own <laugh> um, so I'd have <inaudible> security as well as C security escort me in to give my talk. >>Did Andy jazzy, was he aware of this? >>Um, you know, that's a great question. I don't know. <laugh> >>I'll ask him great story. So obviously you started a young age. I mean, it's so cool to see you jump right in. I mean, I mean, you never grew up with the old school that I used to grew up in loading package software, loading it onto the server, deploying it, plugging the cables in, I mean you just rocking and rolling with DevOps as you look back now what's the big generational shift because now you got the Z generation coming in, millennials are in the workforce. It's changing. Like no one's putting package software on servers. >>Yeah, no, I mean the tools keep getting better, right? We, we keep creating more abstractions that make it easier and easier. When I, when I started doing DevOps, I could go straight into E two APIs. I had APIs from the get go and you know, my background was, I was a software engineer. I never went through like the CIS admin stack. I, I never had to, like you said, rack servers, myself. I was immediately able to scale to I, I was managing, I think 2,500 concurrent servers across every Ables region through software. It was a fundamental shift. >>Did you know what an SRE was at that time? Uh, you were kind of an SRE on >>Yeah, I was basically our first SRE, um, familiar with the, with the phrasing, but really thought of myself as a software engineer who knows cloud APIs, not a SRE. >>All right. So let's talk about what's what's going on now, as you look at the landscape today, what's the coolest thing that's going on in your mind and cloud? >>Yeah, I think the, I think the coolest thing is, you know, we're seeing the next layer of those abstraction tools exist and that's what we're doing with Ze is we've basically gone and we've, we're building an app platform that deploys onto your cloud. So if you're familiar with something like Carku, um, where you just click a GitHub repo, uh, we actually make it that easy. You click a GI hub repo and it'll deploy on a AWS using Al AWS tools. >>So, right. So this is Z. This is the company. Yes. How old's the company >>About a year and a half old now. >>Right. So explain what it does. >>Yeah. So we make it really easy for any software engineer to deploy on a AWS. Um, that's not SREs. These are the actual application engineers doing the business logic. Mm-hmm <affirmative> they don't really want to think about Yamo. They don't really want to configure everything super deeply. Um, they want to say, run this API on a AWS in the best way possible. We've encoded all the best practices into software and we set it up for you. >>Yeah. So I think the problem you're solving is, is that there's a lot of want to be DevOps engineers. And then they realize, oh shit, I don't wanna do this. Yeah. And the people want to do it. They loved under the hood. Right. People love that infrastructure, but the average developer needs to actually be as agile on scale. So that seems to be the problem you solve. Right? Yeah. >>We, we, we give way more productivity to each individual engineer, you know? >>All right. So let me ask you a question. So let me just say, I'm a developer. Cool. I built this new app. It's a streaming app or whatever. I'm making it up cube here, but let's just say I deploy it. I need your service. But what happens about when my customers say, Hey, what's your SLA? The CDN went down from this it's flaky. Does Amazon have? So how do you handle all that SLA reporting that Amazon provides? Cause they do a good job with sock reports all through the console. But as you start getting into DevOps and sell your app, mm-hmm <affirmative> you have customer issues. You, how do you view that? Yeah, >>Well, I, I think you make a great point of AWS has all this stuff already. AWS has SLAs. AWS has contract. Aw, has a lot of the tools that are expected. Um, so we don't have to reinvent the wheel here. What we do is we help people get to those SLAs more easily. So, Hey, this is a AWS SLA as a default. Um, Hey, we'll configure your services. This is what you can expect here. Um, but we can really leverage AWS reli ability of you don't have to trust us. You have to trust S and trust that the setup is good there. >>Do you handle all the recovery or mitigation between, uh, identification say downtime for instance, oh, the servers not 99% downtime, uh, went down for an hour, say something's going on? And is there a service dashboard? How does it get what's the remedy? Do you have, how does all that work? >>Yeah, so we have some built in remediation. You know, we, we basically say we're gonna do as much as we can to keep your endpoint up 24 7 mm-hmm <affirmative>. If it's something in our control, we'll do it. If it's a disc failure, that's on us. If you push bad code, we won't put out that new version until it's working. Um, so we do a lot to make sure that your endpoint stays up, um, and then alert you if there's a problem that we can't fix. So cool. Hey, S has some downtime, this thing's going on. You need to do this action. Um, we'll let you know. >>All right. So what do you do for fun? >>Yeah, so, uh, for, for fun, um, a lot of side projects. <laugh>, uh, >>What's your side hustle right now. You got going on >>The, uh, it's a lot of schools playing >>With serverless. >>Yeah. Playing with a lot of serverless stuff. Um, I think there's a lot of really cool Lam stuff as well, going on right now. Um, I love tools is, is the truest answer is I love building something that I can give to somebody else. And they're suddenly twice as productive because of it. Um, >>That's a good feeling, isn't it? Oh >>Yeah. There's nothing >>Like that. Tools versus platforms. Mm-hmm, <affirmative>, you know, the expression, too many tools in the tool, she becomes, you know, tools for all. And then ultimately tools become platforms. What's your view on that? Because if a good tool works and starts to get traction, you need to either add more tools or start building a platform platform versus tool. What's your, what's your view on our reaction to that kind of concept debate? >>Yeah, it's a good question. Uh, we we've basically started as like a, a platform. First of we've really focused on these, uh, developers who don't wanna get deep into the DevOps. And so we've done all of the piece of the stacks. We do C I C D management. We do container orchestration, we do monitoring. Um, and now we're, spliting those up into individual tools so they can be used awesome in conjunction more. >>Right. So what are some of the use cases that you see for your service? It's DevOps basically nano service DevOps for people on a DevOps team. Do clients have a DevOps person and then one person, two people what's the requirements to run >>Z? Yeah. So we we've got teams, um, from no DevOps is kind of when they start and then we've had teams grow up to about, uh, five, 10 man DevOps teams. Mm-hmm <affirmative> um, so, you know, as more structured people come in, because we're in your cloud, you're able to go in and configure it on top you're we can't block you. Uh, you wanna use some new AOL service. You're welcome to use that alongside the stack that we deploy for >>You. How many customers do you have now? >>So we've got about 40 companies that are using us for all of their infrastructure, um, kind of across the board, um, as well as >>What's the pricing model. >>Uh, so our pricing model is we, we charge basically similar to an engineer salary. So we charge, uh, a monthly rate. We have plans at 300 bucks a month, a thousand bucks a month, and then enterprise plan for based >>On the requirement scale. Yeah. You know, so back into the people cost, you must offer her discounts, not a fully loaded thing, is it? >>Yeah. There's a discounts kind of at scale, >>Then you pass through the Amazon bill. >>Yeah. So our customers actually pay for the Amazon bill themselves. Oh. So >>They have their own >>Account. There's no margin on top. You're linking your Aless account in, um, it, which is huge because we can, we are now able to help our customers get better deals with Amazon. Um, got it. We're incentivized on their team to drive your cost down. >>And what's your unit main unit of economics software scale. >>Yeah. Um, yeah, so we, we think of things as projects. How many services do you have to deploy as that scales up? Um, awesome. >>All right. You're 20 years old now you not even can't even drink legally. <laugh> what are you gonna do when you're 30? We're gonna be there. >>Well, we're, uh, we're making it better. And >>The better, the old guy on the cube here. >><laugh> I think, uh, I think we're seeing a big shift of, um, you know, we've got these major clouds. AWS is obviously the biggest cloud. Um, and it's constantly coming out with new services. Yeah. But we're starting to see other clouds have built many of the common services. So Kubernetes is a great example. It exists across all the clouds. Um, and we're starting to see new platforms come up on top that allow you to leverage tools from multiple clouds. At the same time. Many of our customers actually have AWS as their primary cloud and they'll have secondary clouds or they'll pull features from other clouds into AWS, um, through our software. I think that I'm very excited by that. And I, uh, expect to be working on that when I'm 30. Awesome. >>Well, you gonna have a good future. I gotta ask you this question cuz uh, you know, I've always, I was a computer science undergraduate in the, in the eighties and um, computer science back then was hardcore, mostly systems OS stuff, uh, database compiler. Um, now there's so much compi, right? So mm-hmm <affirmative> how do you look at the high school college curriculum experience slash folks who are nerding out on computer science? It's not one or two things much. You've got a lot of, a lot of things. I mean, look at Python, data engineering, merging as a huge skill. What's it? What's it like for college kids now and high school kids? What, what do you think they should be doing if you had to give advice to your 16 year old self back a few years ago now in college? Um, I mean Python's not a great language, but it's super effective for coding and the data's really relevant, but it's you got other language opportunities, you got tools to build. So you got a whole culture of young builders out there. What should, what should people gravitate to in your opinion stay away from yeah. Or >>Stay away from that's a good question. I, I think that first of all, you're very right of the, the amount of developers is increasing so quickly. Um, and so we see more specialization. That's why we also see, you know, these SREs that are different than typical application engineering. You get more specialization in job roles. Um, I think if, what I'd say to my 16 year old self is do projects, um, the, I learned most of my, what I've learned just on the job or online trying things, playing with different technologies, actually getting stuff out into the world, um, way more useful than what you'll learn in kind of a college classroom. I think classrooms great to, uh, get a basis, but you need to go out and experiment actually try things. >>You know? I think that's great advice. In fact, I would just say from my experience of doing all the hard stuff and cloud is so great for just saying, okay, I'm done, I'm abandoning the project. Move on. Yeah. Because you know, it's not gonna work in the old days. You have to build this data center. I bought all this certain, you know, people hang on to the old, you know, project and try to force it out there. >>You can launch a project, >>Can see gratification, it ain't working <laugh> or this is shut it down and then move on to something new. >>Yeah, exactly. Instantly you should be able to do that much more quickly. Right. >>So you're saying get those projects and don't be afraid to shut it down. Mm-hmm <affirmative> that? Do you agree with that? >>Yeah. I think it's ex experiment. Um, you're probably not gonna hit it rich on the first one. It's probably not gonna be that idea is DJing me this idea. So don't be afraid to get rid of things and just try over and over again. It's it's number of reps that a win. >>I was commenting online. Elon Musk was gonna buy Twitter, that whole Twitter thing. And, and, and someone said, Hey, you know, what's the, I go look at the product group at Twitter's been so messed up because they actually did get it right on the first time <laugh> and, and became such a great product. They could never change it because people would freak out and the utility of Twitter. I mean, they gotta add some things, the added button and we all know what they need to add, but the product, it was just like this internal dysfunction, the product team, what are we gonna work on? Don't change the product so that you kind of have there's opportunities out there where you might get the lucky strike, right. Outta the gate. Yeah. Right. You don't know, >>It's almost a curse too. It's you're not gonna Twitter. You're not gonna hit a rich second time too. So yeah. >><laugh> Johnny Dallas. Thanks for coming on the cube. Really appreciate it. Give a plug for your company. Um, take a minute to explain what you're working on, what you're looking for. You're hiring funding. Customers. Just give a plug, uh, last minute and have the last word. >>Yeah. So, um, John Dallas from Ze, if you, uh, need any help with your DevOps, if you're a early startup, you don't have DevOps team, um, or you're trying to deploy across clouds, check us out ze.com. Um, we are actively hiring. So if you are a software engineer excited about tools and cloud, or you're interested in helping getting this message out there, hit me up. Um, find a Z. >>Yeah. LinkedIn Twitter handle GitHub handle. >>Yeah. I'm the only Johnny on a LinkedIn and GitHub and underscore Johnny Dallas underscore on Twitter. Right? Um, >>Johnny Dallas, the youngest engineer working at Amazon. Um, now 20 we're on great new project here. The cube builders are all young. They're growing in to the business. They got cloud at their, at their back it's, uh, tailwind. I wish I was 20. Again, this is a cue. I'm John for your host. Thanks for watching. >>Thanks.

(upbeat music) >> Hey, everyone. Welcome to theCUBE's coverage of the International Women's Showcase for 2022. I'm your host, Lisa Martin. I'm pleased to welcome Nancy Wong, the general manager of Data Protection and Governance at AWS to the program. Nancy, it's great to have you. >> Thanks so much for having me Lisa, and you know, I really hope that this is hopefully the last year that we'll be celebrating International Women's Day all virtually. >> I agree. I agree. Well, we're going in that right direction globally. So let's cross our fingers. Talk to me a little bit about your role at AWS and what you do there. >> Sure. So as a GM of AWS Data Protection and Governance, a lot of, we tackle quite a few problems that our biggest customers face, right? When they think about, "How do I manage my data?" Right. Especially in this digital world. And speaking of the pandemic, how much data has been generated by consumers, by devices, by systems, by servers? How do you protect all of that data? Right. Especially we hear about cyber crime, cyber attacks. Right. Data breaches. It's really important to make sure that all of our customers have a coherent strategy around not just management, right, but also protection and really how you govern your data. Right. And there's just so many awesome conversations that my team and I have had lately with CSOs or chief technology officers on this topic, as it evolves. >> Data protection is so critical. It's one of my favorite topics to talk about, cybersecurity as well. Talk to me about what it means though if we keep this at a bit of a different level to be an operator within the the big ecosystem that is AWS. >> Yeah. And that's actually one of the the favorite aspects of my role. Right. Which is, you know, I get to innovate every day on behalf of my customers. For example, I love having one-on-one dialogues. I love having architecture conversations where we brainstorm. Right. And so those type of conversations help inform how we deliver and develop products. And so in an operator role, right, for the the women in the audience today, is it really gives you that perspective into not just how, what type of products do you want to build that delight your customers but also from an engineering. Right. And a bottom line perspective of, well how do you make this happen? Right. How do you fund this? And how do you plan out your development milestones? >> What are, tell me a little bit about your background and then what makes women in technology such an important initiative for you to stand behind? >> Absolutely. So I'm so proud today to see that the number of women or the percentage of women enrolled at engineering curriculums just continue to rise. Right. And especially as someone who went through an engineering degree in her undergraduate studies, that was not always the case. Right. So oftentimes, you know, I would look around the classroom and be the only woman on the lab bench or only woman in a CS classroom. And so when you have roles in tech, specifically, that require an undergraduate degree in computer science or a degree in engineering, that helps to, or that only serves to really reduce the population of eligible candidates. Right. Who then, if you look at that pool of eligible candidates who then you can invest and accelerate through the career ladder to become leaders in tech, well that's where you may end up with a representation issue. Right. And that's why we have, for example, so few women leaders in tech that we can look up to as role models. And that's really the problem or the gap that I'm very passionate about solving. And also, Lisa, I'm really excited to tell you a little bit more about advancing women in tech, which is a 501c3 nonprofit organization that I started to tackle this exact problem. >> Talk to me about that, cause it's one of the things that you bring up is, you know, we always say when we're having conversations like this, we can't be what we can't see. We need to be able to see those female leaders. To your point, there aren't a ton in comparison to the male leaders. So talk to me about advancing women in technology, why you founded this, and what you guys are accomplishing. >> Absolutely. So it's been such a personal journey as well. Just starting this organization called Advancing Women In Tech because I started it in 2017. Right. So when I really was, you know, just starting out as a product manager, I was at another big tech company at the time. And what I really realized, right, is looking around you know, I had so many, for example, bosses, managers, peer leaders, who were really invested in growing me as a product manager and growing my tech and career. And this is right after I'd made the transition from the federal government into big tech. What that said though, looking around, there weren't that many women tech leaders that I could look up to, or get coffee, or just have a mentoring conversation. And quickly I realized, well, it's not so much that women can't do it. Right. It's the fact that we're not advancing enough women into leadership roles. And so really we have to look at why that is. Right. And we, you know, from a personal perspective, one contribution towards that angle is upskilling. Right. So if you think about what skills one needs as one climbs a career ladder, whether that's your first people management role, or your first manager manager's role, or obviously for bigger leaders when they start managing thousands, tens of thousands of individuals, well all of that requires different skills. And so learning those skills about how to manage people, how to motivate your teams effectively, super, super important. And of course on the other side, and one that I'm, you know, near to dear to me is that of mentorship and executive sponsorship because you can have all the skills in the world, right. And especially with digital learning and AWIT is very involved with Coursera and AWS in producing and making those resources readily available and accessible. Well, if you don't have those opportunities, if you don't have mentors and sponsors who are well to push you or give you a step ladder to those roles, well you're still not going to get there. Right. And so, that's why actually, if you look at the AWIT mission, it's really those two pillars working very closely together to help advance women into leadership roles. >> The idea of mentorship and sponsorship is so critical. And I think a lot of people don't understand the difference between a mentor and a sponsor. How do you define that difference and how do you bring them into the organization so that they can be mentors and sponsors? >> Yeah, absolutely. And there's, you know, these two terms are often used today so interchangeably that I do get a lot of questions around, well, what is the difference? Right. And how does, let's say a mentor become a sponsor? So, maybe just taking a few steps back, right. When you have let's say questions around compensation or, "Hey I have some job offers, which ones do I consider?" And you ask someone a question or advice, well that person's likely your mentor. Right? And typically a mentor is someone who you can ask those questions on a repeated basis. Who's very accessible to you. Well, a sponsor takes that a few steps forward in the sense that they are sponsoring you into a role or into a project or initiative that you on your own may not be able to achieve. And by doing so, I think what really differentiates a sponsor from a mentor is that the sponsor will actually put their own reputation on the line. Right. They're using their own political capital in order to make sure that you get into that role, you get into that room. Right. And that's why it's so key, for example, especially if you have that relationship already with a person who's your mentor, you're able to ask questions or advice from, to convert them into a sponsor so that you can accelerate your career. >> Great definition, description, and great recommendations for converting mentors to sponsors. You know, I only learned the difference about a mentor and a sponsor a few years ago at another women in tech event that I was hosting. And I thought, "It's brilliant. It makes perfect sense." We need more people to understand the difference, the synergies, and how to promote mentors to sponsors. Talk to me now about advancing women in tech plus the power of AWS. How are they helping this nonprofit to really accelerate? >> Sure. So from an organization perspective, right, there's many women, for example, across the the tech companies who are part of Advancing Women In Tech, obviously Amazon of course as an employee has a very large community within who's part of AWIT. But we also have members across the tech industry from startups to VC firms to of course, Google, Microsoft, and Netflix. You name it. With that said, you know, what AWS has done with AWIT is actually very special in the sense that if you go to the Coursera platform, coursera.org/awit you can see our two Coursera specializations. Four courses each that go through the real world product management fundamentals. Or the business side, the technical skills, and even interviewing for mid-career product management roles. And the second specialization, which I'm super excited to share today, is actually geared towards getting folks ramped up and prepared to successfully pass the Cloud Practitioner's Exam, which is one of the industry recognized standards about understanding the AWS Cloud and being functional in the AWS Cloud. This summer, of course, and I'm sharing kind of a sneak peek announcement that I'll be making tomorrow with the University of Pennsylvania, is that we're kicking off a program for the masters of CIS program, or the Computer Information Systems Master students, to actually go through this Coursera specialization, which is produced by AWIT, sponsored by AWS, and AWS Training and Certifications has so generously donated exam vouchers for these students so that they can then go on and be certified in the AWS Cloud. So that's one just really cool collaboration that we are doing between AWS and AWIT to get more qualified folks in the door in tech jobs, and hopefully at jobs in AWS. >> That's a great collaboration. What are some of the goals in terms of metrics, the number of women that you want to get into the program and complete the program? What are some of those on your radar? >> Absolutely. So one of the reasons, of course, that the Master's of CIS Program, the University of Pennsylvania caught my eye, not withstanding, I graduated from there, but also that just the statistics of women enrolled. Right. So what's really notable about this program is it's entirely online, which as a university creating a Master's degree fully online, well, it takes a ton of resources from the university, from the faculty. And what's really special about these students is that they're already full-time adult professionals, which means that they're working a full-time job, they might be taking care of family obligations, and they're still finding time to advance themselves, to acquire a Master's degree in CS. And best of all, 42% of these students are women. Right. And so that's a number that is multiples of what we're finding in engineering curriculums today. And so my theory is, well if you go to a student population that is over 40%, 42 to be exact percent women, and enable these women to be certified in AWS Cloud, to have direct interview prep and mentorship from AWS software development leaders, well, that greatly increases their chances of getting a full-time role, right, at AWS. Right. At which then we can help them advance their careers to further and further roles in software development. >> So is this curriculum also open to women who aren't currently in tech to be able to open the door for them to get into tech and STEM fields? >> Absolutely. And so in my bad and remiss in mentioning, which is students of this Master's in CS Program are actually students not from tech already. So they're not in a tech field. And they did not have a degree in CS or even engineering as part of their undergraduate studies. So it's truly folks who are outside of tech, that are 42% women, that we're getting into the tech industry with this collaboration between AWS, AWIT, and the University of Pennsylvania. >> That's outstanding to get them in from completely different fields into tech. >> Absolutely. >> How do you help women have the confidence to say, "I want to try this." Cause if we think about every company today is a tech company. It's a data company. It has to be to be competitive. You know, the pandemic taught us that everything we're able to do online and digitally, for example, but how do you help women get the confidence to say, "Okay, I'm going to go from a completely different field into tech." >> Absolutely. So if we, you know, define tech of course as big tech or, you know, now the main companies, right, I myself made that transition, which is why it is a topic near and dear to me because I can personally speak to my journey because I didn't start my career out in tech. Right. Yes. I studied engineering. But with that said, my first full-time job out of college was with the federal government because I wanted to go and build healthdata.gov, right, which gave folks a lot of access to the healthcare data, roles, right, that existed within the U.S. government and the CMS, NIH, you know, CDC, so on and so forth. But that was quite a big change from then taking a product management job at Google. Right. And so how did I make that change? Well, a lot of it came from, you know, the mentors that I had. Right. What I call my personal board of directors who gave me that confidence. And sure, I mean even today, I still have imposter syndrome where, you know, I think, "Am I good enough." Right. "Should I be leading this organization," right, "of data protection and governance." But I think what it boils down to is, you know, inner confidence. Right. And goes back to those two pillars of having the right skills and also the right mentors and sponsors who are willing to help sponsor you into those opportunities and help sponsor you to success. >> Absolutely. Great advice and recommendations. Thanks for sharing your background, Nancy, it's outstanding to see where you started to where you are now and also to what you're enabling for so many other females to get into tech with the AWIT program combined with AWS and UPenn. Exciting stuff. Can't wait to talk to you next year to see where you guys go from here. >> Absolutely Lisa. And what I'm really looking forward to sharing with you next year is the personal testimonials of other women who have gone through the AWIT, the AWS, the UPenn Program and have gotten their tech jobs and also promotions. >> That sounds like a great thing to look forward to. I'm looking forward to that. Nancy, thanks so much for your time and the insight that you shared. >> Thanks so much for having me, Lisa. >> My pleasure. For Nancy Wong, I'm Lisa Martin. You're watching theCUBE's coverage of the International Women's Showcase 2022. (upbeat music)

>>Hello and welcome back to the cube in person at an event AWS reinvent 2021. We're here live with two sets. Also virtual we've watched the cube on the site. Virtual sits a hybrid event. I'm John for your host of the cube. We're here for three days. Wall-to-wall covered chicken off day one. All about software. ISV is also the value of the cloud. We've got two great guests, John Grosse and senior vice president, chief revenue officer Prisma, cloud of Palo Alto networks. Welcome to the cube. >>Thank you for having me excited to be here. >>Three to Joseph's general manager technology partners from AWS. Thanks for coming on again. Good to see you. So obviously the story here at re-invent is Adam Lesley, new CEO taking over Andy Jassy, uh, tomorrow's a big keynote. We're expecting to hear that the cloud is kind of going next gen. The next gen cloud is here. It's about applications, modern applications and true infrastructure as code security is code data as code essentially, applications are now the number one priority. This is a big thing. This is part of the movement of the cloud. So I got to get your guys' perspectives. Where are we in that movement? What are customers doing as they migrate to the cloud? It's not just lift and shift. They're like, okay, I got to rearchitect my business. Big things are happening. What do you guys see? >>Well, I think there's a couple of big drivers at the highest level, right? Some customers are thinking about migrating their it estate to the cloud. They want to take cost out. They want to drive agility. They want to drive a better user experience and you have other customers that want to innovate, right? They want to drive innovation that leverage the cloud for innovation and increase their speed of execution. And as they look at that opportunity, they're having to rethink dev ops and which is making them also think more about DevSecOps and how are they going to accelerate that cloud application life cycle so they can take advantage of microservices. And in addition to that, as we look back on the last two years, as we were talking about before we came on the air and this unfortunate pandemic era that will maybe refer to it, as many customers have been thinking about their supply chains, you know, what am I going to do with my supply chain? How do I really take problems out of that supply chain? So I can continue to serve my customers in my markets. And it's also made them think about different ways to approach their customers. How do they reach their customers? And then how do they fulfill bill and continue to nurture those customer relationships? So I think it goes to the big drivers >>And the, and the security aspect is so huge. You guys have Palo Alto networks? No, that's just give us a perspective and reaction to that. As people digitize their business, you get security built in from day one. This is the number one thing we talk about on the cube bit, baking it in from day one, whether they say shifting left, whatever sure. It's your business, you're now digital. Yeah. >>What are the things that we think we bring to CEO's and CIS is into boards is really three different ways to get started with cloud native security. With Prisma cloud, you can start at the simplest of terms with posture management. I just want to inventory my assets and know what I have out there and make sure those are secure. I want to be compliant. We want to deliver on compliance and governance for my board, my leadership team, others are thinking about workload protection, Kubernetes, serverless containers. What am I going to do with those critical workloads that I'm now moving to the cloud? And then to your point, big push area is shifting security left. I've got to build security in right from the start of that application development life cycle change the way I think about CIC D and delivering those applications securely in the cloud and doing a fast now time to market on applications is critical for customers. And they've got to think about building security. And so they don't have to rework those apps and build security and later. >>So let's talk about what you guys have been doing with customers during the pandemic and how they're going to come out of it with a growth strategy. We had some great talks on our cube program around how the software development life cycle is changing, how modern applications are being built. And I'll see Amazon, you guys enable people to make money on top of Amazon because you make money too. But how are you guys helping customers? What's the big thing that come out of the pandemic. >>Yeah, so, well, the pandemic has been unfortunate for all of humanity, but through this, we have really seen customers accelerating their journey into AWS and security is top of mind for them as customers continue to digitize their software, they are really looking for solutions from Palo Alto networks on AWS. And what they're looking for is something very simple and cost-effective which Palo Alto has provided because of our long-term partnership. And as John mentioned, right due to the pandemic and many other factors around it, there have been many constraints placed on the supply chain, but the economies of scale with AWS has really helped partners and customers address many of these constraints. So we have seen a tremendous movement into AWS the last 20 months. >>And how, how has the partnership for Palo Alto networks been for you guys? Because I wrote in my article, I just posted last night around the preview of this event in my interview that has Leschi is that cloud is enabling the partners Amazon's cloud is enabling partners to do more than be a point solution. And that we're talking about a platform, not tools. I mean, this tools tools are great, but this notion of super clouds are developing where partners are leveraging more than just hosting, right? >>What's your partnerships always start and end with customers. So one of the things we're most excited about from a first of a cloud perspective is we now have over 800 calmly customers that are utilizing Prisma cloud is secure workloads and to secure their security posture management and shift security left using Prisma cloud on AWS. And the other, a couple of big ingredients that we've had together is really multi-dimensional partnership that makes that all possible, right? We're an advanced technology partner. We have a number of programs that we run together, and we've also been a part of a handful of product launches and innovation launches that we're super excited about, like what we've done with guard duty, like what we've also done with auto provisioning using control tower. So multi-dimensional partnership, which is always the best we think starts with customers. And then from there, what we've done is we've taken a really intentional programmatic approach as we think about innovation programs and go to market together. Yeah. >>Follow up on the, you know, mind, you guys have been very successful at Palo Alto networks as your customer base, the more, more sophisticated and smarter around cloud, you got to add more value and be responsive. What is the big trend in your customer base? You see with cloud? Are they obviously keeping stuff on, on premises for certain things, obviously security reasons, but also data's got to open up. So now you have a more of a bigger data aperture. >>Absolutely. Absolutely. And what's happening is what should happen, which is customers are asking us to do more and innovate faster. And so, you know, we're really excited about our recent launch at Prisma cloud 3.0 where it really expanded the platform. Uh, we're now bringing an adoption adviser, which is going to simplify the experience for our mutual customers so that they can more readily adopt CSPs CWPP and extend their utilization of the platform. At the same time, we've made a number of announcements about adding more value into our infrastructure as code approach, you know, shifting security left. So very excited about that. And, and so I think that, you know, what we're finding is that we're needing to listen to customers and quickly build and deliver, uh, innovation in the cloud is they're all trying to your point new use cases and stretching their needs for cloud security. >>I got to say one of my observations of the past two and a half years, even coming into the pandemic was security clearly being baked in from the beginning, but the pandemic really exposed those who were ready for it. Yeah. And that, and that's a big point. And now it's like dev sec ops, no one argues about it anymore. Right. It is what it is. Right. That's a huge difference from just five years ago. >>Absolutely true. Absolutely true. And now, you know, as you're seeing, you know, partnering with AWS customers are delivering actually their end product in the cloud. Right. And that is the most critical relationship is their customer's customer. And they've got to make sure that it absolutely is a secure user experience because now we're talking about customers, identity payment information, we're talking about critical customer relationship management now all in the cloud. And it has to be secured end to end. So very exciting opportunities. >>I mean, uh, you're under a lot of pressure. Now you have a lot of these big partners doing big business. They have big customers. I know they do. Palo Alto has a lot of great customers. How do you support them? What are you guys doing to continue to nurture and support your customers? >>Yeah. Customers is the key word there, John. So we provide value to Palo Alto and other partners to a number of different ways. But one approach that we take is called a well-architected review. It's a process which looks at the software solutions through pillars of security, reliability, performance, cost optimization, and operational excellence. And the reason for that is we want to make sure that the foundation for customers is laid in the best way possible. Because once you have that foundation laid, you can really, really build and scale your business. And so that is one of the ways we continue to provide value and Palo Alto we've taken the well-architected review through all of their solutions, bought the ones existing and the ones in the future. >>I got to say, I've noticed you guys have been using the word primitives a lot. Now it's foundational services. Um, because what we're talking about here is foundation. And a lot of the trends we're seeing from your customers, both is they want to refactor their business value in the cloud, the modern application trend, isn't just apps is about business model innovation in the software itself. So it's asking the infrastructure to be code, ask you to be programmable security with automation, all that AI, this is a trend. Do you guys agree with that? Yeah, >>I absolutely. I do. And I think what you're seeing now from customer's point of view is they need to build security into that application lifecycle mental model. They have to have an end-to-end vision of how they're going to deliver those, those applications at speed and do it, you know, utilizing cloud native architecture so that they can have microservices that deliver value in they're more flexible. And that's part of the power. I think of AWS and Palo Alto networks. First of all, cloud is we're enabling customers to innovate at speed shift left with security, build security into those apps, take rework out, deliver applications faster, which obviously drives more value to them. >>Yeah. I'd love to get your thoughts on something, John, if you don't mind, while you're here, we were talking about for reinvented around major inflection points and every major inflection point in the history of the tech industry, whenever there's a change of how people develop applications, speed and performance was super important. Critical. How do you guys see that? Cause you guys are on the front lines with security performance matters. Now whether it's in the cloud or in transit, what's your >>Absolutely absolutely. You know, it was really interesting in customer conversations. Even some of the customer conversations I've had today, every customer now starts a conversation with some element of cloud security, security, posture management, workload protection, identity data, but they all are coming back now to shifting left with security. It's part of every single conversation. Yes. I was primarily leaders into posture management. Oh, by the way, absolutely got to dive into how I'm going to shift left and build security in. And so that speed of development now I think is going to be a key competitive differentiator for customers. They're going to have to become experts at delivering on that entire application pipeline. >>But your reaction to that speeds and feeds >>Well, it is, I believe it's really important. And um, we're trying to do everything that we can help partners like Palo Alto network with our processes. And most importantly, scaling the business, which I'm sure we'll talk about shortly, how we work together to really get those 800 customers >>Talking about that. Cause you have the advanced technology partnership program. Talk about what you guys do there. >>Yeah. So first of all, I want to thank John and the entire Palo Alto team for building such an excellent partnership across build co-sale and co-market. And as an advanced technology partner, Palo Alto is part of four different competencies, security containers, DevOps networking. And the reason why these competencies are so crucial is because you're able to list your validated solutions with public customer references by use case in each of these competencies, which I think John, you would agree enables them, asked to do focus, demand generation activities through dev days, blog posts, webinars, account mapping, which of course generates those opportunities together. And Palo Alto is also part of our ISB accelerate program. So our sales team is in incented in order to work with Palo Alto and help them close opportunities. And then also you are on AWS marketplace, which enables you to do free trials and enabling you to really scale across the globe. And then we are also helping Palo Alto across the globe with resources, including public sector to help them scale their business. >>The whole selling thing is interesting as the chief revenue officer, it's like, oh yeah, I love that. Um, this is a big deal. Talk about that further. I know the marketplace is where people are buying, but it's a joint sales, Amazon salespeople sell for you, right? >>Cosa, we call it co-sale whereby we can share opportunities with each other. And when we do share those opportunities, the sales teams are engaging together to understand, Hey, what's going on at the customer? What are the pain points? What are the use cases, value proposition, and then going in together to the customer to win the deal. And then continuing that relationship beyond to continue to grow net new revenue, >>Not too shabby, is it, oh yeah. Get more feet on the street. So to speak and virtual, >>There you go. It works on both dimensions and to all the points you made. I mean, we have some terrific mechanisms we use together, you know, like immersion days, dev days where we're able to work with customers, deliver well-architected visions for our customers together. And when we were both designed in, it's obviously a great, it's a great win for the customer enables us to scale. >>I think it's a cutting and not everyone gets these services to, you have to be a certain lay level to get the joint selling. >>That is correct. That's an advanced technology partner and also as part of ISB accelerate, which is our very focused Cosell program. Awesome. >>Well, thanks so much for coming on the cube. Really appreciate. Congratulations on a great partnership. Uh, two great brands. Congratulations, final minute. Just what's your expectation. As we come out of this pandemic, what do you see customers doing? What's the one thing that all customers are preparing for coming out of the pandemic? What do you guys see? >>Well, I think now customers are preparing for acceleration in all of their routes to market. Right now they're having to anticipate their return to some of the normal routes to market that they've for some time now have been trying to reinvent around and trying to drive primarily digital, go to market. Now I think we're going to see growth on every dimension with our customers, because they're going to need to return to some kind of normal with their supply chains, delivering through brick and mortar and their traditional delivery models on top of driving hyper growth that they're already enjoying through their digital go-to-market. >>That's great insight. So, you know, your, your thoughts on companies coming out of the pandemic, looking for a growth strategy, what's the, >>Well, I think they're going to prepare in order to address this pandemic in the future, Some calamity of some way. Right. But I do think that what I'm observing personally, especially segments that have been slower to adopt because they wanted evidence. The pandemic has really increased that whether that's vaccine research or treatment research, it has really accelerated that. So I agree with John B going to >>See it all across the board. I mean, one thing I'd say just support those two awesome insights is that the pandemic expose what works and what doesn't work. Right. You can't hide the ball anymore. You know, if, if software's being used, it's successful. If not, as self-aware right. You can't hide the ball cloud. If it's not working, you know what right away. Yeah. Thanks so much for coming on the Cape. Really appreciate it. Thank you very much. Okay. Cube coverage here at reinvent live 2021. I'm John for your host of the cube. Stay with us wall to wall coverage for the next four days here in the queue.

>>Okay, welcome back everyone. To the cubes coverage here, coop con cloud native con 2021 in person. The Cuba's here. I'm John farrier hosted the queue with Dave Nicholson, my cohost and cloud analyst, man. It's great to be back, uh, in person. We also have a hybrid event. We've got two great guests here, the founders of deep fence, sham, Krista Swami, C co-founder and CTO, and said deep line founder. It's great to have you on. This is a super important topic. As cloud native is crossed over. Everyone's talking about it mainstream, blah, blah, blah. But security is driving the agenda. You guys are in the middle of it. Cutting edge approach and news >>Like, like we were talking about John, we had operating at the intersection of the awesome desk, right? Open source security and cloud cloud native, essentially. Absolutely. And today's a super exciting day for us. We're launching something called track pepper, Apache V2, completely open source. Think of it as an x-ray or MRI scan for your cloud scan, you know, visualize this cloud at scale, all of the modalities, essentially, we look at cloud as a continuum. It's not a single modality it's containers. It's communities, it's William to settle we'll list all of them. Co-exist side by side. That's how we look at it and threat map. It essentially allows you to visualize all of this in real time, think of fed map, but as something that you, that, that takes over the Baton from the CIS unit, when the lift shift left gets over, that's when the threat pepper comes into picture. So yeah, super excited. >>It's like really gives that developer and the teams ops teams visibility into kind of health statistics of the cloud. But also, as you said, it's not just software mechanisms. The cloud is evolving, new sources being turned on and off. No one even knows what's going on. Sometimes this is a really hidden problem, right? Yeah, >>Absolutely. The basic problem is, I mean, I would just talk to, you know, a gentleman 70 of this morning is two 70 billion. Plus public cloud spent John two 70 billion plus even 3 billion, 30 billion they're saying right. Uh, projected revenue. And there is not even a single community tool to visualize all the clouds and all the cloud modalities at scale, let's start there. That's what we sort of decided, you know what, let's start with utilizing everything else there. And then look for known badness, which is the vulnerabilities, which still remains the biggest attack vector. >>Sure. Tell us about some of the hood. How does this all work cloud scale? Is it a cloud service managed service it's code? Take us out, take us through product. Absolutely. >>So, so, but before that, right, there's one small point that Sandeep mentioned. And Richard, I'd like to elaborate here, right? He spoke about the whole cloud spending such a large volume, right? If you look at the way people look at applications today, it's not just single clone anymore. It's multicloud multi regions across diverse plants, right? What does the solution to look at what my interests are to this point? That is a missing piece here. And that is what we're trying to tackle. And that is where we are going as open source. Coming back to your question, right? How does this whole thing work? So we have a completely on-prem model, right? Where customers can download the code today, install it. It can bill, we give binary stool and Shockley just as the exciting announcement that came out today, you're going to see somewhat exciting entrepreneurs. That's going to make a lot more easy for folks out there all day. Yeah, that's fine. >>So how does this, how does this all fit into security as a micro service and your, your vision of that? >>Absolutely. Absolutely. You know, I'll tell you, this has to do with the one of the continual conferences I would sort of when I was trying to get an idea, trying to shape the whole vision really? Right. Hey, what about syncretism? Microservice? I would go and ask people. They mentioned that sounds, that makes sense. Everything is becoming a microservice. Really. So what you're saying is you're going to deploy one more microservice, just like I deploy all of my other microservices. And that's going to look after my microservices. That compute back makes logical sense, essentially. That was the Genesis of that terminology. So defense essentially is deployed as a microservice. You go to scale, it's deployed, operated just like you to your microservices. So no code changes, no other tool chain changes. It just is yet another microservice. That's going to look after you talk about >>The, >>So there's one point I would like to add here, which is something very interesting, right? The whole concept of microservice came from, if you remember the memo from Jeff Bezos, that everybody's going to go, Microsoft would be fired. That gave rise to a very conventional unconditionally of thinking about their applications. Our deep friends, we believe that security should be. Now. You should bring the same unconventional way of thinking to security. Your security is all bottom up. No, it has to start popping up. So your applications on microservice, your security should also be a micro. >>So you need a microservice for a microservice security for the security. You're starting to get into a paradigm shift where you starting to see the API economy that bayzos and Amazon philosophy and their approach go Beanstream. So when I got to ask you, because this is a trend we've been watching and reporting on the actual application development processes, changing from the old school, you know, life cycle, software defined life cycle to now you've got machine learning and bots. You have AI. Now you have people are building apps differently. And the speed of which they want to code is high. And then other teams are slowing them down. So I've heard security teams just screw people over a couple of days. Oh my God, I can wait five days. No, it used to be five weeks. Now it's five days. They think that's progress. They want five minutes, the developers in real time. So this is a real deal optimum. >>Well, you know what? Shift left was a good thing. Instill a good thing. It helps you sort of figure out the issues early on in the development life cycle, essentially. Right? And so you started weaving in security early on and it stays with you. The problem is we are hydrating. So frequently you end up with a few hundred vulnerabilities every time you scan oftentimes few thousand and then you go to runtime and you can't really fix all these thousand one. You know? So this is where, so there is a little bit of a gap there. If you're saying, if look at the CIC cycle, the in financial cycle that they show you, right. You've got the far left, which is where you have the SAS tools, snake and all of that. And then you've got the center where, which is where you hand off this to ops. >>And then on the right side, you've got tech ops defense essentially starts in the middle and says, look, I know you've had thousand one abilities. Okay. But at run time, I see only one of those packages is loaded in memory. And only that is getting traffic. You go and fix that one because that's going to heart. You see what I'm saying? So that gap is what we're doing. So you start with the left, we come in in the middle and stay with you throughout, you know, till the whole, uh, she asks me. Yeah, well that >>Th that, that touches on a subject. What are the, what are the changes that we're seeing? What are the new threats that are associated with containerization and kind of coupled with that, look back on traditional security methods and how are our traditional security methods failing us with those new requirements that come out of the microservices and containerized world. And so, >>So having, having been at FireEye, I'll tell you I've worked on their windows products and Juniper, >>And very, very deeply involved in. >>And in fact, you know what I mean, at the company, we even sold a product to Palo Alto. So having been around the space, really, I think it's, it's, it's a, it's a foregone conclusion to say that attackers have become more sophisticated. Of course they have. Yeah. It's not a single attack vector, which gets you down anymore. It's not a script getting somewhere shooting who just sending one malicious HTP request exploiting, no, these are multi-vector multi-stage attacks. They, they evolve over time in space, you know? And then what happens is I could have shot a revolving with time and space, one notable cause of piling up. Right? And on the other side, you've got the infrastructure, which is getting fragmented. What I mean by fragmented is it's not one data center where everything would look and feel and smell similar it's containers and tuberosities and several lessons. All of that stuff is hackable, right? So you've got that big shift happening there. You've got attackers, how do you build visibility? So, in fact, initially we used to, we would go and speak with, uh, DevSecOps practitioner say, Hey, what is the coalition? Is it that you don't have enough scanners to scan? Is it that at runtime? What is the main problem? It's the lack of visibility, lack of observability throughout the life cycle, as well as through outage, it was an issue with allegation. >>And the fact that the attackers know that too, they're exploiting the fact that they can't see they're blind. And it's like, you know what? Trying to land a plane that flew yesterday and you think it's landing tomorrow. It's all like lagging. Right? Exactly. So I got to ask you, because this has comes up a lot, because remember when we're in our 11th season with the cube, and I remember conversations going back to 2010, a cloud's not secure. You know, this is before everyone realized shit, the club's better than on premises if you have it. Right. So a trend is emerged. I want to get your thoughts on this. What percentage of the hacks are because the attackers are lazier than the more sophisticated ones, because you see two buckets I'm going to get, I'm going to work hard to get this, or I'm going to go for the easy low-hanging fruit. Most people have just a setup that's just low hanging fruit for the hackers versus some sort of complex or thought through programmatic cloud system, because now is actually better if you do it. Right. So the more sophisticated the environment, the harder it is for the hackers, AK Bob wire, whatever you wanna call it, what level do we cross over? >>When does it go from the script periods to the, the, >>Katie's kind of like, okay, I want to go get the S3 bucket or whatever. There's like levels of like laziness. Yeah. Okay. I, yeah. Versus I'm really going to orchestrate Spearfish social engineer, the more sophisticated economy driven ones. Yeah. >>I think, you know what, this attackers, the hacks aren't being conducted the way they worked in the 10, five years ago, isn't saying that they been outsourced, there are sophisticated teams for building exploiters. This is the whole industry up there. Even the nation, it's an economy really. Right. So, um, the known badness or the known attacks, I think we have had tools. We have had their own tools, signature based tools, which would know, look for certain payloads and say, this is that I know it. Right. You get the stuff really starts sort of, uh, getting out of control when you have so many sort of different modalities running side by side. So much, so much moving attack surfaces, they will evolve. And you never know that you've scanned enough because you never happened because we just pushed the code. >>Yeah. So we've been covering the iron debt. Kim retired general, Keith Alexander, his company. They have this iron dome concept where there's more collective sharing. Um, how do you see that trend? Because I can almost imagine that the open-source man is going to love what you guys got. You're going to probably feed on it, like it's nobody's business, but then you start thinking, okay, we're going to be open. And you have a platform approach, not so much a tool based approach. So just give me tools. We all know that when does it, we cross over to the Nirvana of like real security sharing. Real-time telemetry data. >>And I want to answer this in two parts. The first part is really a lot of this wisdom is only in the community. It's a tribal knowledge. It's their informal feeds in from get up tickets. And you know, a lot of these things, what we're really doing with threat map, but as we are consolidating that and giving it out as a sort of platform that you can use, I like to go for free. This is the part you will never go to monetize this. And we are certain about disaster. What we are monetizing instead is you have, like I said, the x-ray or MRI scan of the cloud, which tells you what the pain points are. This is feel free. This is public collective good. This is a Patrick reader. This is for free. It's shocking. >>I took this long to get to that point, by the way, in this discussion. >>Yeah, >>This is this timing's perfect. >>Security is collective good. Right? And if you're doing open source, community-based, you know, programs like this is for the collector group. What we do look, this whole other set map is going to be open source. We going to make it a platform and our commercial version, which is called fetch Stryker, which is where we have our core IP, which is basically think about this way, right? If you figured out all the pain points and using tech map, or this was a free, and now you wanted the remedy for that pain feed to target a defense, we targeted quarantining of those statin workloads and all that stuff. And that's what our IP is. What we really do there is we said, look, you figured out the attack surface using tech fabric. Now I'm going to use threat Stryker to protect their attacks and stress >>Free. Not free to, or is that going to be Fort bang? >>Oh, that's for, okay. >>That's awesome. So you bring the goodness to the party, the goods to the party, again, share that collective, see where that goes. And the Stryker on top is how you guys monetize. >>And that's where we do some uniquely normal things. I would want to talk about that. If, if, if, if you know public probably for 30 seconds or so unique things we do in industry, which is basically being able to monitor what comes in, what goes out and what changes across time and space, because look, most of the modern attacks evolve over time and space, right? So you go to be able to see things like this. Here's a party structure, which has a vulnerability threats. Mapper told you that to strike. And what it does is it tells you a bunch of stress has a vulnerable again, know that somebody is sending a Melissa's HTP request, which has a malicious payload. And you know what, tomorrow there's a file system change. And there is outbound connection going to some funny place. That is the part that we're wanting this. >>Yeah. And you give away the tool to identify the threats and sell the hammer. >>That's giving you protection. >>Yeah. Yeah. Awesome. I love you guys love this product. I love how you're doing it. I got to ask you to define what is security as a microservice. >>So security is a microservice is a deployment modality for us. So defense, what defense has is one console. So defense is currently self posted by the customers within the infrastructure going forward. We'll also be launching a SAS version, the cloud version of it. But what happens as part of this deployment is they're running the management console, which is the gooey, and then a tiny sensor, which is collecting telemetric that is deployed as a microservice is what I'm saying. So you've got 10 containers running defenses level of container. That's, that's an eight or the Microsoft risk. And it utilizes, uh, EDP F you know, for tracing and all that stuff. Yeah. >>Awesome. Well, I think this is the beginning of a shift in the industry. You start to see dev ops and cloud native technologies become the operating model, not just dev dev ops are now in play and infrastructure as code, which is the ethos of a cloud generation is security is code. That's true. That's what you guys are doing. Thanks for coming on. Really appreciate it. Absolutely breaking news here in the queue, obviously great stuff. Open source continues to grow and win in the new model. Collaboration is the cube bringing you all the cover day one, the three days. I'm Jennifer, your host with Dave Nicholson. Thanks for watching.

(upbeat music) >> Back the cube here. I'm John Furrier with the cube. Thanks Adam in the studio. We've got two entrepreneurs here. Co-founders of LastMileXchange, Andrew Hoskin and James Grant. Guys, thanks for coming on the cube, >> John. Good to be here. >> Love to get the entrepreneur, both co-founders making it happen. I mean, the pandemic was either a tailwind or a headwind for companies and certainly the internet didn't break. Everything worked out great. So, let's just jump in, why don't we get into some of the questions. What does LMX do? Who are you guys? Take a quick minute to explain what you guys do. >> Sure. So, we're a software provider. We have a cloud-based SAS platform, which effectively it's a bit like a Skyscanner or an Expedia for networks. Carriers need to buy and sell networks from each other and we help them do that. And we have been in the cloud since day one. And so, that's what we do while we're here and it's a good place for us to tell you about it. >> I got it. I got to ask you, because one of the things being entrepreneur, you've got to read the tea leaves. One of the secrets of being a co-founder and doing anything entrepreneurial these days is you got to see the future, but then you've got to come back to the present and convince everybody, what's going on. >> Entrepreneurs: Yeah. >> What is the core value proposition? What's the day in the life of a conversation? I mean you're talking to Martians now, like, huh? What's the public cloud it's like, is it like, isn't it just the internet? It's changing. What's the value proposition? What's the conversation like? >> So, the value position for us is that we, you know, we work with our customers to accelerate the sales cycle through cloud based services. So, a lot of our customers are global tier one carriers. So, we're looking to automate their connectivity pricing, and we do that via a cloud-based solution. So it is vital to us. And particularly with having customers all across the globe, being able to sort of deploy cloud-based services makes life much easier. >> I got to ask you, one of the things that we love about cloud is the agilities. >> Yeah. >> Can you talk about the impact of what you guys are offering for the agility side. What's the impact of the consumer, the application developer, what's the impact? >> Clouds have a big play for us, big impact for our customers. So we provide our solution effectively, almost a plug and play for them. So, we do quoting really, really well. You want to know where a network is, you want to know the connectivity, we'll sort that out for you, and we can give you a solution that they can plug into their systems really quickly. In terms of, for us, when we first started, we had servers in data centers and managing software on that, but we moved to Amazon pretty early. And what we now have is, we can spin up a new customer environment in a day, which you know, from previously two, three weeks. So, cloud has been transformational for us and hopefully for our customers as well. >> And you guys target mainly carriers? >> Very much so, yeah. We're very much in the big carrier Telco space. The people that provide the fabric upon which all of this sits. >> Yeah. And then by the way, it's magic and this, it's robust. It's what we need, utilities, it's important. Last mile, obviously, as we all, some people look at it and say, go back decades, rug ban, you know, last mile is always that last nut to crack. 5G's here, the mobile sector is looking at massive growth. You're starting to see the cloud providers recognize that the edge is just another network connection. >> Yeah, absolutely. >> How do you guys see that evolving? What's going on? How do you see that affecting your business, the customers on the market? >> Well, so network, I mean, access is all about getting onto the network, whether you're talking cloud or whatever. So, if you can't get into the network, cloud is nothing. If you can't sort of back haul your 5G, you're stuck. So, what we're seeing is, even with 5G, as it rolls out, as people look to densify their networks, they still need to get all that voice stuff, all that data traffic onto fiber. So, we're seeing a lot of interest there still in knowing where connectivity options are, knowing where the network is. With James also, I mean, that other aspect of access, 10 years ago was all about fiber. But you were just telling me before about how increasingly carriers are using 5G as effectively a router in a box, ship it in by a DPD or FedEx out to a customer. >> Yeah. So typically we'll think about mobile as connecting your mobile phone, but now we're looking at sort of, mobile connecting buildings. And one of the key challenges when you're connecting a building with mobile is what the actual connectivity within the building is. So, often we will see mobile maps that show you that sort of connectivity at sort of, the outside level. But of course, you're actually going to have your infrastructure in the building. So, you need to know what the straight signal strength is there. So, we're actually working with a partner at the moment so that we can identify within a building, what the quality of the signal is. >> I mean, that's class, if you think about like, most people think of, oh, it just drops to the end point and then you've got more network behind it, wireless. You got now to work at home dynamics, IOT devices. So, you guys have the buy-sell side of things going on, you got the carriers buying and selling there. >> Entrepreneurs: Yeah, absolutely. >> And then, SD WAN is a huge market, >> Andrew: Absolutely. >> That's growing and, as well. >> And all of that relies on access. Do you know what I mean? Like, you can talk 5G, you can talk IOT. And of course, those are the exciting, sexy things in the industry. But underpinning all of that is a network. And you mentioned the word before and it's right, utility, you know, maybe it's not the sexy side of things, but you've got to have it, otherwise, nothing else works. >> You know, one of the things we do a lot of cloud cover, we cover all of Amazon shows here coming into Telco, the Telco, digital revolution that's going on here, you can see it. And some people aren't ready for it. Almost like, reminds me of the mainframe days back when I was growing up in college, it's like, oh, I'm not, I don't want to do the mainframe. I'm the new guy, I'm the young kid. I love this, a PC and mini computers. Here, it's the same thing. It's kind of like, okay, I see the cloud, but when you have infrastructure as code, >> Yeah. >> Everything gets fuzzy. >> Yeah. >> I mean, now you're talking about programmability. So, that edge at the application level, some say it's going to be a massive innovation enabler, which is going to change that infrastructure's code, which means that guys like you guys got to be able to provide programmable routes, programmable and, >> Yeah. And APR is our, and the programmability of the network, the whole interplay from whether it's quoting, whether it's ordering, whether it's delivering services, whether it's kind of somebody going into somewhere and saying, "I'd like a, a hundred gig into this building", pressing a button and 15 minutes later, everything rolls together to turn it up, is where the whole industry is going. >> Let's take that for a second. >> Sure. >> Just a mind blowing scenario right there. Sounds simple. >> Yeah. >> Compared to where we were just 15 years ago. >> Yeah. >> That scenario didn't exist. >> No. >> And it's hard. It's not trivial. >> No. >> It's not non-trivial. All right. So what's this mean for customers? Are they like buying this level now, like, are they like, where are they on the spectrum of, you know, buying and the progression of operationalizing their business to be fully robust, network end to end, visibility on workloads to network? >> I would say it often depends where the customer is. So, obviously we deal with global customers and that's one of our big selling points is that, you know, a lot of people are focusing on the US, the Western European market, you know, and the connectivity challenges that they're trying to solve there. Our customers have global customers who are looking for connectivity all throughout world. And often there'll be things like mining companies who don't have fiber going into them. And so, we need to be able to work with our customers and their suppliers to be able to automate everything, because you can only fully quote a network when you've got all the locations back. And if you're waiting for information coming back from Africa or from the former CIS, then you know, you're going to have a problem. And we're working with companies in Africa and Russia, Kazakhstan, at the moment to help them automate everything. >> You know what's interesting, I just, my mind just goes nuts here when thinking about what you guys do, because as people start rolling their own with applications, they're going to need to have this programmability, like almost on demand, they're going to need to have, I want to do a digital TV network, I want to provision something or something's hybrid or at the edge. >> You've got a football game, or you've got something like this where you need capacity, you need it quickly. You need it for an event. >> Yeah, exactly. And 5G's perfect. I mean, how many times we've all been at a soccer game or a football game. It's like, I got bars but I have no back haul. Like we all been there. >> Yeah. >> Why, oh? >> Saturated the network and everyone's doing the same thing. >> The radios working, the back haul's choking. I mean, this is real. >> Absolutely. >> How does, does 5G solve that? I mean, where does that get, how does that get solved? I mean, is it going to be ubiquitous? Truly 5G going to make us all work better? I mean, certainly for the end use of 5G is it provides speed, it provides capacity. And also for the operators it provides being able to get more people onto it. And so, and 5G is not my core strength, but it absolutely will be transformative. What I can comment on is, like you say, for an event like this or the football or anything, the Euros, it ultimately goes into a pipe. So, you've got to make sure that you've got to have the right connectivity there and the right capacity there, from the user's phone, through the towers, all the way into the network, all the way to the data center and back again. So the edge, everything, has to play together to do that, and probably, rolling it out quickly and making sure it's agile and making sure it's fast and making sure it's quick and reliable. That's what needs to all work together. I liked how you said you know, the Expedia of the networks. >> Andrew: Yeah. >> That immediately in my mind says, okay, ease of use. >> Andrew: Yeah. >> From consumption standpoint, what's the next level of growth for you guys? I'm almost imagining is programmability or cloudifying or amplifying it, make it rain. >> Yeah, certainly we are going to continue to push into, yeah, effectively digital transformation in fact, across telecoms is happening. You would think there would be a lot further ahead than it is. It's not. There are a lot of people still quoting, ordering manually. So, we're very much part of that, but certainly the ordering and the provisioning, like we've mentioned, that's a big part, but for the industry, and we're going to hopefully be part of that, or we expect to be part of that. So that's, and making sure that connectivity is there when you need it. You know, I'm here, what's there? A bit like flights, I'd like to fly to New York. Who can do it, how much will it cost? I'll buy that one please. And that's what networks should be as well. >> James, what's your vision on how the customers are progressing in their mindset? Obviously, you've got the blocking and tackling to do, you're in the market. Where are they going with the use case and the application? >> The customers are getting to the stage where they're expecting to be able to go into a portal and turn up services. So, as with many things that we're seeing throughout life today, you can go into an app, you can press a couple of buttons and you can, you can order something. So, that's what they're expecting is to be able to just go and say, I need a hundred mg here, press a few buttons. And in 10 minutes time, the circuit's not only quoted, but it's provisioned. At the moment, there's this sort of a digital divide between those that have the digitization in place and those that don't. And that's the sort of the key that we're trying to sort of help the industry with is the sort of the, the outliers and, and also the main carriers to make sure that it's not a sort of, a digital haves and a digital have-nots. >> I was just going to say that. So, if you have the digital haves and have-nots, is that a function of them just not being operationalized in their digitization? Or is it they're not set up for it or they don't have you guys? What's that have-not side of it? How do they become the haves? >> One of the biggest challenges is actually around the sort of, identifying the connectivity at a particular location. So, in some countries it's very easy to do, like the US, UK, Netherlands. We have nice sort of standard address formatting, and you can identify a building at roof level. And when it comes to turning up connectivity straight away, you want to make sure that you turn up the connectivity to the right building. And that's one of the challenges that we're seeing throughout sort of, some of the Eastern European and the LatAm, the Asian and the African markets. >> I mean, we saw what happened with Amazon instances. You've got spot instances, you get reserved instances, you're starting to see that mindset. That's a SAS mindset. >> Yeah. >> That's kind of where things are going. Is that, you guys see the same thing here or is it different? >> Yeah. Well, certainly at the enterprise space, they tend to make decisions over a longer scale. So there, maybe not so much that you sign contracts in a year's term et cetera, but yeah, certainly as a provider, a SAS provider, using all those things, the ability to to tune your expenses, tune your costs, even your resource, you know, you're turning up servers by the hour, by the minute is a big thing. And it takes a mindset change for us and our customers. >> If you don't mind me asking, how long have you guys been doing business as co-founders, when did it start? What was the guiding principle? How do you guys look back now? >> James and I met working for Verizon many years ago. You might've heard of them. And, we sort of did what we do now, in as much as James ran the commercial side of things, I ran the software side of things and we saw that connectivity was a universal problem. And so we saw our opportunity. We went out, we started LastMileXchange. We pivoted once or twice, still in the same space, but we eventually realized that where we are now was what the industry needed. And that's where we've been pushing now for quite a few years. >> I want to give you guys a lot of credit and a lot of props, congratulations. I think, you know, the digital divide has been a broadband challenge for many, many years and decades. Now, you've got that urban divide where people don't have access. And I heard stories during the pandemic that people had access in the region, but couldn't get it to the home, affordability, access, devices. These are new issues, the digital divide, they have connectivity options. >> Andrew: Yeah. >> But it's not really clear yet. So, you're starting to see a lot more of that going on. Of course, the rural areas. >> Andrew: Yeah. >> I live out in the countryside on a farm. So, I'm quite used to their challenges of connectivity. You know, when I first moved into my house, I ended up having to get to way satellite broadband and things have improved now. But when we're talking about 5G, you have people in London, they have 5G. 5G is something that I'm not going to see for three, four years probably. >> Globally, it'll democratize access because like we were saying, we're sitting in an enterprise. You can send out a rooter or a router with a SIM card in it. I mean, you can give a kid a mobile phone in the middle of, you know, Kenya, and he can have access to the world through the internet. So, you know, that increased capacity, that increased densification of networks. Okay, they're not all going to be on 5G today. James hasn't got 5G and he only lives 30 minutes out of London. But 3G, 4G, I think the gentlemen on one of the keynotes was talking there about 3G Plus. You know, effectively, that's going to roll out. The 5G's are going to be in New Yorks and London, but, >> Like, it's going to be bring your own G to your house soon. And I think this space ops is going to be great. And I think overall, just overall, the challenges and the topologies, you're going to start to see diversity in the network topology, and actually it's going to explode. >> Andrew: Yeah, absolutely. Absolutely. >> Going to be super exciting. Well, again, I think you guys are under something big. I think this idea of sasifying, making things programmable, infrastructure as code is going to be pretty big. So, thanks for coming on. And what's your take, real quick, of Cloud City. >> It's been great. We've just walked in. We both said, as we came in, we came in yesterday to set up and we were really blown away and the rest of our team arrived today and they were very impressed as well. I was going to say Telco D on the team, have done a really impressive job. >> I think you have to come here and see it to believe it because when we walked in, it was just like, this place is stunning. >> Awesome. Well that's the cube coverage, we're rocking and rolling here. We're going back to the studio to see Adam and the team. Back to you.

(upbeat music) >> From around the globe, it's theCUBE. With digital coverage of Postgres Vision 2021 brought to you by EDB. >> Well, good day, everybody. John Walls here on theCUBE. We continue our coverage here at Postgres Vision in 2021. Talking today with Andy Harris, who is the Chief Technology Officer at Osirium, a leader in the Privileged Access Management Space, and Andy, good day to you. Thanks for joining us here on theCUBE. >> Good morning to you and good afternoon, yes. >> That's right. Joining us from overseas over in England, we're on this side of the big pond, but nonetheless, we're joined by the power of Zoom. So again, thanks for the time. Andy, for those who aren't familiar who are watching about Osirium, share a little bit about your various service levels of what you provide, the kind of solutions you provide, and how you've achieved a great success in this space. >> Okay. I know these things, mine will be boring. So I'll just put a little slide up now, which is the minimum I think I can get away with which is that we're all about managing privilege. So that's privileged at the endpoint, Privileged Access Management, and Privileged Process Automation. So wherever a CIS admin has to do something on a machine that needs privilege, we like to be involved. Obviously, we like to be able to delegate all the way down to the business functions with Privileged Process Automation and with the EDB or the BDR part of that functionality in EDB that really fits in to our Privileged Access Management. So what I'll do just to take you away from our product. So I'll just quickly show you a slide of the architecture, which is as simple as we have these nodes. If you like the running ADB BDR and they can perform log-ins to a target device using privileged credentials, which we control when we might be really long up to about 128 characters. >> So Andy, if you would, I think you had put together a little show and tell you a demonstration for how when these systems are perhaps under siege if you will. That there are ways in which obviously you've developed to counter this and to be able to continue secure communications, which in the privilege assets world as you know is paramount. >> Yes, indeed. So I'll show you another slide, which gives you a kind of a overview of everything that's going on and you're going to see a little demonstration of two nodes here that has the BDL technology on and they can make these logins, and we have these characters, Bob and Allison. I've just noticed how it marks in department turn Alice to Allison. they should really be Alice because you get Bob, Alice, Carol, Dave, which are the standard encryption users. And what we're going to do is we're going to demonstrate that you can have breaks in the network. So I'm just sharing the network breaks slide. I'm showing the second network break slide. And then we have this function that we've built which we're going to demonstrate for you today, which is called evil beatings. And what it does is whilst there is a politician in the network, we are going to refresh many thousands of times the credentials on the target device. And then we're going to heal the break in the network and then prove that everything is still working. So right now, I'm going to zoom over to my live connection, terminal connections to the machine. And I'm going to run this command here, which is Python EV3. And I'm going to put a hundred cycles in it which is going to do around about 10,000 password refreshes. Okay. And I'm then going to go over to Chrome, and I should have a system here waiting for me. And in this system, you'll see that I've got the device demo and I've got this come online, SSH. And if I click on this I've got a live connection to this machine. Even whilst I have a huge number of queued up and I'll just show you the queued out connections through the admin interface. The system is working extremely hard at the moment. And in fact, if I show you this slide here, you can see that I have all of these queued credential resets and that is giving our system an awful lot of grief. Yeah. I can go back to the device connection and it is all here still top. Why not? And as you can see, it is all working perfectly. And if I was a user of EDB, I think this has to be one of the demonstrations I'd be interested in because it's one of the first things that we did when we dropped that functionality into our products. We wanted to know how well it would work under extreme conditions because you don't think of extreme conditions as normal working, but whenever you have 10 nodes in different countries, there will always be a network break somewhere and someone will always need to be refreshing passwords a ridiculous rates of knots. So Andy let's talk about this kind of the notion that you're providing here, this about accountability and visibility, audit-ability, all these insights that you're providing through this kind of demonstration you've given us how critical is that today, especially when we know there are so many possible intrusions and so many opportunities with legacy systems and new apps and all of this. I mean talking about those three pillars, if you will, the importance of that and what we just saw in terms of providing that peace of mind that everybody wants in their system. >> That's a cracking question. I'm going to enjoy that question. Legacy systems, that's a really good question. If you, we have NHS, which is our national health service and we have hospitals and you have hospitals every country has hospitals. And the equipment that they use like the MRI scanners, the electro-microscope, some of the blood analysis machines, the systems in those costs multiple Gillions of dollars or should use dollars euros, dollars, pounds and the operating systems running those systems, the lifetime of that piece of equipment is much much longer than the lifetime of an operating system. So we glibly throw around this idea of legacy systems and to a hospital that's a system that's a mere five years old and has got to be delivering for another 15 years. But in reality, all of this stuff gets, acquires vulnerabilities because our adversaries the people that want to do organizations bad things ransomware and all the rest of it they are spending all that time learning about the vulnerabilities of old systems. So the beauty of what we do is being able to take those old legacy systems and put a zero trust safety shell around them, and then use extremely long credentials which can't be cracked. And then we make sure that those credentials don't go anywhere near any workstations. But what they do do, is they're inside that ADB database encrypted with a master encryption key, and they make that jump just inside the zero trust boundary so that Bob and Alice outside can get administration connections inside for them to work. So what we're doing is providing safety for those legacy systems. We are also providing an environment for old apps to run in as well. So we have something called a map server which I didn't think you'd asked us that question. I'd have to find you some slides or presentations, which we want to do. We have a map server, which is effectively a very protected window server, and you can put your old applications on them and you can let them age gracefully and carry on running. Dot net 3.5 and all of those old things. And we can map your connection into the older application and then map those connections out. But in terms of the other aspects of it is the hospital stay open 24 hours a day banks run 24 hours a day and they need to be managed from anywhere. We're in a global pandemic, people are working from home. That means that people are working from laptops and all sorts of things that haven't been provisioned by centrality and could all have all sorts of threats and problems to them. And being able to access any time is really important. And because we are changing the credentials on these machines on a regular basis, you cannot lose one. It's absolutely critical. You cannot go around losing Windows active directory domain credentials it just can't be done. And if you have a situation where you've just updated a password and you've had a failure one of those 10 nodes has the correct set of credentials. And when the system heals, you have to work out which one of the 10 it is and the one that did it last must be the one that updates all the other 10 nodes. And I think the important thing is as Osirium we have the responsibility for doing the updates and we have the responsibility for tracking all those things. But we hand the responsibility of making sure that all the other 10 nodes are up to date which just drop it into bi-directional replication and it just happens. And you've seen it happen. I mean, might be just for the fun of it, We'll go back to that demonstration Chrome, and you can see we're still connected to that machine. That's all still running fine but we could go off to our management thing, refresh it and you see that everything there is successful. I can go to a second machine and I can make a second connection to that device. Yet, in the meantime that password has been changed, Oh, I mean, I wouldn't like to tell you how many times it's been changed. I need to be on a slightly different device. I was going to do a reveal password for you, I'll make another connection but the passwords will be typically, do a top on that just to create some more load. But the passwords will typically be... I'll come back to me. They'll typically be 128 characters long. >> Andy, if I could, I mean, 'cause I think you're really showing this very complex set of challenges that you have these days, right? In terms of providing access to multiple devices across, in multiple networking challenges, when you talk to your prospective clients about the kind of how this security perimeters changed, it's very different now than it was four or five years ago. What are the key points that you want them to take away from your discussion about how they have to think about security and access especially in this day and age when we've even seen here in the States. Some very serious intrusions that I think certainly get everybody's attention. >> That's a great question again. They're all... The way that I would answer that question would definitely depend on the continent that I was talking to. But my favorite answer will be a European answer, so I'll give you a European answer. One of the things that you're doing when you come along and provide Privileged Access Management to a traditional IT team, is your taking away the sysadmins right now, before privilege access, they will know the passwords. They will be keeping the passwords in a password vault or something like this. So they own the passwords, they own the credentials. And when you come along with a product like privilege access management you're taking over management of those credentials and you're protecting those systems from a whole wide range of threats. And one of those threats is from the system administrators themselves. And they understand that. So what I would say, it's an interesting question. 'Cause I'm like, I'm thinking I've got two ways of answering I can answer as if I'm talking to management or as if I'm talking to the people who are actually going to use the products and I feel more aligned with the, I feel more aligned with the actual users. >> Yeah, I think let's just, we'll focus on that and I'll let you know, we just have a moment or two left. So if you could maybe boil it down for me a little bit. >> Boiling it down, I would say now look here CIS admins. It's really important that you get your job done but you need to understand that those privileged accounts that you're using on those systems are absolute gold dust if they get into the hands of your adversaries and you need protections income away from those adversaries, but we trust you and we are going to get you the access to your machines as fast as possible. So we're a little bit like a nightclub bouncer but we're like the Heineken of nightclub bounces. When you arrive, we know it's you and we're going to get you to your favorite machine logged on as domain admin, as fast as possible. And while you're there, we're going to cut that session recording of you. And just keep you safe and on the right side. >> All right, I'm going to enjoy my night in the nightclub. Now I can sleep easy tonight knowing that Andy Harris and Osirium are on the case. Thanks, Andy. Andy Harris speaking with us. So the Chief Technology Officer from Osirium as part of our Postgres vision, 2021, coverage here on theCUBE. (upbeat music) >> From theCUBE studios in Palo Alto, in Boston connecting with thought leaders all around the world. This is theCUBE conversation.

>>Hey, welcome to the live panel. My name is Brett. I am your host, and indeed we are live. In fact, if you're curious about that, if you don't believe us, um, let's just show a little bit of the browser real quick to see. Yup. There you go. We're live. So, all right. So how this is going to work is I'm going to bring in some guests and, uh, in one second, and we're going to basically take your questions on the topic designer of the day, that continuous integration testing. Uh, thank you so much to my guests welcoming into the panel. I've got Carlos, Nico and Mandy. Hello everyone. >>Hello? All right, >>Let's go. Let's go around the room and all pretend we don't know each other and that the internet didn't read below the video who we are. Uh, hi, my name is Brett. I am a Docker captain, which means I'm supposed to know something about Docker. I'm coming from Virginia Beach. I'm streaming here from Virginia Beach, Virginia, and, uh, I make videos on the internet and courses on you to me, Carlos. Hey, >>Hey, what's up? I'm Carlos Nunez. I am a solutions architect, VMware. I do solution things with computers. It's fun. I live in Dallas when I'm moving to Houston in a month, which is where I'm currently streaming. I've been all over the Northeast this whole week. So, um, it's been fun and I'm excited to meet with all of you and talk about CIA and Docker. Sure. >>Yeah. Hey everyone. Uh, Nico, Khobar here. I'm a solution engineer at HashiCorp. Uh, I am streaming to you from, uh, the beautiful Austin, Texas. Uh, ignore, ignore the golden gate bridge here. This is from my old apartment in San Francisco. Uh, just, uh, you know, keeping that, to remember all the good days, um, that that lived at. But, uh, anyway, I work at Patrick Corp and I work on all things, automation, um, and cloud and dev ops. Um, and I'm excited to be here and Mandy, >>Hi. Yeah, Mandy Hubbard. I am streaming from Austin, Texas. I am, uh, currently a DX engineer at ship engine. Um, I've worked in QA and that's kind of where I got my, uh, my Docker experience and, um, uh, moving into DX to try and help developers better understand and use our products and be an advocate for them. >>Nice. Well, thank you all for joining me. Uh, I really appreciate you taking the time out of your busy schedule to be here. And so for those of you in chat, the reason we're doing this live, because it's always harder to do things live. The reason we're here is to answer a question. So we didn't come with a bunch of slides and demos or anything like that. We're here to talk amongst ourselves about ideas and really here for you. So we've, we obviously, this is about easy CII, so we're, we're going to try to keep the conversation around testing and continuous integration and all the things that that entails with containers. But we may, we may go down rabbit holes. We may go veer off and start talking about other things, and that's totally fine if it's in the realm of dev ops and containers and developer and ops workflows, like, Hey, it's, it's kinda game. >>And, uh, these people have a wide variety of expertise. They haven't done just testing, right? We, we live in a world where you all kind of have to wear many hats. So feel free to, um, ask what you think is on the top of your mind. And we'll do our best to answer. It may, might not be the best answer or the correct answer, but we're going to do our best. Um, well, let's get it start off. Uh, let's, let's get a couple of topics to start off with. Uh, th the, the easy CGI was my, one of my three ideas. Cause he's the, one of the things that I'm most excited about is the innovation we're seeing around easier testing, faster testing, automated testing, uh, because as much as we've all been doing this stuff for, you know, 15 years, since 20 years since the sort of Jenkins early days, um, it it's, it seems like it's still really hard and it's still a lot of work. >>So, um, let's go around the room real quick, and everybody can just kind of talk for a minute about like your experience with testing and maybe some of your pain points, like what you don't like about our testing world. Um, and we can talk about some pains, cause I think that will lead us to kind of talk about what, what are the things we're seeing now that might be better, uh, ideas about how to do this. I know for me, uh, testing, obviously there's the code part, but just getting it automated, but mostly getting it in the hands of developers so that they can control their own testing. And don't have to go talk to a person to run that test again, or the mysterious Jenkins platform somewhere. I keep mentioning Jenkins cause it's, it is still the dominant player out there. Um, so for me, I'm, I'm, I, I don't like it when I'm walking into a room and there's, there's only one or two people that know how the testing works or know how to make the new tests go into the testing platform and stuff like that. So I'm always trying to free those things so that any of the developers are enabled and empowered to do that stuff. So someone else, Carlos, anybody, um, >>Oh, I have a lot of opinions on that. Having been a QA engineer for most of my career. Um, the shift that we're saying is everyone is dev ops and everyone is QA. Th the issue I see is no one asked developers if they wanted to be QA. Um, and so being the former QA on the team, when there's a problem, even though I'm a developer and we're all running QA, they always tend to come to the one of the former QA engineers. And they're not really owning that responsibility and, um, and digging in. So that's kind of what I'm saying is that we're all expected to test now. And some people, well, some people don't know how it's, uh, for me it was kind of an intuitive skill. It just kind of fit with my personality, but not knowing what to look for, not knowing what to automate, not even understanding how your API end points are used by your front end to know what to test when a change is made. It's really overwhelming for developers. And, um, we're going to need to streamline that and, and hold their hands a little bit until they get their feet wet with also being QA. >>Right. Right. So, um, uh, Carlos, >>Yeah, uh, testing is like, Tesla is one of my favorite subjects to talk about when I'm baring with developers. And a lot of it is because of what Mandy said, right? Like a lot of developers now who used to write a test and say, Hey, QA, go. Um, I wrote my unit tests. Now write the rest of the test. Essentially. Now developers are expected to be able to understand how testing, uh, testing methodologies work, um, in their local environments, right? Like they're supposed to understand how to write an integration tasks federate into and tasks, a component test. And of course, how to write unit tests that aren't just, you know, assert true is true, right? Like more comprehensive, more comprehensive, um, more high touch unit tests, which include things like mocking and stubbing and spine and all that stuff. And, you know, it's not so much getting those tests. Well, I've had a lot of challenges with developers getting those tests to run in Docker because of usually because of dependency hell, but, um, getting developers to understand how to write tests that matter and mean something. Um, it's, it's, it can be difficult, but it's also where I find a lot of the enjoyment of my work comes into play. So yeah. I mean, that's the difficulty I've seen around testing. Um, big subject though. Lots to talk about there. >>Yeah. We've got, we've already got so many questions coming in. You already got an hour's worth of stuff. So, uh, Nico 81st thoughts on that? >>Yeah, I think I definitely agree with, with other folks here on the panel, I think from a, um, the shift from a skillset perspective that's needed to adopt the new technologies, but I think from even from, uh, aside from the organizational, um, and kind of key responsibilities that, that the new developers have to kinda adapt to and, and kind of inherit now, um, there's also from a technical perspective as there's, you know, um, more developers are owning the full stack, including the infrastructure piece. So that adds a lot more to the plate in Tim's oaf, also testing that component that they were not even, uh, responsible for before. Um, and, um, also the second challenge that, you know, I'm seeing is that on, you know, the long list of added, um, uh, tooling and, you know, there's new tool every other day. Um, and, um, that kind of requires more customization to the testing, uh, that each individual team, um, any individual developer Y by extension has to learn. Uh, so the customization, uh, as well as the, kind of the scope that had, uh, you know, now in conferences, the infrastructure piece, um, uh, both of act to the, to the challenges that we're seeing right now for, um, for CGI and overall testing, um, uh, the developers are saying, uh, in, in the market today. >>Yeah. We've got a lot of questions, um, about all the, all the different parts of this. So, uh, let me just go straight to them. Cause that's why we're here is for the people, uh, a lot of people asking about your favorite tools and in one of this is one of the challenges with integration, right? Is, um, there is no, there are dominant players, but there, there is such a variety. I mean, every one of my customers seems like they're using a different workflow and a different set of tools. So, and Hey, we're all here to just talk about what we're, what we're using, uh, you know, whether your favorite tools. So like a lot of the repeated questions are, what are your favorite tools? Like if you could create it from scratch, uh, what would you use? Pierre's asking, you know, GitHub actions sounds like they're a fan of GitHub actions, uh, w you know, mentioning, pushing the ECR and Docker hub and, uh, using vs code pipeline, I guess there may be talking about Azure pipelines. Um, what, what's your preferred way? So, does anyone have any, uh, thoughts on that anyone want to throw out there? Their preferred pipeline of tooling? >>Well, I have to throw out mine. I might as Jenkins, um, like kind of a honorary cloud be at this point, having spoken a couple of times there, um, all of the plugins just make the functionality. I don't love the UI, but I love that it's been around so long. It has so much community support, and there are so many plugins so that if you want to do something, you don't have to write the code it's already been tested. Um, unfortunately I haven't been able to use Jenkins in, uh, since I joined ship engine, we, most of our, um, our, our monolithic core application is, is team city. It's a dotnet application and TeamCity plays really well with.net. Um, didn't love it, uh, Ms. Jenkins. And I'm just, we're just starting some new initiatives that are using GitHub actions, and I'm really excited to learn, to learn those. I think they have a lot of the same functionality that you're looking for, but, um, much more simplified in is right there and get hubs. So, um, the integration is a lot more seamless, but I do have to go on record that my favorite CICT tools Jenkins. >>All right. You heard it here first people. All right. Anyone else? You're muted? I'm muted. Carlin says muted. Oh, Carla says, guest has muted themselves to Carlos. You got to unmute. >>Yes. I did mute myself because I was typing a lot, trying to, you know, try to answer stuff in the chat. And there's a lot of really dark stuff in there. That's okay. Two more times today. So yeah, it's fine. Yeah, no problem. So totally. And it's the best way to start a play more. So I'm just going to go ahead and light it up. Um, for enterprise environments, I actually am a huge fan of Jenkins. Um, it's a tool that people really understand. Um, it has stood the test of time, right? I mean, people were using Hudson, but 15 years ago, maybe longer. And, you know, the way it works, hasn't really changed very much. I mean, Jenkins X is a little different, but, um, the UI and the way it works internally is pretty familiar to a lot of enterprise environments, which is great. >>And also in me, the plugin ecosystem is amazing. There's so many plugins for everything, and you can make your own if you know, Java groovy. I'm sure there's a perfect Kotlin in there, but I haven't tried myself, but it's really great. It's also really easy to write, um, CIS code, which is something I'm a big fan of. So Jenkins files have been, have worked really well for me. I, I know that I can get a little bit more complex as you start to build your own models and such, but, you know, for enterprise enterprise CIO CD, if you want, especially if you want to roll your own or own it yourself, um, Jenkins is the bellwether and for very good reason now for my personal projects. And I see a lot on the chat here, I think y'all, y'all been agreed with me get hub actions 100%, my favorite tool right now. >>Um, I love GitHub actions. It's, it's customizable, it's modular. There's a lot of plugins already. I started using getting that back maybe a week after when GA and there was no documentation or anything. And I still, it was still my favorite CIA tool even then. Um, and you know, the API is really great. There's a lot to love about GitHub actions and, um, and I, and I use it as much as I can from my personal project. So I still have a soft spot for Travis CAI. Um, you know, they got acquired and they're a little different now trying to see, I, I can't, I can't let it go. I just love it. But, um, yeah, I mean, when it comes to Seattle, those are my tools. So light me up in the comments I will respond. Yeah. >>I mean, I, I feel with you on the Travis, the, I think, cause I think that was my first time experiencing, you know, early days get hub open source and like a free CIA tool that I could describe. I think it was the ammo back then. I don't actually remember, but yeah, it was kind of an exciting time from my experience. There was like, oh, this is, this is just there as a service. And I could just use it. It doesn't, it's like get hub it's free from my open source stuff. And so it does have a soft spot in my heart too. So yeah. >>All right. We've got questions around, um, cam, so I'm going to ask some questions. We don't have to have these answers because sometimes they're going to be specific, but I want to call them out because people in chat may have missed that question. And there's probably, you know, that we have smart people in chat too. So there's probably someone that knows the answer to these things. If, if it's not us, um, they're asking about building Docker images in Kubernetes, which to me is always a sore spot because it's Kubernetes does not build images by default. It's not meant for that out of the gate. And, uh, what is the best way to do this without having to use privileged containers, which privileged containers just implying that yeah, you, you, it probably has more privileges than by default as a container in Kubernetes. And that is a hard thing because, uh, I don't, I think Docker doesn't lie to do that out of the gate. So I don't know if anyone has an immediate answer to that. That's a pretty technical one, but if you, if you know the answer to that in chat, call it out. >>Um, >>I had done this, uh, but I'm pretty sure I had to use a privileged, um, container and install the Docker Damon on the Kubernetes cluster. And I CA I can't give you a better solution. Um, I've done the same. So, >>Yeah, uh, Chavonne asks, um, back to the Jenkins thing, what's the easiest way to integrate Docker into a Jenkins CICB pipeline. And that's one of the challenges I find with Jenkins because I don't claim to be the expert on Jenkins. Is there are so many plugins because of this, of this such a huge ecosystem. Um, when you go searching for Docker, there's a lot that comes back, right. So I, I don't actually have a preferred way because every team I find uses it differently. Um, I don't know, is there a, do you know if there's a Jenkins preferred, a default plugin? I don't even know for Docker. Oh, go ahead. Yeah. Sorry for Docker. And jacon sorry, Docker plugins for Jenkins. Uh, as someone's asking like the preferred or easy way to do that. Um, and I don't, I don't know the back into Jenkins that well, so, >>Well, th the new, the new way that they're doing, uh, Docker builds with the pipeline, which is more declarative versus the groovy. It's really simple, and their documentation is really good. They, um, they make it really easy to say, run this in this image. So you can pull down, you know, public images and add your own layers. Um, so I don't know the name of that plugin, uh, but I can certainly take a minute after this session and going and get that. Um, but if you really are overwhelmed by the plugins, you can just write your, you know, your shell command in Jenkins. You could just by, you know, doing everything in bash, calling the Docker, um, Damon directly, and then getting it working just to see that end to end, and then start browsing for plugins to see if you even want to use those. >>The plugins will allow more integration from end to end. Some of the things that you input might be available later on in the process for having to manage that yourself. But, you know, you don't have to use any of the plugins. You can literally just, you know, do a block where you write your shell command and get it working, and then decide if, for plugins for you. Um, I think it's always under important to understand what is going on under the hood before you, before you adopt the magic of a plugin, because, um, once you have a problem, if you're, if it's all a lockbox to you, it's going to be more difficult to troubleshoot. It's kind of like learning, get command line versus like get cracking or something. Once, once you get in a bind, if you don't understand the underlying steps, it's really hard to get yourself out of a bind, versus if you understand what the plugin or the app is doing, then, um, you can get out of situations a lot easier. That's a good place. That's, that's where I'd start. >>Yeah. Thank you. Um, Camden asks better to build test environment images, every commit in CII. So this is like one of those opinions of we're all gonna have some different, uh, or build on build images on every commit, leveraging the cash, or build them once outside the test pile pipeline. Um, what say you people? >>Uh, well, I I've seen both and generally speaking, my preference is, um, I guess the ant, the it's a consultant answer, right? I think it depends on what you're trying to do, right. So if you have a lot of small changes that are being made and you're creating images for each of those commits, you're going to have a lot of images in your, in your registry, right? And on top of that, if you're building those images, uh, through CAI frequently, if you're using Docker hub or something like that, you might run into rate limiting issues because of Docker's new rate, limiting, uh, rate limits that they put in place. Um, but that might be beneficial if the, if being able to roll back between those small changes while you're testing is important to you. Uh, however, if all you care about is being able to use Docker images, um, or being able to correlate versions to your Docker images, or if you're the type of team that doesn't even use him, uh, does he even use, uh, virgins in your image tags? Then I would think that that might be a little, much you might want to just have in your CIO. You might want to have a stage that builds your Docker images and Docker image and pushes it into your registry, being done first particular branches instead of having to be done on every commit regardless of branch. But again, it really depends on the team. It really depends on what you're building. It really depends on your workflow. It can depend on a number of things like a curse sometimes too. Yeah. Yeah. >>Once had two points here, you know, I've seen, you know, the pattern has been at every, with every, uh, uh, commit, assuming that you have the right set of tests that would kind of, uh, you would benefit from actually seeing, um, the, the, the, the testing workflow go through and can detect any issue within, within the build or whatever you're trying to test against. But if you're just a building without the appropriate set of tests, then you're just basically consuming almond, adding time, as well as all the, the image, uh, stories associated with it without treaty reaping the benefit of, of, of this pattern. Uh, and the second point is, again, I think if you're, if you're going to end up doing a per commit, uh, definitely recommend having some type of, uh, uh, image purging, um, uh, and, and, and garbage collection process to ensure that you're not just wasting, um, all the stories needed and also, um, uh, optimizing your, your bill process, because that will end up being the most time-consuming, um, um, you know, within, within your pipeline. So this is my 2 cents on this. >>Yeah, that's good stuff. I mean, those are both of those are conversations that could lead us into the rabbit hole for the rest of the day on storage management, uh, you know, CP CPU minutes for, uh, you know, your build stuff. I mean, if you're in any size team, more than one or two people, you immediately run into headaches with cost of CIA, because we have now the problem of tools, right? We have so many tools. We can have the CIS system burning CPU cycles all day, every day, if we really wanted to. And so you re very quickly, I think, especially if you're on every commit on every branch, like that gets you into a world of cost mitigation, and you probably are going to have to settle somewhere in the middle on, uh, between the budget, people that are saying you're spending way too much money on the CII platform, uh, because of all these CPU cycles, and then the developers who would love to have everything now, you know, as fast as possible and the biggest, biggest CPU's, and the biggest servers, and have the bills, because the bills can never go fast enough, right. >>There's no end to optimizing your build workflow. Um, we have another question on that. This is another topic that we'll all probably have different takes on is, uh, basically, uh, version tags, right? So on images, we, we have a very established workflow in get for how we make commits. We have commit shots. We have, uh, you know, we know get tags and there's all these things there. And then we go into images and it's just this whole new world that's opened up. Like there's no real consensus. Um, so what, what are your thoughts on the strategy for teams in their image tag? Again, another, another culture thing. Um, commander, >>I mean, I'm a fan of silver when we have no other option. Um, it's just clean and I like the timestamp, you know, exactly when it was built. Um, I don't really see any reason to use another, uh, there's just normal, incremental, um, you know, numbering, but I love the fact that you can pull any tag and know exactly when it was created. So I'm a big fan of bar, if you can make that work for your organization. >>Yep. People are mentioned that in chat, >>So I like as well. Uh, I'm a big fan of it. I think it's easy to be able to just be as easy to be able to signify what a major changes versus a minor change versus just a hot fix or, you know, some or some kind of a bad fix. The problem that I've found with having teams adopt San Bernardo becomes answering these questions and being able to really define what is a major change, what is a minor change? What is a patch, right? And this becomes a bit of an overhead or not so much of an overhead, but, uh, uh, uh, a large concern for teams who have never done versioning before, or they never been responsible for their own versioning. Um, in fact, you know, I'm running into that right now, uh, with, with a client that I'm working with, where a lot, I'm working with a lot of teams, helping them move their applications from a legacy production environment into a new one. >>And in doing so, uh, versioning comes up because Docker images, uh, have tags and usually the tax correlate to versions, but some teams over there, some teams that I'm working with are only maintaining a script and others are maintaining a fully fledged JAK, three tier application, you know, with lots of dependencies. So telling the script, telling the team that maintains a script, Hey, you know, you should use somber and you should start thinking about, you know, what's major, what's my number what's patch. That might be a lot for them. And for someone or a team like that, I might just suggest using commit shots as your versions until you figure that out, or maybe using, um, dates as your version, but for the more for the team, with the larger application, they probably already know the answers to those questions. In which case they're either already using Sember or they, um, or they may be using some other version of the strategy and might be in December, might suit them better. So, um, you're going to hear me say, it depends a lot, and I'm just going to say here, it depends. Cause it really does. Carlos. >>I think you hit on something interesting beyond just how to version, but, um, when to consider it a major release and who makes those decisions, and if you leave it to engineers to version, you're kind of pushing business decisions down the pipe. Um, I think when it's a minor or a major should be a business decision and someone else needs to make that call someone closer to the business should be making that call as to when we want to call it major. >>That's a really good point. And I add some, I actually agree. Um, I absolutely agree with that. And again, it really depends on the team that on the team and the scope of it, it depends on the scope that they're maintaining, right? And so it's a business application. Of course, you're going to have a product manager and you're going to have, you're going to have a product manager who's going to want to make that call because that version is going to be out in marketing. People are going to use it. They're going to refer to and support calls. They're going to need to make those decisions. Sember again, works really, really well for that. Um, but for a team that's maintaining the scripts, you know, I don't know, having them say, okay, you must tell me what a major version is. It's >>A lot, but >>If they want it to use some birds great too, which is why I think going back to what you originally said, Sember in the absence of other options. I think that's a good strategy. >>Yeah. There's a, there's a, um, catching up on chat. I'm not sure if I'm ever going to catch up, but there's a lot of people commenting on their favorite CII systems and it's, and it, it just goes to show for the, the testing and deployment community. Like how many tools there are out there, how many tools there are to support the tools that you're using. Like, uh, it can be a crazy wilderness. And I think that's, that's part of the art of it, uh, is that these things are allowing us to build our workflows to the team's culture. Um, and, uh, but I do think that, you know, getting into like maybe what we hope to be at what's next is I do hope that we get to, to try to figure out some of these harder problems of consistency. Uh, one of the things that led me to Docker at the beginning to begin with was the fact that it wa it created a consistent packaging solution for me to get my code, you know, off of, off of my site of my local system, really, and into the server. >>And that whole workflow would at least the thing that I was making at each step was going to be the same thing used. Right. And that, that was huge. Uh, it was also, it also took us a long time to get there. Right. We all had to, like Docker was one of those ones that decade kind of ideas of let's solidify the, enter, get the consensus of the community around this idea. And we, and it's not perfect. Uh, you know, the Docker Docker file is not the most perfect way to describe how to make your app, but it is there and we're all using it. And now I'm looking for that next piece, right. Then hopefully the next step in that, um, that where we can all arrive at a consensus so that once you hop teams, you know, okay. We all knew Docker. We now, now we're all starting to get to know the manifests, but then there's this big gap in the middle where it's like, it might be one of a dozen things. Um, you know, so >>Yeah, yeah. To that, to that, Brett, um, you know, uh, just maybe more of a shameless plug here and wanting to kind of talk about one of the things that I'm on. So excited, but I work, I work at Tasha Corp. I don't know anyone, or I don't know if many people have heard of, um, you know, we tend to focus a lot on workflows versus technologies, right. Because, you know, as you can see, even just looking at the chat, there's, you know, ton of opinions on the different tooling, right. And, uh, imagine having, you know, I'm working with clients that have 10,000 developers. So imagine taking the folks in the chat and being partnered with one organization or one company and having to make decisions on how to build software. Um, but there's no way you can conversion one or, or one way or one tool, uh, and that's where we're facing in the industry. >>So one of the things that, uh, I'm pretty excited about, and I don't know if it's getting as much traction as you know, we've been focused on it. This is way point, which is a project, an open source project. I believe we got at least, uh, last year, um, which is, it's more of, uh, it's, it is aim to address that really, uh, uh, Brad set on, you know, to come to tool to, uh, make it extremely easy and simple. And, you know, to describe how you want to build, uh, deploy or release your application, uh, in, in a consistent way, regardless of the tools. So similar to how you can think of Terraform and having that pluggability to say Terraform apply or plan against any cloud infrastructure, uh, without really having to know exactly the details of how to do it, uh, this is what wave one is doing. Um, and it can be applied with, you know, for the CIA, uh, framework. So, you know, task plugability into, uh, you know, circle CEI tests to Docker helm, uh, Kubernetes. So that's the, you know, it's, it's a hard problem to solve, but, um, I'm hopeful that that's the path that we're, you know, we'll, we'll eventually get to. So, um, hope, you know, you can, you can, uh, see some of the, you know, information, data on it, on, on HashiCorp site, but I mean, I'm personally excited about it. >>Yeah. Uh I'm to gonna have to check that out. And, um, I told you on my live show, man, we'll talk about it, but talk about it for a whole hour. Uh, so there's another question here around, uh, this, this is actually a little bit more detailed, but it is one that I think a lot of people deal with and I deal with a lot too, is essentially the question is from Cameron, uh, D essentially, do you use compose in your CIO or not Docker compose? Uh, because yes I do. Yeah. Cause it, it, it, it solves so many problems am and not every CGI can, I don't know, there's some problems with a CIO is trying to do it for me. So there are pros and cons and I feel like I'm still on the fence about it because I use it all the time, but also it's not perfect. It's not always meant for CIA. And CIA sometimes tries to do things for you, like starting things up before you start other parts and having that whole order, uh, ordering problem of things anyway. W thoughts and when have thoughts. >>Yes. I love compose. It's one of my favorite tools of all time. Um, and the reason why it's, because what I often find I'm working with teams trying to actually let me walk that back, because Jack on the chat asked a really interesting question about what, what, what the hardest thing about CIS for a lot of teams. And in my experience, the hardest thing is getting teams to build an app that is the same app as what's built in production. A lot of CGI does things that are totally different than what you would do in your local, in your local dev. And as a result of that, you get, you got this application that either doesn't work locally, or it does work, but it's a completely different animal than what you would get in production. Right? So what I've found in trying to get teams to bridge that gap by basically taking their CGI, shifting the CII left, I hate the shift left turn, but I'll use it. >>I'm shifting the CIO left to your local development is trying to say, okay, how do we build an app? How do we, how do we build mot dependencies of that app so that we can build so that we can test our app? How do we run tests, right? How do we build, how do we get test data? And what I found is that trying to get teams to do all this in Docker, which is normally a first for a lot of teams that I'm working with, trying to get them all to do all of this. And Docker means you're running Docker, build a lot running Docker, run a lot. You're running Docker, RM a lot. You ran a lot of Docker, disparate Docker commands. And then on top of that, trying to bridge all of those containers together into a single network can be challenging without compose. >>So I like using a, to be able to really easily categorize and compartmentalize a lot of the things that are going to be done in CII, like building a Docker image, running tests, which is you're, you're going to do it in CII anyway. So running tests, building the image, pushing it to the registry. Well, I wouldn't say pushing it to the registry, but doing all the things that you would do in local dev, but in the same network that you might have a mock database or a mock S3 instance or some of something else. Um, so it's just easy to take all those Docker compose commands and move them into your Yammel file using the hub actions or your dankest Bob using Jenkins, or what have you. Right. It's really, it's really portable that way, but it doesn't work for every team. You know, for example, if you're just a team that, you know, going back to my script example, if it's a really simple script that does one thing on a somewhat routine basis, then that might be a lot of overhead. Um, in that case, you know, you can get away with just Docker commands. It's not a big deal, but the way I looked at it is if I'm, if I'm building, if I build something that's similar to a make bile or rate file, or what have you, then I'm probably gonna want to use Docker compose. If I'm working with Docker, that's, that's a philosophy of values, right? >>So I'm also a fan of Docker compose. And, um, you know, to your point, Carlos, the whole, I mean, I'm also a fan of shifting CEI lift and testing lift, but if you put all that logic in your CTI, um, it changes the L the local development experience from the CGI experience. Versus if you put everything in a compose file so that what you build locally is the same as what you build in CGI. Um, you're going to have a better experience because you're going to be testing something more, that's closer to what you're going to be releasing. And it's also very easy to look at a compose file and kind of, um, understand what the dependencies are and what's happening is very readable. And once you move that stuff to CGI, I think a lot of developers, you know, they're going to be intimidated by the CGI, um, whatever the scripting language is, it's going to be something they're going to have to wrap their head around. >>Um, but they're not gonna be able to use it locally. You're going to have to have another local solution. So I love the idea of a composed file use locally, um, especially if he can Mount the local workspace so that they can do real time development and see their changes in the exact same way as it's going to be built and tested in CGI. It gives developers a high level of confidence. And then, you know, you're less likely to have issues because of discrepancies between how it was built in your local test environment versus how it's built in NCI. And so Docker compose really lets you do all of that in a way that makes your solution more portable, portable between local dev and CGI and reduces the number of CGI cycles to get, you know, the test, the test data that you need. So that's why I like it for really, for local dev. >>It'll be interesting. Um, I don't know if you all were able to see the keynote, but there was a, there was a little bit, not a whole lot, but a little bit talk of the Docker, compose V two, which has now built into the Docker command line. And so now we're shifting from the Python built compose, which was a separate package. You could that one of the challenges was getting it into your CA solution because if you don't have PIP and you got down on the binary and the binary wasn't available for every platform and, uh, it was a PI installer. It gets a little nerdy into how that works, but, uh, and the team is now getting, be able to get unified with it. Now that it's in Golang and it's, and it's plugged right into the Docker command line, it hopefully will be easier to distribute, easier to, to use. >>And you won't have to necessarily have dependencies inside of where you're running it because there'll be a statically compiled binary. Um, so I've been playing with that, uh, this year. And so like training myself to do Docker going from Docker dash compose to Docker space, compose. It is a thing I I'm almost to the point of having to write a shell replacement. Yeah. Alias that thing. Um, but, um, I'm excited to see what that's going, cause there's already new features in it. And it, these built kit by default, like there's all these things. And I, I love build kit. We could make a whole session on build kit. Um, in fact there's actually, um, maybe going on right now, or right around this time, there is a session on, uh, from Solomon hikes, the seat, uh, co-founder of Docker, former CTO, uh, on build kit using, uh, using some other tool on top of build kit or whatever. >>So that, that would be interesting for those of you that are not watching that one. Cause you're here, uh, to do a check that one out later. Um, all right. So another good question was caching. So another one, another area where there is no wrong answers probably, and everyone has a different story. So the question is, what are your thoughts on CII build caching? There's often a debate between security. This is from Quentin. Thank you for this great question. There's often a debate between security reproducibility and build speeds. I haven't found a good answer so far. I will just throw my hat in the ring and say that the more times you want to build, like if you're trying to build every commit or every commit, if you're building many times a day, the more caching you need. So like the more times you're building, the more caching you're gonna likely want. And in most cases caching doesn't bite you in the butt, but that could be, yeah, we, can we get the bit about that? So, yeah. Yeah. >>I'm going to quote Carlos again and say, it depends on, on, you know, how you're talking, you know, what you're trying to build and I'm quoting your colors. Um, yeah, it's, it's got, it's gonna depend because, you know, there are some instances where you definitely want to use, you know, depends on the frequency that you're building and how you're building. Um, it's you would want to actually take advantage of cashing functionalities, um, for the build, uh, itself. Um, but if, um, you know, as you mentioned, there could be some instances where you would want to disable, um, any caching because you actually want to either pull a new packages or, um, you know, there could be some security, um, uh, disadvantages related to security aspects that would, you know, you know, using a cache version of, uh, image layer, for example, could be a problem. And you, you know, if you have a fleet of build, uh, engines, you don't have a good grasp of where they're being cashed. We would have to, um, disable caching in that, in that, um, in those instances. So it, it would depend. >>Yeah, it's, it's funny you have that problem on both sides of cashing. Like there are things that, especially in Docker world, they will cash automatically. And, and then, and then you maybe don't realize that some of that caching could be bad. It's, it's actually using old, uh, old assets, old artifacts, and then there's times where you would expect it to cash, that it doesn't cash. And then you have to do something extra to enable that caching, especially when you're dealing with that cluster of, of CIS servers. Right. And the cloud, the whole clustering problem with caching is even more complex, but yeah, >>But that's, that's when, >>Uh, you know, ever since I asked you to start using build kits and able to build kit, you know, between it's it's it's reader of Boston in, in detecting word, you know, where in, in the bill process needs to cash, as well as, uh, the, the, um, you know, the process. I don't think I've seen any other, uh, approach there that comes close to how efficient, uh, that process can become how much time it can actually save. Uh, but again, I think, I think that's, for me that had been my default approach, unless I actually need something that I would intentionally to disable caching for that purpose, but the benefits, at least for me, the benefits of, um, how bill kit actually been processing my bills, um, from the builds as well as, you know, using the cash up until, you know, how it detects the, the difference in, in, in the assets within the Docker file had been, um, you know, uh, pretty, you know, outweigh the disadvantages that it brings in. So it, you know, take it each case by case. And based on that, determine if you want to use it, but definitely recommend those enabling >>In the absence of a reason not to, um, I definitely think that it's a good approach in terms of speed. Um, yeah, I say you cash until you have a good reason not to personally >>Catch by default. There you go. I think you catch by default. Yeah. Yeah. And, uh, the trick is, well, one, it's not always enabled by default, especially when you're talking about cross server. So that's a, that's a complexity for your SIS admins, or if you're on the cloud, you know, it's usually just an option. Um, I think it also is this, this veers into a little bit of, uh, the more you cash the in a lot of cases with Docker, like the, from like, if you're from images and checked every single time, if you're not pinning every single thing, if you're not painting your app version, you're at your MPN versions to the exact lock file definition. Like there's a lot of these things where I'm I get, I get sort of, I get very grouchy with teams that sort of let it, just let it all be like, yeah, we'll just build two images and they're totally going to have different dependencies because someone happened to update that thing and after whatever or MPM or, or, and so I get grouchy about that, cause I want to lock it all down, but I also know that that's going to create administrative burden. >>Like the team is now going to have to manage versions in a very much more granular way. Like, do we need to version two? Do we need to care about curl? You know, all that stuff. Um, so that's, that's kind of tricky, but when you get to, when you get to certain version problems, uh, sorry, uh, cashing problems, you, you, you don't want those set those caches to happen because it, if you're from image changes and you're not constantly checking for a new image, and if you're not pinning that V that version, then now you, you don't know whether you're getting the latest version of Davion or whatever. Um, so I think that there's, there's an art form to the more you pen, the less you have, the less, you have to be worried about things changing, but the more you pen, the, uh, all your versions of everything all the way down the stack, the more administrative stuff, because you're gonna have to manually change every one of those. >>So I think it's a balancing act for teams. And as you mature, I to find teams, they tend to pin more until they get to a point of being more comfortable with their testing. So the other side of this argument is if you trust your testing, then you, and you have better testing to me, the less likely to the subtle little differences in versions have to be penned because you can get away with those minor or patch level version changes. If you're thoroughly testing your app, because you're trusting your testing. And this gets us into a whole nother rant, but, uh, yeah, but talking >>About penny versions, if you've got a lot of dependencies isn't that when you would want to use the cash the most and not have to rebuild all those layers. Yeah. >>But if you're not, but if you're not painting to the exact patch version and you are caching, then you're not technically getting the latest versions because it's not checking for all the time. It's a weird, there's a lot of this subtle nuance that people don't realize until it's a problem. And that's part of the, the tricky part of allow this stuff, is it, sometimes the Docker can be almost so much magic out of the box that you, you, you get this all and it all works. And then day two happens and you built it a second time and you've got a new version of open SSL in there and suddenly it doesn't work. Um, so anyway, uh, that was a great question. I've done the question on this, on, uh, from heavy. What do you put, where do you put testing in your pipeline? Like, so testing the code cause there's lots of types of testing, uh, because this pipeline gets longer and longer and Docker building images as part of it. And so he says, um, before staging or after staging, but before production, where do you put it? >>Oh man. Okay. So, um, my, my main thought on this is, and of course this is kind of religious flame bait, so sure. You know, people are going to go into the compensation wrong. Carlos, the boy is how I like to think about it. So pretty much in every stage or every environment that you're going to be deploying your app into, or that your application is going to touch. My idea is that there should be a build of a Docker image that has all your applications coded in, along with its dependencies, there's testing that tests your application, and then there's a deployment that happens into whatever infrastructure there is. Right. So the testing, they can get tricky though. And the type of testing you do, I think depends on the environment that you're in. So if you're, let's say for example, your team and you have, you have a main branch and then you have feature branches that merged into the main branch. >>You don't have like a pre-production branch or anything like that. So in those feature branches, whenever I'm doing CGI that way, I know when I freak, when I cut my poll request, that I'm going to merge into main and everything's going to work in my feature branches, I'm going to want to probably just run unit tests and maybe some component tests, which really, which are just, you know, testing that your app can talk to another component or another part, another dependency, like maybe a database doing tests like that, that don't take a lot of time that are fascinating and right. A lot of would be done at the beach branch level and in my opinion, but when you're going to merge that beach branch into main, as part of a release in that activity, you're going to want to be able to do an integration tasks, to make sure that your app can actually talk to all the other dependencies that it talked to. >>You're going to want to do an end to end test or a smoke test, just to make sure that, you know, someone that actually touches the application, if it's like a website can actually use the website as intended and it meets the business cases and all that, and you might even have testing like performance testing, low performance load testing, or security testing, compliance testing that would want to happen in my opinion, when you're about to go into production with a release, because those are gonna take a long time. Those are very expensive. You're going to have to cut new infrastructure, run those tests, and it can become quite arduous. And you're not going to want to run those all the time. You'll have the resources, uh, builds will be slower. Uh, release will be slower. It will just become a mess. So I would want to save those for when I'm about to go into production. Instead of doing those every time I make a commit or every time I'm merging a feature ranch into a non main branch, that's the way I look at it, but everything does a different, um, there's other philosophies around it. Yeah. >>Well, I don't disagree with your build test deploy. I think if you're going to deploy the code, it needs to be tested. Um, at some level, I mean less the same. You've got, I hate the term smoke tests, cause it gives a false sense of security, but you have some mental minimum minimal amount of tests. And I would expect the developer on the feature branch to add new tests that tested that feature. And that would be part of the PR why those tests would need to pass before you can merge it, merge it to master. So I agree that there are tests that you, you want to run at different stages, but the earlier you can run the test before going to production. Um, the fewer issues you have, the easier it is to troubleshoot it. And I kind of agree with what you said, Carlos, about the longer running tests like performance tests and things like that, waiting to the end. >>The only problem is when you wait until the end to run those performance tests, you kind of end up deploying with whatever performance you have. It's, it's almost just an information gathering. So if you don't run your performance test early on, um, and I don't want to go down a rabbit hole, but performance tests can be really useless if you don't have a goal where it's just information gap, uh, this is, this is the performance. Well, what did you expect it to be? Is it good? Is it bad? They can get really nebulous. So if performance is really important, um, you you're gonna need to come up with some expectations, preferably, you know, set up the business level, like what our SLA is, what our response times and have something to shoot for. And then before you're getting to production. If you have targets, you can test before staging and you can tweak the code before staging and move that performance initiative. Sorry, Carlos, a little to the left. Um, but if you don't have a performance targets, then it's just a check box. So those are my thoughts. I like to test before every deployment. Right? >>Yeah. And you know what, I'm glad that you, I'm glad that you brought, I'm glad that you brought up Escalades and performance because, and you know, the definition of performance says to me, because one of the things that I've seen when I work with teams is that oftentimes another team runs a P and L tests and they ended, and the development team doesn't really have too much insight into what's going on there. And usually when I go to the performance team and say, Hey, how do you run your performance test? It's usually just a generic solution for every single application that they support, which may or may not be applicable to the application team that I'm working with specifically. So I think it's a good, I'm not going to dig into it. I'm not going to dig into the rabbit hole SRE, but it is a good bridge into SRE when you start trying to define what does reliability mean, right? >>Because the reason why you test performance, it's test reliability to make sure that when you cut that release, that customers would go to your site or use your application. Aren't going to see regressions in performance and are not going to either go to another website or, you know, lodge in SLA violation or something like that. Um, it does, it does bridge really well with defining reliability and what SRE means. And when you have, when you start talking about that, that's when you started talking about how often do I run? How often do I test my reliability, the reliability of my application, right? Like, do I have nightly tasks in CGI that ensure that my main branch or, you know, some important branch I does not mean is meeting SLA is meeting SLR. So service level objectives, um, or, you know, do I run tasks that ensure that my SLA is being met in production? >>Like whenever, like do I use, do I do things like game days where I test, Hey, if I turn something off or, you know, if I deploy this small broken code to production and like what happens to my performance? What happens to my security and compliance? Um, you can, that you can go really deep into and take creating, um, into creating really robust tests that cover a lot of different domains. But I liked just using build test deploy is the overall answer to that because I find that you're going to have to build your application first. You're going to have to test it out there and build it, and then you're going to want to deploy it after you test it. And that order generally ensures that you're releasing software. That works. >>Right. Right. Um, I was going to ask one last question. Um, it's going to have to be like a sentence answer though, for each one of you. Uh, this is, uh, do you lint? And if you lint, do you lent all the things, if you do, do you fail the linters during your testing? Yes or no? I think it's going to depend on the culture. I really do. Sorry about it. If we >>Have a, you know, a hook, uh, you know, on the get commit, then theoretically the developer can't get code there without running Melinta anyway, >>So, right, right. True. Anyone else? Anyone thoughts on that? Linting >>Nice. I saw an additional question online thing. And in the chat, if you would introduce it in a multi-stage build, um, you know, I was wondering also what others think about that, like typically I've seen, you know, with multi-stage it's the most common use case is just to produce the final, like to minimize the, the, the, the, the, the image size and produce a final, you know, thin, uh, layout or thin, uh, image. Uh, so if it's not for that, like, I, I don't, I haven't seen a lot of, you know, um, teams or individuals who are actually within a multi-stage build. There's nothing really against that, but they think the number one purpose of doing multi-stage had been just producing the minimalist image. Um, so just wanted to kind of combine those two answers in one, uh, for sure. >>Yeah, yeah, sure. Um, and with that, um, thank you all for the great questions. We are going to have to wrap this up and we could go for another hour if we all had the time. And if Dr. Khan was a 24 hour long event and it didn't sadly, it's not. So we've got to make room for the next live panel, which will be Peter coming on and talking about security with some developer ex security experts. And I wanted to thank again, thank you all three of you for being here real quick, go around the room. Um, uh, where can people reach out to you? I am, uh, at Bret Fisher on Twitter. You can find me there. Carlos. >>I'm at dev Mandy with a Y D E N D Y that's me, um, >>Easiest name ever on Twitter, Carlos and DFW on LinkedIn. And I also have a LinkedIn learning course. So if you check me out on my LinkedIn learning, >>Yeah. I'm at Nicola Quebec. Um, one word, I'll put it in the chat as well on, on LinkedIn, as well as, uh, uh, as well as Twitter. Thanks for having us, Brett. Yeah. Thanks for being here. >>Um, and, and you all stay around. So if you're in the room with us chatting, you're gonna, you're gonna, if you want to go to see the next live panel, I've got to go back to the beginning and do that whole thing, uh, and find the next, because this one will end, but we'll still be in chat for a few minutes. I think the chat keeps going. I don't actually know. I haven't tried it yet. So we'll find out here in a minute. Um, but thanks you all for being here, I will be back a little bit later, but, uh, coming up next on the live stuff is Peter Wood security. Ciao. Bye.

>>Hello, and welcome. Very excited to see everybody here. DockerCon is going fantastic. Everybody's uh, engaging in the chat. It's awesome to see. My name is Peter McKee. I'm the head of developer relations here at Docker and Taber. Today. We're going to be talking about container first development now and in the future. But before we do that, a couple little housekeeping items, first of all, yes, we are live. So if you're in our session, you can go ahead and chat, ask us questions. We'd love to get all your questions and answer them. Um, if you come to the main page on the website and you do not see the chat, go ahead and click on the blue button and that'll die. Uh, deep dive you into our session and you can interact with the chat there. Okay. Without further ado, let's just jump right into it. Katie, how are you? Welcome. Do you mind telling everybody who you are and a little bit about yourself? >>Absolutely. Hello everyone. My name is Katie and currently I am the eco-system advocate at cloud native computing foundation or CNCF. My responsibility is to lead and represent the end-user community. So these are all the practitioners within the cloud native space that are vendor neutral. So they use cloud native technologies to build their services, but they don't sell it. So this is quite an important characteristic as well. My responsibility is to make sure to close the gap between these practitioners and the project maintainers, to make sure that there is a feedback loop around. Um, I have many roles within the community. I am on the advisory board for KIPP finishes, a sandbox project. I'm working with open UK to make sure that Elton standards are used fairly across data, hardware, and software. And I have been, uh, affiliated way if you'd asked me to make sure that, um, I'm distributing a cloud native fundamental scores to make cloud and they do a few bigger despite everyone. So looking forward to this panel and checking with everyone. >>Awesome. Yeah. Welcome. Glad to have you here. Johanna's how are you? Can you, uh, tell everybody a little bit about yourself and who you are? Yeah, sure. >>So hi everybody. My name is Johannes I'm one of the co-founders at get pot, which in case you don't know is an open-source and container based development platform, which is probably also the reason why you Peter reached out and invited me here. So pleasure to be here, looking forward to the discussion. Um, yeah, though it is already a bit later in Munich. Um, and actually my girlfriend had a remote cocktail class with her colleagues tonight and it took me some stamina to really say no to all the Moscow mules that were prepared just over there in my living room. Oh wow. >>You're way better than me. Yeah. Well welcome. Thanks for joining us. Jerome. How are you? Good to see you. Can you tell everybody who you are and a little bit about yourself? Hi, >>Sure. Yeah, so I'm, I, I used to work at Docker and some, for me would say I'm a container hipster because I was running containers in production before it for hype. Um, I worked at Docker before it was even called Docker. And then since 2018, I'm now a freelancer and doing training and consulting around Docker containers, Kubernetes, all these things. So I used to help folks do stuff with Docker when I was there and now I still have them with containers more generally speaking. So kind of, uh, how do we say same, same team, different company or something like that? Yeah. >>Yeah. Perfect. Yeah. Good to see you. I'm glad you're on. Uh, Jacob, how are you? Good to see you. Thanks for joining us. Good. Yeah. Thanks for having me tell, tell everybody a little bit about yourself who you are. >>Yeah. So, uh, I'm the creator of a tool called mutagen, which is an open source, uh, development tool for doing high performance file synchronization and, uh, network forwarding, uh, to enable remote development. And so I come from like a physics background where I was sort of always doing, uh, remote developments, you know, whether that was on a big central clusters or just like some sort of local machine that was a bit more powerful. And so I, after I graduated, I built this tool called mutagen, uh, for doing remote development. And then to my surprise, people just started using it to use, uh, with Docker containers. And, uh, that's kind of grown into its primary use case now. So I'm, yeah, I've gotten really involved with the Docker community and, uh, talked with a lot of great people and now I'm one of the Docker captains. So I get to talk with even more and, and join these events and yeah, but I'm, I'm kind of focused on doing remote development. Uh, cause I, you know, I like, I like having all my tools available on my local machine, but I also like being able to pull in a little bit more powerful hardware or uh, you know, maybe a software that I can't run locally. And so, uh, that's sort of my interest in, in Docker container. Yeah. Awesome. >>Awesome. We're going to come back to that for sure. But yeah. Thank you again. I really appreciate you all joining me and yeah. So, um, I've been thinking about container first development for a while and you know, what does that actually mean? So maybe, maybe we can define it in our own little way. So I, I just throw it out to the panel. When you think about container first development, what comes to mind? What w what, what are you kind of thinking about? Don't be shy. Go ahead. Jerome. You're never a loss of words >>To me. Like if I go back to the, kind of the first, uh, you know, training engagements we did back at Docker and kind of helping folks, uh, writing Dockerfiles to stop developing in containers. Um, often we were replacing, um, uh, set up with a bunch of Vagrant boxes and another, like the VMs and combinations of local things. And very often they liked it a lot and they were very soon, they wanted to really like develop in containers, like run this microservice. This piece of code is whatever, like run that in containers because that means they didn't have to maintain that thing on their own machine. So that's like five years ago. That's what it meant to me back then. However, today, if you, if you say, okay, you know, developing in containers, um, I'm thinking of course about things like get bought and, uh, I think it's called PR or something like that. >>Like this theme, maybe that thing with the ESCO, that's going to run in a container. And you, you have this vs code thing running in your browser. Well, obviously not in your browser, but in a container that you control from your browser and, and many other things like that, that I, I think that's what we, where we want to go today. Uh, and that's really interesting, um, from all kinds of perspectives, like Chevy pair pairing when we will not next to each other, but actually thousands of miles away, um, or having this little environment that they can put aside and come back to it later, without it having using resource in my machine. Um, I don't know, having this dev service running somewhere in the cloud without needing something like, it's at the rights that are like the, the possibilities are really endless. >>Yeah. Yeah. Perfect. Yeah. I'm, you know, a little while ago I was, I was torn, right. W do I spin up containers? Do I develop inside of my containers? Right. There's foul sinking issues. Um, you know, that we've been working on at Docker for a while, and Jacob is very, very familiar with those, right? Sometimes it, it becomes hard, but, and I, and I love developing in the cloud, but I also have this screaming, you know, fast machine sitting on my desktop that I think I should take advantage of. So I guess another question is, you know, should we be developing inside of containers? Is that a smart thing to do? Uh, I'd love to hear you guys' thoughts around that. >>You know, I think it's one of those things where it's, you know, for me container first development is really about, um, considering containers as sort of a first class citizen in, in terms of your development toolkit, right. I mean, there's not always that silver bullet, that's like the one thing you should use for everything. You know, you shouldn't, you shouldn't use containers if they're not fitting in or adding value to your workflow, but I think there's a lot of scenarios that are like, you know, super on super early on in the development process. Like as soon as you get the server kind of running and working and, you know, you're able to access it, you know, running on your local system. Uh that's I think that's when the value comes in to it to add containers to, you know, what you're doing or to your project. Right. I mean, for me, they're, um, they're more of a orchestrational tool, right? So if I don't have to have six different browser tabs open with like, you know, an API server running at one tab and a web server running in another tab and a database running in another tab, I can just kind of encapsulate those and, and use them as an automation thing. So I think, you know, even if you have a super powerful computer, I think there's still value in, um, using containers as, as a orchestrational mechanism. Yeah. Yeah, >>For sure. I think, I think one of the, one of my original aha moments with Docker was, oh, I can spin up different versions of a database locally and not have to install it and not have to configure it and everything, but, you know, it just ran inside of a container. And that, that was it. Although it's might seem simple to some people that's very, very powerful. Right. So I think being able to spin things up and containers very quickly is one of the super benefits. But yeah, I think, uh, developing in containers is, is hard right now, right. With, um, you know, and how do you do that? Right. Does anybody have any thoughts around, how do you go about that? Right. Should you use a container as just a development environment, so, you know, creating an image and then running it just with your dev tools in it, or do you just, uh, and maybe with an editor all inside of it, and it's just this process, that's almost like a VM. Um, yeah. So I'll just kick it back to the panel. I'd love to hear your thoughts on, you know, how do you set up and configure, uh, containers to develop in any thoughts around that? >>Maybe one step back again, to answer your question, what kind of container first development mean? I think it doesn't mean, um, by default that it has to be in the cloud, right? As you said, um, there are obvious benefits when it comes to the developer experience of containers, such as, I dunno, consistency, we have standardized tools dependencies for the dev side of things, but it also makes their dev environment more similar to all the pipeline that is somehow happening to the right, right. So CIC D all the way to production, it is security, right? Which also somehow comes with standardization. Um, but vulnerability scanning tools like sneak are doing a great job there. And, um, for us, it gets pod. One of the key reasons why we created get pod was literally creating this peace of mind for deaths. So from a developer's point of view, you do not need to take care anymore about all the hassle around setups and things that you will need to install. >>And locally, based on some outdated, REIT me on three operating systems in your company, everybody has something different and leading to these verbs in my machine situations, um, that really slow professional software developers down. Right. Um, back to your point, I mean, with good pod, we obviously have to package everything together in one container because otherwise, exactly the situation happens that you need to have five browser tabs open. So we try and leverage that. And I think a dev environment is not just the editor, right? So a dev environment includes your source code. It includes like a powerful shell. It includes file systems. It includes essentially all the tools you need in order to be productive databases and so on. And, um, yeah, we believe that should be encapsulated, um, um, in a container. >>Yeah. Awesome. Katie, you talked to a lot of end users, right. And you're talking to a lot of developers. What, what's your thoughts around container first development, right? Or, or what's the community out there screaming or screaming. It might be too to, uh, har you know, to, to two grand of the word. Right. But yeah, I love it. I love to hear what your, your thoughts. >>Absolutely. So I think when you're talking about continuing driven development, uh, the first thing that crosses my mind is the awareness of the infrastructure or the platform you're going to run your application on top of, because usually when you develop your application, you'd like to replicate as much as possible the production or even the staging environment to make sure that when you deploy your application, you have us little inconsistencies as possible, but at the same time, you minimize the risk for something to go wrong as well. So when it talking about the, the community, um, again, when you deploy applications and containers and Kubernetes, you have to use, you have awareness about, and probably apply some of the best practices, like introducing liveliness and readiness probes, to make sure that your application can restart in, in case it actually goes down or there's like a you're starving going CPU or something like that. >>So, uh, I think when it comes to deployment and development of an application, the main thing is to actually improve the end developer experience. I think there has been a lot of focus in the community to develop the tool, to actually give you the right tool to run application and production, but that doesn't necessarily, um, go back to how the end developer is actually enabling that application to run into that production system. So I think there has been, uh, this focus for the community identified now, and it's more, more, um, or trying to build momentum on enhancing the developer experience. And we've seen this going through many, uh, where we think production of many tools did what has been one of them, which actually we can have this portable, um, development environment if you choose so, and you can actually replicate them across different teams in different machines, which is actually quite handy. >>But at the same time, we had tools such as local composts has been a great tool to run locally. We have tool such as carefully, which is absolutely great to automatically dynamically upload any changes to how within your code. So I think all of these kinds of tools, they getting more matured. And again, this is going back to again, we need to enhance our developer experience coming back to what is the right way to do so. Um, I think it really depends on the environment you have in production, because there's going to define some of the structures with the tool and you're going to have internally, but at the same time, um, I'd like to say that, uh, it really depends on, on what trucks are developing. Uh, so it's, it's, I would like to personally, I would like to see a bit more diversification in this area because we might have this competitive solutions that is going to push us to towards a new edge. So this is like, what definitely developer experience. If we're talking about development, that's what we need to enhance. And that's what I see the momentum building at the moment. >>Yeah. Yeah. Awesome. Jerome, I saw you shaking your head there in agreement, or maybe not, but what's your thoughts? >>I was, uh, I was just reacting until 82. Uh, it depends thinking that when I, when I do training, that's probably the answer that I gave the most, uh, each time somebody asks, oh, should we do diesel? And I was also looking at some of the questions in the chat about, Hey, the, should we like have a negatory in the, in the container or something like that. And folks can have pretty strong opinions one way or the other, but as a ways, it kind of depends what we do. It also depends of the team that we're working with. Um, you, you could have teams, you know, with like small teams with folks with lots of experience and they all come with their own Feb tools and editorials and plugins. So you know that like you're gonna have PRI iMacs out of my cold dead hands or something like that. >>So of course, if you give them something else, they're going to be extremely unhappy or sad. On the other hand, you can have team with folks who, um, will be less opinionated on that. And even, I don't know, let's say suddenly you start working on some project with maybe a new programming language, or maybe you're targeting some embedded system or whatever, like something really new and different. And you come up with all the tools, even the ADE, the extensions, et cetera, folks will often be extremely happy in that case that you're kind of giving them a Dettol and an ADE, even if that's not what they usually would, uh, would use, um, because it will come with all of the, the, the nice stage, you know, the compression, the, um, the, the, the bigger, the, whatever, all these things. And I think there is also something interesting to do here with development in containers. >>Like, Hey, you're going to start working on this extremely complex target based on whatever. And this is a container that has everything to get started. Okay. Maybe it's not your favorites editor, but it has all the customization and the conserver and whatever. Um, so you can start working right away. And then maybe later you, we want to, you know, do that from the container in a way, and have your own Emacs, atom, sublime, vs code, et cetera, et cetera. Um, but I think it's great for containers here, as well as they reserve or particularly the opportunity. And I think like the, that, that's one thing where I see stuff like get blood being potentially super interesting. Um, it's hard for me to gauge because I confess I was never a huge ID kind of person had some time that gives me this weird feeling, like when I help someone to book some, some code and you know, that like with their super nice IDE and everything is set up, but they feel kind of lost. >>And then at some point I'm like, okay, let's, let's get VI and grep and let's navigate this code base. And that makes me feel a little bit, you know, as this kind of old code for movies where you have the old, like colorful guy who knows going food, but at the end ends up still being obsolete because, um, it's only a going for movies that whole good for masters and the winning right. In real life, we don't have conformance there's anymore mentioned. So, um, but part of me is like, yeah, I like having my old style of editor, but when, when the modern editorial modern ID comes with everything set up and configured, that's just awesome. That's I, um, it's one thing that I'm not very good at sitting up all these little things, but when somebody does it and I can use it, it's, it's just amazing. >>Yeah. Yeah. I agree. I'm I feel the same way too. Right. I like, I like the way I've I have my environment. I like the tools that I use. I like the way they're set up. And, but it's a big issue, right? If you're switching machines, like you said, if you're helping someone else out there, they're not there, your key bindings aren't there, you can't, you can't navigate their system. Right? Yeah. So I think, you know, talking about, uh, dev environments that, that Docker's coming out with, and we're, you know, there's a lot, there, there's a, it's super complex, all these things we're talking about. And I think we're taking the approach of let's do something, uh, well, first, right. And then we can add on to that. Right. Because I think, you know, setting up full, full developed environments is hard, right. Especially in the, the, um, cloud native world nowadays with microservices, do you run them on a repo? >>Do you not have a monitor repo? Maybe that would be interesting to talk about. I think, um, you know, I always start out with the mono repos, right. And you have all your services in there and maybe you're using one Docker file. And then, because that works fine. Cause everything is JavaScript and node. And then you throw a little Python in there and then you throw a little go and now you start breaking things out and then things get too complex there, you know, and you start pulling everything out into different, get repos and now, right. Not everything just fits into these little buckets. Right. So how do you guys think maybe moving forward, how do we attack that night? How do we attack these? Does separate programming languages and environments and kind of bring them all together. You know, we, we, I hesitate, we solve that with compose around about running, right about executing, uh, running your, your containers. But, uh, developing with containers is different than running containers. Right. It's a, it's a different way to think about it. So anyway, sorry, I'm rattling on a little bit, but yeah. Be interesting to look at a more complex, uh, setup right. Of, uh, of, you know, even just 10 microservices that are in different get repos and different languages. Right. Just some thoughts. And, um, I'm not sure we all have this flushed out yet, but I'd love to hear your, your, you guys' thoughts around that. >>Jacob, you, you, you, you look like you're getting ready to jump there. >>I didn't wanna interrupt, but, uh, I mean, I think for me the issue isn't even really like the language boundary or, or, um, you know, a sub repo boundary. I think it's really about, you know, the infrastructure, right? Because you have, you're moving to an era where you have these cloud services, which, you know, some of them like S3, you can, you can mock up locally, uh, or run something locally in a container. But at some point you're going to have like, you know, cloud specific hardware, right? Like you got TPS or something that maybe are forming some critical function in your, in your application. And you just can't really replicate that locally, but you still want to be able to develop against that in some capacity. So, you know, my, my feeling about where it's going to go is you'll end up having parts of your application running locally, but then you also have, uh, you know, containers or some other, uh, element that's sort of cohabitating with, uh, you know, either staging or, or testing or production services that you're, uh, that you're working with. >>So you can actually, um, you know, test against a really or realistic simulation or the actual, uh, surface that you're running against in production. Because I think it's just going to become untenable to keep emulating all of that stuff locally, or to have to like duplicate these, you know, and, you know, I guess you can argue about whether or not it's a good thing that, that everything's moving to these kind of more closed off cloud services, but, you know, the reality of situation is that's where it's going to go. And there's certain hardware that you're going to want in the cloud, especially if you're doing, you know, machine learning oriented stuff that there's just no way you're going to be able to run locally. Right. I mean, if you're, even if you're in a dev team where you have, um, maybe like a central machine where you've got like 10 or 20 GPU's in it, that's not something that you're going to be able to, to, to replicate locally. And so that's how I kind of see that, um, you know, containers easing that boundary between different application components is actually maybe more about co-location, um, or having different parts of your application run in different locations, on different hardware, you know, maybe someone on your laptop, maybe it's someone, you know, AWS or Azure or somewhere. Yeah. It'd be interesting >>To start seeing those boundaries blur right. Working local and working in the cloud. Um, and you might even, you might not even know where something is exactly is running right until you need to, you know, that's when you really care, but yeah. Uh, Johanas, what's your thoughts around that? I mean, I think we've, we've talked previously of, of, um, you know, hybrid kind of environments. Uh, but yeah. What, what's your thoughts around that? >>Um, so essentially, yeah, I think, I mean, we believe that the lines between cloud and local will also potentially blur, and it's actually not really about that distinction. It's just packaging your dev environment in a way and provisioning your dev environment in a way that you are what we call always ready to coat. So that literally, um, you, you have that for the, you described as, um, peace of mind that you can just start to be creative and start to be productive. And if that is a container potentially running locally and containers are at the moment. I think, you know, the vehicle that we use, um, two weeks ago, or one week ago actually stack blitz announced the web containers. So potentially some things, well, it's run in the browser at some point, but currently, you know, Docker, um, is the standard that enables you to do that. And what we think will happen is that these cloud-based or local, um, dev environments will be what we call a femoral. So it will be similar to CIS, um, that we are using right now. And it doesn't literally matter, um, where they are running at the end. It's just, um, to reduce friction as much as possible and decrease and yeah, yeah. Essentially, um, avoid or the hustle that is currently involved in setting up and also managing dev environments, um, going forward, which really slows down specifically larger teams. >>Yeah. Yeah. Um, I'm going to shift gears a little bit here. We have a question from the audience in chat, uh, and it's, I think it's a little bit two parts, but so far as I can see container first, uh, development, have the challenges of where to get safe images. Um, and I was going to answer it, but let me keep it, let me keep going, where to get safe images and instrumentation, um, and knowing where exactly the problem is happening, how do we provide instrument instrumentation to see exactly where a problem might be happening and why? So I think the gist of it is kind of, of everything is in a container and I'm sitting outside, you know, the general thought around containers is isolation, right. Um, so how do I get views into that? Um, whether debugging or, or, or just general problems going on. I think that's maybe a broader question around the, how you, you know, you have your local hosts and then you're running everything containers, and what's the interplay there. W what's your thoughts there? >>I tend to think that containers are underused interactively. I mean, I think in production, you have this mindset that there's sort of this isolated environment, but it's very, actually simple to drop into a shell inside of a container and use it like you would, you know, your terminal. Um, so if you want to install software that way, you know, through, through an image rather than through like Homebrew or something, uh, you can kind of treat containers in that way and you can get a very, um, you know, direct access to the, to the space in which those are running in. So I think, I think that's maybe the step one is just like getting rid of that mindset, that, that these are all, um, you know, these completely encapsulated environments that you can't interact with because it's actually quite easy to just Docker exec into a container and then use it interactively >>Yeah. A hundred percent. And maybe I'll pass, I'm going to pass this question. You drone, but maybe demystify containers a little bit when I talked about this on the last, uh, panel, um, because we have a question in the, in the chat around, what's the, you know, why, why containers now I have VMs, right? And I think there's a misunderstanding in the industry, uh, about what, what containers are, we think they're fair, packaged stuff. And I think Jacob was hitting on that of what's underneath the hood. So maybe drown, sorry, for a long way to set up a question of what, what, what makes up a container, what is a container >>Is a container? Well, I, I think, um, the sharpest and most accurate and most articulate definition, I was from Alice gold first, and I will probably misquote her, but she said something like containers are a bunch of capsulated processes, maybe running on a cookie on welfare system. I'm not sure about the exact definition, but I'm going to try and, uh, reconstitute that like containers are just processes that run on a Unix machine. And we just happen to put a bunch of, um, red tape or whatever around them so that they are kind of contained. Um, but then the beauty of it is that we can contend them as much, or as little as we want. We can go kind of only in and put some actual VM or something like firecracker around that to give some pretty strong angulation, uh, all we can also kind of decontam theorize some aspects, you know, you can have a container that's actually using the, um, the, um, the network namespace of the host. >>So that gives it an entire, you know, wire speed access to the, to the network of the host. Um, and so to me, that's what really interesting, of course there is all the thing about, oh, containers are lightweight and I can pack more of them and they start fast and the images can be small, yada yada, yada. But to me, um, with my background in infrastructure and building resilient, things like that, but I find really exciting is the ability to, you know, put the slider wherever I need it. Um, the, the, the ability to have these very light containers, all very heavily, very secure, very anything, and even the ability to have containers in containers. Uh, even if that sounds a little bit, a little bit gimmicky at first, like, oh, you know, like you, you did the Mimi, like, oh, I heard you like container. >>So I put Docker when you're on Docker. So you can run container for you, run containers. Um, but that's actually extremely convenient because, um, as soon as you stop building, especially something infrastructure related. So you challenge is how do you test that? Like, when we were doing.cloud, we're like, okay, uh, how do we provision? Um, you know, we've been, if you're Amazon, how do you provision the staging for us installed? How do you provision the whole region, Jen, which is actually staging? It kind of makes things complicated. And the fact that we have that we can have containers within containers. Uh, that's actually pretty powerful. Um, we're also moving to things where we have secure containers in containers now. So that's super interesting, like stuff like a SIS box, for instance. Um, when I saw that, that was really excited because, uh, one of the horrible things I did back in the days as Docker was privileged containers, precisely because we wanted to have Docker in Docker. >>And that was kind of opening Pandora's box. That's the right, uh, with the four, because privileged containers can do literally anything. They can completely wreck up the machine. Um, and so, but at the same time, they give you the ability to run VPNs and run Docker in Docker and all these cool things. You can run VM in containers, and then you can list things. So, um, but so when I saw that you could actually have kind of secure containers within containers, like, okay, there is something really powerful and interesting there. And I think for folks, well, precisely when you want to do development in containers, especially when you move that to the cloud, that kind of stuff becomes a really important and interesting because it's one thing to have my little dev thing on my local machine. It's another thing when I want to move that to a swarm or Kubernetes cluster, and then suddenly even like very quickly, I hit the wall, which is, oh, I need to have containers in my containers. Um, and then having a runtime, like that gets really intense. >>Interesting. Yeah, yeah, yeah. And I, and jumping back a bit, um, yeah, uh, like you said, drum at the, at the base of it, it containers just a, a process with, with some, uh, Abra, pardon me, operating constructs wrapped around it and see groups, namespaces those types of things. But I think it's very important to, for our discussion right. Of, uh, developers really understanding that, that this is just the process, just like a normal process when I spin up my local bash in my term. Uh, and I'm just interacting with that. And a lot of the things we talk about are more for production runtimes for securing containers for isolating them locally. I don't, I don't know. I'll throw the question out to the panel. Is that really relevant to us locally? Right. Do we want to pull out all of those restrictions? What are the benefits of containers for development, right. And maybe that's a soft question, but I'd still love to hear your thoughts. Maybe I'll kick it over to you, Katie, would you, would you kick us off a little bit with that? >>I'll try. Um, so I think when, again, I was actually thinking of the previous answers because maybe, maybe I could do a transition here. So, interesting, interesting about containers, a piece of trivia, um, the secrets and namespaces have been within the Linux kernel since 2008, I think, which just like more than 10 years ago, hover containers become popular in the last years. So I think it's, it's the technology, but it's about the organization adopting this technology. So I think why it got more popular now is because it became the business differentiator organizations started to think, how can I deliver value to my customers as quickly as possible? So I think that there should be this kind of two lane, um, kind of progress is the technology, but it's at the same time organization and cultural now are actually essential for us to develop, uh, our applications locally. >>Again, I think when it's a single application, if you have just one component, maybe it's easier for you to kind of run it locally, have a very simple testing environment. Sufficient is a container necessary, probably not. However, I think it's more important when you're thinking to the bigger picture. When we have an architecture that has myriads of microservices at the basis, when it's something that you have to expose, for example, an API, or you have to consume an API, these are kind of things where you might need to think about a lightweight set up within the containers, only local environment to make sure that you have at least a similar, um, environment or a configuration to make sure that you test some of the expected behavior. Um, I think the, the real kind of test you start from the, the dev cluster will like the dev environment. >>And then like for, for you to go to staging and production, you will get more clear into what exactly that, um, um, configuration should be in the end. However, at the same time, again, it's, it's more about, um, kind of understanding why you continue to see this, the thing, like, I don't say that you definitely need containers at all times, but there are situations when you have like, again, multiple services and you need to replicate them. It's just the place to, to, to work with these kind of, um, setups. So, um, yeah, really depends on what you're trying to develop here. Nothing very specific, unfortunately, but get your product and your requirements are going to define what you're going to work with. >>Yeah, no, I think that's a great answer, right. I think one of the best answers in, in software engineering and engineering in general as well, it depends. Right. It's things are very specific when we start getting down to the details, but yeah, generally speaking, you know, um, I think containers are good for development, but yeah, it depends, right. It really depends. Is it helping you then? Great. If it's hindering you then, okay. Maybe think what's, what's the hindrance, right. And are containers the right solution. I agree. 110% and, >>And everything. I would like absurd this too as well. When we, again, we're talking about the development team and now we have this culture where we have the platform and infrastructure team, and then you have your engineering team separately, especially when the regulations are going to be segregated. So, um, it's quite important to understand that there might be a, uh, a level of up-skilling required. So pushing for someone to use containers, because this is the right way for you to develop your application might be not, uh, might not be the most efficient way to actually develop a product because you need to spend some time to make sure that the, the engineering team has the skills to do so. So I think it's, it's, again, going back to my answers here is like, truly be aware of how you're trying to develop how you actually collaborate and having that awareness of your platform can be quite helpful in developing your, uh, your publication, the more importantly, having less, um, maybe blockers pushing it to a production system. >>Yeah, yeah. A hundred percent. Yeah. The, uh, the cultural issue is, is, um, within the organization, right. Is a very interesting thing. And it, and I would submit that it's very hard from top down, right. Pushing down tools and processes down to the dev team, man, we'll just, we'll just rebel. It usually comes from the bottom up. Right. What's working for us, we're going to do right. And whether we do it in the shadows and don't let it know, or, or we've conformed, right. Yeah. A hundred percent. Um, interesting. I would like to think a little bit in the future, right? Like, let's say, I don't know, two, three years from now, if, if y'all could wave a and I'm from Texas. So I say y'all, uh, if you all could wave a magic wand, what, what, what would that bring about right. What, what would, what would be the best scenario? And, and we just don't have to say containers. Right. But, you know, what's the best development environment and I'm going to kick it over to you, Jacob. Cause I think you hinted at some of that with some hybrid type of stuff, but, uh, yeah. Implies, they need to keep you awake. You're, you're, you're, uh, almost on the other side of the world for me, but yeah, please. >>Um, I think, you know, it's, it's interesting because you have this technology that you've been, that's been brought from production, so it's not, um, necessarily like the right or the normal basis for development. So I think there's going to be some sort of realignment or renormalization in terms of, uh, you know, what the, what the basis and the abstractions that we're using on a daily basis are right. Like images and containers as they exist now are really designed for, um, for production use cases. And, and in terms of like, even even the ergonomics of opening a shell inside a container, I think is something that's, um, you know, not as polished or not as smooth as it could be because they've come from production. And so I think it's important, like not to, not to have people look at, look at the technology as it exists now and say like, okay, this is slightly rough around the edges, or it wasn't designed for this use case and think, oh, there's, you know, there's never any way I could use this for, for my development of workflows. >>I think it's, you know, it's something Docker's exploring now with, uh, with the, uh, dev containers, you know, it's, it's a new, and it's an experimental paradigm and it may not be what the final picture looks like. As, you know, you were saying, there's going to be kind of a baseline and you'll add features to that or iterate on that. Um, but I think that's, what's interesting about it, right? Cause it's, there's not a lot of things as developers that you get to play with that, um, that are sort of the new technology. Like if you're talking about things you're building to ship, you want to kind of use tried and true components that, you know, are gonna, that are going to be reliable. But I think containers are that interesting point where it's like, this is an established technology, but it's also being used in a way now that's completely different than what it was designed for. And, and, you know, as hackers, I think that's kind of an interesting opportunity to play with it, but I think, I think that's, what's going to happen is you're just going to see kind of those production, um, designed, uh, knobs kind of sanded down or redesigned for, for development. So that's kind of where I see it going. >>Yeah. Yeah. And I think that's what I was trying to hint out earlier is like, um, yeah, just because all these things are there, does it actually mean we need them locally? Right. Do they make sense? I, I agree. A hundred percent, uh, anybody else drawn? What are your thoughts around that? And then, and then, uh, I'll probably just ask all of you. I'd love to hear each of your thoughts of the future. >>I had a thought was maybe unrelated, but I was kind of wondering if we would see something on the side of like energy efficiency in some way. Um, and maybe it's just because I've been thinking a lot about like climate change and things like that recently, and trying to reduce like the, uh, the energy use energy use and things like that. Perhaps it's also because I recently got a new laptop, which on paper is super awesome, but in practice, as soon as you try to have like two slack tabs and a zoom call, you know, it's super fast, both for 30 seconds. And after 30 seconds, it blows its thermal budget and it's like slows down to a crawl. And I started to think, Hmm, maybe, you know, like before we, we, we were thinking about, okay, I don't have that much CPU available. So you have to be kind of mindful about that. >>And now I wonder how are we going to get in something similar to that, but where you try to save CPU cycles, not just because you don't have that many CPU cycles, but more because you know, that you can't go super fast for super long when you are on one of these like small laptops or tablets or phones, like you have this demo budget to take into account. And, um, I wonder if, and how like, is there something where goaltenders can do some things here? I guess it can be really interesting if they can do some the equivalent of like Docker top and Docker stats. And if I could see, like how much what's are these containers using, I can already do that with power top on Linux, for instance, like process by process. So I'm thinking I could see what's the power usage of, of some containers. Um, and I wonder if down the line, is this going to be something useful or is this just silly because we can just masquerade CPU usage for, for Watson and forget about it. >>Yeah. Yeah. It was super, super interesting, uh, perspective for sure. I'm going to shut up because I want to, I want to give, make sure I give Johannes and Katie time. W w what are your thoughts of the future around, let's just say, you know, container development in general, right? You want, you want to start absolutely. Oh, honest, Nate. Johns wants more time. I say, I'll try not to. Beneficiate >>Expensive here, but, um, so one of the things that we've we've touched upon earlier in the panel was multicloud strategy. And I was reading one of the data reports from it was about the concept of Kubernetes from gamer Townsville. But what is working for you to see there is that more and more organizations are thinking about multicloud strategy, which means that you need to develop an application or need an infrastructure or a component, which will allow you to run this application bead on a public cloud bead, like locally in a data center and so forth. And here, when it comes to this kind of, uh, maybe problems we come across open standards, this is where we require something, which will allow us to execute our application or to run our platform in different environments. So when you're thinking about the application or development of the application, one of the things that, um, came out in 2019 at was the Oakland. >>Um, I wish it was Kybella, which is a, um, um, an open application model based application, which allows you to describe the way you would like your service to be executed in different environments. It doesn't need to be well developed specifically for communities. However, the open application model is specialized. So specialized tries to cover multiple platforms. You will be able to execute your application anywhere you want it to. So I think that that's actually quite important because it completely obstructs what is happening underneath it, completely obstructs notions, such as containers, uh, or processes is just, I want this application and I want to have this kind of behavior is so example of, to scale in this conditions or to, um, to be exposed for these, uh, end points and so forth. And everything that I would like to mention here is that maybe this transcends again, the, uh, the logistics of the application development, but it definitely will impact the way we run our applications. >>So one of the biggest, well, one of the new trends that is kind of gaining momentum now has been around Plaza. And this is again, something which is trying to present what we have the on containers. Again, it's focusing on the, it's kind of a cyclical, um, uh, action movement that we have here. When we moved from the VMs to containers, it was smaller footprint. We want like better execution, one, this agnosticism of the platforms. We have the same thing happening here with Watson, but again, it consents a new, um, uh, kind of, well, it teaches in you, uh, in new climax here, where again, we shrink the footprint of the cluster. We have a better isolation of all the services. We have a better trend, like portability of how services and so forth. So there is a great potential out there. And again, like why I'm saying this is some of these technologies are gonna define the way we're gonna do our development of the application on our local environment. >>That's why it's important to kind of maybe have an eye there and maybe see if some of those principles of some of those technologies we can bring internally as well. And just this, like a, a final thought here, um, security has been mentioned as well. Um, I think it's something which has been, uh, at the forefront, especially when it comes to containers, uh, especially when it comes to enterprise organizations and those who are regulated, which I feel come very comfortable to run their application within a VM where you have the full isolation, you can do what we have complete control of what's happening inside that compute. So, um, again, security has been at the forefront at the moment. So I know it has mentioned in the panel before. I'd like to mention that we have the security white paper, which has been published. We have the software supply chain, white paper as well, which twice to figure out or define some of these good practices as well, again, which you can already apply from your development environment and then propagate them to production. So I'm just going to leave, uh, all of these. That's all. >>That's awesome. And yeah, well, while is very, very interesting. I saw the other day that, um, and I forget who it was, maybe, maybe all can remember, um, you know, running, running the node, um, engine inside of, you know, in Walzem inside of a browser. Right. And, uh, at first glance I said, well, we already have a JavaScript execution engine. Right. And it's kind of like Docker and Docker. So you have, uh, you know, you have the browser, then, then you have blossom and then you have a node, you know, a JavaScript runtime. And, and I didn't understand was while I was, um, you know, actually executing is JavaScript and it's not, but yeah, it's super interesting, super powerful. I always felt that the browser was, uh, Java's what write once run anywhere kind of solution, right. That never came about, they were thinking of set top, uh, TV boxes and stuff like that, which is interesting. >>I don't know, you'll some of the history of Java, but yeah. Wasm is, is very, I'm not sure how to correctly pronounce it, but yeah, it's extremely interesting because of the isolation in that boxing. Right. And running powerful languages that were used to inside of a more isolated environment. Right. And it's almost, um, yeah, it's kind of, I think I've mentioned it before that the containers inside of containers, right. Um, yeah. So Johannes, hopefully I gave you enough time. I delayed, I delayed as much as I can. My friend, you better, you better just kidding. I'm just kidding, please, please. >>It was by the way, stack let's and they worked together with Google and with Russell, um, developing the web containers, it's called there's, it's quite interesting. The research they're doing there. Yeah. Yeah. I mean, what we believe and I, I also believe is that, um, yeah, probably somebody is doing to death environments, what Docker did to servers and at least that good part. We hope that somebody will be us. Um, so what we mean by that is that, um, we think today we are still somehow emotionally attached to our dev environments. Right. We give them names, we massage them over time, which can also have its benefits, but it's, they're still pets in some way. Right. And, um, we believe that, um, environments in the future, um, will be treated similar like servers today as automated resources that you can just spin up and close down whenever you need them. >>Right. And, um, this trend essentially that you also see in serverless, if you look at what kind of Netlify is doing a bit with preview environments, what were sellers doing? Um, there, um, we believe will also arrive at, um, at Steph environments. It probably won't be there tomorrow. So it will take some time because if there's also, you know, emotion involved into, in that, in that transition, but ultimately really believe that, um, provisioning dev environments also in the cloud allows you to leverage the power of the cloud and to essentially build all that stuff that you need in order to work in advance. Right? So that's literally either command or a button. So either, I don't know, a command that spins up your local views code and SSH into, into a container, or you do it in a browser, um, will be the way that professional development teams will develop in the future. Probably let's see in our direction of document, we say it's 2000 to 23. Let's see if that holds true. >>Okay. Can we, can, we let's know. Okay. Let's just say let's have a friendly bet. I don't know that's going to be closed now, but, um, yeah, I agree. I, you know, it's my thought around is it, it's hard, right? Th these are hard. And what problems do you tackle first, right? Do you tackle the day, one of, uh, you know, of development, right. I joined a team, Hey, here's your machine? And you have Docker installed and there you go, pull, pull down your environment. Right. Is that necessarily just an image? You know, what, what exactly is that sure. Containers are involved. Right. But that's, I mean, you, you've probably all gone through it. You joined a team, new project, even open-source project, right there. There's a huge hurdle just to get everything configured, to get everything installed, to get it up and running, um, you know, set aside all understanding the code base. >>Cause that's a different issue. Right. But just getting everything running locally and to your point earlier, Jacob of around, uh, recreating, local production cues and environments and, you know, GPS or anything like that, right. Is extremely hard. You can't do a lot of that locally. Right. So I think that's one of the things I'd love to see tackled. And I think that's where we're tackling in dev environments, uh, with Docker, but then now how do you become productive? Right. And where do we go from there? And, uh, and I would love to see this kind of hybrid and you guys have been all been talking about it where I can, yes. I have it configured everything locally on my nice, you know, apple notebook. Right. And then, you know, I go with the family and we go on vacation. I don't want to drag this 16 inch, you know, Mac laptop with me. >>And I want to take my nice iPad with the magic keyboard and all the bang stuff. Right. And I just want to fire up and I pick up where I left off. Right. And I keep coding and environment feels, you know, as much as it can that I'm still working at backup my desktop. I think those, those are very interesting to me. And I think reproducing, uh, the production running runtime environments as close as possible, uh, when I develop my, I think that's extremely powerful, extremely powerful. I think that's one of the hardest things, right. It's it's, uh, you know, we used to say, we, you debug in production. Right. We would launch, right. We would do, uh, as much performance testing as possible. But until you flip that switch on a big, on a big site, that's where you really understand what is going to break. >>Right. Well, awesome. I think we're just about at time. I really, really appreciate everybody joining me. Um, it's been a pleasure talking to all of you. We have to do this again. If I, uh, hopefully, you know, I I'm in here in America and we seem to be doing okay with COVID, but I know around the world, others are not. So my heart goes out to them, but I would love to be able to get out of here and come see all of you and meet you in person, maybe break some bread together. But, um, again, it was a pleasure talking to you all, and I really appreciate you taking the time. Have a good evening. Cool. >>Thanks for having us. Thanks for joining us. Yes.

>> Announcer: From around the Globe, it's theCUBE with coverage of Kube Con and Cloud Native Con Europe 2021 virtual brought to you by Red Hat, the cloud native computing foundation and ecosystem partners. >> Hello, and welcome back to theCUBE's coverage of Kube Con and Cloud Native Con 2021 virtual. I'm John Furrier, host of theCUBE, here with a great guest, I'm excited to talk to. His company, that he was part of founding CTO, was bought by Red Hat. Ali Golshan, Senior Director of Global Software Engineer at Red Hat, formerly CTO of StackRox. Ali thanks for coming on, I appreciate it. Thanks for joining us. >> Thanks for having me excited to be here. >> So big acquisition in January, where we covered it on SiliconANGLE, You guys, security company, venture backed amplify Sequoya and on and on. Big part of Red Hat story in their security as developers want to shift left as they say and as more and more modern applications are being developed. So congratulations. So real quick, just quick highlight of what you guys do as a company and inside Red Hat. >> Sure, so the company's premise was built around how do you bring security the entire application life cycle. So StackRox focuses on sort of three big areas that we talk about. One is, how do you secure the supply chain? The second part of it is, how do you secure infrastructure and foster management and then the third part is now, how do you protect the workload that run on top of that infrastructure. So this is the part that aligned really well with Red Hat which is, Red Hat had wanted to take a lot of what we do around infrastructure, foster management configuration management and developer tools integrated into a lot of the things they do and obviously the workload protection part was a very seamless part of integrating us into the OpenShift part because we were built around cloud native constructs and obviously Red Hat having some of the foremost experts around cloud native sort of created a really great asset. >> Yeah, you guys got a great story. Obviously cloud native applications are rocking and rolling. You guys were in early serverless emerges, Kubernetes and then security in what I call the real time developer workflow. Ones that are building really fast, pushing code. Now it's called day two operations. So cloud native did two operations kind of encapsulates this new environment. You guys were right in the sweet spot of that. So this became quite the big deal, Red Hat saw an opportunity to bring you in. What was the motivation when you guys did the deal Was it like, "wow" this is a good fit. How did you react? What was the vibe at the StackRox when this was all going down? >> Yeah, so I think there's really three areas you look for, anytime a company comes up and sort of starts knocking on your door. One is really, is the team going to be the right fit? Is the culture going to be the right environment for the people? For us, that was a big part of what we were taking into consideration. We found Red Hat's general culture, how they approach people and sort of the overall approach the community was very much aligned with what we were trying to do. The second part of it was really the product fit. So we had from very early on started to focus purely on the Kubernetes components and doing everything we could, we call it sort of our product approach built in versus bolted on and this is sort of a philosophy that Red Hat had adopted for a long time and it's a part of a lot of their developer tools, part of their shift left story as well as part of OpenShift. And then the third part of it was really the larger strategy of how do you go to market. So we were hitting that point where we were in triple digit customers and we were thinking about scalability and how to scale the company. And that was the part that also fit really well which was obviously, RedHat more and more hearing from their customers about the importance and the criticality of security. So that last part happened to be one part. We ended up spending a lot of time on it, ended up being sort of three out of three matches that made this acquisition happen. >> Well congratulations, always great to see startups in the right position. Good hustle, great product, great market. You guys did a great job, congratulations. >> Thank you. >> Now, the big news here at KubeCon as Linux foundation open-source, you guys are announcing that you're open-sourcing at StackRox, this is huge news, obviously, you now work for an open-source company and so that was probably a part of it. Take us through the news, this is the top story here for this segment tickets through open-source. Take us through the news. >> Yeah, so traditionally StackRox was a proprietary tool. We do have open-source tooling but the entire platform in itself was a proprietary tool. This has been a number of discussions that we've had with the Red Hat team from the very beginning. And it sort of aligns around a couple of core philosophies. One is obviously Red Hat at its core being an open-source company and being very much plugged into the community and working with users and developers and engineers to be able to sort of get feedback and build better products. But I think the other part of it is that, I think a lot of us from a historic standpoint have viewed security to be a proprietary thing as we've always viewed the sort of magic algorithms or black boxes or some magic under the hood that really moved the needle. And that happens not to be the case anymore also because StackRox's philosophy was really built around Kubernetes and Built-in, we feel like one of the really great messages around wide open-source of security product is to build that trust with the community being able to expose, here's how the product works, here's how it integrates here are the actions it takes here's the ramifications or repercussions of some of the decisions you may make in the product. Those all I feel make for very good stories of how you build connection, trust and communication with the community and actually get feedback on it. And obviously at its core, the company being very much focused on Kubernetes developer tools, service manage, these are all open-source toolings obviously. So, for us it was very important to sort of talk the talk and walk the walk and this is sort of an easy decision at the end of the day for us to take the platform open-source. And we're excited about it because I think most still want a productized supported commercial product. So while it's great to have some of the tip of the spear customers look at it and adopt the open-source and be able to drive it themselves. We're still hearing from a lot of the customers that what they do want is really that support and that continuous management, maintenance and improvement around the product. So we're actually pretty excited. We think it's only going to increase our velocity and momentum into the community. >> Well, I got some questions on how it's going to work but I do want to get your comment because I think this is a pretty big deal. I had a conversation about 10 years ago with Doug Cutting, who was the founder of Hadoop, And he was telling me a story about a company he worked for, you know all this coding, they went under and the IP was gone, the software was gone and it was a story to highlight that proprietary software sometimes can never see the light of day and it doesn't continue. Here, you guys are going to continue the story, continue the code. How does that feel? What's your expectations? How's that going to work? I'm assuming that's what you're going to open it up which means that anyone can download the code. Is that right? Take us through how to first of all, do you agree with that this is going to stay alive and how's it going to work? >> Yeah, I mean, I think as a founder one of the most fulfilling things to have is something you build that becomes sustainable and stands the test of time. And I think, especially in today's world open-source is a tool that is in demand and only in a market that's growing is really a great way to do that. Especially if you have a sort of an established user base and the customer base. And then to sort of back that on top of thousands of customers and users that come with Red Hat in itself, gives us a lot of confidence that that's going to continue and only grow further. So the decision wasn't a difficult one, although transparently, I feel like even if we had pushed back I think Red Hat was pretty determined about open-source and we get anyway, but it's to say that we actually were in agreement to be able to go down that path. I do think that there's a lot of details to be worked out because obviously there's sort of a lot of the nuances in how you build product and manage it and maintain it and then, how do you introduce community feedback and community collaboration as part of open-source projects is another big part of it. I think the part we're really excited about is, is that it's very important to have really good community engagement, maintenance and response. And for us, even though we actually discussed this particular strategy during StackRox, one of the hindering aspects of that was really the resources required to be able to manage and maintain such a massive open-source project. So having Red Hat behind us and having a lot of this experience was very relevant. I think, as a, as a startup to start proprietary and suddenly open it and try to change your entire business model or go to market strategy commercialization, changed the entire culture of the company can sometimes create a lot of headwind. And as a startup, like sort of I feel like every year just trying not to die until you create that escape velocity. So those were I think some of the risk items that Red Hat was able to remove for us and as a result made the decision that much easier. >> Yeah, and you got the mothership with Red Hat they've done it before, they've been doing it for generations. You guys, you're in the startup, things are going crazy. It's like whitewater rafting, it's like everything's happening so fast. And now you got the community behind you cause you're going to have the CNC if you get Kubecon. I mean, it's a pretty great community, the support is amazing. I think the only thing the engineers might want to worry about is go back into the code base and clean things up a bit, as you start to see the code I'm like, wait a minute, their names are on it. So, it's always always a fun time and all serious now this is a big story on the DevSecOps. And I want to get your thoughts on this because kubernetes is still emerging, and DevOps is awesome, we've been covering that in for all of the life of theCUBE for the 11 years now and the greatness of DevOps but now DevSecOps is critical and Kubernetes native security is what people are looking at. When you look at that trend only continuing, what's your focus? What do you see? Now that you're in Red Hat as the CTO, former CTO of StackRox and now part of the Red Hat it's going to get bigger and stronger Kubernetes native and shifting left-hand or DevSecOps. What's your focus? >> Yeah, so I would say our focus is really around two big buckets. One is, Kubernetes native, sort of a different way to think about it as we think about our roadmap planning and go-to-market strategy is it's mutually exclusive with being in infrastructure native, that's how we think about it and as a startup we really have to focus on an area and Kubernetes was a great place for us to focus on because it was becoming the dominant orchestration engine. Now that we have the resources and the power of Red Hat behind us, the way we're thinking about this is infrastructure native. So, thinking about cloud native infrastructure where you're using composable, reusable, constructs and objects, how do you build potential offerings or features or security components that don't rely on third party tools or components anymore? How do you leverage the existing infrastructure itself to be able to conduct some of these traditional use cases? And one example we use for this particular scenario is networking. Networking, the way firewalling in segmentation was typically done was, people would tweak IP tables or they would install, for example, a proxy or a container that would terminate MTLS or become inline and it would create all sorts of sort of operational and risk overhead for users and for customers. And one of the things we're really proud of as sort of the company that pioneered this notion of cloud native security is if you just leverage network policies in Kubernetes, you don't have to be inline you don't have to have additional privileges, you don't have to create additional risks or operational overhead for users. So we're taking those sort of core philosophies and extending them. The same way we did to Kubernetes all the way through service manager, we're doing the same sorts of things Istio being able to do a lot of the things people are traditionally doing through for example, proxies through layer six and seven, we want to do through Istio. And then the same way for example, we introduced a product called GoDBledger which was an open-source tool, which would basically look at a yaml on helm charts and give you best practices responses. And it's something you we want for example to your get repositories. We want to take those sort of principles, enabling developers, giving them feedback, allowing them not to break their existing workflows and leveraging components in existing infrastructure to be able to sort of push security into cloud native. And really the two pillars we look at are ensuring we can get users and customers up and running as quickly as possible and reduce as much as possible operational overhead for them over time. So we feel these two are really at the core of open-sourcing in building into the infrastructure, which has sort of given us momentum over the last six years and we feel pretty confident with Red Hat's help we can even expand that further. >> Yeah, I mean, you bring up a good point and it's certainly as you get more scale with Red Hat and then the customer base, not only in dealing with the threat detection around containers and cloud native applications, you got to kind of build into the life cycle and you've got to figure out, okay, it's not just Kubernetes anymore, it's something else. And you've got advanced cluster security with Red Hat they got OpenShift cloud platform, you're going to have managed services so this means you're going to have scale, right? So, how do you view that? Because now you're going to have, you guys at the center of the advanced cluster security paradigm for Red Hat. That's a big deal for them and they've got a lot of R and D and a lot of, I wouldn't say R and D, but they got emerging technologies developing around that. We covered that in depth. So when you start to get into advanced cluster, it's compliance too, it's not just threat detection. You got insights telemetry, data acquisition, so you have to kind of be part of that now. How do you guys feel about that? Are you up for the task? >> Yeah, I hope so it's early days but we feel pretty confident about it, we have a very good team. So as part of the advanced cluster security we work also very closely with the advanced cluster management team in Red Hat because it's not just about security, it's about, how do you operationalize it, how do you manage it and maintain it and to your point sort of run it longterm at scale. The compliance part of it is a very important part. I still feel like that's in its infancy and these are a lot of conversations we're having internally at Red Hat, which is, we all feel that compliance is going to sort of more from the standard benchmarks you have from CIS or particular compliance requirements like the power, of PCI or Nest into how do you create more flexible and composable policies through a unified language that allows you to be able to create more custom or more useful things specific to your business? So this is actually, an area we're doing a lot of collaboration with the advanced cluster management team which is in that, how do you sort of bring to light a really easy way for customers to be able to describe and sort of abstract policies and then at the same time be able to actually and enforce them. So we think that's really the next key point of what we have to accomplish to be able to sort of not only gain scale, but to be able to take this notion of, not only detection in response but be able to actually build in what we call declarative security into your infrastructure. And what that means is, is to be able to really dictate how you want your applications, your services, your infrastructure to be configured and run and then anything that is sort of conflicting with that is auto responded to and I think that's really the larger vision that with Red Hat, we're trying to accomplish. >> And that's a nice posture to have you build it in, get it built in, you have the declarative models then you kind of go from there and then let the automation kick in. You got insights coming in from Red Hat. So all these things are kind of evolving. It's still early days and I think it was a nice move by Red Hat, so congratulations. Final question for you is, as you prepare to go to the next generation KubeCon is also seeing a lot more end user participation, people, you know, cloud native is going mainstream, when I say mainstream, seeing beyond the hyperscalers in the early adopters, Kubernetes and other infrastructure control planes are coming in you start to see the platforms emerge. Nobody wants another security tool, they want platforms that enable applications handle tools. As it gets more complicated, what's going to be the easy button in security cloud native? What's the approach? What's your vision on what's next? >> Yeah so, I don't know if there is an easy button in security and I think part of it is that there's just such a fragmentation and use cases and sort of designs and infrastructure that doesn't exist, especially if you're dealing with such a complex stack. And not only just a complex stack but a potentially use cases that not only span runtime but they deal with you deployment annual development life cycle. So the way we think about it is more sort of this notion that has been around for a long time which is the shared responsibility model. Security is not security's job anymore. Especially, because security teams probably cannot really keep up with the learning curve. Like they have to understand containers then they have to understand Kubernetes and Istio and Envoy and cloud platforms and APIs. and there's just too much happening. So the way we think about it is if you deal with security a in a declarative version and if you can state things in a way where how infrastructure is ran is properly configured. So it's more about safety than security. Then what you can do is push a lot of these best practices back as part of your gift process. Involve developers, engineers, the right product security team that are responsible for day-to-day managing and maintaining this. And the example we think about is, is like CVEs. There are plenty of, for example, vulnerability tools but the CVEs are still an unsolved problem because, where are they, what is the impact? Are they actually running? Are they being exploited in the wild? And all these things have different ramifications as you span it across the life cycle. So for us, it's understanding context, understanding assets ensuring how the infrastructure has to handle that asset and then ensuring that the route for that response is sent to the right team, so they can address it properly. And I think that's really our larger vision is how can you automate this entire life cycle? So, the information is routed to the right teams, the right teams are appending it to the application and in the future, our goal is not to just pardon the workload or the compute environment, but use this information to action pardon application themselves and that creates that additional agility and scalability. >> Yeah it's in the lifecycle of that built in right from the beginning, more productivity, more security and then, letting everything take over on the automation side. Ali congratulations on the acquisition deal with Red Hat, buyout that was great for them and for you guys. Take a minute to just quickly answer final final question for the folks watching here. The big news is you're open-sourcing StackRox, so that's a big news here at KubeCon. What can people do to get involved? Well, just share a quick quick commercial for what people can do to get involved? What are you guys looking for? Take a pledge to the community? >> Yeah, I mean, what we're looking for is more involvement in direct feedback from our community, from our users, from our customers. So there's a number, obviously the StackRox platform itself being open-source, we have other open-source tools like the KubeLinter. What we're looking for is feedback from users as to what are the pain points that they're trying to solve for. And then give us feedback as to how we're not addressing those or how can we better design our systems? I mean, this is the sort of feedback we're looking for and naturally with more resources, we can be a lot faster in response. So send us feedback good or bad. We would love to hear it from our users and our customers and get a better sense of what they're looking for. >> Innovation out in the open love it, got to love open-source going next gen, Ali Golshan Senior Director of Global Software Engineering the new title at Red Hat former CTO and founder of StackRox which spread had acquired in January, 2021. Ali thanks for coming on congratulations. >> Thanks for having, >> Okay, so keeps coverage of Kube Con cloud native Con 2021. I'm John Furrie, your host. Thanks for watching. (soft music)

>> Announcer: From around the Globe, it's theCUBE with coverage of Kube Con and Cloud Native Con Europe 2021 virtual brought to you by Red Hat, the cloud native computing foundation and ecosystem partners. >> Hello, and welcome back to theCUBE's coverage of Kube Con and Cloud Native Con 2021 virtual. I'm John Furrier, host of theCUBE, here with a great guest, I'm excited to talk to. His company, that he was part of founding CTO, was bought by Red Hat. Ali Golshan, Senior Director of Global Software Engineer at Red Hat, formerly CTO of StackRox. Ali thanks for coming on, I appreciate it. Thanks for joining us. >> Thanks for having me excited to be here. >> So big acquisition in January, where we covered it on SiliconANGLE, You guys, security company, venture backed amplify Sequoya and on and on. Big part of Red Hat story in their security as developers want to shift left as they say and as more and more modern applications are being developed. So congratulations. So real quick, just quick highlight of what you guys do as a company and inside Red Hat. >> Sure, so the company's premise was built around how do you bring security the entire application life cycle. So StackRox focuses on sort of three big areas that we talk about. One is, how do you secure the supply chain? The second part of it is, how do you secure infrastructure and foster management and then the third part is now, how do you protect the workload that run on top of that infrastructure. So this is the part that aligned really well with Red Hat which is, Red Hat had wanted to take a lot of what we do around infrastructure, foster management configuration management and developer tools integrated into a lot of the things they do and obviously the workload protection part was a very seamless part of integrating us into the OpeShift part because we were built around cloud native constructs and obviously Red Hat having some of the foremost experts around cloud native sort of created a really great asset. >> Yeah, you guys got a great story. Obviously cloud native applications are rocking and rolling. You guys were in early serverless emerges, Kubernetes and then security in what I call the real time developer workflow. Ones that are building really fast, pushing code. Now it's called day two operations. So cloud native did two operations kind of encapsulates this new environment. You guys were right in the sweet spot of that. So this became quite the big deal, Red Hat saw an opportunity to bring you in. What was the motivation when you guys did the deal Was it like, "wow" this is a good fit. How did you react? What was the vibe at the StackRox when this was all going down? >> Yeah, so I think there's really three areas you look for, anytime a company comes up and sort of starts knocking on your door. One is really, is the team going to be the right fit? Is the culture going to be the right environment for the people? For us, that was a big part of what we were taking into consideration. We found Red Hat's general culture, how they approach people and sort of the overall approach the community was very much aligned with what we were trying to do. The second part of it was really the product fit. So we had from very early on started to focus purely on the Kubernetes components and doing everything we could, we call it sort of our product approach built in versus built it on and this is sort of a philosophy that Red Hat had adopted for a long time and it's a part of a lot of their developer tools, part of their shift left story as well as part of OpenShift. And then the third part of it was really the larger strategy of how do you go to market. So we were hitting that point where we were in triple digit customers and we were thinking about scalability and how to scale the company. And that was the part that also fit really well which was obviously, RedHat more and more hearing from their customers about the importance and the criticality of security. So that last part happened to be one part. We ended up spending a lot of time on it, ended up being sort of the outer three matches that made this acquisition happen. >> Well congratulations, always great to see startups in the right position. Good hustle, great product, great market. You guys did a great job, congratulations. >> Thank you. >> Now, the big news here at KubeCon as Linux foundation open-source, you guys are announcing that you're open-sourcing at StackRox, this is huge news, obviously, you now work for an open-source company and so that was probably a part of it. Take us through the news, this is the top story here for this segment tickets through open-source. Take us through the news. >> Yeah, so traditionally StackRox was a proprietary tool. We do have open-source tooling but the entire platform in itself was a proprietary tool. This has been a number of discussions that we've had with the Red Hat team from the very beginning. And it sort of aligns around a couple of core philosophies. One is obviously Red Hat at its core being an open-source company and being very much plugged into the community and working with users and developers and engineers to be able to sort of get feedback and build better products. But I think the other part of it is that, I think a lot of us from a historic standpoint have viewed security to be a proprietary thing as we've always viewed the sort of magic algorithms or black boxes or some magic under the hood that really moved the needle. And that happens not to be the case anymore also because StackRox's philosophy was really built around Kubernetes and Built-in, we feel like one of the really great messages around wide open-source of security product is to build that trust with the community being able to expose, here's how the product works, here's how it integrates here are the actions it takes here's the ramifications or repercussions of some of the decisions you may make in the product. Those all I feel make for very good stories of how you build connection, trust and communication with the community and actually get feedback on it. And obviously at its core, the company being very much focused on Kubernetes developer tools, service manage, these are all open-source toolings obviously. So, for us it was very important to sort of talk the talk and walk the walk and this is sort of an easy decision at the end of the day for us to take the platform open-source. And we're excited about it because I think most still want a productized supported commercial product. So while it's great to have some of the tip of the spear customers look at it and adopt the open-source and be able to drive it themselves. We're still hearing from a lot of the customers that what they do want is really that support and that continuous management, maintenance and improvement around the product. So we're actually pretty excited. We think it's only going to increase our velocity and momentum into the community. >> Well, I got some questions on how it's going to work but I do want to get your comment because I think this is a pretty big deal. I had a conversation about 10 years ago with Doug Cutting, who was the founder of Hadoop, And he was telling me a story about a company he worked for, you know all this coding, they went under and the IP was gone, the software was gone and it was a story to highlight that proprietary software sometimes can never see the light of day and it doesn't continue. Here, you guys are going to continue the story, continue the code. How does that feel? What's your expectations? How's that going to work? I'm assuming that's what you're going to open it up which means that anyone can download the code. Is that right? Take us through how to first of all, do you agree with that this is going to stay alive and how's it going to work? >> Yeah, I mean, I think as a founder one of the most fulfilling things to have is something you build that becomes sustainable and stands the test of time. And I think, especially in today's world open-source is a tool that is in demand and only in a market that's growing is really a great way to do that. Especially if you have a sort of an established user base and the customer base. And then to sort of back that on top of thousands of customers and users that come with Red Hat in itself, gives us a lot of confidence that that's going to continue and only grow further. So the decision wasn't a difficult one, although transparently, I feel like even if we had pushed back I think Red Hat was pretty determined about open-source and we get anyway, but it's to say that we actually were in agreement to be able to go down that path. I do think that there's a lot of details to be worked out because obviously there's sort of a lot of the nuances in how you build product and manage it and maintain it and then, how do you introduce community feedback and community collaboration as part of open-source projects is another big part of it. I think the part we're really excited about is, is that it's very important to have really good community engagement, maintenance and response. And for us, even though we actually discussed this particular strategy during StackRox, one of the hindering aspects of that was really the resources required to be able to manage and maintain such a massive open-source project. So having Red Hat behind us and having a lot of this experience was very relevant. I think, as a, as a startup to start proprietary and suddenly open it and try to change your entire business model or go to market strategy commercialization, changed the entire culture of the company can sometimes create a lot of headwind. And as a startup, like sort of I feel like every year just trying not to die until you create that escape velocity. So those were I think some of the risk items that Red Hat was able to remove for us and as a result made the decision that much easier. >> Yeah, and you got the mothership with Red Hat they've done it before, they've been doing it for generations. You guys, you're in the startup, things are going crazy. It's like whitewater rafting, it's like everything's happening so fast. And now you got the community behind you cause you're going to have the CNC if you get Kubecon. I mean, it's a pretty great community, the support is amazing. I think the only thing the engineers might want to worry about is go back into the code base and clean things up a bit, as you start to see the code I'm like, wait a minute, their names are on it. So, it's always always a fun time and all serious now this is a big story on the DevSecOps. And I want to get your thoughts on this because kubernetes is still emerging, and DevOps is awesome, we've been covering that in for all of the life of theCUBE for the 11 years now and the greatness of DevOps but now DevSecOps is critical and Kubernetes native security is what people are looking at. When you look at that trend only continuing, what's your focus? What do you see? Now that you're in Red Hat as the CTO, former CTO of StackRox and now part of the Red Hat it's going to get bigger and stronger Kubernetes native and shifting left-hand or DevSecOps. What's your focus? >> Yeah, so I would say our focus is really around two big buckets. One is, Kubernetes native, sort of a different way to think about it as we think about our roadmap planning and go-to-market strategy is it's mutually exclusive with being in infrastructure native, that's how we think about it and as a startup we really have to focus on an area and Kubernetes was a great place for us to focus on because it was becoming the dominant orchestration engine. Now that we have the resources and the power of Red Hat behind us, the way we're thinking about this is infrastructure native. So, thinking about cloud native infrastructure where you're using composable, reusable, constructs and objects, how do you build potential offerings or features or security components that don't rely on third party tools or components anymore? How do you leverage the existing infrastructure itself to be able to conduct some of these traditional use cases? And one example we use for this particular scenario is networking. Networking, the way firewalling in segmentation was typically done was, people would tweak IP tables or they would install, for example, a proxy or a container that would terminate MTLS or become inline and it would create all sorts of sort of operational and risk overhead for users and for customers. And one of the things we're really proud of as sort of the company that pioneered this notion of cloud native security is if you just leverage network policies in Kubernetes, you don't have to be inline you don't have to have additional privileges, you don't have to create additional risks or operational overhead for users. So we're taking those sort of core philosophies and extending them. The same way we did to Kubernetes all the way through service manager, we're doing the same sorts of things Istio being able to do a lot of the things people are traditionally doing through for example, proxies through layer six and seven, we want to do through Istio. And then the same way for example, we introduced a product called GoDBledger which was an open-source tool, which would basically look at a yaml on helm charts and give you best practices responses. And it's something you we want for example to your get repositories. We want to take those sort of principles, enabling developers, giving them feedback, allowing them not to break their existing workflows and leveraging components in existing infrastructure to be able to sort of push security into cloud native. And really the two pillars we look at are ensuring we can get users and customers up and running as quickly as possible and reduce as much as possible operational overhead for them over time. So we feel these two are really at the core of open-sourcing in building into the infrastructure, which has sort of given us momentum over the last six years and we feel pretty confident with Red Hat's help we can even expand that further. >> Yeah, I mean, you bring up a good point and it's certainly as you get more scale with Red Hat and then the customer base, not only in dealing with the threat detection around containers and cloud native applications, you got to kind of build into the life cycle and you've got to figure out, okay, it's not just Kubernetes anymore, it's something else. And you've got advanced cluster security with Red Hat they got OpenShift cloud platform, you're going to have managed services so this means you're going to have scale, right? So, how do you view that? Because now you're going to have, you guys at the center of the advanced cluster security paradigm for Red Hat. That's a big deal for them and they've got a lot of R and D and a lot of, I wouldn't say R and D, but they got emerging technologies developing around that. We covered that in depth. So when you start to get into advanced cluster, it's compliance too, it's not just threat detection. You got insights telemetry, data acquisition, so you have to kind of be part of that now. How do you guys feel about that? Are you up for the task? >> Yeah, I hope so it's early days but we feel pretty confident about it, we have a very good team. So as part of the advanced cluster security we work also very closely with the advanced cluster management team in Red Hat because it's not just about security, it's about, how do you operationalize it, how do you manage it and maintain it and to your point sort of run it longterm at scale. The compliance part of it is a very important part. I still feel like that's in its infancy and these are a lot of conversations we're having internally at Red Hat, which is, we all feel that compliance is going to sort of more from the standard benchmarks you have from CIS or particular compliance requirements like the power, of PCI or Nest into how do you create more flexible and composable policies through a unified language that allows you to be able to create more custom or more useful things specific to your business? So this is actually, an area we're doing a lot of collaboration with the advanced cluster management team which is in that, how do you sort of bring to light a really easy way for customers to be able to describe and sort of abstract policies and then at the same time be able to actually and enforce them. So we think that's really the next key point of what we have to accomplish to be able to sort of not only gain scale, but to be able to take this notion of, not only detection in response but be able to actually build in what we call declarative security into your infrastructure. And what that means is, is to be able to really dictate how you want your applications, your services, your infrastructure to be configured and run and then anything that is sort of conflicting with that is auto responded to and I think that's really the larger vision that with Red Hat, we're trying to accomplish. >> And that's a nice posture to have you build it in, get it built in, you have the declarative models then you kind of go from there and then let the automation kick in. You got insights coming in from Red Hat. So all these things are kind of evolving. It's still early days and I think it was a nice move by Red Hat, so congratulations. Final question for you is, as you prepare to go to the next generation KubeCon is also seeing a lot more end user participation, people, you know, cloud native is going mainstream, when I say mainstream, seeing beyond the hyperscalers in the early adopters, Kubernetes and other infrastructure control planes are coming in you start to see the platforms emerge. Nobody wants another security tool, they want platforms that enable applications handle tools. As it gets more complicated, what's going to be the easy button in security cloud native? What's the approach? What's your vision on what's next? >> Yeah so, I don't know if there is an easy button in security and I think part of it is that there's just such a fragmentation and use cases and sort of designs and infrastructure that doesn't exist, especially if you're dealing with such a complex stack. And not only just a complex stack but a potentially use cases that not only span runtime but they deal with you deployment annual development life cycle. So the way we think about it is more sort of this notion that has been around for a long time which is the shared responsibility model. Security is not security's job anymore. Especially, because security teams probably cannot really keep up with the learning curve. Like they have to understand containers then they have to understand Kubernetes and Istio and Envoy and cloud platforms and APIs. and there's just too much happening. So the way we think about it is if you deal with security a in a declarative version and if you can state things in a way where how infrastructure is ran is properly configured. So it's more about safety than security. Then what you can do is push a lot of these best practices back as part of your gift process. Involve developers, engineers, the right product security team that are responsible for day-to-day managing and maintaining this. And the example we think about is, is like CVEs. There are plenty of, for example, vulnerability tools but the CVEs are still an unsolved problem because, where are they, what is the impact? Are they actually running? Are they being exploited in the wild? And all these things have different ramifications as you span it across the life cycle. So for us, it's understanding context, understanding assets ensuring how the infrastructure has to handle that asset and then ensuring that the route for that response is sent to the right team, so they can address it properly. And I think that's really our larger vision is how can you automate this entire life cycle? So, the information is routed to the right teams, the right teams are appending it to the application and in the future, our goal is not to just pardon the workload or the compute environment, but use this information to action pardon application themselves and that creates that additional agility and scalability. >> Yeah it's in the lifecycle of that built in right from the beginning, more productivity, more security and then, letting everything take over on the automation side. Ali congratulations on the acquisition deal with Red Hat, buyout that was great for them and for you guys. Take a minute to just quickly answer final final question for the folks watching here. The big news is you're open-sourcing StackRox, so that's a big news here at KubeCon. What can people do to get involved? Well, just share a quick quick commercial for what people can do to get involved? What are you guys looking for? Take a pledge to the community? >> Yeah, I mean, what we're looking for is more involvement in direct feedback from our community, from our users, from our customers. So there's a number, obviously the StackRox platform itself being open-source, we have other open-source tools like the KubeLinter. What we're looking for is feedback from users as to what are the pain points that they're trying to solve for. And then give us feedback as to how we're not addressing those or how can we better design our systems? I mean, this is the sort of feedback we're looking for and naturally with more resources, we can be a lot faster in response. So send us feedback good or bad. We would love to hear it from our users and our customers and get a better sense of what they're looking for. >> Innovation out in the open love it, got to love open-source going next gen, Ali Golshan Senior Director of Global Software Engineering the new title at Red Hat former CTO and founder of StackRox which spread had acquired in January, 2021. Ali thanks for coming on congratulations. >> Thanks for having, >> Okay, so keeps coverage of Kube Con cloud native Con 2021. I'm John Furrie, your host. Thanks for watching. (soft music)

>>From around the globe. It's the cube presenting enterprise digital resilience on hybrid and multicloud brought to you by IO Tahoe. Okay. Now we're going to go into the demo and we want to get a better understanding of how you can leverage OpenShift and IO Tahoe to facilitate faster application deployment. Let me pass the mic to Savita, take it away. >>Uh, thanks Dave. Happy to be here again. Um, guys, as they've mentioned, my name is to be the Davis. I'm the enterprise account executive here at IO Tahoe. Uh, so today we just wanted to give you guys a general overview of how we're using open shift. >>Yeah. Hey, I'm Noah IO. Tahoe's data operations engineer working with OpenShift, and I've been learning the ins and outs of OpenShift for like the past few months and I'm here to share it up line. >>Okay. So, so before we begin, I'm sure everybody wants to know Noah. What are the benefits of using OpenShift? >>Well, um, there's five that I can think of a faster time to operations, simplicity, automation control, and digital resilience. >>Okay. So, so that, that's really interesting because those are the exact same benefits that we at Aja Tahoe delivered to our customers. But, uh, let's start with faster time to operation by running IO Tahoe on OpenShift. Is it faster than let's say using Kubernetes and other platforms? >>Well, um, our objective at IO Tahoe has to be accessible across multiple cloud platforms, right? And so by hosting our application and containers, uh, we're able to achieve this. So to answer your question, it's faster to create end user application images, using container tools like Kubernetes with OpenShift as compared to like Kubernetes with Docker cryo or container D. >>Okay. So, so we got a bit technical there. Um, can you explain that in a bit more detail? >>Yeah, there's a bit of vocabulary involved. Uh, so basically containers are used in developing things like databases, web servers, or applications such as I've taught. What's great about containers is that they split the workload. So developers can select a libraries without breaking anything. And CIS admins can update the host without interrupting the programmers. Uh, now OpenShift works hand-in-hand with Kubernetes to provide a way to build those containers for applications. >>Okay, got it. Uh, so basically containers make life easier for developers and system admins. So how does OpenShift differ from other platforms? >>Um, well this kind of leads into the second benefit I want to talk about, which is simplicity. Basically. There's a lot of steps involved with when you're using Kubernetes with a Docker, but OpenShift simplifies this with their source to image process that takes the source code and turns it into a container image, but that's not all, uh, OpenShift has a lot of automation and features that simplify working with containers and important one being its web console. Um, so here I've set up a light version of OpenShift code ready containers. And I was able to set up our application right from the web console. And I was able to set up this entire thing in windows, Mac, and Linux. So it's environment agnostic in that sense. >>Okay. So I think I seen the top left. This is a developer's view. What would a systems admin view look like? >>That's a good question. So, uh, here's the, uh, administrator view and this kind of ties into the benefit of control. Um, this view gives insights into each one of the applications and containers that are running and you can make changes without affecting deployment. Um, and you can also within this view, set up each layer of security and there's multiple that you can prop up, but I haven't fully messed around with it because since with my look, I'd probably locked myself out. >>Okay. Um, so, so that seems pretty secure. Um, is there a single point security such as you use a login or are there multiple layers of security? Yeah. >>Um, there are multiple layers of security. There's your user login security groups and general role based access controls. Um, but there's also a ton of layers of security surrounding like the containers themselves. But for the sake of time, I won't get too far into it. >>Okay. Uh, so you mentioned simplicity and time to operation as being two of the benefits. You also briefly mentioned automation and as you know, automation is the backbone of our platform here at IO Tahoe. So that's certainly grabbed my attention. Can you go a bit more in depth in terms of automation? >>Yeah, sure. I'd say that automation is important benefit. Uh, OpenShift provides extensive automation that speeds up that time to operation, right? So the latest versions of open should come with a built-in cryo container engine, which basically means that you get to skip that container engine installation step. And you don't have to like log into each individual container hosts and configure networking, configure the registered servers, storage, et cetera. So I'd say, uh, it automates the more boring kind of tedious processes. >>Okay. So I see the iota template there. What does it allow me to do >>In terms of automation in application development? So we've created an OpenShift template, which contains our application. This allows developers to instantly like, um, set up a product within that template or within that. Yeah. >>Okay. Um, so Noah, last question. Speaking of vocabulary, you mentioned earlier digital resilience is a term we're hearing, especially in the banking and finance world. Um, it seems from what you described industries like banking and finance would be more resilient using OpenShift, correct? >>Yeah. In terms of digital resilience, OpenShift will give you better control over the consumption of resources each container is using. In addition, the benefit of containers is that, uh, like I mentioned earlier, CIS admins can troubleshoot the servers about like bringing down the application. And if the application does go down, it's easy to bring it back up using the templates and like the other automation features that OpenShift provides. >>Okay. So thanks so much. So any final thoughts you want to share? >>Yeah. Just want to give a quick recap of like the five benefits that you gain by using OpenShift. Uh, the five are time to operation automation, control, security and simplicity. Uh, you can deploy applications faster. You can simplify the workload. You can automate a lot of the otherwise tedious processes can maintain full control over your workflow and you can assert digital resilience within your environment. >>So guys, thanks for that. Appreciate the demo. Um, I wonder you guys have been talking about the combination of IO Tahoe and red hat. Can you tie that in Sabita to digital resilience specifically? >>Yeah, sure. Dave, um, so why don't we speak to the benefits of security controls in terms of digital resilience at Iowa hope? Uh, we automated detection and applied controls at the data level. So this would provide for more enhanced security. >>Okay. But so if you were to try to do all these things manually, I mean, what's, what does that do? How, how much time can I compress? What's the time to value? >>So, um, with our latest versions via Tahoe, we're taking advantage of faster deployment time, um, associated with containerization and Kubernetes. So this kind of speeds up the time it takes for customers to start using our software as they be able to quickly spin up a hotel and their own on-premise environment or otherwise in their own cloud environment, like including AWS or shore Oracle GCP and IBM cloud. Um, our quick start templates allow flexibility to deploy into multicloud environments, all just using like a few clicks. >>Okay. Um, so, so now I'll just quickly add, so what we've done, I Tahoe here is we've really moved our customers away from the whole idea of needing a team of engineers to apply controls to data as compared to other manually driven workflows. Uh, so with templates, automation, pre-built policies and data controls, one person can be fully operational within a few hours and achieve results straight out of the box, uh, on any cloud. >>Yeah. We've been talking about this theme of abstracting, the complexity that's really what we're seeing is a major trend in this coming decade. Okay, great. Thanks Savita Noah. Uh, ho how can people get more information or if they have any follow-up questions, where should they go? >>Yeah, sure. They've I mean, if you guys are interested in learning more, you know, reach out to us at info at dot com to speak with one of our sales engineers. I mean, we'd love to hear from you. So book a meeting as soon as you can. >>All right. Thanks guys. Keep it right there for more cube content with IO Tahoe.

>> Hello everyone, and welcome back to theCUBEs coverage of the Snowflake Data Cloud Summit 2020. We're tracking the rise of the data cloud Sunny Bedi is here with me. He's the CIO and Chief Data Officer for Snowflake. Sunny, thanks for making the time today. Good to see you. >> Same here, Dave. Thanks for having me over. >> Yeah, so you're welcome. So before we get into it, I got to ask you, I mean, you recently left Nvidia to join Snowflake. I mean(chuckles) one of the few companies that are almost as hot as Snowflake, how come? >> Well, you know Dave I joined Nvidia 12 years ago. I was there for 12 years, when Nvidia was less than 2000 people company. And Nvidia have an unbelievable growth trajectory, and then from 2000 employees to 16,000, when I left in December of 2019. And Snowflake kind of provided the same opportunity to come in, and help scale the company. I thrive in an environment where I can be creative, I thrive in an environment where I can build things, I can scale things, I can grow things. And its been just a perfect opportunity to come and repeat that success over here. >> Awesome, Well we wish you the best. Talk about your role a little bit. I mean, it's like totally unique. I mean, especially in certain smaller organizations that have the same person, in the role of Chief Information Officer and Chief Data Officer, but, which are you? Are you more CIO, CDO, how do you balance that out? >> I would say that I'm both, to be an effective CIO, you need immersion with automation, you need immersion with data, you need immersion with security, and you also need immersion with compliance. So if all of these things are together, things are integrated. You have a cohesive way of handling all the pieces that come together. We believe if you keep them separated, you create silos and we definitely don't want silos. We want integration. We want seamless integration to drive and scale the company for future. >> I always felt-- >> So my time is balanced between both areas. >> I mean, I always felt like a lot of the CIOs I talked to, they'd love to get more involved in the data, but they're just too busy trying to keep the lights on. So, maybe what are your thoughts on the priorities of each hats CIO and CDO? >> Yeah, so look, I mean, I think because we're a full cloud company, we don't have anything on-prem. I don't have any workloads on-prem. we don't have a data center. I really don't have to worry about all the operational challenges that you have to deal with being an on-prem company. So the cycles that I can be involved from a transformation prospect, driving transformation for the company, both on the data side, as well as on the IT side. I have that cycles to invest that time and energy into both areas. Typically in a traditional company, which has not yet migrated towards the cloud, a major portion of their bandwidth gets wasted. CIOs bandwidth and IT professionals bandwidth gets wasted, in dealing with the operational challenges that you have in an on-prem environment. So having not to worry about that over here, it gives me all the cycles to be investing my time on both areas. >> Yeah, a lot of wasted IT labor over the decades. Let me ask you, how is running a data company? We were inside of a fast moving Silicon Valley Tech Company. What are the similarities and the differences from some of the customers? I mean, on the one hand, you're moving faster than your customers at least most of them, and you don't have the technical that you just described, CX on Nirvana. On the other hand, you're an example of what's possible. You can sort of set the best practice mark. How do you see that dynamic? >> So, in our firm world-class IT organization, it needs to be data-driven, it needs to be highly automated, it needs to enable world-class user experience, and then to secure and make the environment compliant resilient. The cloud platform that we have, inside Snowflake, allows us to achieve all of that. Now that is, an ideal situation to be in. But you don't have to deal with, all the on-prem type of workloads. So finding that balance is what we're going after. And, however this is a journey, right. For other companies who are not on the cloud, its a journey. They have to prioritize that. They have to start moving things to the cloud, and that's where we are different and similar, right. We're different that we don't have to worry about that. Everything is in the cloud for us. And then, that's kind of how we see it. >> So, you know, used to call it the dogfooding segment, but Oliver Bussmann was the CIO of SAP. So no, no, Dave, we call it drinking your own champagne. (laughs) which is how you guys are referring to it. But, sometimes still in such situations you're (laughs) inside the sausage factory, which is good in a way because you see it before it goes into production. But, so what's your journey with, with Snowflake been like? >> Yeah, so that's a really good question. That's a major portion of what I do at work. And, let's start with the first principles of we believe, that we want to measure everything in the company, that's important for companies performance. If we measure the right things, we believe we can drive the best outcomes. We are driven through those first principles and we leveraged our business applications, our data, our security, our automation, and our compliance to integrate with our product to power, all these use cases and workloads. In our own environment, we call that snow house. Which is nothing but a Snowflake instance. So, for all the new products that we are coming into market with, we work very closely with the engineering team, with the product management team, to make sure that we actually become customer zero, and try to use as much functionality of that, inside our own enterprise and give as much feedback to our engineering and our product management teams, so that they can make the customer one experience to be world-class. So that's kind of in a nutshell how we go to market with those products. >> So you're customer zero. So all the product guys that they suck up to you, or are they afraid of you? (laughs) >> Well, I think it's a very neutral, beneficial relationship. So, they know that my team's feedback, is important to how they are kind of shaping up the product, and it's just not necessarily IT, right. We have folks in finance, folks in sales, marketing, everybody is drinking the champagne, right. And IT and the data team actually enabled that deployment, but the use cases are pretty much in the entire enterprise of the company in every aspect of it. Well you know-- >> Including security. >> Well, that's what we say. We always talk about alignment, but it's like, it's almost alignment by design, as opposed to being this forced thing. I'm interested in this, sort of Snowflake on Snowflake concept that you guys talk about. What were your objectives going in and maybe thinking about the outcomes, what did you expect? Did you work backwards from that? What were you trying to achieve? >> Yeah, I mean, look again back to the first principles. We believe we want to measure everything that's important to our business. That will drive the right outcomes. We then layer the application layer. We then overlay the business process layer. We then overlay the compliance and security layer. And the end result really is operationalizing Snowflake internally to drive our business, making the right choices, right decisions for the company. So we have a ton of use cases that are just ideal, using Snowflake on Snowflake. You know I can give you some examples of that if you like, >> Yes. >> But, >> Go on please. >> Security being one of the biggest use cases. We use the entire monitoring and remediation work that goes in the security compliance world, all through Snowflake. And we are finding real time events through data sharing, with our key suppliers. And we're ensuring that we're protecting our environment as much as possible with that whole infrastructure. >> You talked about layering, governance, security, et cetera. Yeah (laughs) I'm imagining a coat of primer paint in a nice and smooth over, it's not a bolt-on. I want to press you on that, because it can't be an afterthought. And what you're describing is much more of a modern approach. And I want you to totally differentiate between the layers that you talked about and what you've surely seen in your experience over the years as a bolt-on, what's the difference? >> Well, I mean the security wall, there's a lot of data, and a lot of the data that is critical to your environment. You want to make sure it is fully complete, you're getting it in the right hands, in the right platform to understand that, and doing the correlation work that needs to happen real time. Our platform allows all that data to be ingested and real time and anything that is suspicious, that's being out there. We're finding that stuff in real time. The monitoring has to be real time. And if there is an event, somebody needs to take an action real time. So the platform allows it to integrate altogether. And basically, the suppliers that we're using are also doing data sharing with us on this platform. So it makes the whole security remediation to be really really fantastic experience. >> Well I think too, I'd to share often with my audience when I talk to practitioners that are using Snowflake they, surprising to me when I first heard this, they said, "Well we choose Snowflake as the security," and I went, what! But the simplicity and the workflow is simpler, and it just means less human labor involved in setting these things up. So I wonder if you could talk about the team that you put together, the culture that you're building, and what's the makeup look like? >> Sure, so are you specifically asking about the characteristics of how we're building up the culture? >> Yeah, absolutely. >> Okay, so I think we're looking for, obviously very much high energy folks, people who have, high accountability, they're data-driven. We want to measure everything that's important to us. We're looking for folks who have situational awareness, and then finally high sense of urgency. I think all of these elements, allows IT organization to be integrated with the business. In large traditional companies, IT organizations kind of disintegrate with the business. We want to integrate with the business, to drive the best outcomes that are needed for the company. >> I Want to ask you about some of your favorite use cases, but you mentioned measurement. How do you measure? What are you measuring? >> Sure, so I would say that, let's just take security. Cause we talked about security. Let's just use security as a use case. So in security, there are many different frameworks, as you may know, right. There is the NIST framework, there is the CIS framework, there is an ISO framework. We have adopted towards a CIS framework inside Snowflake. That framework has 20 controls and that 20 controls has another 20 sub-controls. So we're talking about 400 controls potentially. Not every control is applicable to us, but majority of them are. And so for every control, there is a source of data, that's being ingested in Snowflake. I'll give you an example of that is asset management. So, asset management for end points, asset management for our servers, or asset management for our network gear. All of that data gets ingested inside Snowflake. We measure that. We can tell you exactly how many end points I have. I can tell you exactly when an employee gets onboarded, what laptop we have given them, when the employee leaves the company, I'll be collecting that laptop back on time, I'll be revoking all that access. That's part of CIS Control 1 as an example, and we're measuring all of that. And I can tell you exactly at my real time inside Snowflake. How effective I am for that specific control. That's just an example of that Dave. Now imagine 400 of these items that make up the whole security CIS framework. You want to measure everything on that 400 controls or 400 sub-controls. And you want to make sure that if any of that control is not being managed properly, you're alerted about it and you're remediating it to prevent a security issue that may pop up. >> Awesome, visibility and automation component. Are you a CSO too Sunny? We don't really have that title. We don't really have a CSO title, but I do wear a security hat as well. It's actually a joint responsibility between... I manage the corporate security. The product security is inside the product team, but we use the same common framework. We use the same common telemetry. We use the same common methodology. Incident management response teams are very similar, and it's all powered through a Snowflake. >> Awesome. Sunny Bedi you're great guests, I would imagine the sales guys love dragging you on zooms these days to sales calls, just to (laughs) share best practice, but love to have you back and continue the conversation. Sunny Bedi, really appreciate your time. Thank you. >> Thank you Dave. Thank you very much. >> All right, keep it right there everybody. We'll be right back with our next guest, right after this short break.

>> Narrator: From around the globe, it's theCUBE, covering the Upgrade 2020, the NTT Research Summit presented by NTT Research. >> Hey, welcome back everybody. Jeff Frick here with theCUBE. We're in Palo Alto studio for our ongoing coverage of the Upgrade 2020, it's the NTT Research conference. It's our first year covering the event, it's actually the first year for the event inaugural, a year for the events, we're really, really excited to get into this. It's basic research that drives a whole lot of innovation, and we're really excited to have our next guest. He is Kazuhiro Gomi, he is the President and CEO of NTT Research. Kazu, great to see you. >> Hi, good to see you. >> Yeah, so let's jump into it. So this event, like many events was originally scheduled I think for March at Berkeley, clearly COVID came along and you guys had to make some changes. I wonder if you can just share a little bit about your thinking in terms of having this event, getting this great information out, but having to do it in a digital way and kind of rethinking the conference strategy. >> Sure, yeah. So NTT Research, we started our operations about a year ago, July, 2019. and I always wanted to show the world that to give a update of what we have done in the areas of basic and fundamental research. So we plan to do that in March, as you mentioned, however, that the rest of it to some extent history, we needed to cancel the event and then decided to do this time of the year through virtual. Something we learned, however, not everything is bad, by doing this virtual we can certainly reach out to so many peoples around the globe at the same time. So we're taking, I think, trying to get the best out of it. >> Right, right, so you've got a terrific lineup. So let's jump into a little bit. So first thing just about NTT Research, we're all familiar, if you've been around for a little while about Bell Labs, we're fortunate to have Xerox PARC up the street here in Palo Alto, these are kind of famous institutions doing basic research. People probably aren't as familiar at least in the states around NTT basic research. But when you think about real bottom line basic research and how it contributes ultimately, it gets into products, and solutions, and health care, and all kinds of places. How should people think about basic research and its role in ultimately coming to market in products, and services, and all different things. But you're getting way down into the weeds into the really, really basic hardcore technology. >> Sure, yeah, so let me just from my perspective, define the basic research versus some other research and development. For us that the basic research means that we don't necessarily have any like a product roadmap or commercialization roadmap, we just want to look at the fundamental core technology of all things. And from the timescale perspective obviously, not that we're not looking at something new, thing, next year, next six months, that kind of thing. We are looking at five years or sometimes longer than that, potentially 10 years down the road. But you mentioned about the Bell Lab and Xerox PARC. Yeah, well, they used to be such organizations in the United States, however, well, arguably those days have kind of gone, but so that's what's going on in the United States. In Japan, NTT has have done quite a bit of basic research over the years. And so we wanted to, I think because that a lot of the cases that we can talk about the end of the Moore's laws and then the, we are kind of scary time for that. The energy consumptions on ITs We need to make some huge, big, fundamental change has to happen to sustain our long-term development of the ideas and basically for the sake of human beings. >> Right, right. >> So NTT sees that and also we've been doing quite a bit of basic research in Japan. So we recognize this is a time that the let's expand this activities and then by doing, as a part of doing so is open up the research lab in Silicon Valley, where certainly we can really work better, work easier to with that the global talents in this field. So that's how we started this endeavor, like I said, last year. And so far, it's a tremendous progress that we have made, so that's where we are. >> That's great, so just a little bit more specific. So you guys are broken down into three labs as I understand, you've got the Physics, the PHI, which is Physics and Informatics, the CIS lab Cryptography and Information Security, and the MEI lab Medical and Health Informatics, and the conference has really laid out along those same tracks, really day one is a whole lot of stuff, or excuse me, they do to run the Physics and Informatics day. The next day is really Cryptography and Information Security, and then the Medical and Health Informatics. So those are super interesting but very diverse kind of buckets of fundamental research. And you guys are attacking all three of those pillars. >> Yup, so day one, general session, is that we cover the whole, all the topics. And but just that whole general topics. I think some people, those who want to understand what NTT research is all about, joining day one will be a great day to be, to understand more holistic what we are doing. However, given the type of research topic that we are tackling, we need the deep dive conversations, very specific to each topic by the specialist and the experts in each field. Therefore we have a day two, three, and four for a specific topics that we're going to talk about. So that's a configuration of this conference. >> Right, right, and I love. I just have to read a few of the session breakout titles 'cause I think they're just amazing and I always love learning new vocabulary words. Coherent nonlinear dynamics and combinatorial optimization language multipliers, indistinguishability obfuscation from well-founded assumptions, fully deniable communications and computation. I mean, a brief history of the quasi-adaptive NIZKs, which I don't even know what that stands for. (Gomi laughing) Really some interesting topics. But the other thing that jumps out when you go through the sessions is the representation of universities and really the topflight university. So you've got people coming from MIT, CalTech, Stanford, Notre Dame, Michigan, the list goes on and on. Talk to us about the role of academic institutions and how NTT works in conjunction with academic institutions, and how at this basic research level kind of the commercial academic interests align and come together, and work together to really move this basic research down the road. >> Sure, so the working with academic, especially at the top-notch universities are crucial for us. Obviously, that's where the experts in each field of the basic research doing their super activities and we definitely need to get connected, and then we need to accelerate our activities and together with the entities researchers. So that has been kind of one of the number one priority for us to jumpstart and get some going. So as you mentioned, Jeff, that we have a lineup of professors and researchers from each top-notch universities joining to this event and talking at a generous, looking at different sessions. So I'm sure that those who are listening in to those sessions, you will learn well what's going on from the NTT's mind or NTT researchers mind to tackle each problem. But at the same time you will get to hear that top level researchers and professors in each field. So I believe this is going to be a kind of unique, certainly session that to understand what's it's like in a research field of quantum computing, encryptions, and then medical informatics of the world. >> Right. >> So that's, I am sure it's going to be a pretty great lineups. >> Oh, absolutely, a lot of information exchange. And I'm not going to ask you to pick your favorite child 'cause that would be unfair, but what I am going to do is I noticed too that you also write for the Forbes Technology Council members. So you're publishing on Forbes, and one of the articles that you publish relatively recently was about biological digital twins. And this is a topic that I'm really interested in. We used to do a lot of stuff with GE and there was always a lot of conversation about digital twins, for turbines, and motors, and kind of all this big, heavy industrial equipment so that you could get ahead of the curve in terms of anticipating maintenance and basically kind of run simulations of its lifetime. Need concept, now, and that's applied to people in biology, whether that's your heart or maybe it's a bigger system, your cardiovascular system, or the person as a whole. I mean, that just opens up so much interesting opportunities in terms of modeling people and being able to run simulations. If they do things different, I would presume, eat different, walk a little bit more, exercise a little bit more. And you wrote about it, I wonder if you could share kind of your excitement about the potential for digital twins in the medical space. >> Sure, so I think that the benefit is very clear for a lot of people, I would hope that the ones, basically, the computer system can simulate or emulate your own body, not just a generic human body, it's the body for Kazu Gomi at the age of whatever. (Jeff laughing) And so if you get that precise simulation of your body you can do a lot of things. Oh, you, meaning I think a medical professional can do a lot of thing. You can predict what's going to happen to my body in the next year, six months, whatever. Or if I'm feeling sick or whatever the reasons and then the doctor wants to prescribe a few different medicines, but you can really test it out a different kind of medicines, not to you, but to the twin, medical twin then obviously is safer to do some kind of specific medicines or whatever. So anyway, those are the kind of visions that we have. And I have to admit that there's a lot of things, technically we have to overcome, and it will take a lot of years to get there. But I think it's a pretty good goal to define, so we said we did it and I talked with a couple of different experts and I am definitely more convinced that this is a very nice goal to set. However, well, just talking about the goal, just talking about those kinds of futuristic thing, you may just end up with a science fiction. So we need to be more specific, so we have the very researchers are breaking down into different pieces, how to get there, again, it's going to be a pretty long journey, but we're starting from that, they're try to get the digital twin for the cardiovascular system, so basically the create your own heart. Again, the important part is that this model of my heart is very similar to your heart, Jeff, but it's not identical it is somehow different. >> Right, right. >> So we are looking on it and there are certainly some, we're not the only one thinking something like this, there are definitely like-minded researchers in the world. So we are gathered together with those folks and then come up with the exchanging the ideas and coming up with that, the plans, and ideas, that's where we are. But like you said, this is really a exciting goal and exciting project. >> Right, and I like the fact that you consistently in all the background material that I picked up preparing for this today, this focus on tech for good and tech for helping the human species do better down the road. In another topic, in other blog post, you talked about and specifically what are 15 amazing technologies contributing to the greater good and you highlighted cryptography. So there's a lot of interesting conversations around encryption and depending kind of commercialization of quantum computing and how that can break all the existing kind of encryption. And there's going to be this whole renaissance in cryptography, why did you pick that amongst the entire pallet of technologies you can pick from, what's special about cryptography for helping people in the future? >> Okay, so encryption, I think most of the people, just when you hear the study of the encryption, you may think what the goal of these researchers or researches, you may think that you want to make your encryption more robust and more difficult to break. That you can probably imagine that's the type of research that we are doing. >> Jeff: Right. >> And yes, yes, we are doing that, but that's not the only direction that we are working on. Our researchers are working on different kinds of encryptions and basically encryptions controls that you can just reveal, say part of the data being encrypted, or depending upon that kind of attribute of whoever has the key, the information being revealed are slightly different. Those kinds of encryption, well, it's kind of hard to explain verbally, but functional encryption they call is becoming a reality. And I believe those inherit data itself has that protection mechanism, and also controlling who has access to the information is one of the keys to address the current status. Current status, what I mean by that is, that they're more connected world we are going to have, and more information are created through IOT and all that kind of stuff, more sensors out there, I think. So it is great on the one side that we can do a lot of things, but at the same time there's a tons of concerns from the perspective of privacy, and securities, and stuff, and then how to make those things happen together while addressing the concern and the leverage or the benefit you can create super complex accessing systems. But those things, I hate to say that there are some inherently bringing in some vulnerabilities and break at some point, which we don't want to see. >> Right. >> So I think having those securities and privacy mechanism in that the file itself is I think that one of the key to address those issues, again, get the benefit of that they're connected in this, and then while maintaining the privacy and security for the future. >> Right. >> So and then that's, in the end will be the better for everyone and a better society. So I couldn't pick other (Gomi and Jeff laughing) technology but I felt like this is easier for me to explain to a lot of people. So that's mainly the reasons that I went back launching. >> Well, you keep publishing, so I'm sure you'll work your way through most of the technologies over a period of time, but it's really good to hear there's a lot of talk about security not enough about privacy. There's usually the regs and the compliance laws lag, what's kind of happening in the marketplace. So it's good to hear that's really a piece of the conversation because without the privacy the other stuff is not as attractive. And we're seeing all types of issues that are coming up and the regs are catching up. So privacy is a super important piece. But the other thing that is so neat is to be exposed not being an academic, not being in this basic research every day, but have the opportunity to really hear at this level of detail, the amount of work that's being done by big brain smart people to move these basic technologies along, we deal often in kind of higher level applications versus the stuff that's really going on under the cover. So really a great opportunity to learn more and hear from, and probably understand some, understand not all about some of these great, kind of baseline technologies, really good stuff. >> Yup. >> Yeah, so thank-you for inviting us for the first one. And we'll be excited to sit in on some sessions and I'm going to learn. What's that one phrase that I got to learn? The N-I-K-Z-T. NIZKs. (laughs) >> NIZKs. (laughs) >> Yeah, NIZKs, the brief history of quasi-adaptive NI. >> Oh, all right, yeah, yeah. (Gomi and Jeff laughing) >> All right, Kazuhiro, I give you the final word- >> You will find out, yeah. >> You've been working on this thing for over a year, I'm sure you're excited to finally kind of let it out to the world, I wonder if you have any final thoughts you want to share before we send people back off to their sessions. >> Well, let's see, I'm sure if you're watching this video, you are almost there for that actual summit. It's about to start and so hope you enjoy the summit and in a physical, well, I mentioned about the benefit of this virtual, we can reach out to many people, but obviously there's also a flip side of the coin as well. With a physical, we can get more spontaneous conversations and more in-depth discussion, certainly we can do it, perhaps not today. It's more difficult to do it, but yeah, I encourage you to, I think I encouraged my researchers NTT side as well to basic communicate with all of you potentially and hopefully then to have more in-depth, meaningful conversations just starting from here. So just feel comfortable, perhaps just feel comfortable to reach out to me and then all the other NTT folks. And then now, also that the researchers from other organizations, I'm sure they're looking for this type of interactions moving forward as well, yeah. >> Terrific, well, thank-you for that open invitation and you heard it everybody, reach out, and touch base, and communicate, and engage. And it's not quite the same as being physical in the halls, but that you can talk to a whole lot more people. So Kazu, again, thanks for inviting us. Congratulations on the event and really glad to be here covering it. >> Yeah, thank-you very much, Jeff, appreciate it. >> All right, thank-you. He's Kazu, I'm Jeff, we are at the Upgrade 2020, the NTT Research Summit. Thanks for watching, we'll see you next time. (upbeat music)

>>Fly from San Francisco. It's the cube covering RSA conference, 2020 San Francisco brought to you by Silicon angle media. >>Welcome back everybody. Jeffrey here with the cube. We're at RSA 2020, downtown San Francisco and Moscone center, 40,000 professionals in the security industries, the biggest security event in the world. I'm pretty sure, certainly the biggest one in the U S we're excited to have somebody who's been running around taking care of these problems and talking to customers for a very long time. It's got a great longterm perspective. We're happy to have him. Jonathan, new wind, the VP global field say-so team for fortunate. Jonathan, great to see you. So you said you've been coming to this show for a long, long time. Love to get kind of your impressions that the human element is the theme. Yeah, well, sheer, you know, I, I think, uh, it's changing. It's uh, the attendance is broken out by very senior people who've been here for, you know, multiple events and then a whole new slew of people are coming into the industry, right. >>And there's a lot of excitement. It's, um, there's a little bit less of a buzz. It just seems it's a little bit less people here this year because of the virus scare. Um, but overall I think that the themes are pretty consistent, which is kind of tragic that the themes are consistent year after year because this suggests that not a lot has changed despite the $130 billion and it works with purity span. You know, absolutely complexity. Uh, everyone is telling me about how to solve complexity, how to do more with less, uh, how to do more with less and fewer people and how to get their arms around this vast volume of data that's being generated. And there's a lot of talk about automation and AI, uh, but much more practical, less buzzwords and more practical solutions. And yet still tons of new vendors, right? Tons of new opportunities. >>You know, I don't know what the final count is on the vendor side, but it's a really large number and you go off into the corners to the EDBD little, little, a little mini boost is still a time of innovation. So I think that people trying to move the ball. So I think when the first show first started, there were less than a less than 500 vendors, I think in the industry back in 2007 I think today we're North of of 5,000 and it's probably 8,000 or about 5,000 vendors in the immediate vicinity here. But just go around the corner and there are dozens of others having their own events and the neighboring hotels and restaurants. It's astounding the number of different point products are still coming into the industry and, and, and that really suggests that we haven't gotten our arms around integrating all of this technology. >>And it's just another level of complexity. So what do you tell your friends on the buy side, right? Who know you and say, say Jonathan, I'm going, I'm going to RSA. How in the heck am I supposed to navigate not only the show specifically, but kind of this vendor landscape and then make sense of it all? I'm telling him to look for vendors that are partners that have a longterm perspective and that do the integration for you. You know, one of the things coming from an operational background, as I talked to other CSOs, like our job is to operate technology. It really isn't about integrating technology. It really isn't about OAA and product. I want to focus my budget and my resources on operating technologies and manage risk. So I look for partners and mentors like, like Fordanet that has a fabric with 258 plus different products and vendors that are already integrated out of the box. >>I'm looking for someone that solves complexity rather than a specific problem or specific threat vector. And I'm really looking for some of that helps me understand and manage risk because that's the object of the exercise in cybersecurity today. It's not about compliance, it's about compliance, it's about security, it's about resilience, but a reasonable level of care in managing risk. Right. And yeah, it's, it's a great topic cause I was thinking that kind of in terms of insurance. Yeah. In terms of, you know, how much do you spend and you can't insure everything to 100% right. So it's going to be some number less than that. Everybody else needs a piece of the pie. But how do you make those kinds of trade offs, investment versus risk? Because you can't absolutely protect everything. It makes no sense. So I think that value of it comes back to the CSO and his or her team. >>It's a very human decision. Uh, there is no prescriptive definition of what reasonable care is. You know, outside of one statement by Kamala Harrison, she was the state's attorney in California here, which is the CIS 20 is the minimum level of reasonable care. And so now we have to understand how do we define what is reasonable, what is the risk appetite or tolerance for a company? And once you identify those things, what are the controls and mitigation measures that you're gonna have in place to mitigate those risks? And then what's left is residual risk. And that's a hard decision. How much will you absorb? How much will you transfer, uh, and how much will you just tolerate? Um, but it's really no longer just about compliance, uh, and it's no longer just about having a security or continuity or resilience about all of those things. At a reasonable level. >>Right. It's interesting as pulling up Winnie Naylor from, from Cisco gave one of the early ketos and she talked about, you know, really this security profession, embracing those pesky people that keep clicking on links because really they're the people that can, that have the data around the specific, um, applications and specific assets that the company has to kinda have that informed decision as to what is it worth to protect and do we need to protect it? Do we need to protect them more? Can we let this thing go a little bit? Yeah. I think the human element is the hardest part, you know, in mind at this conference and its theme, that human element. The hardest part about this job is that it's not just mechanical issues on routing issues and networking issues, but it's about dealing with all types of humans, innocent humans that do strange and bad things unknowingly. >>And then malicious people who do very bad things that by design. And so the research suggests that no matter what we do in security awareness training, some 4% of our employee base will continually fail security awareness tests. Well, we fished actively. And so one of the things that we need to do is use automation and intelligence so that you could comb through all of that data and make a better informed decision about what risks you're going to mitigate, right? And for this 4% that are habitually abusing the system and can't be retrained while you can isolate them, right, and make sure that they're, they're separated and they're not able to, uh, to do things that may harm the organization. Right. The other human element is the people on the security teams, right. And it's a tough resource. There aren't enough of them. And, and, and historically, they'd been the ones that, that integration point between all these different systems and it's a highly stressful job. >>You know, there was a Forbes article that said 17% of all CSOs are functional alcoholics. I mean, I mean, and they met as a 17 for 17%. One of every six CSOs medicates himself or herself with alcohol. And medicate is a very specific term of art. It doesn't mean recreational drinking means you are a functional alcoholic and that tells you about the level of stress and complexity. You know, in this job, our research suggests that the average CSO lifespan is somewhere on the low end of about 12 months on the high end, somewhere about 24. You know, in their role or in their profession, their role and their current job, their current gig, they're not lasting more than than two years. Uh, the sheer complexity and stress of the job and you know, and, and those, of course, 24 months, three of those months are just orientation cause that gives you an idea. >>It's a level of stress and complexity that the average CSO is going to face here. Right. So really begs for a lot more automation, a lot more automation on the defense side. It does, it, it makes for a lot more automation. And how do you help those teams cope with a massive levels of complexity and data that's coming out of these digitized and digitally transformed enterprises, right? And when you think about each person's going to generate three to five terabytes of data per person per day, uh, and that computing is going to change in the next three to five years. Right now 85% of computing and data generated comes from traditional it functions as you move into 5g and edge based computing, the vast majority of data generating computing will be done on the edge. So the level of complexity, the number of technologies and devices that we're going to have to monitor is only going to expand, right? >>Right, right. And the speed of those transactions and the speed of the potential harm. So marry that against the research data says that 99% of the attacks could have been mitigated through simple intermediate controls and that the patches, the signatures were readily available. And so the thing to contemplate as we go into this heightened level of complexity and expansion of our computing environment is we're missing the basics today, right? Right. If 99% of the successful attacks are based upon exploits that are known that the signatures are available in the patches available for then a year, what are we going to do when everything else becomes even more complex, more sophisticated. Yeah. That's funny. That was part of, of of raw heats keynote, uh, to kick off the whole thing is he said, you know, we as security professionals like to focus on the complex, we like to focus on the, the ornate and the, and the super sophisticated attacks on the reality is the vast majority and we're just coming right in the normal side door that they've been coming in all along. >>And one thing I decided during my time at the Verizon data breach investigations report was a 77% of all the breaches were not identified by the security team. They were identified by law enforcement. And so 77, 77% of the case. So let's, so let's say you've got a CIS admin that that goes out and accesses financial information before the earnings call and does insider trading. And it's the sec that calls the FBI. And then it's the FBI that calls you and said, by the way, your CIS admin is going to be charged with insider trading. And that's how they know that there's been a compromise out. And in many cases, what does that tell you? Despite $130 billion of network security spend this year alone, that's seven out of 10 data breaches will be identified by law enforcement and not the security team. Yeah. So that tells you that not the security law enforcement team, either it's the FBI or the sec hires the cl service and it just says that security is so complex that until we find ways like the FORNAS security fabric to automate and to manage complexity in an integrated way, you know, that's the, that's the leading edge indicator that I look for is that at what point do security teams identify more data breaches then law enforcement and the victims and they're way behind at this point? >>I think so, unfortunately. Yes. That's crazy. So, um, but there's a lot more AI now that you guys can use to write on the good guys side. But how does that really square the circle when you're saying so many of it just comes through the simple approaches because of lack of visibility. Uh, SOC teams are overwhelmed by the volume of data. And so the way to address the volume and variety and velocity of data is to use artificial intelligence to use a machine to make human decisions and behavior at machine speed. And so when we launched our 40 AI product offering and the virtual security analysts, you know, the research that we did suggest that is he pivoted a five SOC analysts. And so that's one way of helping SOC teams that are overwhelmed by the volume of data that are understaffed, to use artificial intelligence to distill out from all of that, that data, that useful patterns, and to marry that with our Florida guard intelligence, say, okay, this is the techniques, tactics and procedures most likely associated with this threat vector right now, escalate that to a human to make a decision on whether you want to mitigate that. >>And once you decide to mitigate that, use the automated and integrated capabilities of the fabric to make an efficient and effective, uh, mitigation, uh, of that incident. Right? Yeah. Yeah. That's interesting. You bring up the sec case. We had a conversation earlier today where we were talking about deep fakes. Yeah. If somebody had the use case that, you know, what, if you just had a pretty straight forward, deep fake of some executive from some companies saying something to move the market and you drop that into the, uh, into the social stream three minutes before the close on a Friday, you get a play off the off the margin leverage. Nobody gets to really investigate the thing until the four minutes are over. Markets are closed, right? You get a significant financials damage in a situation like that, not even really directly impacting the company system. Right. >>So you're, you're hitting on the fact that we are more interconnected than ever and that the traditional compensating controls that we would have used to mitigate that type of risk is not, not as effective. And so, you know, that's going to be a challenge moving forward. Everything is going to be more interconnected, accelerated and decisions will be driven by data. So it's all of those things will drive complexity. So maybe next year when we talk again, we'll see it and see that. But I'm a little, one of the reasons I'm, you know, I have a credit freeze personally is that I'm aware of things like, like deep fakes, uh, impersonations moving my identities. So having a credit freeze allows, allows me to know that no one can leverage my credit even if they have my data. Right. Interesting. So thanks. Question. We sit down here a year from now, uh, without the benefit of 20, 20 hindsight. >>Yeah. You know, what do you think the themes are going to be? What, what do you see as kind of this kind of short term move in the market based on some of these factors that you've identified? I think, uh, more automation, more uh, artificial intelligence ways of automating the traditional process was insecurity. The secondarily, I think there's going to be the rising awareness of edge based computing and smart systems, autonomous level five vehicles that are networked and rather than a sensory based awareness, smart homes, smart industrial applications, uh, that computing will be done on the edge increasingly and those industrial applications, that 85% of the data computer will be done there. And that increasingly the cloud will become a repository for, for, uh, for storage and correlation. But the actual computing and actuation will be done on the edge. And so as 5g takes hold, you're going to see tremendous transformations in our society and our economy and how we conduct commerce, how we communicate. >>Uh, and that leads some more complexity. That's why, that's why I'm so focused on helping organizations getting security right now before that next onslaught of complexity hits us. It's coming. It is the five G IOT thing is, is just around the corner. The look at the telcos, there is a very specific reason why they're investing literally hundreds of billions of dollars into five G and the tremendous societal and economic changes that that will bring in infrastructure, communications and security will have to stay pace with that. One of the things that we're going to see moving forward is that the digital infrastructure is only successful only as successful as a security is. And I think we'll, we should see a breakdown in the traditional operational silos in network operations and security operations as Michelle Dennett. He said earlier on the air, if you cannot protect, you should not connect. But unfortunately people are still connecting before they're ready to. Absolutely. Well, hopefully there'll be a little bit more circumspect going forward. We'll try Jonathan, thanks for, uh, for taking a few minutes and sharing your perspective. Really appreciate it. Always a fun time. Alright, Jonathan, I'm Jeff. You're watching the cube where at RSA 2020 from downtown San Francisco. Thanks for watching. We'll see you next time.