>>Welcome to this cube conversation. I'm Dave Nicholson and we're having this conversation in advance of cube con cloud native con north America, 2021. Uh, we are going to be talking specifically about a subject near and dear to my heart, and that is security. We have a very special guest from red hat, the security lead from the office of the CTO. New kinds. Welcome. Welcome to the cube Luke. >>Oh, it's great to be here. Thank you, David. Really looking forward to this conversation. >>So you have a session, uh, at a CubeCon slash cloud native con this year. And, uh, frankly, I look at the title and based on everything that's going on in the world today, I'm going to accuse you of clickbait because the title of your session is a secure supply chain vision. Sure. What other than supply chain has is in the news today, all of these things going on, but you're talking about the software supply chain. Aren't you tell, tell us about, tell us about this vision, where it came from Phyllis in. >>Yes, very much. So I do agree. It is a bit of a buzzword at the moment, and there is a lot of attention. It is the hot topic, secure supply chains, thanks to things such as the executive order. And we're starting to see an increase in attacks as well. So there's a recent statistic came out that was 620%. I believe increase since last year of supply chain attacks involving the open source ecosystem. So things are certainly ramping up. And so there is a bit of clickbait. You got me there. And um, so supply chains, um, so it's predominantly let's consider what is a supply chain. Okay. And we'll, we'll do this within the context of cloud native technology. Okay. Cause there's many supply chains, you know, many, many different software supply chains. But if we look at a cloud native one predominantly it's a mix of people and machines. >>Okay. So you'll have your developers, uh, they will then write code. They will change code and they'll typically use our, a code revision control system, like get, okay, so they'll make their changes there. Then push those changes up to some sort of repository, typically a get Harbor or get level, something like that. Then another human will then engage and they will review the code. So somebody that's perhaps a maintain will look at the code and they'll improve that a code. And then at the same time, the machine start to get involved. So you have your build servers that run tests and integration tests and they check the code is linted correctly. Okay. And then you have this sort of chain of events that start to happen. These machines, these various actors that start to play their parts in the chain. Okay. So your build system might generate a container image is a very common thing within a cloud native supply chain. >>Okay. And then that image is typically deployed to production or it's hosted on a registry, a container registry, and then somebody else might utilize that container image because it has software that you've packaged within that container. Okay. And then this sort of prolific expansion of use of coasts where people start to rely on other software projects for their own dependencies within their code. Okay. And you've got this kind of a big spaghetti of actors that are dependent on each other and feed him from each other. Okay. And then eventually that is deployed into production. Okay. So these machines are a lot of them non open source code. Okay. Even if there is a commercial vendor that manages that as a service, it's all based on predominantly open source code. Okay. And the security aspects with the supply chain is there's many junctures where you can exploit that supply chain. >>So you can exploit the human, or you could be a net ferrous human in the first place you could steal somebody's identity. Okay. And then there's the build systems themselves where they generate these artifacts and they run jobs. Okay. And then there are the production system, which pulls these down. Okay. And then there's the element of which we touched upon around libraries and dependencies. So if you look at a lot of projects, they will have approximately around a hundred, perhaps 500 dependencies that they all pull in from. Okay. So then you have the supply chains within each one of those, they've got their own set of humans and machines. And so it's a very large spaghetti beast of, of, of sort of dependence and actors and various identities that make up. >>Yeah. You're, you're describing a nightmarish, uh, scenario here. So, uh, so, so I definitely appreciate the setup there. It's a chain of custody nightmare. Yeah. >>Yes. Yeah. But it's also a wonderful thing because it's allowed us to develop in the paradigms that we have now very fast, you know, you can, you can, you can prototype and design and build and ship very fast, thanks to these tools. So they're wonderful. It's not to say that they're, you know, that there is a gift there, but security has arguably been left as a bit of an afterthought essentially. Okay. So security is always trying to it's at the back of the race. It's always trying to catch up with you. See what I mean? So >>Well, so is there a specific reason why this is particularly timely? Um, in, you know, when we, when we talk about deployment of cloud native applications, uh, something like 75% of what we think of is it is still on premesis, but definitely moving in the direction of what we loosely call cloud. Um, is why is this particularly timely? >>I think really because of the rampant adoption that we see. So, I mean, as you rightly say, a lot of, uh, it companies are still running on a, sort of a, more of a legacy model okay. Where deployments are more monolithic and statics. I mean, we've both been around for a while when we started, you would, you know, somebody would rack a server, they plug a network cable and you'd spend a week deploying the app, getting it to run, and then you'd walk away and leave it to a degree. Whereas now obviously that's really been turned on its head. So there is a, an element of not everybody has adopted this new paradigm that we have in development, but it is increasing, there is rapid adoption here. And, and many that aren't many that rather haven't made that change yet to, to migrate to a sort of a cloud type infrastructure. >>They certainly intend to, well, they certainly wished to, I mean, there's challenges there in itself, but it, I would say it's a safe bet to say that the prolific use of cloud technologies is certainly increasing as we see in all the time. So that also means the attack vectors are increasing as we're starting to see different verticals come into this landscape that we have. So it's not just your kind of a sort of web developer that are running some sort of web two.site. We have telcos that are starting to utilize cloud technology with virtual network functions. Uh, we have, um, health banking, FinTech, all of these sort of large verticals are starting to come into cloud and to utilize the cloud infrastructure model that that can save them money, you know, and it can make them, can make their develop more agile and, you know, there's many benefits. So I guess that's the main thing is really, there's a convergence of industries coming into this space, which is starting to increase the security risks as well. Because I mean, the security risks to a telco are a very different group to somebody that's developing a web platform, for example. >>Yeah. Yeah. Now you, you, uh, you mentioned, um, the sort of obvious perspective from the open source perspective, which is that a lot of this code is open source code. Um, and then I also, I assume that it makes a lot of sense for the open source community to attack this problem, because you're talking about so many things in that chain of custody that you described where one individual private enterprise is not likely to be able to come up with something that handles all of it. So, so what's your, what's your vision for how we address this issue? I know I've seen in, um, uh, some of the content that you've produced an allusion to this idea that it's very similar to the concept of a secure HTTP. And, uh, and so, you know, imagine a world where HTTP is not secure at any time. It's something we can't imagine yet. We're living in this parallel world where, where code, which is one of the four CS and cloud security, uh, isn't secure. So what do we do about that? And, and, and as you share that with us, I want to dive in as much as we can on six store explain exactly what that is and, uh, how you came up with this. >>Yes, yes. So, so the HTTP story's incredibly apt for where we are. So around the open source ecosystem. Okay. We are at the HTTP stage. Okay. So a majority of code is pulled in on trusted. I'm not talking about so much here, somebody like a red hat or, or a large sort of distributor that has their own sign-in infrastructure, but more sort of in the, kind of the wide open source ecosystem. Okay. The, um, amount of code that's pulled in on tested is it's the majority. Okay. So, so it is like going to a website, which is HTTP. Okay. And we sort of use this as a vision related to six store and other projects that are operating in this space where what happened effectively was it was very common for sites to run on HTTP. So even the likes of Amazon and some of the e-commerce giants, they used to run on HTTP. >>Okay. And obviously they were some of the first to, to, uh, deploy TLS and to utilize TLS, but many sites got left behind. Okay. Because it was cumbersome to get the TLS certificate. I remember doing this myself, you would have to sort of, you'd have to generate some keys, the certificate signing request, you'd have to work out how to run open SSL. Okay. You would then go to an, uh, a commercial entity and you'd probably have to scan your passport and send it to them. And there'll be this kind of back and forth. Then you'll have to learn how to configure it on your machine. And it was cumbersome. Okay. So a majority just didn't bother. They just, you know, they continue to run their, their websites on protected. What effectively happened was let's encrypt came along. Okay. And they disrupted that whole paradigm okay. >>Where they made it free and easy to generate, procure, and set up TLS certificates. So what happened then was there was a, a very large change that the kind of the zeitgeists changed around TLS and the expectations of TLS. So it became common that most sites would run HTTPS. So that allowed the browsers to sort of ring fence effectively and start to have controls where if you're not running HTTPS, as it stands today, as it is today is kind of socially unacceptable to run a site on HTTP is a bit kind of, if you go to HTTP site, it feels a bit, yeah. You know, it's kind of, am I going to catch a virus here? It's kind of, it's not accepted anymore, you know, and, and it needed that disruptor to make that happen. So we want to kind of replicate that sort of change and movement and perception around software signing where a lot of software and code is, is not signed. And the reason it's not signed is because of the tools. It's the same story. Again, they're incredibly cumbersome to use. And the adoption is very poor as well. >>So SIG stores specifically, where did this, where did this come from? And, uh, and, uh, what's your vision for the future with six? >>Sure. So six door, six doors, a lockdown project. Okay. It started last year, July, 2020 approximately. And, uh, a few people have been looking at secure supply chain. Okay. Around that time, we really started to look at it. So there was various people looking at this. So it's been speaking to people, um, various people at Purdue university in Google and, and other, other sort of people trying to address this space. And I'd had this idea kicking around for quite a while about a transparency log. Okay. Now transparency logs are actually, we're going back to HTTPS again. They're heavily utilized there. Okay. So when somebody signs a HTTPS certificate as a root CA, that's captured in this thing called a transparency log. Okay. And a transparency log is effectively what we call an immutable tamper proof ledger. Okay. So it's, it's kind of like a blockchain, but it's different. >>Okay. And I had this idea of what, if we could leverage this technology okay. For secure supply chain so that we could capture the provenance of code and artifacts and containers, all of these actions, these actors that I described at the beginning in the supply chain, could we utilize that to provide a tamper resistant publicly or DePaul record of the supply chain? Okay. So I worked on a prototype wherever, uh, you know, some, uh, a week or two and got something basic happening. And it was a kind of a typical open source story there. So I wouldn't feel right to take all of the glory here. It was a bit like, kind of, you look at Linux when he created a Linux itself, Linus, Torvalds, he had an idea and he shared it out and then others started to jump in and collaborate. So it's a similar thing. >>I, um, shared it with an engineer from Google's open source security team called Dan Lawrence. Somebody that I know of been prolific in this space as well. And he said, I'd love to contribute to this, you know, so can I work this? And I was like, yeah, sure though, you know, the, the more, the better. And then there was also Santiago professor from Purdue university took an interest. So a small group of people started to work on this technology. So we built this project that's called Rico, and that was effectively the transparency log. So we started to approach projects to see if they would like to, to utilize this technology. Okay. And then we realized there was another problem. Okay. Which was, we now have a storage for signed artifacts. Okay. A signed record, a Providence record, but nobody's signing anything. So how are we going to get people to sign things so that we can then leverage this transparency log to fulfill its purpose of providing a public record? >>So then we had to look at the signing tools. Okay. So that's where we came up with this really sort of clever technology where we've managed to create something called ephemeral keys. Okay. So we're talking about a cryptographic key pair here. Okay. And what we could do we found was that we could utilize other technologies so that somebody wouldn't have to manage the private key and they could generate keys almost point and click. So it was an incredibly simple user experience. So then we realized, okay, now we've got an approach for getting people to sign things. And we've also got this immutable, publicly audited for record of people signing code and containers and artifacts. And that was the birth of six store. Then. So six store was created as this umbrella project of all of these different tools that were catering towards adoption of signing. And then being able to provide guarantees and protections by having this transparency log, this sort of blockchain type technology. So that was where we really sort of hit the killer application there. And things started to really lift off. And the adoption started to really gather steam then. >>So where are we now? And where does this go into the future? One of the, one of the wonderful things about the open source community is there's a sense of freedom in the creativity of coming up with a vision and then collaborating with others. Eventually you run headlong into expectations. So look, is this going to be available for purchase in Q1? What's the, >>Yeah, I, I will, uh, I will fill you in there. Okay. So, so with six door there's, um, there's several different models that are at play. Okay. I'll give you the, the two predominant ones. So one, we plan, we plan to run a public service. Okay. So this will be under the Linux foundation and it'll be very similar to let's encrypt. So you as a developer, if you want to sign your container, okay. And you want to use six door tooling that will be available to you. There'll be non-profit three to use. There's no specialties for anybody. It's, it's there for everybody to use. Okay. And that's to get everybody doing the right thing in signing things. Okay. The, the other model for six stories, this can be run behind a firewall as well. So an enterprise can stand up their own six store infrastructure. >>Okay. So the transparency log or code signing certificates, system, client tools, and then they can sign their own artifacts and secure, better materials, all of these sorts of things and have their own tamper-proof record of everything that's happened. So that if anything, untoward happens such as a key compromise or somebody's identity stolen, then you've got a credible source of truth because you've got that immutable record then. So we're seeing, um, adoption around both models. We've seen a lot of open source projects starting to utilize six store. So predominantly key, um, Kubernetes is a key one to mention here they are now using six store to sign and verify their release images. Okay. And, uh, there's many other open-source projects that are looking to leverage this as well. Okay. And then at the same time, various people are starting to consider six door as being a, sort of an enterprise signing solution. So within red hat, our expectations are that we're going to leverage this in open shift. So open shift customers who wish to sign their images. Okay. Uh, they want to sign their conflicts that they're using to deploy within Kubernetes and OpenShift. Rather they can start to leverage this technology as open shift customers. So we're looking to help the open source ecosystem here and also dog food, this, and make it available and useful to our own customers at red hat. >>Fantastic. You know, um, I noticed the red hat in the background and, uh, and, uh, you know, I just a little little historical note, um, red hat has been there from the beginning of cloud before, before cloud was cloud before there was anything credible from an enterprise perspective in cloud. Uh, I, I remember in the early two thousands, uh, doing work with tree AWS and, uh, there was a team of red hat folks who would work through the night to do kernel level changes for the, you know, for the Linux that was being used at the time. Uh, and so a lot of, a lot of what you and your collaborators do often falls into the category of, uh, toiling in obscurity, uh, to a certain degree. Uh, we hope to shine light on the amazing work that you're doing. And, um, and I, for one appreciate it, uh, I've uh, I've, I've suffered things like identity theft and, you know, we've all had brushes with experiences where compromise insecurity is not a good thing. So, um, this has been a very interesting conversation. And again, X for the work that you do, uh, do you have any other, do you have any other final thoughts or, or, uh, you know, points that we didn't cover on this subject that come to mind, >>There is something that you touched upon that I'd like to illustrate. Okay. You mentioned that, you know, identity theft and these things, well, the supply chain, this is critical infrastructure. Okay. So I like to think of this as you know, there's, sir, they're serving, you know, they're solving technical challenges and, you know, and the kind of that aspect of software development, but with the supply chain, we rely on these systems. When we wake up each morning, we rely on them to stay in touch with our loved ones. You know, we are our emergency services, our military, our police force, they rely on these supply chains, you know, so I sort of see this as there's a, there's a bigger vision here really in protecting the supply chain is, is for the good of our society, because, you know, a supply chain attack can go very much to the heart of our society. You know, it can, it can be an attack against our democracies. So I, you know, I see this as being something that's, there's a humanistic aspect to this as well. So that really gets me fired up to work on this technology., >>it's really important that we always keep that perspective. This isn't just about folks who will be attending CubeCon and, uh, uh, uh, cloud con uh, this is really something that's relevant to all of us. So, so with that, uh, fantastic conversation, Luke, it's been a pleasure to meet you. Pleasure to talk to you, David. I look forward to, uh, hanging out in person at some point, whatever that gets me. Uh, so with that, uh, we will sign off from this cube conversation in anticipation of cloud con cube con 2021, north America. I'm Dave Nicholson. Thanks for joining us.

>>Oh, welcome back to the cubes coverage of coop con cloud native con 2021. I'm John is the Cuba, David Nicholson, our cloud host analyst, and it's exciting to be back in person in event. So we're back. It's been two years with the cube con and Linux foundation. So scrape, it was a hybrid event and we have a great guest here, Cuban London, Nick Dirk, and CT field CTO of harness and harness.io. The URL love the.io. Good to see you. >>Thank you guys for having me on. I genuinely appreciate >>It. Thanks for coming on. You were a part of our AWS startup showcase, which you guys were featured as a fast growing mature company, uh, as cloud scales, you guys have been doing extremely well. So congratulations. But now we're in reality now, right? So, okay. Cloud native has kind of like, okay, we don't have to sell it anymore. People buying into it. Um, and now operationalizing it with cloud operations, which means you're running stuff, applications and infrastructure is code and it costs money. Yeah. Martine Casada at Andreessen Horowitz. Oh, repatriated from the cloud. So there's a lot of, there's some cost conversations starting to happen. This is what you guys are in the middle of. >>Yeah, absolutely. What's interesting is when you think about it today, we want to shift left. When you want to empower all the engineers, we want to empower people. We're not giving them the data they need, right. They get a call from the CFO 30 days later, as opposed to actually being able to look at what change I did and how it actually affected. And this is what we're bringing in. Allowing people to have is now really empowering. So throughout the whole software delivery life cycle from CGI continuous integration, continuous delivery feature flagging, and even bringing cost modeling and in cloud cost management. And even then being able to shut down, shut down the services that you're not using, how much of that is waste. We talk about it. Every single cloud conference it's how much is waste. And so being able to actually turn those on, use those accordingly and then take advantage of even the cheapest instances when you should. That's really what >>It's so funny. People almost trip over dollars to pick up pennies in the cloud business because they're so focused on innovation that they think, okay, we've got to just innovate at all costs, but at some point you can make it productive for the developers in process in the pipeline to actually manage that. >>That's exactly it. I mean, if you think about it to me in order to breach state continuous delivery, we have to automate everything. Right. But that doesn't mean stop at just delivering, you know, to production. That means to customer, which means we've got to make them happy, but then ultimately all of those resources in dev and QA and staging and UAT, we've sticker those as well. And if we're not being mindful of it, the costs are astronomical, right. And we've seen it time and time again with every company you see, you've seen every article about how they've blown through all their budgets. So bring it to the people that can affect change. That's really the difference, making it visible, looking at it. In-depth not just at the cloud level and all the spend there, but also even at the, uh, thinking about it, the Kubernetes level down to the containers, the pods and understanding where are the resources even inside of the clusters and bringing that as an aggregate, not just for visibility and, and giving recommendations, but now more importantly, because part of a pipeline start taking action. That's where it's interesting. It's not just about being able to see it and understand it and hope, right? Hope is not a strategy acting upon it is what makes it valuable. And that's part of the automate everything. >>Yeah. We'll let that at the Dawn of the age of DevOps, uh, there was a huge incentive for a developer just to get their job done, to seize control of infrastructure, the idea of infrastructure as code, you know, and it's, it's, you know, w when it was being born, it's a fantastic, I've always wondered though, you know, be careful what you wish for. Do you really want all of that responsibility? So we've got responsibility from a compliance and security perspective and of course cost. So, so where do we, where do we go from here, I guess is the question. Yeah. So >>When we look at building this all together, I think when we think about software delivery, everybody wants to go fast. We start with velocity, right? Everybody says, that's where I want to go. And to your point with governance compliance, the next roadblock to hit is weight. In order to go fast, I have to do it appropriately. I've got governing bodies that tell me how this has to work. And that becomes a challenge. >>It slows it down too. It doesn't, I mean, basically people are getting pissed off, right? This is, this general sentiment is, is that developers are moving fast with their code. And then they have to stop. Compliance has to give the green light sometimes days, correct? Uh, it used to be weeks now. It's days, it's still unacceptable. So there's like this always been that tension to the security groups or say it, or finance was like slow down and they actually want to go faster. So that has to be policy-based something. Yep. This is the future. What is your take on that? >>Take on, this is pretty simple. When everybody talks about people, process and technology, it's kind of bogus, right? It's all about confidence. If you're confident that your developers can deploy appropriately and they're not going to do something wrong, you'll let them to play all the time. Well, that requires process. But if you have tooling that literally guarantees your governance, make sure that at no point in time, can any of your developers actually do something wrong. Now you have, >>That's the key. That's the key. That's the key because you're giving them a policy-based guardrails to execute in their programs >>And that's it. So now you can free up all those pieces. So all those bottlenecks, all those waiting all those time, and this is how all of our customers, they move from, you know, change advisory boards that approve deployments. >>Can you give us some, give us some, give us some, uh, customer anecdotal examples of this inaction and kind of the love letters you get, or, or the customer you take us through a use case of how it all. >>So this is one of my favorites. So NCR national cash register. If you slide a credit card at like a Chick-fil-A or a Safeway, right? Um, traditional technology. But what was interesting is they went from doing PCI audit, which would take seven days to go to a PCI audit right now with harness, because, >>And by the way, when you and the seventh, six day, the things that you did on day one change. >>Exactly, exactly. And so now, because of using harness and everything's audited, and all the changes are, are controlled to make sure that developers again, can only do what they're allowed. They only get to broadcast two per production. If they've met all their security requirements, all their compliance, permits, all their quality checks. Now, because of that, they literally gave a re read only view of harness to their auditor. And in three hours it was over. And it's because now we're that evidence file from code commit through to production. Yeah. It's there for point of sale compliant. >>So what is the benefits to them? What's the result saves them time, saves the money. What's the good, the free up more times. I'll see the chops it down. That's the key. >>Yeah. It's actually something we didn't build in like our ROI calculators, which was, we talked to their engineers and we gave them their nights and their weekends back, which I thought was amazing. But Thursday night, when we're doing that deploy, they don't have to be up. Harness is actually managing and understanding, using machine learning to understand what normal looks like. So they don't have to, they don't have to sit and look at the knock or sit in the war room and eat the free pizza. Yeah. Right. And then when those things break, same concept rates aren't as good. So >>I got to ask you, I got you here. You know, as the software development delivery lifecycle is radically being overhauled right now, which people generally agree that that's the case, the old models are, are different. How do you see your vision around AI and automation playing into this? Because you could say, okay, we're going to have different kinds of coding styles. This batch has got an AI block here. It's very Lego block. Like yep. Okay. Services and higher level services in the cloud. What's your reaction to how this impacts automation and >>Sure. So throughout our entire platform, we've designed our AI to take care of the worst parts of anyone's job as Guinea dev ops person. If they love babysitting deployments, they don't harness handles that for them, ask your engineers that they love sitting there waiting for their tests to run. Every time they build, they go get coffee, right. Because we're waiting for all of our tests to run. Y yeah. Right. The reality >>Is sometimes they have to wait days and >>That's it. But like, if I change the gas cap on, uh, on your car, would you expect me to check every light switch and every electronic piece? No. Well, why do we do that with code? And so our AI, our ML is designed to remove all the things that people hate. It's not to remove people's jobs. It's actually to make their jobs much better. >>How do you guys feed the data? What's the training algorithm for that? How does that work? Yeah, >>Actually, it's interesting. A lot of people think it's going to take a ton of time to figure this out. The good news is we start seeing this on the second deployment. On the second bill, we have to have a baseline of what good looks like, and that's where it starts. And it goes from there. And by the way, this isn't a lot of people say AI, and this AML, I teach a class on this because ML is not standard deviation. It's not some checks. So we use a massive amount of machine learning, but we have neural networks to think about things like engineers do. Like if we looked at a log and I saw the same log with two different user IDs, you and I would know, well, it's the same thing. It's just different users, but machine learning models. Don't so we've got to build neural networks to actually think like humans. So that, >>So that's the whole expectation maximization kind of concept of people talk about, >>Well, and that's it because at the end of the day, we're like I said, I'm not trying to take people's jobs. I want to meet. >>Yeah. You want to do the crap work out of the way. And I had to do other redundant, heavy lifting that they have to do every single time we use the cloud way. We've >>Built mechanical muscle in, in the early 19 hundreds. Right. And it made everyone's jobs easier, allowed them to do more with their time. That's exactly what we're doing here. >>I mean, we've seen the big old guys in the industry trying to evolve. You got the hot startups coming out. So you got, you know, adapt or die as classic thing. We've been saying for many years, David on the cube, you know that. So it's like, this is a moment of truth. We're going to see who comes out the other side. How do you, Nick, what would you be your, your kind of guess of when that other side is, when are we gonna know the winners and the losers truly in the sense of where we are now? >>So I think what I've found is that in this space specifically, there's a constant shift and this is something with software. And the problem is, is that we see them come in ebbs and flows, right. And very few times are there businesses that actually carry the model? And what you find is that when they focus on one specific problem, it solves it. Now, if I was working on VMs a few years ago, great, but now we're, we're here at coop con, right? And that's because it's eaten, uh, that side of the world. And so I think it's the companies that can actually grow the test of time and continue to expand to where the problems are. Right. And that's one of the things that I traditionally think about harness and we've done it. We cover our customers where they were, I think the old mainframes, if you had to, where they were, where they are at their traditional, their VM. >>I mean, if you think about it, Nick, it's one of those things where it's like, that's such a common sense way to look at it evolves with a problem. So I ride the right with tech ways. But if you think about the high order bit, here is just applications. We ended the day. Companies have applications that they want to write modern. The applications of their business is going to be codified so that you just work backwards from there. Then you say, okay, what is the infrastructure as code working for me? That's an ethos of dev ops. And that's where we're at. So that's why I think that the cloud need is kind of one already, but we still have the edge devices, more complexity. This is a huge next level conversation at one point is that we just put a hard and top on the complexity. When is that coming? Because the developers are clear. They want to go fast. They want to go shift left and have all that data, get the right analytics, the telemetry and the AI. But it's too complicated still. That is a big problem. >>It's too complicated. You ask for a full-stack developer to also know infrastructure, to also know edge computing. Like it's impossible, right? And this is where tooling helps, right? Because if you can actually parameterize that and make it to the engineers and have to care, they can do what they're best at. Hey, I'm great at turning code in artifact, let them do that and have tooling take care of the rest. This is where our goal is. Again, allow people >>We'll do what they love. And this is kind of the new roles that are changing. What SRE has done. Everyone talks about the SRE and some states just as he had dev ops guy, but it's not just that there's also, uh, different roles emerging. It's, it's an architectural game. At this point, we would say, >>I'd say a hundred percent. And this is where the decisions that you make on are architecturally. If you don't know how to then roll them out, this is what we've seen. Time and time again, you go to these large companies, I've got these great architectures on planning four years later, we haven't reached it because to that point process, >>The process killed them four >>Different new tools throughout the process. Well, yeah. >>So when do we hit peak Kubernetes peak >>Kubernetes? I think we have a bit to go in and I'm excited about the networking space and really what we're doing there and, and bringing that holistic portion of the network, like when Istio was originally released, I thought that was one of the most amazing things, uh, to truly come to it. And I think there's a vast space in networking. Um, and, and so I think in the next few years, we're going to see this, you know, turn into that a hundred percent utilized across the board. This will be that where everyone's workloads continue to exist. Um, somewhat like VMs we're in >>And, and, and no, no fear of developers as code in the very near future. You're talking about automating the mundane. Correct. Uh, there have been stories recently about the three-day workweek, you know, as a, as a fan of, um, utopian science fiction, myself, as opposed to dystopian. Absolutely. I think that, you know, technology does have the opportunity to lift all boats and, uh, and it's, it's not nothing to be afraid of. You know, the fact that I put my dishes in the dishwasher and they run by themselves for three hours. It's a good thing. It's a great thing. >>I don't need to deal with that. Yeah, I agree. No, I think that's, and that's what I said in the beginning. Right. That's really where we can start empowering people. So allow them to do what they're good at and do what they're best at. And if you look at why do people quit? We don't have to go so hard to find. Yeah. Why? Because they're secondary to babysit and implement and they're told everywhere they go, they're not going to have to >>That's the line. And that's all right. We got a break, but it's great insight to have you on the Q one final question for you. Um, I got to ask about the whole data as code something that I've been riffing on for a bunch of years now. And as infrastructures could we get that, but data is now the resource everyone needs, and everyone's trying to, okay, I have the control plane for this and that, but ultimately data cannot be siloed. This is a critical architectural element. How does that get resolved in the land of the competitive advantage and lock in and whatnot? What's your take on that? >>So data's an interesting one because it has, it has gravity and this is the problem. And as we move, as I think you guys know, as you move to the edge as remove, move it places there's insights to be taken at the edge there's insights to be taken as it moves through. And I think what you'll see honestly, going forward is you'll see compute done differently to your point. It needs to be aggregated. It needs to be able to be used together, but I think you'll see people computing it on its way through it. So now even in transport, you'll start seeing insights gained in real time before you can have the larger insights. And I see that happening more and more. Um, and I think ultimately we just want to empower that >>Nick, great to have you on CTO of field CTO of harness and harness.io is a URL. Check it out. Thanks for the insight. Thank you so much. Great comments. Appreciate it. Natural cube analysts right here, Nick, of course, we've got our, our analysts right here, David Nicholson. You're good on your own. I'm John for a, you know, we have the host. Thanks for watching. Stay with two more days of coverage. We'll be back after this short break.

>>from around the globe. It's the cube with coverage of Kublai >>Khan and Cloud Native Con, Europe 2021 >>virtual brought to you by red hat. The cloud Native >>computing foundation >>and ecosystem partners. >>Welcome back to the cubes coverage everyone of Coop Con 2021 Cloud Native Con 21 virtual europe. I'm john for your host of the cube. We've got two great guests here, James Labaki, senior Director of Product management, Red Hat and Richer Puree. IBM fellow and chief scientist at IBM Gentlemen, thanks for coming on the cube, appreciate it. >>Thank you for having us. >>So, um, got an IBM fellow and Chief scientist, Senior Director Product management. You guys have the keys to the kingdom on cloud Native. All right, it's gonna be fun. So let's just jump into it. So I want to ask you before we get into some of the questions around the projects, what you guys take of cube con this year, in terms of the vibe, I know it's virtual in europe north America, we looked like we might be in person but this year with the pandemic cloud native just seems to have a spring to its step, it's got more traction. I've seen the cloud native piece even more than kubernetes in a way. So scott cooper diseases continues to have traction, but it's always about kubernetes now. It's more cloud native. I what do you guys think about that? >>Yeah, I'm sure you have thoughts and I could add on >>Yes, I I think well I would really think of it as almost sequential in some ways. Community is too cold now there's a layer which comes above it which is where all our, you know, clients and enterprises realize the value, which is when the applications really move. It's about the applications and what they can deliver to their end customers. And the game now is really about moving those applications and making them cloud native. That's when the value of that software infrastructure will get realized and that's why you are seeing that vibe in the, in the clients and enterprises and at two corners. Well, >>yeah, I mean, I think it's exciting. I've been covering this community since the beginning as you guys know the cube. This is the enablement moment where the fruit is coming off the tree is starting to see that first wave of you mentioned that enablement, it's happening and you can see it in the project. So I want to get into the news here, the conveyor community. What is this about? Can you take a minute to explain what is the conveyor community? >>Yeah, yeah. I think uh, you know, uh, what, what we discovered is we were starting to work with a lot of end users and practitioners. Is that what we're finding is that they kind of get tired of hearing about digital transformation and from multiple vendors and and from sales folks and these sorts of things. And when you speak to the practitioners, they just want to know what are the practical implications of moving towards a more collaborative architecture. And so, um, you know, when you start talking to them at levels beyond, uh, just generic kind of, you know, I would say marketing speak and even the business cases, the developers and sys admins need to know what it is they need to do to their application architecture is the ways they're working for to successfully modernize their applications. And so the idea behind the conveyor community was really kind of two fold. One was to help with knowledge sharing. So we started running meetups where people can come and share their knowledge of what they've done around specific topics like strangling monoliths or carving offside containers or things that sidecar containers are things that they've done successfully uh to help uh kind of move things forward. So it's really about knowledge sharing. And then the second piece we discovered was that there's really no place where you can find open source tools to help you re host re platform and re factor your applications to kubernetes. And so that's really where we're trying to fill that void is provide open source options in that space and kind of inviting everybody else to collaborate with us on that. >>Can you give an example of something uh some use cases of people doing this, why the need the drivers? It makes sense. Right. As a growing, you've got, you have to move applications. People want to have um applications moved to communities. I get that. But what are some of the use cases that were forcing this? >>Yeah, absolutely, for sure. I don't know if you have any you want to touch on um specifically I could add on as well. >>Yeah, I think some of the key use cases, I would really say it will be. So let let me just, I think James just talked about re host, re hosting, re platform ng and re factoring, I'm gonna put some numbers on it and then they talk about the use case a little bit as well. I would really say 30 virtual machines movement. That's it. That's the first one to happen. Easy, easier one, relatively speaking. But that's the first one to happen. The re platform in one where you are now really sort of changing the stack as well but not changing the application in any major way yet. And the hardest one happened around re factoring, which is, you are, you know, this is when we start talking about cloud native, you take a monolithic application which you know legacy applications which have been running for a long time and try to re factor them so that you can build microservices out of them. The very first, I would say set of clients that we are seeing at the leading edge around this will be around banking and insurance. Legacy applications, banking is obviously finances a large industry and that's the first movement you start seeing which is where the complexity of the application in terms of some of the legacy code that you are seeing more onto the, into the cloud. That for a cloud native implementation as well as their as well as a diversity of scenarios from a re hosting and re platform ng point of view. And we'll talk about some of the tools that we are putting in the community uh to help the users and uh and the developer community in many of these enterprises uh move into a cloud native implementation lot of their applications. And also from the point of view of helping them in terms of practice, is what I describe as best practices. It is not just about tools, it's about the community coming together. How do I do this? How do I do that? Actually, there are best practices that we as a community have gathered. It's about that sharing as well, James. >>Yeah, I think you hit the nail on the head. Right. So you re hosting like for example, you might have uh an application that was delivered, you buy an SV that is not available containerized yet. You need to bring that over as a VM. So you can bring that into Q Bert, you know, and actually bring that and just re hosted. You can, you might have some things that you've already containerized but they're sitting on a container orchestration layer that is no longer growing, right? So the innovation has kind of left that platform and kind of kubernetes has become kind of that standard one, the container orchestration layer, if you want become the de facto standard. And so you want to re platform that that takes massaging and transforming metadata to do that to create the right objects and so on and so forth. So there's a bunch of different use cases around that that kind of fall into that re host tree platform all the way up to re factoring >>So just explain for the audience and I know I love I love the three things re hosting re platform in and re factoring what's the difference between re platform NG and re factoring specifically, what's the nuance there? >>Yeah, yeah, so so a lot of times I think people have a lot of people, you know, I think obviously amazon kind of popularized the six hours framework years ago, you know, with, with, with, with that. And so if you look at what they kind of what they popularize it was replied corn is really kind of like a lift tinker and shift. So maybe it's, I, I'm not just taking my VM and putting it on new infrastructure, I'm gonna take my VM, maybe put on new infrastructure, but I'm gonna switch my observer until like a lighter weight observer or something like that at the same time. So that would fall into like a re platform or in the case, you know, one of the things we're seeing pretty heavily right now is the move from cloud foundry to kubernetes for example, where people are looking to take their application and actually transform it and run it on kubernetes, which requires you to really kind of re platform as well. And re factoring >>is what specific I get the >>report re factoring is, I think just following on to what James said re factoring is really about um the complexity of the application, which was mainly a monolithic large application, many of these legacy applications which have so many times, actually hundreds of millions of dollars of assets for these uh these enterprises, it's about taking the code and re factoring it in terms of dividing it into uh huh different pieces of court which can themselves be spun as microservices. So then it becomes true, it takes starting advantage of agility or development in a cloud native environment as well. It's not just about either lift and shift of the VM or or lift tinker and shift from a, from a staff point of view. It's really about not taking applications and dividing them so that we can spin microservices and it has the identity of the development of a cloud. >>I totally got a great clarification, really want to get that out there because re platform ng is really a good thing to go to the cloud. Hey, I got reticent open source, I'll use that, I can do this over here and then if we use that vendor over there, use open source over there. Really good way to look at it. I like the factory, it's like a complete re architecture or re factoring if you will. So thank you for the clarification. Great, great topic. Uh, this is what practitioners think about. So I gotta ask the next question, what projects are involved in in the community that you guys are working? It seems like a really valuable service uh and group. Um can you give an overview and what's going on in the community specifically? >>Yeah, so there's really right now, there's kind of five projects that are in the community and they're all in different, I would say different stages of maturity as well. So, um there's uh when you look at re hosting, there's two kind of primary projects focused on that. One is called forklift, which is about migrating your virtual machines into cuba. So covert is a way that you can run virtual machines orchestrated by kubernetes. We're seeing kind of a growth in demand there where people want to have a common orchestration for both their VMS and containers running on bare metal. And so forklift helps you actually mass migrate VMS into that environment. Um The second one on the re hosting side is called Crane. So Crane is really a tool that helps you migrate applications between kubernetes clusters. So you imagine you have all your you know, you might have persistent data and one kubernetes cluster and you want to migrate a name space from one cluster to another. Um That's where Crane comes in and actually helps you migrate between those um on the re platforms that we have moved to cube, which actually came from the IBM research team. So they actually open source that uh you sure you want to speak about uh moved to >>cube. Yeah, so so moved to cuba is really as we discuss the re platform scenario already, it is about, you know, if you are in a docker environment or hungry environment uh and you know, kubernetes has become a de facto standard now you are containerized already, but you really are actually moving into the communities based environment as the name implies, It's about moved to cuba back to me and this is one of the things we were looking at and as we were looking, talking to a lot of, a lot of users, it became evident to us that they are adapting now the de facto standard. Uh and it's a tool that helps you enable your applications in that new environment and and move to the new stuff. >>Yeah. And then the the the only other to our tackle which is uh probably like the one of the newest projects which is focused on kind of assessment and analysis of applications for container reservation. So actually looking at and understanding what the suitability is of an application for being containerized and start to be like being re factored into containers. Um and that's that's uh, you know, we have kind of engineers across both uh Red hat IBM research as well as uh some folks externally that are starting to become interested in that project as well. Um and the last, the last project is called Polaris, which is a tool to help you measure your software delivery performance. So this might seem a little odd to have in the community. But when you think about re hosting re platform and re factoring, the idea is that you want to measure your software delivery performance on top of kubernetes and that's what this does. It kind of measures the door metrics. If you're familiar with devops realization metrics. Um so things like, you know, uh you know, your change failure rate and other things on top of their to see are you actually improving as you're making these changes? >>Great. Let me ask the question for the folks watching or anyone interested, how do they get involved? Who can contribute, explain how people get involved? Is our site, is there up location slack channel? What's out there? >>Yeah, yeah, all of the above. So we have a, we have, we have a slack channel, we're on slack dot kubernetes dot io on town conveyor, but if you go to www dot conveyor dot io conveyor with a K. Uh, not like the cube with a C. Uh, but like cube with a K. Uh, they can go to a conveyor to Ohio and um, there they can find everything they need. So, um, we have a, you know, a governance model that's getting put in place, contributor ladder, all the things you'd expect. We're kind of talking into the C N C F around the gap delivery groups to kind of understand if we can um, how we can align ourselves so that in the future of these projects take off, they can become kind of sandbox projects. Um and uh yeah, we would welcome any and all kind of contribution and collaboration >>for sure. I don't know if you have >>anything to add on that, I >>think you covered it at the point has already um, just to put a plug in for uh we have already been having meetups, so on the best practices you will find the community, um, not just on convert or die. Oh, but as you start joining the community and those of meet ups and the help you can get whether on the slack channel, very helpful on the day to day problems that you are encountering as you are taking your applications to a cloud native environment. >>So, and I can see this being a big interest enterprises as they have a mix and match environment and with container as you can bring and integrate old legacy. And that's the beautiful thing about hybrid cloud that I find fascinating right now is that with all the goodness of stade Coubertin and cloud native, if you've got a legacy environments, great fit now. So you don't have to kill the old to bring in the news. So this is gonna be everything a real popular project for, you know, the class, what I call the classic enterprise, So what you guys both have your companies participated in. So with that is that the goal is that the gulf of this community is to reach out to the classic enterprise or open source because certainly and users are coming in like, like, like you read about, I mean they're coming in fast into the community. >>What's the goal for the community really is to provide assistant and help and guidance to the users from a community point of view. It's not just from us whether it is red hat or are ideal research, but it's really enterprises start participating and we're already seeing that interest from the enterprises because there was a big gap in this area, a lot of vendor. Exactly when you start on this journey, there will be 100 people who will be telling you all you have to do is this Yeah, that's easy. All you have to do. I know there is a red flag goes up, >>it's easy just go cloud native all the way everything is a service. It's just so easy. Just you know, just now I was going to brian gracefully, you get right on that. I want to just quickly town tangent here, brian grazer whose product strategist at red hat, you're gonna like this because he's like, look at the cloud native pieces expanding because um, the enterprises now are, are in there and they're doing good work before you saw projects like envoy come from the hyper scales like lift and you know, the big companies who are building their own stuff, so you start to see that transition, it's no longer the debate on open source and kubernetes and cloud native. It's the discussion is integration legacy. So this is the big discussion this week. Do you guys agree with that? And what would, what would be your reaction? >>Yeah, no, I, I agree with you. Right. I mean, I think, you know, I think that the stat you always here is that the 1st 20 of kind of cloud happened and now there's all the rest of it. Right? And, and modernization is going to be the big piece right? You have to be able to modernize those applications and those workloads and you know, they're, I think they're gonna fall in three key buckets, right? Re host free platform re factor and dependent on your business justification and you know, your needs, you're going to choose one of those paths and we just want to be able to provide open tools and a community based approach to those folks too to help that certainly will have and just, you know, just like it always does, you know, upstream first and then we'll have enterprise versions of these migration tool kits based on these projects, but you know, we really do want to kind of build them, you know, and make sure we have the best solution to the problem, which we believe community is the way to do that. >>And I think just to add to what James said, typically we are talking about enterprises, these enterprises will have thousands of applications, so we're not talking about 10 40 number. We're talking thousands or 20% is not a small number is still 233 400. But man, the work is remaining and that's why they are getting excited about cloud negative now, okay, now we have seen the benefit but this little bit here, but now, let's get, you know serious about about that transformation and this is about helping them in a cloud native uh in an open source way, which is what red hat. XL Sad. Let's bring the community together. >>I'm actually doing a story on that. You brought that up with thousands of applications because I think it's, it's under underestimate, I think it's going to be 1000s and thousands more because businesses now, software driven everywhere and observe ability has pointed this out. And I was talking to the founder of uh Ravana project and it's like, how many thousands of dashboards you're gonna need? Roads are So so this is again, this is the problems and the opportunities are coming together, the abstraction will get you to move up the stack in terms of automation. So it's kind of fascinating when you start thinking about the impact as this goes the next level. And so I have to ask your roaches since you're an IBM fellow and chief scientist, which by the way, is a huge distinction. Congratulations. Being an IBM fellow is is a big deal. Uh IBM takes that very seriously. Only a few of them. You've seen many waves and cycles of innovation. How would you categorize this one now? Because maybe I'm getting old and and loving this right now. But this seems like everything kind of coming together in one flash 10.1 major inflection point. All the other waves combined seemed to be like in this one movement very fast. What's your what's your take on this wave that we're in? >>Yes, I would really say there is a lot of technology has been developed but that technology needs to have its value unleashed and that's exactly where the intersection of those applications and that technology occurs. Um I'm gonna put in yet another. You talked about everything becoming software. This was Anderson I think uh Jack Lee said the software is eating the world another you know, another wave that has started as a i eating software as well. And I do believe these two will go inside uh to uh like let me just give you a brief example re factoring how you take your application and smart ways of using ai to be able to recommend the right microservices for you is another one that we've been working towards and some of those capabilities will actually come in this community as well. So when we talk about innovations in this area, We are we are bringing together the best of IBM research as well. As we are hoping the community actually uh joints as well and enterprises are already starting to join to bring together the latest of the innovations bringing their applications and the best practices together to unleash that value of the technology in moving the rest of that 80%. And to be able to seamlessly bridge from my legacy environment to the cloud native environment. >>Yeah. And hybrid cloud is gonna be multi cloud really is the backbone and operating system of business and life society. So as these apps start to come on a P i is an integration, all of these things are coming together. So um yeah, this conveyor project and conveyor community looks like a really strong approach. Congratulations. Good >>job bob. >>Yeah, great stuff. Kubernetes, enabling companies is enabling all kinds of value here in the cube. We're bringing it to you with two experts. Uh, James Richard, thanks for coming on the Cuban sharing. Thank you. >>Thank you. >>Okay, cube con and cloud native coverage. I'm john furry with the cube. Thanks for watching. Yeah.