(upbeat music) >> Hello, brilliant humans and welcome back to theCUBE. We're live from Detroit, Michigan. My name is Savannah Peterson. Joined here with John Furrier, John, so exciting, day three. >> Day three, cranking along, doing great, final day of KubeCon, it wraps up. This next segment's going to be great. It's about WebAssembly, the hottest trend here, at KubeCon that nobody knows about cause they just got some funding and it's got some great traction. Multiple players in here. People are really interested in this and they're really discovering it. They're digging into it. So, we're going to hear from one of the founders of the company that's involved. So, it'll be great. >> Yeah, I think we're right at the tip of the iceberg really. We started off the show with Scott from Docker talking about this, but we have a thought leader in this space. Please welcome Matt Butcher the CEO and co-founder of Fermyon Thank you for being here. Welcome. >> Yeah, thanks so much for having me. Favorite thing to talk about is WebAssembly after that is coffee but WebAssembly first. >> Hey, it's the morning. We can talk about both those on the show. (all chuckles) >> It might get confusing, but I'm willing to try. >> If you can use coffee as a metaphor to teach everyone about WebAssembly throughout the rest of the show. >> All right. That would be awesome. >> All right I'll keep that in mind. >> So when we were talking before we got on here I thought it was really fun because I think the hype is just starting in the WebAssembly space. Very excited about it. Where do you think we're at, set the stage? >> Honestly, we were really excited to come here and see that kind of first wave of hype. We came here expecting to have to answer the question you know, what is WebAssembly and why is anybody looking at it in the cloud space, and instead people have been coming up to us and saying, you know this WebAssembly thing, we're hearing about it. What are the problems it's solving? >> Savannah: Yeah. >> We're really excited to hear about it. So, people literally have been stopping us in restaurants and walking down the street, hey, "You're at KubeCon, you're the WebAssembly people. Tell us more about what's going on." >> You're like awesome celeb. I love this. >> Yeah, and I, >> This is great >> You know the, the description I used was I expected to come here shouting into the void. Hey, you know anybody, somebody, let me tell you about WebAssembly. Instead it's been people coming to us and saying "We've heard about it. Get us excited about it," and I think that's a great place to be. >> You know, one of the things that's exciting too is that this kind of big trend with this whole extraction layer conversation, multicloud, it reminds me of the old app server days where, you know there was a separation between the back end and front end, and then we're kind of seeing that now with this WebAssembly Wasm trend where the developers just want to have the apps run everywhere and the coding to kind of fall in, take a minute to explain what this is, why it's important, why are people jazzed about there's other companies like Cosmonic is in there. There's a lot of open source movement behind it. You guys are out there, >> Savannah: Docker. >> 20 million in fresh funding. Why is this important? What is it and why is it relevant right now? Why are people talking about it? >> I mean, we can't... There is no penasia in the tech world much for the good of all of us, right? To keep us employed. But WebAssembly seems to be that technology that just sort of arose at the right time to solve a number of problems that were really feeling intractable not very long ago. You know, at the core of what is WebAssembly? Well it's a binary format, right? But there's, you know, built on the same, strain of development that Java was built on in the 90's and then the .net run time. But with a couple of little fundamental changes that are what have made it compelling today. So when we think about the cloud world, we think about, okay well security's a big deal to us. Virtual machines are a way for us to run other people's untrusted operating systems on our hardware. Containers come along, they're a... The virtual machine is really the heavyweight class. This is the big thing. The workhorse of the cloud. Then along come Containers, they're a little slimmer. They're kind of the middleweight class. They provide us this great way to sort of package up just the application, not the entire operating system just the application and the bits we care about and then be able to execute those in a trusted environment. Well you know, serverless was the buzzword a few years ago. But one thing that serverless really identified for us is that we didn't actually have the kind of cloud side architecture that was the compute layer that was going to be able to fulfill the promise of serverless. >> Yeah. >> And you know, at that time I was at Microsoft we got to see behind the curtain and see how Azure operates and see the frustration with going, okay how do we get this faster? How do we get this startup time down from seconds to hundreds of milliseconds, WebAssembly comes along and we're able to execute these things in sub one millisecond, which means there is almost no cost to starting up one of these. >> Sub one millisecond. I just want to let everyone rest on that for a second. We've talked a lot about velocity and scale on the show. I mean everyone here is trying to do things faster >> Yep >> Obviously, but that is a real linchpin that makes a very big difference when we're talking about deploying things. Yeah. >> Yeah, and I mean when you think about the ecological and the cost impact of what we're building with the cloud. When we leave a bunch of things running in idle we're consuming electricity if nothing else. The electricity bill keeps going up and we're paying for it via cloud service charges. If you can start something in sub one millisecond then there's no reason you have to leave it running when nobody's using it. >> Savannah: Doesn't need to be in the background. >> That's right. >> So the lightweight is awesome. So, this new class comes up. So, like Java was a great metaphor there. This is kind of like that for the modern era of apps. >> Yeah. >> Where is this going to apply most, do you think? Where's it going to impact most? >> Well, you know, I think there are really four big categories. I think there's the kind of thing I was just talking about I think serverless and edge computing and kind of the server class of problem space. I think IOT is going to benefit, Amazon, Disney Plus, >> Savannah: Yes, edge. >> And PBS, sorry BBC, they all use WebAssembly for the players because they need to run the same player on thousands of different devices. >> I didn't even think about that use case. What a good example. >> It's a brilliant way to apply it. IOT is a hard space period and to be able to have that kind of layer of abstraction. So, that's another good use case >> Savannah: Yeah. >> And then I think this kind of plugin model is another one. You see it was Envoy proxy using this as a way to extend the core features. And I think that one's going to be very, very promising as well. I'm forgetting one, but you know. (all chuckles) I think you end up with these kind of discreet compartments where you can easily fit WebAssembly in here and it's solving a problem that we didn't have the technology that was really adequately solving it before. >> No, I love that. One of the things I thought was interesting we were all at dinner, we were together on Tuesday. I was chatting with Paris who runs Deliveroo at Apple and I can't say I've heard this about too many tools but when we were talking about WebAssembly she said "This is good for everybody" And, it's really nice when technologies come along that will raise the water level across the board. And I love that you're leading this. Speaking of you just announced a huge series aid, 20 million dollars just a few days ago. What does that mean for you and the team? >> I mean there's a little bit of economic uncertainty and it's always nice, >> Savannah: Just a little bit. >> Little bit. >> Savannah: It's come up on the show a little bit this week >> Just smidge. and it's nice to know that we're at a critical time developing this kind of infrastructure layer developing this kind of developer experience where they can go from, you know, blinking cursor to deployed application in two minutes or less. It would be a tragedy if that got forestalled merely because you can't achieve the velocity you need to carry it out. So, what's very exciting about being able to raise around like that at this critical time is that gives us the ability to grow strategically, be able to continue releasing products, building a community around WebAssembly as a whole and of course around our products at Fermyon is a little smaller circle in the bigger circle, and that's why we are so excited about having closed around, that's the perfect one to extend a runway like that. >> Well I'm super excited by this because one I love the concept. I think it's very relevant, like how you progress heavyweight, middleweight, maybe this is lightweight class. >> I know, I'm here for the analogy. No, it's great, its great. >> Maybe it's a lightweight class. >> And we're slimming, which not many of us can say in these times so that's awesome. >> Maybe it's more like the tractor trailer, the van, now you got the sports car. >> Matt: Yeah, I can go.. >> Now you're getting Detroit on us. >> I was trying for a coffee, when I just couldn't figure it out. (all chuckles) >> So, you got 20 million. I noticed the investors amplify very good technical VC and early stage firm. >> Amazing, yeah. >> Insight, they do early stage, big early stage like this. Also they're on the board of Docker. Docker was intent to put a tool out there. There's other competition out there. Cosmonic is out there. They're funded. So you got VC funded companies like yourselves and Cosmonic and others. What's that mean? Different tool chains, is it going to create fragmentation? Is there a common mission? How do you look at the competition as you get into the market >> When you see an ecosystem form. So, here we are at KubeCon, the cloud native ecosystem at this point I like to think of them as like concentric rings. You have the kind of core and then networking and storage and you build these rings out and the farther out you get then the easier it is to begin talking about competition and differentiation. But, when you're looking at that core piece everybody's got to be in there together working on the same stuff, because we want interoperability, we want standards based solutions. We want common ways of building things. More than anything, we want the developers and operators and users who come into the ecosystem to be able to like instantly feel like, okay I don't have to learn. Like you said, you know, 50 different tools for 50 different companies. "I see how this works", and they're doing this and they're doing this. >> Are you guys all contributing into the same open source? >> Yep, yeah, so... >> All the funding happens. >> Both CNCF and the ByteCode Alliance are organizations that are really kind of pushing forward that core technology. You know, you mentioned Cosmonic, Microsoft, SOSA, Red Hat, VMware, they're all in here too. All contributing and again, with all of us knowing this is that nascent stage where we got to execute it. >> How? >> Do it together. >> How are you guys differentiating? Because you know, open source is a great thing. Rising Tide floats all boats. This is a hot area. Is there a differentiation discussion or is it more let's see how it goes, kind of thing? >> Well for us, we came into it knowing very specifically what the problem was we wanted to solve. We wanted this serverless architecture that executed in sub one millisecond to solve, to really create a new wave of microservices. >> KubeCon loves performance. They want to run their stuff on the fastest platform possible. >> Yeah, and it shouldn't be a roadblock, you know, yeah. >> And you look at someone like SingleStore who's a database company and they're in it because they want to be able to run web assemblies close to the data. Instead of doing a sequel select and pulling it way out here and munging it and then pushing it back in. They move the code in there and it's executing in there. So everybody's kind of finding a neat little niche. You know, Cosmonic has really gone more for an enterprise play where they're able to provide a lot of high level security guarantees. Whereas we've been more interested in saying, "Hey, this your first foray into WebAssembly and you're interested in serverless we'll get you going in like a couple of minutes". >> I want to ask you because we had Scott Johnston on earlier opening keynote so we kind of chatted one-on-one and I went off form cause I really wanted to talk to him because Docker is one of the most important companies since their pivot, when they did their little reset after the first Docker kind of then they sold the enterprise off to Mirantis they've been doing really, really well. What's your relationship to Docker? He was very bullish with you guys. Insights, joint investor. Is there a relationship? You guys talk, what's going on there? >> I mean, I'm going to have to admit a little bit of hero worship on my part. I think Scott is brilliant. I just do, and having come from the Kubernetes world the Fermyon team, we've always kind of kept an eye on Docker communicated with a lot of them. We've known Justin Cormack for years. Chris Cornett. (indistinct) I mean yeah, and so it has been a very natural >> Probably have been accused of every Docker Con and we've did the last three years on the virtual side with them. So, we know them really well. >> You've always got your finger on the pulse for them. >> Do you have a relationship besides a formal relationship or is it more of pass shoot score together in the industry? >> Yeah. No, I think it is kind of the multi-level one. You come in knowing people. You've worked together before and you like working with each other and then it sort of naturally extends onto saying, "Hey, what can we do together?" And also how do we start building this ecosystem around us with Docker? They've done an excellent job of articulating why WebAssembly is a complimentary technology with Containers. Which is something I believe very wholeheartedly. You need all three of the heavyweight, middleweight, lightweight. You can't do all the with just one, and to have someone like that sort of with a voice profoundly be able to express, look we're going to start integrating it to show you how it works this way and prevent this sort of like needless drama where people are going, oh Dockers dead, now everything's WebAssembly, and that's been a great.. >> This fight that's been going on. I mean, Docker, Kubernetes, WebAssembly, Containers. >> Yeah. >> We've seen on the show and we both know this hybrid is the future. We're all going to be using a variety of different tools to achieve our goals and I think that you are obviously one of them. I'm curious because just as we were going on you mentioned that you have a PhD in philosophy. (Matt chuckles) >> Matt: Yeah. >> Which is a wild card. You're actually our second PhD in philosophy working in a very technical role on the show this week, which is kind of cool. So, how does that translate into the culture at Fermyon? What's it like on the team? >> Well, you know, a philosophy degree if nothing else teaches you to think in systems and both human systems and formal systems. So that helps and when you approach the process of building a company, you need to be thinking both in terms of how are we organizing this? How are we organizing the product? How do we organize the team? We have really learned that culture is a major deal and culture philosophy, >> Savannah: Why I'm bringing it up. >> We like that, you know, we've been very forward. We have our chip values, curiosity, humility inclusivity and passion, and those are kind of the four things that we feel like that each of us every day should strive to be exhibiting these kinds of things. Curiosity, because you can't push the envelope if you don't ask the hard questions. Humility, because you know, it's easy to get cocky and talk about things as if you knew all the answers. We know we don't and that means we can learn from Docker and Microsoft >> Savannah: That's why you're curious. >> And the person who stops by the booth that we've never met before and says, "hey" and inclusivity, of course, building a community if you don't execute on that well you can't build a good community. The diversity of the community is what makes it stronger than a singular.. >> You have to come in and be cohesive with the community. >> Matt: Yeah. >> The app focus is a really, I think, relevant right now. The timing of this is right online. I think Scott had a good answer I thought on the relationship and how he sees it. I think it's going to be a nice extension to not a extension that way, but like. >> It probably will be as well. >> Almost a pun there John, almost a pun. >> There actually might be an extension, but evolution what we're going to get to which I think is going to be pure application server, like. >> Yep, yep. Like performance for new class of developer. Then now the question comes up and we've been watching developer productivity. That is a big theme and our belief is that if you take digital transformation to its conclusion IT and developers aren't a department serving the business they are the business. That means the developer workflows will have to be radically rebuilt to handle the velocity and new tech for just coding. I call it architectural list. >> I like that. I might steal that. >> It's a pun, but it's also brings up the provocative question. You shouldn't have to need an architecture to code. I mean, Java was great for that reason in many ways. So, if that happens if the developers are running the business that means more apps. The apps is the business. You got to have tool chains and productivity. You can't have fragmentation. Some people are saying WebAssembly might, fork tool chains, might challenge the developer productivity. what's your answer to that? How would you address that objection? >> I mean the threat of forking is always lurking in the corner in open source. In a way it's probably a positive threat because it keeps us honest it keeps us wanting to be inclusive again and keep people involved. Honestly though, I'm not particularly worried about it. I know that the W-3 as a standards body, of course, one of the most respected standards bodies on the planet. They do html, they do cascading style sheets. WebAssembly is in that camp and those of us in the core are really very interested in saying, you know, come on in, let's build something that's going to be where the core is solid and you know what you got and then you can go into the resurgence of the application server. I mean, I wholeheartedly agree with you on that, and we can only get there if we say, all right, here are the common paradigms that we're all going to agree to use, now let's go build stuff. >> And as we've been saying, developers are setting, I think are going to set the standards and they're going to vote with their code and their feet, if you will. >> Savannah: A hundred percent. >> They will decide if you're not aligning with what they want to do. okay. On how they want to self-serve and or work, you'll figure that out. >> Yep, yep. >> You'll get instant feedback. >> Yeah. >> Well, you know, again, I tell you a huge fan of Docker. One of the things that Docker understood at the very outset, is that they had an infrastructure tool and developers were the way to get adoption, and if you look at how fast they got adoption versus many, many other technologies that are profoundly impacted. >> Savannah: Wild. >> Yeah. >> Savannah: It's a cool story. >> It's because they got the developers to go, "This is amazing, hey infrastructure folks, here's an infrastructure tool that we like" and the infrastructure folks are used to code being tossed over the wall are going, "Are you for real?" I mean, and that was a brilliant way to do it and I think that what.. >> John: Yeah, yeah. >> We want to replay in the WebAssembly world is making it developer friendly and you know the kind of infrastructure that we can actually operate. >> Well congratulations to the entire community. We're huge fans of the concept. I kind of see where it's going with connect the dots. You guys getting a lot of buzz. I have to ask you, my final question is the hype is beyond all recognition at this point. People are super pumped and enthusiastic about it and people are looking at it maybe some challenging it, but that's all good things. How do you get to the next level where people are confident that this is actually going to go the next step? Hype to confidence. We've seen great hype. Envoy was hyped up big time before it came in, then it became great. That was one of my favorite examples. Hype is okay, but now you got to put some meat on the bone. The sizzle on the stake so to speak. So what's going to be the stake for you guys as you see this going forward? What's the need? >> Yeah, you know, I talk about our first guiding story was, you know, blinking cursor to deployed application in two minutes. That's what you need to win developers initially. So, what's the next story after that? It's got to be, Fermyon can run real world applications that solve real world problems. That's where hype often fails. If you can build something that's neat but nobody's quite sure what to do with it, to use it, maybe somebody will discover a good use. But, if you take that gambling asset, >> Savannah: It's that ending answer that makes the difference. >> Yeah, yeah. So we say, all right, what are developers trying to build with our platform and then relentlessly focus on making that easier and solving the real world problem that way. That's the crucial thing that's going to drive us out of that sort of early hype stage into a well adopted technology and I talk from Fermyon point of view but really that's for all of us in the WebAssembly. >> John: Absolutely. >> Very well stated Matt, just to wrap us up when we're interviewing you here on theCUBE next year, what do you hope to be able to say then that you can't say today? >> All this stuff about coffee we didn't cover today, but also.. (all chuckles) >> Savannah: Here for the coffee show. Only analogies, that's a great analogy. >> I want to walk here and say, you know last time we talked about being able to achieve density in servers that was, you know, 10 times Kubernetes. Next year I want to say no, we're actually thousands of times beyond Kubernetes that we're lowering people's electricity bill by making these servers more efficient and the developers love it. >> That your commitment to the environment is something I want to do an entirely different show on. We learned that 7-8% of all the world's powers actually used on data centers through the show this week which is jarring quite frankly. >> Yeah, yeah. Tragic would be a better way of saying that. >> Yeah, I'm holding back so that we don't go over time here quite frankly. But anyways, Matt Butcher thank you so much for being here with us. >> Thank you so much for having me it was pleasure.. >> You are worth the hype you are getting. I am grateful to have you as our WebAssembly thought leader. In addition to Scott today from Docker earlier in the show. John Furrier, thanks for being my co-host and thank all of you for tuning into theCUBE here, live from Detroit. I'm Savannah Peterson and we'll be back with more soon. (ambient music)

(soft music) >> Good morning from Detroit, Michigan. theCUBE is live on our second day of coverage of KubeCon + CloudNativeCon North America 2022. Lisa Martin here with John Furrier. John, great to be back with you. The buzz is here, no doubt. We've been talking a lot about the developers. And one of the biggest bottlenecks that they face in software delivery, is when they're stuck waiting for access to environments. >> Yeah, this next segment's going to be very interesting. It's a company that's making DevOps more productive, but recognizing the reality of how people are working remotely, but also company to company developers. People are collaborating in all kinds of forms, so this is really going to be a great segment. >> Exactly. Two new guests to theCUBE who know theCUBE, but are first time on theCUBE from Release Hub, Tommy McClung, it's CEO and Matt Carter, it's CMO. Guys, great to have you on the program. >> Thank you. >> Thanks for having us here. >> So we want to dig into Release Hub, so the audience really gets an understanding. But Tommy, I want to get an understanding of your background. >> Sure. >> You've been at Release Hub for what, three years? >> Yep, I'm the co-founder. >> Before that you were at TrueCar? >> I was, yeah, I was the CTO at TrueCar. And prior to that, I've been a software engineer my entire career. I've started a couple of companies before this. Software engineer at heart. I've been working on systems management and making developers productive since 2000, long time. So it's fun to be working on developer productivity stuff. And this is our home and this is where I feel the most comfortable. >> Lisa: Yeah. And Matt, you're brand new to the company as it's chief marketing officer. >> Matt: Yeah, so I just joined earlier this month, so really excited to be here. I came over from Docker, so it's great to be able to keep working with developers and helping them, not only get their jobs done better and faster, but just get more delight out of what they do every day, that's a super important privilege to me and it's exciting to go and work on this at Release here. >> Well, they're lucky to have you. And we work together, Matt, at Docker, in the past. Developer productivity's always been a key, but communities are now more important. We've been seeing on theCUBE that developers are going to decide the standards, they're going to vote with their axes and their code. And what they decide to work on, it has to be the best. And that's going to be the new defacto standard. You guys have a great solution that I like. And I love the roots from the software engineering background because that's the hardest thing right now, is how do you scale the software, making things simpler and easier. And when things happen, you don't want to disrupt the tool chains, you want to make sure the code is right, you guys have a unique solution. Can you take a minute to explain what it is and why it's so important? >> Tommy: Yeah, I'll use a little bit of my experience to explain it. I was the CTO of a company that had 300 engineers, and sharing a handful of environments, really slowed everybody down, you bottleneck there. So in order to unlock the productivity of that team, developers need environments for development, they need it for testing, they need it for staging, you run your environments in production. So the environment is the key building block in every software development process. And like my last company, there were very few of them, one or two, everybody sharing them. And so the idea at Release is to make environments available on demand, so if a developer needs one for anything, they can spin one up. So if they want to write their code in a environment based in the cloud, they can do that, if they want to test on a poll request, an environment will automatically spin up. And the environments are full stack, include all the services, data, settings, configuration that runs the app. So developers literally get an isolated copy of the application, so they can develop knowing they're not stepping on other developers' toes. >> John: Can you give an example of what that looks like? Do they have to pre-configure the environment, or how does that work? Can you give an example? >> Yeah, sure. You have to, just like infrastructure is code, we call this environments is code. So you need to define your environment, which we have a lot of tools that help you do that. Analyze your repositories, help you define that environment. Now that you have the template for that, you can easily use that template to derive multiple environments out of it. A key part of this is everybody wants to make sure their development and data is secure. It runs within the AWS account of our customer. So we're the control plane that orchestrates it and the data and applications run within the context of their AWS account, so it's- >> John: What's the benefit? >> Tommy: Well, bottlenecking, increased developer productivity, developer happiness is a big one. Matt talks about this all the time, keeping developers in flow, so that they're focused on the job and not being distracted with, "Hey DevOps team, I need you to go spin up an environment." And a lot of times in larger organizations, not just the environments, but the process to get access to resources is a big issue. And so DevOps was designed to let developers take control of their own development process, but were still bottlenecking, waiting for environments, waiting for resources from the DevOps team, so this allows that self-service capability to really be there for the developer. >> Lisa: Matt, talk about... Target audience is the developer, talk about though... Distill that down into the business value. What am I, if I'm a financial services organization, or a hospital, or a retailer in e-commerce, what is my business value going to be with using technology like this and delighting those developers? >> Matt: I think there's three things that really matter to the developers and to the financial leader in the organization, A, developers are super expensive and they have a lot of opportunities. So if a developer's not happy and finding joy and productivity in what they're doing, they're going to look elsewhere. So that's the first thing, the second thing is that when you're running a business, productivity is one measure, but also, are you shipping something confidently the first time, or do you have to go back and fix things? And by having the environment spun up with all of your name space established, your tendencies are managed, all of your data being brought in, you're testing against a very high fidelity version of your application when you check in code. And so by doing that, you're testing things more quickly, and they talk a lot about shifting left, but it's making that environment as fully functional and featured as possible. So you're looking at something as it will appear in production, not a subset of that. And then the last thing, and this is one where the value of Figma is very important, a lot of times, you'll spin up an environment on AWS and you may forget about it and might just keep running and chewing up resources. Knowing that when you're done it goes away, means that you're not spending money on things just sitting there on your AWS instance, which is very important for competitors. >> Lisa: So I hear retention of developers, you're learning that developers, obviously business impact their speed to value as well. >> Tommy: Yep. >> And trust, you're enabling your customers to instill trust in their developers with them. >> Tommy: That's right, yeah. >> Matt: And trust and delight, they can be across purposes, a developer wants to move fast and they're rewarded for being creative, whereas your IT team, they're rewarded for predictability and consistency, and those can be opposing forces. And by giving developers a way to move quickly and the artifact that they're creating is something that the IT team understands and works within their processes, allows you to let both teams do what they care about and not create a friction there. >> John: What about the environment as a service? I love that 'cause it makes it sound like it's scaling in the cloud, which you have mentioned you do that. Is it for companies that are working together? So I don't want to spin up an environment, say we're a businesses, "Hey, let's do a deal. "I'm going to integrate my solution into yours. "I got to get my developers to maybe test it out, "so I'm spinning up an environment with you guys," then what do I do? >> Tommy: Well as far as if you're a customer of ours, is that the way you're asking? Well, a lot of times, it's being used a lot in internal development. So that's the first use case, is I'm a developer, you have cross collaboration amongst teams, so a developer tools. And what you're talking about is more, I'm using an environment for a demo environment, or I'm creating a new feature that I want to share with a customer, That's also possible. So if I'm a developer and I'm building a feature and it's for a specific customer of mine, I can build that feature and preview it with the customer before it actually goes into production. So it's a sandbox product development area for the developers to be actually integrating with their customers very, very quickly before it actually makes its way to all of the end users. >> A demo? >> It could be a demo. >> It's like a collaboration feature? >> Sandbox environment. We have customers- >> Kind of like we're seeing more of this collaboration with developers. This becomes a well- >> Tommy: And it's not even just collaboration with internal teams, it's now you're collaborating with your customer while you're building your software, which is actually really difficult to do if you only have one environment, you can't have- >> John: Yeah, I think that's a killer right there, that's the killer app right there. >> Matt: Instead of sending a Figma to a customer, this is what's going to look like, it's two dimensions, this is the app. That is a massive, powerful difference. >> Absolutely. In terms of customer delay, customer retention, employee engagement, those are all inextricably linked. Can you share, Matt, the voice of the customer? I just saw the release with TripActions, I've been a TripActions user myself, but give us this sense, I know that you're brand new, but the voice of the customer, what is it? What is it reflecting? How is it reinforcing your value prop? >> Matt: I think the voice that comes through consistently is instead of spending time building the system that is hard to do and complicated and takes our engineering cycles, our engineers can focus on whether it's platform engineering, new features and whatnot, it's more valuable to the company to build features, it's more exciting for a developer to build features and to not have to keep going back and doing things manually, which you're doing a... This is what we do all day long. To do it as a sideline is hard. And the customers are excited 'cause they get to move onto higher value activities with their time. >> Lisa: And everybody wants that, everybody wants to be able to contribute high value projects, programs for their organization rather than doing the boring stuff. >> Tommy: Yeah. I think with TripActions specifically, a lot of platform engineering teams are trying to build something like this in house, and it's a lot of toil, it's work that isn't value added, it enables developers to get their job done, but it's not really helping the business deliver a feature to the user. And so this whole movement of platform engineering, this is what those groups are doing and we're a big enabler to those teams, to get that to market faster. >> John: You're targeting businesses, enterprises, developers. >> That's right. >> Mainly, right, developers? >> Yeah. >> What's the business model? How are you guys making money? What's the strategy there? >> Yeah, I mean we really like to align with the value that we deliver. So if a user creates an environment, we get paid when that happens. So it's an on-demand, if you use the environment, you pay us, if you don't, you don't. >> John: Typical cloud-based pricing. >> Yeah. >> Pay as you go. >> Tommy: Usage based pricing. >> Is there a trigger on certain of how it gets cost? Is it more of the environment size, or what's the- >> Yeah, I mean there's a different tier for if you have really large, complicated environments. And that's the trend, that distributed applications aren't simple anymore, so if you have a small little rails app, it's going to be cheaper than if you have a massive distributed system. But manageable, the idea here is that this should help you save money over investing deeply into a deep platform engineering team. So it's got to be cost effective and we're really cognizant of that. >> So you got a simple approach, which is great. Talk about the alternative. What does it look like for a customer that you want to target? What's their environment? What does it look like, so that if I'm a customer, I would know I need to call you guys at Relief Hub. Is it sprawl? Is it multiple tool chains? Chaos, mayhem? What does it look like? >> Tommy: Yeah, let's have Matty, Matt could do this one. >> When you look at the systems right now, I think complexity is the word that keeps coming up, which is that, whether you're talking about multi-cloud or actually doing it, that's a huge thing. Microservices proliferation are happening over and over again, different languages. What I'm excited about with Release, is not dissimilar from what we saw in the Docker movement, which is that there's all this great stuff out there, but there's that common interface there, so you can actually run it locally on your machine, do your dev and test, and know that it's going to operate with, am I using Couchbase or Postgres or whatever, I don't care, it's going to work this way. Similar with Release, people are having to build a lot of these bespoke solutions that are purpose built for one thing and they're not designed to the platform. And the platform for platform engineering gives us a way to take that complexity out the equation, so you're not limited to what you can do, or, "Oh crud, I want to move to something else, "I have to start over again," that process is going to be consistent no matter what you're doing. So you're not worried about evolution and success and growth, you know that you've got a foundation that's going to grow. Doing it on your own, you have to build things in that very bespoke, specific manner, and that just creates a lot more toil than you'd want to get if you were using a platform and focusing on the value after your company. >> Matt Klein was just on here. He was with Lyft, he was the one who open source Envoy, which became very popular. We asked him what he thought about the future and he's like, it's too hard to work with all this stuff. He was mentioning Yamo code, but he got triggered a little bit, but his point was there's a lot to pull together. And it sounds like you guys have this solution, back in the old days, spin up some EC2, compute, similar way, right? "Hey, I don't want to person a server, I person a server, rack and stack, top of rack switch, I'm going to go to the cloud, use EC2. >> Tommy: Yeah, I mean just think about if- >> You're an environment version of that. Why wait for it to be built? >> Yeah. >> Is that what I'm getting- >> Yeah, I mean, and an application today isn't just the EC2 instances, it's all of your data, it's your configuration. Building it one time is actually complicated to get your app to work it, doing it lots of times to make your developers productive with copies of that, is incredibly difficult. >> John: So you saw the problem of developers waiting around for someone to provision an environment. >> Tommy: That's right. >> So they can do whatever they want to do. >> Tommy: That's right. >> Test, ship, do, play around, test the customer. Whatever that project scope is, they're waiting around versus spinning up an environment. >> Yeah, absolutely, 100%. >> And that's the service. >> That's what it is. >> Take time, reduce the steps it takes, make it more productive. >> And build an amazing developer experience that you know your developers are going to love. If you're at Facebook or Google, they have thousands of DevOps people building platforms. If you're a company that doesn't have that resource, you have a choice of go build this yourself, which is a distraction, or invest in something like us and focus on your core. >> John: You got Matt on board, got a new CMO, you got enterprise class features and I saw the press release. Talk about the origination story, why you developed it, and then take a minute to give a plug for the company, on what you're looking for, I'm sure you're hiring, what's going on? >> Tommy: Yeah, I've been an entrepreneur for 20 years. My last experience at TrueCar, I saw this problem firsthand. And as the CTO of that company, I looked into the market for a solution to this, 'cause we had this problem of 300 developers, environments needed for everything. So we ended up building it ourselves and it costs multiple millions of dollars to build it. And so as the buyer at the time, I was like, man, I would've spent to solve this, and I just couldn't. So as a software engineer at heart, having seen this problem my entire career, it was just a natural thing to go work on. So yeah, I mean, for anybody that wants to create unlimited environments for their team, just go to releasehub.com. It's pretty self-explanatory, how to give it a shot and try it out. >> Environments is a service, from someone who had the problem, fixed it, built it- >> That's right. >> For other people. What are you guys hiring, looking for some people? >> Yeah, we have engineering hires, sales hires, Matt's got a few marketing hires coming, >> Matt: I was going to say, got some marketing coming. >> Selfishly he has that. (John laughs) The team's growing and it's a really great place to work. We're 100% remote. Part of this helps that, we build this product and we use it every day, so you get to work on what you build and dog food, it's pretty cool. >> Great solution. >> We love remote development environments. Being here and watching that process where building a product and a feature for the team to work better, wow, we should share this with customers. And the agility to deliver that was really impressive, and definitely reinforced how excited I am to be here 'cause we're building stuff for ourselves, which is- >> Matt: Well we're psyched that you're here in theCUBE. Matt, what's your vision for marketing? You got a hiring plan, you got a vision, I'm sure you got some things to do. What's your goals? What's your objective? >> My goal is... The statement people say, you can't market to developers. And I don't want to market to developers, I want to make sure developers are made aware of how they can learn new things in a really efficient way, so their capabilities grow. If we get people more and more successful with what they're doing, give them joy, reduce their toil and create that flow, we help them do things that make you excited, more creative. And that's to me, the reward of this. You teach people how to do that. And wow, these customers, they're building the greatest innovations in the world, I get to be part of that, which is awesome. >> Lisa: Yeah. Delighted developers has so many positive business outcomes that I'm sure organizations in any industry are going to be able to achieve. So exciting stuff, guys. Thank you so much for joining John and me on the program. Good luck with the growth and congrats on what you've enabled so far in just a few short years. >> Thank you, appreciate it. >> Thanks you so much. >> Thank you for having us on. >> Appreciate it. >> Pleasure. >> Thank you. >> For our guests and for John Furrier, I'm Lisa Martin. You're watching theCUBE, live in Detroit, at KubeCon + CloudNativeCon '22. We're back after a short break. (soft music)

(upbeat music) >> Good afternoon, everyone. Welcome back to theCUBE Live in Detroit, Michigan. Lisa Martin here with John Furrier. We are covering KubeCon + CloudNativeCon '22. John, this is day two of our coverage wall-to-wall three days of coverage on theCUBE. We've been talking a lot about the developer and how the world is starting to really revolve around developer and DevOps portfolios. >> Yes, developers, startups, big companies, all transforming. This next segment, we want to hear from how Dell Technologies cloud natives, big time strategy there and looking forward to it. It's good. It's going to be a great segment. >> Yes, please welcome back one of our alumni to theCUBE. Brad Maltz is here, Senior Director of DevOps Portfolio and DevRel for Dell Technologies. Good to see you. >> Thank you guys for having me. >> So, Dell at KubeCon, what's going on? >> Yeah, that's literally the most common question I'm getting. So for us, it's a lot about our customer base is making that transformation into a DevOps world. And they have a ton of Dell and they're like, Hey, from a Dell perspective, how do you help us make that transformation into a DevOps operating model? So we're here to explain that. We're here to talk about infrastructure as code, our container Kubernetes story, our multi-cloud story. We're talking about all of it. >> Tell us about those stories and what the value is in it for companies to work with Dell as they transition. >> So when we look at it from a DevOps perspective for us, it's all about the culture, the operating model shift they're trying to make. And what that means to them is they have to figure out how do they automate all of the stacks they have to deal with. Whether it's going to be server, storage, data protection, network, and all the way up through the hypervisor and Kubernetes. That means they need to work with an ecosystem of tools. Things like Ansible, things like Terraform, all that stuff. Our job is to make our portfolio more consumable in the infrastructure as code space. That's one part of the discussion. The second part of the conversation is Kubernetes won. Kubernetes won the abstraction in this multi-cloud world and we as Dell are helping our customers consume Kubernetes. Whether it's by bringing solutions and more appliance oriented mentality to the market or whether it's actually enabling them with our container storage modules and CSI drivers. >> So it as supercloud as we call or multi-cloud as some people call it, you're starting to see the abstraction for interoperability, but essentially just distributed hybrid cloud. Edge as you guys have a big presence. So Dell's supplying not just the data center anymore. Cloud models are moving to hybrid on-premises, edge is growing. We saw some great use cases where military applications are using Kubernetes and all kinds of new things. So this real examples happening right now. This is going to impact Dell's customers and Dell as a supplier of compute and servers. And the gear that runs everything. Like at a telco, you can have a data center at an edge spot, like a box could be a data center. >> Telco is a great example cause we created the business, the Telco business unit. And in the Telco business unit, our goal was, hey, telco is a little different than enterprise edge. Enterprise edge, retail, manufacturing, healthcare. They have certain needs. Telco, much smaller group of customers that have a much different set of needs. And that's very similar is how do we scale at the edge? How do we control things programmatically? How do we do it in a secure way? And how do we do it so that our people internally don't have to deal with the underpinnings of all that infrastructure. Just make it easier for them. That's our goal through the edge discussions, through telco and all that. >> Yeah. We've been doing a big thing on why hardware matters. Hardware's back. We look at all the hyperscalers, the big competition is faster, faster, faster chips, faster the physics. This is part of the supply chain both hardware and software. Okay. So developers want more power. At the end of the day, this community here wants invisible infrastructure and they want it fast. >> Brad: Yes, that's exactly right. >> There's a lot under the hub. It's still servers. >> You still got firmware, you still got bio, you still got to management operating system, You still got to patch things, kernels, security issues, all of that from a server perspective. We haven't even talked about storage or networking or any of the other stuff. So there's a ton of buttons and dials under the covers. >> And that's totally going to be awesome. And the question comes in, okay, now take me to the cloud native because automation, infrastructures code, these are now the hotspots. Software supply chain, not hardware, software supply chain. So these are all things that are going to be intersecting. What's your view? >> In the multi-cloud view of the world, what we really have are our customers are saying, okay, we started on one cloud, Amazon or Azure or Google. And they're like, you know what? We had to go to a second cloud for whatever reason, many reasons. Now we have to manage two clouds. And by the way, we never got fully off-prem. So now we have all of our on-premises stuff plus multiple clouds. How do we deal with the complexity there? And the complexity there is everything from data problems of data mobility, data protection, replication, all that stuff. How do we deal with the actual application life cycle management across that? And that's where a lot of the tooling we're discussing comes in. That's where Kubernetes comes in and they want to do it in an agnostic way. 'Cause if they can't begin to transition to do it in a standardized layer, then the end of the day they're still going to be managing three totally different environments with three separate engineering teams. >> So is your target audience primarily existing Dell customers, legacy customers, or is it really wide open? >> It's actually been opening up. So we have kind of, the way I view it is we have three different segments that we're going to be going after. We have what I would say is the top 10% of the industry that's really able to skill up into this DevOps world very quickly. They're going to go after the GitOps, they're going to go after all those things. That's a combination of existing customers, but also the really, really large customers that can build their own clouds on-premises. We then have the other end of the spectrum. People that aren't making the shift. People that are like, you know what this DevOps transformation it's not going to help us there, but we still need server and storage and whatnot. And then I like to call it the squishy middle. 60, 70% of the market that's like, we can't scale up in time, we can't hire the people, they're not available 'cause that 10% just got them all, but we still have the same problems. And how do we operate in a world where we have that multi-cloud type of a problem, but we can't find the people. Now you got to figure out more of the no-code, low-code packaged solutions, packaged automation coming from companies like Dell and others. >> So there's customers that are either at the beginning of their journey are not convinced yet. What are some of the barriers that they're seeing that Dell can help them overcome? >> Number one thing, education. >> Lisa: Really? >> We're hearing that consistently here at KubeCon and just customer meetings all over the place. There is a segment of the industry that they're empowered to move into a DevOps model. They don't have the ability or resources. They're not able to say, I've been doing this forever in this way in storage. How do I do that in another thing? And they're scared. They want somebody to come in and kind of handhold them a little bit, but somebody they trust. Somebody they've been working with for a very long time. That's Dell's role. Hands-on labs, training materials, how-to videos, but do it in the comfortable way that they feel like, okay we got this. >> And the success with the customers has been that well-documented. The success with the company, again, continues to survive and thrive in all conditions. So Michael Dell knows what he's doing. Love following his strategy. Michael, if you're watching, I know he watches theCUBE video, congratulations. But now the hard question for Dell is this, the applications used to run on PCs, now they're running PCs under the covers and servers. The application space here at this community is enabled by Kubernetes, is creating a new application runtime like environment. I like, compared to the old app server days when things were like just application specific, development got easier. We're in that renaissance now where the app runtime is being enabled by Kubernetes. You guys been there, done that in the old school, now the new school. What's your view on this Kubernetes? What's Dell's view on? >> Yeah, so back to Kubernetes won in my head. It's just flat out won and part of the reason, and it beat out a lot of things. You remember Cloud Foundry, which there's still a thing, but Cloud Foundry went a little too far up into the application stack and constrained the application developers a bit too much. Kubernetes success is two things. It's because they're not constraining the developer, but they're also figuring out how to enable that IT operations mindset. And they become that happy medium that's out there. So now all of a sudden, application modernization conversations and cloud-native app development, there is a standard package. There's standard load balancing and security paradigm, standard registration mechanisms, all built into the Kubernetes layer, by the way, enabled by an ecosystem. And because they're actually going through that, what's happening now is we can finally move forward. We can take that next step and we can build around that ecosystem of Kubernetes. >> That is thematically something that we've been hearing, John, for the last day and a half is the maturation of Kubernetes People, what's next? We are ready for the next step. Talk about Dell as an enabler of that. >> Yeah, so a funny, another part of that paradigm is Kubernetes does not equal virtualization. And this is a hard one in this industry right now. A lot of people say, well, yeah, we did the VMware pivot and then the KVM and everything else and they're like, this is just another one of those pivots. I'm like, no it's not. Virtualization was the pivot of physical hardware became virtual hardware, but you still thought of it in CPU memory disc and you managed it in the same way. Kubernetes, it's a such a different way of thinking about operationalization and all that abstraction that what we're realizing is people need to take baby steps into Kubernetes right now. The maturity of it is great because there is an ecosystem around it, but the majority of the industry isn't even aware of the basics of Kubernetes right now. So our job, we look at it as the education part, but also can we deliver the solutions together with the OpenShift's of the world and the Tanzu's of the world and the Rancher's of the world. Can we deliver more of that full stack experience going into the next few years? That's where we believe we can help accelerate them. Education and that delivery mechanism. >> And the community support is going to be there too. You got to have the. >> 100%. >> The community, not just education, which you guys done before, but doing it with open source vibe. >> That's where DevRel comes in. So the DevRel half of my world now is all about Dell in the community. And to be part of community isn't just to say, Hey, I'm going to go sponsor something. That's not community to me. >> It doesn't hurt. >> It doesn't hurt, but we're going to do that. We're definitely going to help with that. What our notion is you got to participate, you got to contribute, you got to be there, you got to be part of the community. That's part of my developer relations team is to become part of it. >> You got to be part of it and belong. Belonging is earning. >> Brad: Yes. >> And that's the key. And the other thing we were talking about standards and Dell has won a lot of business 'cause the PC and the servers all had standards, standard components. Standards now in the community are being driven by developer consensus. >> Brad: Yes. >> So that is an interesting new paradigm. So if you make cloud native work where all the hardware and software that's powering the builders is invisible. The developers will tell you what they want. >> 100%. >> And that's why your Kubernetes, Cloud Foundry example is so on point. It's a little bit nuanced, but what happened there is, let's explain Kubernetes was loosely de facto enabling. They didn't try to take too much territory. They didn't over push. >> Brad: Exactly. >> They were very flexible, lightweight at first, but it was enabling. >> It was organic. >> And we called it on theCUBE, I'm not going to lie, we called that early on. So props to us. >> Brad: Good job. >> Pat on the back. >> Lisa: Pat your own back. >> We get it right a lot. But now there's impact though. But the Dell I think speaks to the theme here, which just we talked is that you got startups here. We had from Envoy, we saw the donator there. He started his own company. You got Dell, which has large enterprises running massive workloads with a lot of legacy and modernization. So you got a combination of both coming together. This is going to be a collision of innovation. >> Oh I look, that's exactly right. Part of what I've been getting is not just the end users, the infrastructure developers, and whatnot around here. Startups look, come to Dell, and they're like, why are you here? Like we build this and we don't talk to you. And we're like, why not? If we come to market and start delivering more of those Kubernetes oriented solutions and the Kubernetes stack experience, that's where you guys should be working with us. You're part of the ecosystem. >> Well, your job is to say to them, look it when you want to write your software for the edge and we have market share of the most hardware at the edge, 'cause we perform better on the edge. No one wants to write software on the slower platform. >> No. >> Name me one I want to write software that's just, this is something, but people don't understand that's why you're here. >> Brad: That's exactly right. >> The game is about performance. >> Brad: Yeah. >> Cloud can do it, you can do it with a machine. So it depends where in the distributed computing chain you're at. >> You bring up one topic that actually isn't a core discussion topic around DevOps, but I am seeing more HPC and a AI/ML conversations popping up in this DevOps cloud native space. 'Cause even the market of HPC, which is a very traditional market, commodity server driven in the past, they're starting to say, how do I take advantage of Kubernetes and all of the benefits that we've been talking about. >> What are some of the things that you've heard like in your sense is the key theme or the talk track of Kubernetes, its evolution? What's on the developer's minds the last day and a half at this conference? >> Oh, okay. That's a hard question, but a good one. So the way I look at it is probably it's the robustness of the features within Kubernetes, not the native features, but even partner included features. They just want to be able to handle security in a much more, I hate to say zero trust, but secure cloud native way. There's tools in the Kubernetes ecosystem that are so integrated into Kubernetes. They don't have to think sometimes as much about how do they do it themselves. They can go find through open source or off-the-shelf startup and say, I need that and I can spin it up in about five minutes and now I'm doing that without having to spend weeks or months and having to build that. And that's security is one example. You can go through the networking discussion, you can go through so many different areas. The fact is because of community and the ecosystem, that is the winning formula for Kubernetes to enable the development. That's all I'm hearing here is they're like, give me more, give me more startups, give me more of these technologies. >> And ease of use has been a big topic here. We've been talking before we came on camera about VMware has done great since it used the virtual machine example versus Kubernetes. That is millions of developers and operators on VMware. They have about 200,000 plus just in VMUG alone. So they are going to transform their careers. They're looking for a home. They're looking for a community for the next 10 years. I mean, VMware will still be around with Broadcom, but I'm speculating that it will be much more in maintenance mode. But to get someone's career in fourth gear, fifth gear, you got to go and get that next skill set, and that's the question. Where do all these operators, IT operators go to become enterprise operators? >> Brad: That's exactly right. >> That is a big topic. What's your reaction? >> Sp I'm actually a living proof of that. I grew up in the VMware ecosystem. And for me making that pivot, it took me many years. One of the ways I did that was I actually have run in Dell, our advanced development pivotal Dojos, if you remember Pivotal. >> Yes. >> And doing the Pair Programming in Agile. It took me that mental shift to say, okay, we were doing it that way and now there's a new way to do it through code with developers and using all the new buzzwords. And that pivot is different for somebody that's just starting now, and they don't have access to a Dojo that they can go handle like a whole bunch of pair programmers. How do they make that pivot? That's 100% what we have to do. >> Okay, so my question is this, this is a hard question for you, maybe you can answer or not or maybe you can. What's different now than the attempt in the past from Dell EMC to do work or align with the developers? I think, was it five, six years ago, it was an effort. Was it timing? What's different now from then? >> So that attempt was awesome. That team was great. I was very close to that team and that was from the EMC side originally is where they have built that out. And the notion of that was that we just have to go start contributing knowledge and technology into the community and start really taking the brand and trying to expand the brand to be relevant in that community. Nothing wrong. That was actually an amazing way they did it. I think through the merger there was definitely a little bit of, okay, well, maybe this isn't one of our top priorities right now and that's probably what happened through the actual merger. >> John: It's a little bit distraction. >> It was distraction. >> Timings wasn't as good now. >> You try merging a 67 billion merger. I mean it's just really hard to do. What happened here is I think we finally got past a lot of that with the merger and now we're in steady stage/growth mode, which is a notion that now we can go and do this again in the new world, taking our lessons learned from what we did before, and try to actually go and update that in these new power apps. >> And you could point to some specific timing issues. Like at that time this community wasn't as advanced along. Kubernetes wasn't as clear. Visibility to that value proposition. Although a lot of people were speculating what happened that way. >> Exactly. >> But now with multi-cloud, I think developers starting to see the reality that it ain't going to be one cloud. >> Well, multi-cloud is not one cloud, so 100%. >> Well, I mean there's multi-cloud today, but it's really not multi-cloud by the way it could be. The people have multiple clouds. I think that gives developers comfort that existing enterprise players. Remember Microsoft wasn't really in the cloud game six, seven years ago. Look where they are now. Significant progress, nipping at the heels of AWS. So all the enterprise players are back at the table. >> Brad: Yeah, definitely. We're here. >> And that's timing issue. >> We're here. >> Talk about, you're here, you are helping customers get to the basics of Kubernetes. You talked a lot about the importance of the education. >> Brad: Yes. >> That screams to me that Dell can be a facilitator of cultural change within organizations, whether it's a bank or a hospital or a retailer or whatnot. Another thing that I'm curious about, what you guys are doing, how you've evolved, Dell is a massive partner ecosystem. How is the partner ecosystem involved in helping customers build their DevOps portfolios and really start embracing, understanding, and learning about Kubernetes? >> So that's an ever changing world right now. And that's part of why we're here at KubeCon is to help expand that. We have a very, very strong partner community. Not even just channel, but like technology partner community. And our goal is to understand with our DevOps portfolio what needs to be the next step of that partner community. Do we have to go partner up with like the, I'll use examples, the Solo.io. Do we have to partner up with all the mesh companies, the HashiCorp, which we are, We have to understand where the layers that make sense and where don't. There are some that don't make sense because they're so often to an app developer land or they're so far above even Kubernetes sometimes that maybe they don't make sense in our partner community. >> How influential are, I know we got to go soon, but how influential are your customers in helping to make some of those decisions? It's all about the customer at the end of the day. >> They're the only one that's deciding for us. They have to come to us. We have to see the need. We have to understand the discussions through our sales mechanisms, our other mechanisms. We're using that data every single day, every hour to make those decisions. >> Awesome. Brad, it's been great to have you. Sorry we took more of your time than we planned, but it was so interesting. >> No, this is awesome. >> Dell at KubeCon, you've done a great job of explaining why that absolutely resonates, the relevance, and why customers should be looking at Dell as their partner for this. Thank you so much for your time and your insights. >> Thank you guys. >> All right. For John Furrier and our guest, I'm Lisa Martin. You're watching theCUBE live at KubeCon + CloudNativeCon '22 from Detroit, Michigan. Stick around, our next guest will be here in just a minute. (gentle music)

>>Good morning and welcome back to Detroit, Michigan. My name is Savannah Peterson and I'm here on set of the cube, my co-host John Farer. How you doing this morning, John? >>Doing great. Feeling fresh. Day two of three days of coverage, feeling >>Fresh. That is that for being in the heat of the conference. I love that attitude. It's gonna >>Be a great day today. We'll see you at the end of the day. Yeah, >>Well, we'll hold him to it. All right, everyone hold 'em accountable. Very excited to start the day off with an internet, a legend as well as a cube og. We are joined this morning by Matt Klein. Matt, welcome to the show. >>Thanks for having me. Good to see you. Yep. >>It's so, what's the vibe? Day two, Everyone's buzzing. What's got you excited at the show? You've been here before, but it's been three years you >>Mentioned. I, I was saying it's been three years since I've been to a conference, so it's been interesting for me to see what is, what is the same and what is different pre and post covid. But just really great to see everyone here again and nice to not be sitting in my home by myself. >>You know, Savannah said you're an OG and we were referring before we came on camera that you were your first came on the Cub in 2017, second Cuban event. But you were, I think, on the first wave of what I call the contributor momentum, where CNCF really got the traction. Yeah. You were at Lift, Envoy was contributed and that was really hyped up and I remember that vividly. It was day zero they called it back then. Yeah. And you got so much traction. People are totally into it. Yeah. Now we've got a lot of that going on now. Right. A lot of, lot of day Zero events. They call 'em co, co-located events. You got web assembly, a lot of other hype out there. What do you see out there that you like? How would you look at some of these other Sure. Communities that are developing, What's the landscape look like as you look out? Because Envoy set the table, what is now a standard >>Practice. Yeah. What's been so interesting for me just to come here to the conference is, you know, we open source Envoy in 2016. We donated in 2017. And as you mentioned at that time, Envoy was, you know, everyone wanted to talk about Envoy. And you know, much to my amazement, Envoy is now pervasive. I mean, it's used everywhere around the world. It's like, never in my wildest dreams would I have imagined that it would be so widely used. And it's almost gotten to the point where it's become boring. You know, It's just assumed that Envoy is, is everywhere. And now we're hearing a lot about Eeb p f and Web assembly and GI ops and you know, AI and a bunch of other things. So it's, it's actually great. It's made me very happy that it's become so pervasive, but it's also fun. Yeah. We mention to, to look around all other stuff >>Like congratulate. It's just a huge accomplishment really. I think it's gonna be historic, historical moment for the industry too. But I like how it progressed. I mean, I don't mind hype cycles as long as it's some vetting. Sure. Of course. You know, use cases that are clearly defined, but you gotta get that momentum in the community, but then you start gotta get down to, to business. Yep. So, so to speak and get it deployed, get traction. Yep. What should projects look like? And, and give us the update on Envoy. Cause you guys have a, a great use case of how you got traction. Right. Take us through some of the early days of what made Envoy successful in your opinion. Great question. >>Yeah. You know, I, I think Envoy is fairly unique around this conference in the sense that Envoy was developed by Lyft, which is an end user company. And many of the projects in this ecosystem, you know, no judgment, for better or worse, they are vendor backed. And I think that's a different delivery mechanism when it's coming from an end user where you're solving a, a particular business case. So Envoy was really developed for Lyft in a, you know, very early scaling days and just, you know, trying to help Lyft solve its business problems. So I think when Envoy was developed, we were, you know, scaling, we were falling over and actually many other companies were having similar problems. So I think Envoy became very widely deployed because many companies were having similar issues. So Envoy just became pervasive among lift peer companies. And then we saw a lot of vendor uptake in the service mesh space in the API gateway space among large internet providers. So, I I I, I think it's just, it's an interesting case because I think when you're solving real problems on the ground, in some ways it's easier to actually get adoption than if you're trying to develop it from a commercial backing. >>And that's the class, I mean, almost, It's almost like open source product market fit. It is in its own way. Cause you have a problem. Absolutely. Other people have the same problem finding >>Too. I mean, it's, it's designed thinking from >>A different, When, when I talk to people about open source, I like to tell people that I do not think it's any different than starting a company. I actually think it's all the same problems finding pro product, market fit, hiring, like finding contributors and maintainers, like doing PR and marketing. Yeah. Getting team together, traction, getting, getting funding. I mean, you have to have money to do all these things. Yeah. So I think a lot of people think of open source as I, I don't know, you know, this fantastic collaborative effort and, and it is that, but there's a lot more to it. Yeah. And it is much more akin to starting a >>Company. Let's, let's just look at that for a second. Cause I think that's a good point. And I was having a conversation in the hallway two nights ago on this exact point. If the power dynamics of a startup in the open source, as you point out, is just different, it's community based. So there are things you just gotta be mindful of. It's not top down. >>Exactly. It's not like, >>Right. You know, go take that hill. It's really consensus based, but it is a startup. All those elements are in place. Absolutely. You need leadership, you gotta have debates, alignment, commit, You gotta commit to a vision. Yep. You gotta make adjustments. Build the trajectory. So based on that, I mean, do you see more end user traction? Cause I was, we were talking also about Intuit, they donated some of their tow code R goes out there. Yep. R go see the CDR goes a service. Where's the end user contributions to these days? Do you feel like it's good, still healthy? >>I, I mean, I, I'm, I'm biased. I would like to see more. I think backstage outta Spotify is absolutely fantastic. That's an area just in terms of developer portals and developer efficiency that I think has been very underserved. So seeing Backstage come outta Spotify where they've used it for years, and I think we've already seen they had a huge date, you know, day one event. And I, I think we're gonna see a lot more out of that >>Coming from, I'm an end user, pretend I'm an end user, so pretend I have some code. I want to, Oh man, I'm scared. I don't am I'm gonna lose my competitive edge. What's the, how do you talk to the enterprise out there that might be thinking about putting their project out there for whether it's the benefit of the community, developing talent, developing the product? >>Sure. Yeah. I would say that I, I would ask everyone to think through all of the pros and cons of doing that because it's not for free. I mean, doing open source is costly. It takes developer time, you know, it takes management time, it takes budgeting dollars. But the benefits if successful can be huge, right? I mean, it can be just in terms of, you know, getting people into your company, getting users, getting more features, all of that. So I would always encourage everyone to take a very pragmatic and realistic view of, of what is required to make that happen. >>What was that decision like at Lyft >>When you I I'm gonna be honest, it was very naive. I I think we've, of that we think we need to know. No, just didn't know. Yeah. I think a lot of us, myself included, had very minimal open source experience. And had we known, or had I known what would've happened, I, I still would've done it. But I, I'm gonna be honest, the last seven years have aged me what I feel like is like 70 or a hundred. It's been a >>But you say you look out in the landscape, you gotta take pride, look at what's happened. Oh, it's, I mean, it's like you said, it >>Matured fantastic. I would not trade it for anything, but it has, it has been a journey. What >>Was the biggest surprise? What was the most eye opening thing about the journey for you? >>I, I think actually just the recognition of all of the non-technical things that go into making these things a success. I think at a conference like this, people think a lot about technology. It is a technology conference, but open source is business. It really is. I mean, it, it takes money to keep it going. It takes people to keep >>It going. You gotta sell people on the concepts. >>It takes leadership to keep it going. It takes internal, it takes marketing. Yeah. So for me, what was most eyeopening is over the last five to seven years, I feel like I actually have not developed very many, if any technical skills. But my general leadership skills, you know, that would be applicable again, to running a business have applied so well to, to >>Growing off, Hey, you put it out there, you hear driving the ship. It's good to do that. They need that. It really needs it. And the results speak for itself and congratulations. Yeah. Thank you. What's the update on the project? Give us an update because you're seeing, seeing a lot of infrastructure people having the same problem. Sure. But it's also, the environments are a little bit different. Some people have different architectures. Absolutely different, more cloud, less cloud edges exploding. Yeah. Where does Envoy fit into the landscape they've seen and what's the updates? You've got some new things going on. Give the updates on what's going on with the project Sure. And then how it sits in the ecosystem vis-a-vis what people may use it for. >>Yeah. So I'm, from a core project perspective, honestly, things have matured. Things have stabilized a bit. So a lot of what we focus on now are less Big bang features, but more table stakes. We spend a lot of time on security. We spend a lot of time on software supply chain. A topic that you're probably hearing a lot about at this conference. We have a lot of software supply chain issues. We have shipped Quicken HTB three over the last year. That's generally available. That's a new internet protocol still work happening on web assembly where ha doing a lot of work on our build and release pipeline. Again, you would think that's boring. Yeah. But a lot of people want, you know, packages for their fedora or their ADU or their Docker images. And that takes a lot of effort. So a lot of what we're doing now is more table stakes, just realizing that the project is used around the world very widely. >>Yeah. The thing that I'm most interested in is, we announced in the last six months a project called Envoy Gateway, which is layered on top of Envoy. And the goal of Envoy Gateway is to make it easier for people to run Envoy within Kubernetes. So essentially as an, as an ingress controller. And Envoy is a project historically, it is a very sophisticated piece of software, very complicated piece of software. It's not for everyone. And we want to provide Envoy Gateway as a way of onboarding more users into the Envoy ecosystem and making Envoy the, the default API gateway or edge proxy within Kubernetes. But in terms of use cases, we see Envoy pervasively with service mesh, API gateway, other types of low balancing cases. I mean, honestly, it's, it's all over the place at >>This point. I'm curious because you mentioned it's expanded beyond your wildest dreams. Yeah. And how could you have even imagined what Envoy was gonna do? Is there a use case or an application that really surprised you? >>You know, I've been asked that before and I, it's hard for me to answer that. It's, it's more that, I mean, for example, Envoy is used by basically every major internet company in China. I mean, like, wow. Everyone in China uses Envoy, like TikTok, like Alibaba. I mean like everyone, all >>The large sale, >>Everyone. You know, and it's used, it's used in the, I'm just, it's not just even the us. So I, I think the thing that has surprised me more than individual use cases is just the, the worldwide adoption. You know, that something could be be everywhere. And that I think, you know, when I open my phone and I'm opening all of these apps on my phone, 80 or 90% of them are going through Envoy in some form. Yeah. You know, it's, it's just that pervasive, I blow your mind a little bit sometimes >>That does, that's why you say plumber on your Twitter handle as your title. Cause you're working on all these things that are like really important substrate issues, Right. For scale, stability, growth. >>And, you know, to, I, I guess the only thing that I would add is, my goal for Envoy has always been that it is that boring, transparent piece of technology. Kind of similar to Linux. Linux is everywhere. Right? But no one really knows that they're using Linux. It's, it's justs like Intel inside, we're not paying attention. It's just there, there's >>A core group working on, if they have pride, they understand the mission, the importance of it, and they make their job is to make it invisible. >>Right. Exactly. >>And that's really ease of use. What's some of the ease of use sways and, and simplicity that you're working on, if you can talk about that. Because to be boring, you gotta be simpler and easier. All boring complex is unique is not boring. Complex is stressful. No, >>I I think we approach it in a couple different ways. One of them is that because we view Envoy as a, as a base technology in the ecosystem, we're starting to see, you know, not only vendors, but other open source projects that are being built on top of Envoy. So things like API Gateway, sorry, Envoy Gateway or you know, projects like Istio or all the other projects that are out there. They use Envoy as a component, but in some sense Envoy is a, as a transparent piece of that system. Yeah. So I'm a big believer in the ecosystem that we need to continue to make cloud native easier for, for end users. I still think it's too complicated. And so I think we're there, we're, we're pushing up the stack a bit. >>Yeah. And that brings up a good point. When you start seeing people building on top of things, right? That's enabling. So as you look at the enablement of Envoy, what are some of the things you see out on the horizon if you got the 20 mile stare out as you check these boring boxes, make it more plumbing, Right? Stable. You'll have a disruptive enabling platform. Yeah. What do you see out there? >>I am, you know, I, again, I'm not a big buzzword person, but, so some people call it serverless functions as a service, whatever. I'm a big believer in platforms in the sense that I really believe in the next 10 to 15 years, developers, they want to provide code. You know, they want to call APIs, they want to use pub subsystems, they want to use cas and databases. And honestly, they don't care about container scheduling or networking or load balancing or any of >>These things. It's handled in the os >>They just want it to be part of the operating system. Yeah, exactly. So I, I really believe that whether it's an open source or in cloud provider, you know, package solutions, that we're going to be just moving increasingly towards systems likes Lambda and Fargate and Google Cloud Run and Azure functions and all those kinds of things. And I think that when you do that much of the functionality that has historically powered this conference like Kubernetes and Onvoy, these become critical but transparent components that people don't, they're not really aware of >>At that point. Yeah. And I think that's a great call out because one of the things we're seeing is the market forces of, of this evolution, what you just said is what has to happen Yep. For digital transformation to, to get to its conclusion. Yep. Which means that everything doesn't have to serve the business, it is the business. Right. You know it in the old days. Yep. Engineers, they serve the business. Like what does that even mean? Yep. Now, right. Developers are the business, so they need that coding environment. So for your statement to happen, that simplicity in visibility calling is invisible os has to happen. So it brings up the question in open source, the trend is things always work itself out on the wash, as we say. So when you start having these debates and the alignment has to come at some point, you can't get to those that stay without some sort of defacto or consensus. Yep. And even standards, I'm not a big be around hardcore standards, but we can all agree and have consensus Sure. That will align behind, say Kubernetes, It's Kubernetes a standard. It's not like an i e you know, but this next, what, what's your reaction to this? Because this alignment has to come after debate. So all the process contending for I am the this of that. >>Yeah. I'm a look, I mean, I totally see the value in like i e e standards and, and there's a place for that. At the same time, for me personally as a technologist, as an engineer, I prefer to let the, the market as it were sort out what are the defacto standards. So for example, at least with Envoy, Envoy has an API that we call Xds. Xds is now used beyond Envoy. It's used by gc, it's used by proprietary systems. And I'm a big believer that actually Envoy in its form is probably gonna go away before Xds goes away. So in some ways Xds has become a defacto standard. It's not an i e e standard. Yeah. We, we, we have been asked about whether we should do that. Yeah. But I just, I I think the >>It becomes a component. >>It becomes a component. Yeah. And then I think people gravitate towards these things that become de facto standards. And I guess I would rather let the people on the show floor decide what are the standards than have, you know, 10 people sitting in a room figure out >>The community define standards versus organizational institutional defined standards. >>And they both have places a >>Hundred percent. Yeah, sure. And, and there's social proof in both of them. Yep. >>Frankly, >>And we were saying on the cube that we believe that the developers will decide the standard. Sure. Because that's what you're basically saying. They're deciding what they do with their code. Right. And over time, as people realize the trade of, hey, if everyone's coding this right. And makes my life easier to get to that state of nirvana and enlightenment, as we would say. Yeah. Yeah. >>Starting strong this morning. John, I I love this. I'm curious, you mentioned Backstage by Spotify wonderful example. Do you think that this is a trend we're gonna see with more end users >>Creating open source projects? Like I, you know, I hope so. The flip side of that, and as we all know, we're entering an uncertain economic time and it can be hard to justify the effort that it takes to do it well. And what I typically counsel people when they are about to open source something is don't do it unless you're ready to commit the resources. Because opensourcing something and not supporting it. Yeah. I actually can be think, I think it'd be worse. >>It's an, it's insult that people, you're asking to commit to something. Exactly. Needs of time, need the money investment, you gotta go all in and push. >>So I, so I very much want to see it and, and I want to encourage that here, but it's hard for me to look into the crystal ball and know, you know, whether it's gonna happen more >>Or less at what point there were, are there too many projects? You know, I mean, but I'm not, I mean this in, in a, in a negative way. I mean it more in the way of, you know, you mentioned supply chain. We were riffing on the cube about at some point there's gonna be so much code open source continuing thundering away with, with the value that you're just gluing things. Right. I don't need the code, this code there. Okay. What's in the code? Okay. Maybe automation can help out on supply chain. Yeah. But ultimately composability is the new >>Right? It is. Yeah. And, and I think that's always going to be the case. Case. Good thing. It is good thing. And I, I think that's just, that's just the way of things for sure. >>So no code will be, >>I think, I think we're seeing a lot of no code situations that are working great for people. And, and, but this is actually really no different than my, than my serverless arguing from before. Just as a, as a, a slight digression. I'm building something new right now and you know, we're using cloud native technologies and all this stuff and it's still, >>What are you building? >>Even as a I'm, I'm gonna keep that, I'm gonna keep that secret. I know I'm, but >>We'll find out on Twitter. We're gonna find out now that we know it. Okay. Keep on mystery. You open that door. We're going down see in a couple weeks. >>Front >>Page is still an angle. >>But I, I was just gonna say that, you know, and I consider myself, you know, you're building something, I'm, I see myself an expert in the cloud native space. It's still difficult, It's difficult to, to pull together these technologies and I think that we will continue to make it easier for people. >>What's the biggest difficulties? Can you give us some examples? >>Well, just, I mean, we still live in a big mess of yammel, right? Is a, there's a, there's a lot of yaml out there. And I think just wrangling all of that in these systems, there's still a lot of cobbling together where I think that there can be unified platforms that make it easier for us to focus on our application logic. >>Yeah. I gotta ask you a question cuz I've talked to college kids all the time. My son's a junior in CS and he's, you know, he's coding away. What would you, how does a student or someone who's learning figure out where, who they are? Because there's now, you know, you're either into the infrastructure under the hood Yeah. Or you're, cuz that's coding there option now coding the way your infrastructure people are working on say the boring stuff so everyone else can have ease of use. And then what is just, I wanna just code, there's two types of personas. How does someone know who they are? >>My, when I give people career advice, my biggest piece of advice to them is in the first five to seven to 10 years of their career, I encourage people to do different things like every say one to two to three years. And that doesn't mean like quitting companies and changing companies, it could mean, you know, within a company that they join doing different teams, you know, working on front end versus back end. Because honestly I think people don't know. I think it's actually very, Yeah. Our industry is so broad. Yeah. That I think it's almost impossible to >>Know. You gotta get your hands dirty to jump >>In order to know what you like. And for me, in my career, you know, I've dabbled in different areas, but I've always come back to infrastructure, you know, that that's what I enjoy >>The most. Okay. You gotta, you gotta taste everything. See what you, what >>You like. Exactly. >>Right. Last question for you, Matt. It's been three years since you were here. Yep. What do you hope that we're able to say next year? That we can't say this year? Hmm. Beyond the secrets of your project, which hopefully we will definitely be discussing then. >>You know, I I, I don't have anything in particular. I would just say that I would like to see more movement towards projects that are synthesizing and making it easier to use a lot of the existing projects that we have today. So for example, I'm, I'm very bullish on backstage. Like I, I've, I've always said that we need better developer UIs that are not CLIs. Like I know it's a general perception among many people. Totally agree with you. Frankly, you're not a real systems engineer unless you type on the command line. I, I think better user interfaces are better for humans. Yep. So just for a project like Backstage to be more integrated with the rest of the projects, whether that be Envo or Kubernete or Argo or Flagger. I, I just, I think there's tremendous potential for further integration of some >>Of these projects. It just composability That makes total sense. Yep. Yep. You're, you're op you're operating and composing. >>Yep. And there's no reason that user experience can't be better. And then more people can create and build. So I think it's awesome. Matt, thank you so much. Thank you. Yeah, this has been fantastic. Be sure and check out Matt on Twitter to find out what that next secret project is. John, thank you for joining me this morning. My name is Savannah Peterson and we'll be here all day live from the cube. We hope you'll be joining us throughout the evening until a happy hour today. Thanks for coming. Thanks for coming. Thanks for watching.

(upbeat techno music) >> Hello, everyone. Welcome to theCUBE here live in Detroit for KubeCon + CloudNativeCon 2022. I'm John Furrier, host of theCUBE. This is our seventh consecutive KubeCon + CloudNativeCon. Since inception, theCube's been there every year. And of course, theCUBE continues to grow. So does the community as well as our host roster. I'm here with my co-host, Lisa Martin. Lisa, great to see you. And our new theCube host, Savannah Peterson. Savannah, welcome to theCUBE. >> Thanks, John. >> Welcome. >> Welcome to the team. >> Thanks, team. It's so wonderful to be here. I met you all last KubeCon and to be sitting on this stage in your company is honestly an honor. >> Well, great to have you. Lisa and I have done a lot of shows together and it's great to have more cadence around. You know, more fluid around the content, and also the people. And I would like you to take a minute to tell people your background. You know the community here. What's the roots? You know the Cloud Native world pretty well. >> I know it as well as someone my age can. As we know, the tools and the tech is always changing. So hello, everyone. I'm Savannah Peterson. You can find me on the internet @SavIsSavvy. Would love to hear from you during the show. Big fan of this space and very passionate about DevOps. I've been working in the Silicon Valley and the Silicon Alley for a long time, helping companies scale internationally as a community builder as well as a international public speaker. And honestly, this is just such a fun evolution for my career and I'm grateful to be here with you both. >> We're looking forward to having you on theCUBE. Appreciate it. Lisa? >> Yes. >> KubeCon. Amazing again this year. Just keeps growing bigger and bigger. >> Yes. >> Keynote review, you were in there. >> Yup. >> I had a chance to peek in a little bit, but you were there and got most of the news. What was the action? >> You know, the action was really a big focus around the maintainers, what they're doing, giving them the props and the kudos and the support that they deserve. Not just physically, but mentally as well. That was a really big focus. It was also a big focus on mentoring and really encouraging more people- >> Love that. >> I did, too. I thought that was fantastic to get involved to help others. And then they showed some folks that had great experiences, really kind of growing up within the community. Probably half of the keynote focus this morning was on that. And then looking at some of the other projects that have graduated from CNCF, some of these successful projects, what they're doing, what folks are doing. Cruise, one of the ones that was featured. You've probably seen their driverless cars around San Francisco. So it was great to see that, the successes that they've had and where that's going. >> Yeah. Lisa, we've done how many shows? Hundreds of shows together. When you see a show like this grow and continue to mature, what's your observation? You've seen many shows we've hosted together. What jumps out this year? Is it just that level of maturization? What's your take on this? >> The maturization of the community and the collaboration of the community. I think those two things jumped out at me even more than last year. Last year, obviously a little bit smaller event in North America. It was Los Angeles. This year you got a much stronger sense of the community, the support that they have for each other. There were a lot of standing ovations particularly when the community came out and talked about what they were doing in Ukraine to support fellow community members in Ukraine and also to support other Ukrainians in terms of getting in to tech. Lot of standing ovations. Lot of- >> Savannah: Love that, yeah. >> Real authenticity around the community. >> Yeah, Savannah, we talked on our intro prior to the event about how inclusive this community is. They are really all in on inclusivity. And the Ukraine highlight, this community is together and they're open. They're open to everybody. >> Absolutely. >> And they're also focused on growing the educational knowledge. >> Yeah, I think there's a real celebration of curiosity within this community that we don't find in certain other sectors. And we saw it at dinner last night. I mean, I was struck just like you Lisa walking in today. The energy in that room is palpably different from last year. I saw on Twitter this morning, people are very excited. Many people, their first KubeCon. And I'm sure we're going to be feeding off of that, that kind of energy and that... Just a general enthusiasm and excitement to be here in Detroit all week. It's a treat. >> Yeah, I even saw Stu Miniman earlier, former theCube host. He's at Red Hat. We were talking on the way in and he made an observation I thought was interesting I'll bring up because this show, it's a lot "What is this show? What isn't this show?" And I think this show is about developers. What it isn't is not a business show. It's not about business. It's not about industry kind of posturing or marketing. All the heavy hitters on the dev side are here and you don't see the big execs. I mean, you got the CEOs of startups here but not the CEOs of the big public companies. We see the doers. So, I mean, I think my take is this show's about creating products for builders and creating products that people can consume. And I think that is the Cloud Native lanes that are starting to form. You're either creating something for builders to build stuff with or you're creating stuff that could be consumed. And that seems for applications. So the whole app side and services seem to be huge. >> They also did a great job this morning of showcasing some of the big companies that we all know and love. Spotify. Obviously, I don't think a day goes by where I don't turn on Spotify. And what it's done- >> Me neither. >> What it's done for the community... Same with Intuit, I'm a user of both. Intuit was given an End User Award this morning during the keynote for their contributions, what they're doing. But it was nice to see some just everyday companies, Cloud Native companies that we all know and love, and to understand their contributions to the community and how those contributions are affecting all of us as end users. >> Yeah, and I think those companies like Intuit... Argo's been popular, Arlo now new, seeing those services, and even enterprises are contributing. You know, Lyft is always here, popular with Envoy. The community isn't just vendors and that's the interesting thing. >> I think that's why it works. To me, this event is really about the celebration of developer relations. I mean, every DevRel from every single one of these companies is here. Like you said, in lieu of the executive, that's essentially who we're attracting. And if you look out over the show floor here, I mean, we've probably got, I don't know, three to four extra vendors that we had last year. It totally is a different tone. This community doesn't like to be sold to. This community likes to be collaborative. They like to learn and they like to help. And I think we see that within the ecosystem inside the room today. >> It's not a top down sales pitch. It's really consensus. >> No. >> Do it out in the open transparency. Don't sell me stuff. And I think the other thing I like about this community is that we're starting to see that... And then we've said this in theCube before. We'll say it again. Maybe be more controversial. Digital transformation is about the developer, right? And I think the power is going to shift in every company to the developer because if you take digital transformation to completion, everything happens the way it's happening, the company is the application. It's not IT who serves the organization- >> I love thinking about it like that. That's a great point, John. >> The old phase was IT was a department that served the business. Well, the business is IT now. So that means developer community is going to grow like crazy and they're going to be in the front lines driving all the change. In my opinion, you going to see this developer community grow like crazy and then the business side on industry will match up with that. I think that's what's going to happen. >> So, the developers are becoming the influencers? >> Developers are the power source for all companies. They're in charge. They're going to dictate terms to how businesses will run because that's going to be natural 'cause digital transformation's about the app and the business is the app. So that mean it has to be coded. So I think you're going to see a lot of innovation around app server-like experiences where the the apps are just being developed faster than the infrastructures enabling that completely invisible. And I think you're going to see this kind of architecture-less, I'll put it out there that term architecture-less, environment where you don't need an architecture. It's just you code away. >> Yeah, yeah. We saw GitHub's mentioned in the keynote this morning. And I mean, low code, no code. I think your fingers right on the pulse there. >> Yeah. What did you guys see? Anything else you see? >> I think just the overall... To your point, Savannah, the energy. Definitely higher than last year. When I saw those standing ovations, people really come in together around the sense of community and what they've accomplished especially in the last two plus years of being remote. They did a great job of involving a lot of folks, some of whom are going to be on the program with us this week that did remote parts of the keynote. One of our guests on today from Vitess was talking about the successes and the graduation of their program so that the sense of community, but also not just the sense of it, the actual demonstration of it was also quite palpable this morning, and I think that's something that I'm excited for us to hear about with our guests on the program this week. >> Yeah, and I think the big story coming out so far as the show starts is the developers are in charge. They're going to set the pace for all the ops, data ops, security ops, all operations. And then the co-located events that were held Monday and Tuesday prior to kickoff today. You saw WebAssembly's come out of the woodwork as it got a lot of attention. Two startups got funded heavily on Series A. You're starting to see that project really work well. That's going to be an additional to the container market. So, interesting to see how Docker reacts to that. Red Hat's doing great. ServiceMeshCon was phenomenal. I saw Solo.iOS got massive traction with those guys. So like Service Mesh, WebAssembly, you can start to see the dots connecting. You're starting to see this layer below Kubernetes and then a layer above Kubernetes developing. So I think it's going to be great for applications and great for the infrastructure. I think we'll see how it comes out and all these companies we have on here are all about faster, more integrated, some very, very interesting to see. So far, so good. >> You guys talked about in your highlight session last week or so. Excited to hear about the end users, the customer stories. That's what I'm interested in understanding as well. It's why it resonates with me when I see brands that I recognize. Well, I use it every day. How are they using containers and Kubernetes? How are they actually not just using it to deploy their app, their technologies, that we all expect are going to be up 24/7, but how are they also contributing to the development of it? So I'm really excited to hear those end users. >> We're going to have Lockheed Martin. And we wrote a story on SiliconANGLE, the Red Hat, Lockheed Martin, real innovation on the edge. You're starting to see educate with the edge. It's really the industrial edge coming to be big. It'd be very interesting to see. >> Absolutely, we got Ford Motor Company coming on as well. I always loved stories, Savannah, that are history of companies. Ford's been around since 1903. How is a company that- >> Well, we're in the home of Ford- as well here. >> We are. How they evolved digitally? What are they doing to enable the developers to be those influencers that John says? It's going to be them. >> They're a great example of a company that's always been on the forefront, too. I mean, they had a head of VRs 25 years ago when most people didn't even know what VR was going to stand for. So, I can't wait for that one. You tease the Docker interview coming up very well, John. I'm excited for that one. One last thing I want to bring up that I think is really refreshing and it's reflected right here on this stage is you talked about the inclusion. I think there's a real commitment to diversity here. You can see the diversity stats on CNCF's website. It's right there on KubeCon. At the bottom, there's a link in every email I've gotten highlighting that. We've got two women on this stage all week which is very exciting. And the opening keynote was a woman. So quite frankly, I am happy as a female in this industry to see a bit more representation. And I do appreciate just on the note of being inclusive, it's not just about gender or age, it's also about the way that CNCF thinks about your experience since we're in this kind of pandemic transitional period. They've got little pins. Last year, we had bracelets depending on your level of comfort. Equivocally like a stoplight which is... I just think it's really nice and sensitive and that attention to detail makes people feel comfortable. Which is why we have the community energy that we have. >> Yeah, and being 12 years in the business... With theCUBE, we've been 12 years in the business, seven years with KubeCon and Cloud Native, I really appreciate the Linux Foundation including me as I get older. (Lisa and Savannah laugh) >> Savannah: That's a good point. >> Ageism were, "Hey!" Thank you. >> There was a lot of representation. You talked about females and so often we go to shows and there's very few females. Some companies are excellent at it. But from an optics perspective, to me it stands out. There was great representation across. There was disabled people on stage, people of color, women, men of all ages. It was very well-orchestrated. >> On the demographic- >> And sincere. >> Yeah, yeah. >> And the demographics, too. On the age side, it's lower too. You're starting to see younger... I mean, high school, college representation. I saw a lot of college students last night. I saw on the agenda sessions targeting universities. I mean, I'm telling you this is reaching down. Open source now is so great. It's growing so fast. It's continuing to thunder away. And with success, it's just getting better and better. In fact, we were talking last night about at some point we might not have to write code. Just glue it together. And that's why I think the supply chain and security thing is an issue. But this is why it's so great. Anyone can code and I think there's a lot of learning to have. So, I think we'll continue to do our job to extract the signal from the noise. So, thanks for the kickoff. Good commentary. Thank you. All right. >> Of course. >> Let's get started. Day one of three days of live coverage here at KubeCon + CloudNativeCon. I'm John Furrier with Lisa Martin, and Savannah Peterson. Be back with more coverage starting right now. (gentle upbeat music)

(upbeat music) >> Welcome back, everyone. Live coverage here at KubeCon + CloudNativeCon here in Detroit, Michigan. I'm John Furrier, your host of theCUBE for special one-on-one conversation with Scott Johnston, who's the CEO of Docker, CUBE alumni, been around the industry, multiple cycles of innovation, leading one of the most important companies in today's industry inflection point as Docker what they've done since they're, I would say restart from the old Docker to the new Docker, now modern, and the center of the conversation with containers driving the growth of Kubernetes. Scott, great to see you. Thanks for coming on theCUBE. >> John, thanks for the invite. Glad to be here. >> You guys have had great success this year with extensions. Docker as a business model's grown. Congratulations, you guys are monetizing well. Pushing up over 50 million. >> Thank you. >> I hear over pushing a hundred million maybe. What the year to the ground will tell me, but it's good sign. Plus you've got the community and nurturing of the ecosystem continuing to power away and open source is not stopping. It's thundering away growth. Younger generation coming in. >> That's right. >> Developer tool chain that you have has become consistent. Almost de facto standard. Others are coming in the market. A lot of competition emerging. You got a lot going on right now. What's going on? >> Well, I know it's fantastic time in our industry. Like all companies are becoming software companies. That means they need to build new applications. That means they need developers to be productive and to be safely productive. And we, and this wonderful CNCF ecosystem are right in the middle of that trend, so it's fantastic. >> So you have millions of developers using Docker. >> Tens of millions. >> Tens of millions of developed Docker and as the market's changing, I was commenting before we came on camera, and I'd love to get your reaction, comment on it. You guys represent the modernization of containers, open source. You haven't really changed how open source works, but you've kind of modernized it. You're starting to see developers at the front lines, more and more power going to developers. >> Scott: That's right. >> They want self-service. They vote with their code. >> That's right. >> They vote with their actions. >> Scott: That's right. >> And if you take digital transformation to its conclusion, it's not IT serves the business or it's a department, the company is IT. >> That's right. >> The company is the application, which means developers are running everything. >> Yes, yes. I mean, one of the jokes, not jokes in the valley is that Tesla is in a car company. Tesla is a computer company that happens to have wheels on the computer. And I think we can smile at that, but there's so many businesses, particularly during COVID, that realize that. What happened during COCID? If you're going to the movies, nope, you're now going to Netflix. If you're going to the gym, now you're doing Peloton. So this realization that like I have to have a digital game, not just on the side, but it has to be the forefront of my business and drive my business. That realization is now any industry, any company across the board. >> We've been reporting aggressively for past three years now. Even now we're calling some things supercloud. If companies, if they don't realize that IT is not a department, they will probably be out of business. >> That's a hundred percent. >> It's going to transform into full on invisible infrastructure. Infrastructure as code, whatever you want to call that going, configuration, operations, developers will set the pace. This has a lot to do with some of your success. You're at the beginning of it. This is just the beginning. What can you talk about that in your mind is contributing to the success of Docker? I know you're going to say team, everything, I get that, but like what specifically in the industry is driving Docker's success right now? >> Well, it did. We did have a fantastic team. We do have a fantastic team and that is one of the reasons, primary reasons our success. But what is also happening, John, is because there's a demand for applications, I'll just throw it out there. 750 million new applications are coming in the market in the next two years. That is more applications that have been developed in the entire 40 years history of IT. So just think about the productivity demands that are coming at developers. And then you also see the need to do so safely, meaning ship quickly, but ship safely. And yet 90 some percent of every application consists of open source components that are now on attack surface for criminals. And so typically our industry has had to say one or the other, okay, you can ship quickly but not safely, or you can ship safely, but it's not going to go fast. And one of the reasons I think Docker is where it is today is that we're able to offer both. We're able to unlock that you can ship quickly, safely using Docker, using the Docker toolchain, using integrations we have with all the wonderful partners here at CNCF that is unique. And that's a big reason why we're seeing the success we're seeing. >> And you're probably pleased with extensions this year. >> Yes. >> The performance of extensions that you launched at DockerCon '22. >> Yes. Well, extensions are part of that story and that developers have multiple tools. They want choice, developers like choice to be productive and Docker is part of that, but it's not the only solution. And so Docker extensions allow the monitoring providers and the observability and if you want a separate Kubernetes stack, like all of that flexibility, extensions allows. And again, offers the power and the innovation of this ecosystem to be used in a Docker development and context. >> Well, I want to get into some of the details of some of your products and how they're evolving. But first I want to get your thoughts on the trend line here that we reported at the opening segment. The hot story is WebAssembly, the Wasm, which really got a lot of traction or interest. People enthous about it. >> Interest, yeah. >> Lot of enthusiasm. Confidence we'll see how that evolves, but a lot of enthusiasm for sure. I've never seen something this hyped up since Envoy, in my opinion. So a lot of interest from developers. What is Wasm or WebAssembly is actually what it is, but Wasm is the codeword or nickname. What is Wasm? >> So in brief, WebAssembly is a new application type, full stop. And it's just enough of the components that you need and it's just a binary format that is very, very secure. And so it's lightweight, it's fast and secure. And so it opens up a lot of interesting use cases for developer, particularly on the edge. Another use case for Wasm is in the browser. Again, lightweight, fast, secure also. >> John: Sounds like an app server to me. >> And so we think it's a very, very interesting trend. And you ask, Okay, what's Docker's role in that? Well, Docker has been around eight years now, eight plus years, tens of millions developers using it. They've already made investments in skills, talent, automation, toolchains, pipelines. And Docker started with Linux containers as we know, then brought that same experience to Windows containers, then brought it to serverless functions. About 25% of Amazon Lambdas are OCI image containers. And so we were seeing that trend. We were also seeing the community actually without any prompting from us, start to fork and play with Docker and apply it to Wasm. And we're like, Huh, that's interesting. What if we helped get behind that trend, such that you changed just one line of a Docker file, now you're able to produce Wasm objects instead of Linux containers and just bring that same easy to use. >> So that's not a competition to Docker's? >> Not a competition at all. In fact, very complimentary. We showed off on Monday at the Wasm day, how in the same Docker compose application, multi-service application. One service is delivered via Linux container, Another service is delivered via Wasm. >> And Wasm is what? Multiple languages? 'Cause what is it? >> Yes. So the binary can be compiled from multiple languages. So RAS, JavaScript, on and on and on. At the end of the day, it's a smaller binary that provides a function, typically a single function that you can stand up and deploy on an edge. You can stand up and deploy on the server side or stand up and deploy on the browser. >> So from a container standpoint, from your customer standpoint, what a Linux container is is a similar thing to what a Wasm container is. >> They could implement the same function. That's right. Now a Linux container can have more capabilities that a function might not have, but that's. >> John: From a workflow standpoint. >> That's right. And that's more of a use case by use case standpoint. What we serve is we serve developers and we started out serving developers with Linux containers, then Windows containers, then Lambdas, now Wasm. Whatever other use case, what other application type comes along, we want to be there to serve developers. >> So one of the things I want to get your thoughts on, because this has come up in a couple CUBE interviews before, and we were talking before we came on camera, is developers want ease of use and simplicity. They don't want more steps to do things. They don't want things harder. >> That's right. So the classic innovation is reduce the time it takes to do something, reduce the steps, make it easier. That's a formula of success. >> Scott: That's right. >> When you start adding more toolchains into the mix, you get tool sprawl. So that's not really, that's antithesis to developer. So the argument is, okay, do I have to use a new tool chain for Wasm? Is that a fact or no? >> That's exactly right. That was what we were seeing and we thought, well, how can Docker help with this situation? And Docker can help by bringing the same existing toolchain that developers are already familiar with. The same automation, the same pipelines. And just by changing a line of Docker file, changing a single line of composed file, now they get the power of Wasm unlocked in the very same tools they were using before. >> So your position is, hey, don't adopt some toolchain for Wasm. You can just do it in line with Docker. >> No need to, no need to. We're providing it right there out of the box, ready for them. >> That's raise and extend, as they would say, build Microsoft strategy there. That's nice. Okay, so let's get back into like the secure trusted 'cause that was another theme at DockerCon. We covered that deeply. Software supply chain, I was commenting on my intro with Savannah and Lisa that at some point open source means so plentiful. You might not have to write code. You got to glue together. So as code proliferates, the question what's in there? >> That's right. This is what they call the software supply chain. You've been all over this. Where are we with this? Is it harder now? Is it easier? Was there progress? Take us through what's the state of the art. I think we're early on this one, John, in the industry because I think the realization of how much open source is inside a given app is just now hitting consciousness. And so the data we have is that for any given application, anywhere from 75 to 85% is actually not unique to the developer or the organization. It's open source components that they have put together. And it's really down to that last 15, 25%, which is their own unique code that they're adding on top of all this open source code. So right there, it's like, aha, that's a pretty interesting profile or distribution of value, which means those open source components, where are they finding them? How are they integrating them? How do they know those open source components are going to be supported and trusted and secured? And that's the challenge for us as an industry right now is to make it just obvious where to get the components, how safe they are, who's standing behind them, and how easy it is to assemble them into a working application. >> All right. So the question that I had specifically on security 'cause this had come up before. All good on the trusted and I think that message is evergreen. It's a north star. That's a north star for you. How are you making images more secure and how are you enabling organizations to identify security issues in containers? Can you share your strategy and thoughts on that particular point? >> Yes. So there's a range of things in the secure software supply chain and it starts with, are you starting with trusted open source components that you know have support, that you know are secured? So in Docker Hub today, we have 14 million applications, but a subset of that, we've worked with the upstream providers to basically designate as trusted open source content. So this is the Docker official images, Docker verified publisher images, Docker sponsored open source. And those different categories have levels of certification assurance that they must go through. Generate an SBOM, so you know what's inside that container. It has to be scanned by a scanning tool and those scanning results have to be made available. >> John: Are you guys scanning that? >> So we provide a scanner, they can use another scanner as long as they publish the results of that scan. And then the whole thing is signed. >> Are you publishing the results on your side too? >> Yeah, we published our results through an open database that's accessible to all. >> Free. >> Free, a hundred percent free. You come in and you can see every image on hub. >> So I'm a user, for free I can see security vulnerabilities that are out there that have been identified. >> By version, by layer, all the way through. And you can see tracking all the way back to the package that's upstream. So you know how to remediate and we provide recommendations on how to remediate that with the latest version. >> John: And you don't charge for that. >> We don't charge for that. We do not charge for that. And so that's the trusted upstream. >> So organization can look at the scan, they can look at the scan data and hopefully, what happens if they're not scanned? >> So we provide scanning tools both for the local environments for Docker Desktop, as well as for hub. So if you want to do your own scan, so for example, when you're that developer adding the 15, 25%, you got to scan your stuff as well. Not just leave it up to the already scanned components. And so we provide tools there. We also provide tools to track the packages that that developer might be including in their custom code, all the way back upstream to whatever MPM repo or what have you that they picked up. And then if there's a CVE 30 days later, we also track that as well. We say, Hey, that package was was safe 29 days ago, but today CVE just came out, better upgrade to the latest version and get that out there. So basically if you get down to it, it's like start with trusted components and then have observability not just on the moment. >> And scan all the time. >> Scan all the time and scanning gives you that observability and importantly not just at that moment, but through the lifecycle of the application, through lifecycle of the artifact. So end-to-end 24/7 observability of the state of your supply chain. That's what's key, John. >> That's the best practice. >> That's the key. That's the key. >> Awesome, I agree. That's great. Well, I'm glad we've dug into that's super important. Obviously organizations can get that scanning that's exceed the vulnerabilities, that can take action. That's going to be a big focus here for you, security. It's not going to stop, is it? >> It's never going to stop because criminals are incentive to keep attacking. And so it's the gift that keeps on giving, if you will. >> Okay, so let's get into some of the products. Docker Desktop seems to be doing well. Docker Hub has always been a staple of it. And how's that going? >> Yeah, Docker Hub has 18 million monthly actives hitting it and that's growing by double digits year over year. And what they're finding, going back to our previous thread, John, is that they're coming there for the trusted content. In fact, those three categories that I referenced earlier are about 2000 applications of the 14 million. And yet they represent 56% of the 15 billion downloads a month from Docker Hub. Meaning developers are identifying that, hey, I want trusted source. We raise those in the search results and we have a visual cue. And so that's the big driver of hub's growth right now, is I want trusted content, where do I go? I go to Hub, download that trusted open source and I'm ready to go. >> I have been seeing some chatter on the internet and some people's sharing that they're looking at other places, besides hub, to do some things. What's your message to folks out there around Docker Hub? Why Docker Hub and desktop together? 'Cause you mentioned the toolchain before, but those two areas, I know they've been around for a while, you continue to work on them. What's the message to the folks out there about stay with the hub? >> Sure. I mean the beauty of our ecosystem is that it's interoperable. The standards for build, share and run, we're all using them here at CNCF. So yes, there's other registries. What we would say is we have the 18 million monthly active that are pulling, we have the worldwide distribution that is 24/7 high, five nines reliability, and frankly, we're there to provide choice. And so yes, we have have our trusted content, but for example, the Tanzu apps, they also distribute through us. Red Hat applications also distribute through us because we have the reach and the distribution and offer developers choice of Dockers content, choice of Red Hats content, choice of VMware's, choice of Bitnami, so on so forth. So come to the hub for the distribution to reach and that the requirements we have for security that we put in place for our publishers, give users and publishers an extra degree of assurance. >> So the Docker Hub is an important part of the system? >> Scott: Yes, very much so. >> And desktop, what's new with desktop? >> So desktop of course is the other end of the spectrum. So if trusted components start up on Docker Hub, developers are pulling them down to the desktop to start assembling their application. And so the desktop gives that developer all the tools he or she needs to build that modern application. So you can have your build tooling, your debug tooling, your IDE sitting alongside there, your Docker run, your Docker compose up. And so the loop that we see happening is the dev will have a database they download from hub, a front-end, they'll add their code to it and they'll just rapidly iterate. They'll make a change, stand it up, do a unit test, and when they're satisfied do a git commit, off it goes into production. >> And your goal obviously is to have developers stay with Docker for their toolchain, their experience, make it their home base. >> And their trusted content. That's right. And the trusted content and the extensions are part of that. 'Cause the extensions provide complimentary tooling for that local experience. >> You guys have done an amazing job. I want to give you personal props. I've been following Docker from the beginning when they had the pivot, they sold the enterprise to Mirantis, went back to the roots, modernized, riding the wave. You guys are having a good time. I got to ask the question 'cause people always want to know 'cause open source is about transparency. How you guys making your money? Business is good. How's that work and what was the lucky, what was the not lucky strike, but what was the aha moment? What was the trigger that just made you just kick in this new monetization growth wave? >> So the monetization is per seat, per developer seat. And that changed in November 2019. We were pricing on the server side before, and as you said, we sold that off. And what changed is some of the trends we were talking about that the realization by all organizations that they had to become software companies. And Docker provided the productivity in an engineered desktop product and the trusted content, it provided the productivity safely to developers. And frankly then we priced it at a rate that is very reasonable from an economic standpoint. If you look at developer productivity, developers are paid anywhere from 150 to 300 to 400, 500,000 even higher. >> But when you're paying your developers that much, then productivity is a premium. And what we were asking for from companies from a licensing standpoint was really a modest relative to the making those developers product. >> It's not like Oracle. I mean talk about extracting the value out of the customer. But your point is your positioning is always stay quarter of the open source, but for companies that adopt the structural change to be developer first, a software company, there's a premium to pay because you devalue there. >> And need the tooling to roll it out at scales. So the companies are paying us. They're rolling it out to tens of thousand developers, John. So they need management, they need visibility, they need guardrails that are all around the desktop. So, but just to put a stat on it, so to your point about open source and the freemium wheel working, of our 13 million Docker accounts, 12 are free, about a million are paid for accounts. And that's by design because the open source. >> And you're not gouging developers per se, it's just, not gouging anyone, but you're not taking money out of their hands. It's the company. >> If the company is paying for their productivity so that they can build safely. >> More goodness more for the developer. >> That's right. That's right. >> Gouging would be more like the Oracle strategy. Don't comment. You don't need to comment. I keep saying that, but it's not like you're taxing. It's not a heavy. >> No, $5 a month, $9 a month, $24 a month depending on level. >> But I think the big aha to me and in my opinion is that you nailed the structural change culturally for a company. If they adopt the software ecosystem approach for transforming their business, they got to pay for it. So like a workflow, it's a developer. >> It's another tool. I mean, do they pay for their spreadsheet software? Do they pay for their back office ERP software? They do >> That's my point. >> to make those people popular or sorry, make those people successful, those employees successful. This is a developer tool to make developer successful. >> It's a great, great business model. Congratulations. What's next for you guys? What are you looking for? You just had your community events, you got DockerCon coming up next year. What's on the horizon for you? Put a plugin for the company. What are you looking for? Hiring? >> Yeah, so we're growing like gangbusters. We grew from 60 with the reset. We're now above 300 and we're continuing to grow despite this economic climate. Like our customers are very much investing in software capabilities. So that means they're investing in Docker. So we're looking for roles across the board, software engineers, product managers, designers, marketing, sales, customer success. So if you're interested, please reach out. The next year is going to be really interesting because we're bringing to market products that are doubling down on these areas, doubling down a developer productivity, doubling down on safety to make it even more just automatic that developers just build so they don't have to think about it. They don't need a new tool just to be safer. We hinted a bit about automating SBOM creation. You can see more of that pull through. And in particular, developers want to make the right decision. Everyone comes to work wanting to make the right decision. But what they often lack is context. They often lack like, well, is this bit of code safe or not? Or is this package that I just downloaded over here safe or not? And so you're going to see us roll out additional capabilities that give them very explicit contextual guidance of like, should you use this or not? Or here's a better version over here, a safer version over there. So stay tuned for some exciting stuff. >> It's going to be a massive developer growth wave coming even bigger we've ever seen. Final questions just while I got you here. Where do you see WebAssembly, Wasm going? If you had to throw a dart at the board out a couple years, what does it turn into? >> Yeah, so I think it's super exciting. Super exciting, John. And there's three use cases today. There's browser, there's edge, and there's service side in the data center of the cloud. We see the edge taking off in the next couple years. It's just such a straight line through from what they're doing today and the value that standing up a single service on the edge go. The service side needs some work on the Wasm runtime. The Wasm runtime is not multi-threaded today. And so there's some deep, deep technical work that's going on. The community's doing a fantastic job, but that'll take a while to play through. Browsers also making good progress. There's a component model that Wasm's working on that'll really ignite the industry. That is going to take another couple years as well. So I'd say let's start with the edge use case. Let's get everyone excited about that value proposition. And these other two use cases will come along. >> It'll all work itself out in the wash as open source always does. Scott Johnston, the Chief Executive Officer at Docker. Took over at the reset, kicking butt and taking names. Congratulations. You guys are doing great. Continue to power the developer movement. Thanks for coming on. >> John, thanks so much. Pleasure to be here. >> We're bringing you all the action here. Extracting the signal from the noise. I'm John Furrier, day one of three days of wall-to-wall live coverages. We'll be back for our next guest after this short break. (gentle music)

(upbeat music) >> Hello, everyone. Welcome to theCUBE here, in Palo Alto, California for a Cube Conversation. I'm John Furrier, host of theCUBE. This is a KubeCon preview conversation. We got a great guest here, in studio, Madhura Maskasky, Co-Founder and VP of Product, Head of Product at Platform9. Madhura, great to see you. Thank you for coming in and sharing this conversation about, this cube conversation about KubeCon, a Kubecon conversation. >> Thanks for having me. >> A light nice play on words there, a little word play, but the fun thing about theCUBE is, we were there at the beginning when OpenStack was kind of on its transition, Kubernetes was just starting. I remember talking to Lou Tucker back in, I think Seattle or some event and Craig McLuckie was still working at Google at the time. And Google was debating on putting the paper out and so much has happened. Being present at creation, you guys have been there too with Platform9. Present at creation of the Kubernetes wave was not obvious only a few insiders kind of got the big picture. We were one of 'em. We saw this as a big wave. Docker containers at that time was a unicorn funded company. Now they've went back to their roots a few years ago. I think four years ago, they went back and recapped and now they're all pure open source. Since then Docker containers and containers have really powered the Kubernetes wave. Combined with the amazing work of the CNCF and KubeCon which we've been covering every year. You saw the maturation, you saw the wave, the early days, end user projects being contributed. Like Envoy's been a huge success. And then the white spaces filling in on the map, you got observability, you've got run time, you got all the things, still some white spaces in there but it's really been great to watch this growth. So I have to ask you, what do you expect this year? You guys have some cutting edge technology. You got Arlo announced and a lot's going on Kubernetes this year. It's going mainstream. You're starting to see the traditional enterprises embrace and some are scaling faster than others, manage services, plethora of choices. What do you expect this year at KubeCon North America in Detroit? >> Yeah, so I think you summarize kind of that life cycle or lifeline of Kubernetes pretty well. I think I remember the times when, just at the very beginning of Kubernetes, after it was released we were sitting I think with box, box dot com and they were describing to us why they are early adopters of Kubernetes. And we were just sitting down taking notes trying to understand this new project and what value it adds, right? And then flash forward to today where there are Dilbert strips written about Kubernetes. That's how popular it has become. So, I think as that has happened, I think one of the things that's also happened is the enterprises that adopted it relatively early are running it at a massive scale or looking to run it at massive scale. And so I think at scale cloud-native is going to be the most important theme. At scale governance, at scale manageability are going to be top of the mind. And the third factor, I think that's going to be top of the mind is cost control at scale. >> Yeah, and one of the things that we've seen is that the incubated projects a lot more being incubated now and you got the combination of end user and company contributed open source. You guys are contributing RLO >> RLO. >> and open source. >> Yeah. >> That's been part of your game plan there. So you guys are no stranger open source. How do you see this year's momentum? Is it more white space being filled? What's new coming out of the block? What do you think is going to come out of this year? What's rising in terms of traction? What do you see emerging as more notable that might not have been there last year? >> Yeah, so I think it's all about filling that white space, some level of consolidation, et cetera. That's usually the trend in the cloud-native space. And I think it's going to continue to be on that and it's going to be tooling that lets users simplify their lives. Now that Kubernetes is part of your day to day. And so it is observability, et cetera, have always been top of the mind, but I think starting this year, et cetera it's going to be at the next level. Which is gone other times of just running your Prometheus at individual cluster level, just to take that as an example. Now you need a solution- >> Yep. >> that operates at this massive scale across different distributions and your edge locations. So, it's taking those same problems but taking them to that next order of management. >> I'm looking at my notes here and I see orchestration and service mesh, which Envoy does. And you're seeing other solutions come out as well like Linkerd and whatnot. Some are more popular than others. What areas do you see are most needed? If you could go in there and be program chair for a day and you've got a day job as VP of product at Platform9. So you kind of have to have that future view of the roadmap and looking back at where you've come, what would you want to prioritize if you could bring your VP of product skills to the open source and saying, hey, can I point out some needs here? What would you say? >> Yeah, I think just the more tooling that lets people make sense and reduce some of the chaos that this prowling ecosystem of cloud-native creates. Which is tooling, that is not adding more tooling that covers white space is great, but introducing abilities that let you better manage what you have today is probably absolutely top of the mind. And I think that's really not covered today in terms of tools that are around. >> You know, I've been watching the top five incubated projects in CNCF, Argo cracked the top five. I think they got close to 12,000 GitHub stars. They have a conference now, ArgoCon here in California. What is that about? >> Yeah. >> Why is that so popular? I mean, I know it's kind of about obviously workflows and dealing with good pipeline, but why is that so popular right now? >> I think it's very interesting and I think Argo's journey and it's just climbed up in terms of its Github stars for example. And I think it's because as these scale factors that we talk about on one end number of nodes and clusters growing, and on the other end number of sites you're managing grows. I think that CD or continuous deployment of applications it used to kind of be something that you want to get to, it's that north star, but most enterprises wouldn't quite be there. They would either think that they're not ready and it's not needed enough to get there. But now when you're operating at that level of scale and to still maintain consistency without sky rocketing your costs, in terms of ops people, CD almost becomes a necessity. You need some kind of manageable, predictable way of deploying apps without having to go out with new releases that are going out every six months or so you need to do that on a daily basis, even hourly basis. And that's why. >> Scales the theme again, >> Yep. >> back to scale. >> Yep. >> All right, final question. We'll wrap up this preview for KubeCon in Detroit. Whereas we start getting the lay of the land and the focus. If you had to kind of predict the psychology of the developer that's going to be attending in person and they're going to have a hybrid event. So, they will be not as good as being in person. Us, it's going to be the first time kind of post pandemic when I think everyone's going to be together in LA it was a weird time in the calendar and Valencia was the kind of the first international one but this is the first time in North America. So, we're expecting a big audience. >> Mhm. >> If you could predict or what's your view on the psychology of the attendee this year? Obviously pumped to be back. But what do you think they're going to be thinking about? what's on their mind? What are they going to be peaked on? What's the focus? Where will be the psychology? Where will be the mindset? What are people going to be looking for this year? If you had to make a prediction on what the attendees are going to be thinking about what would you say? >> Yeah. So there's always a curiosity in terms of what's new, what new cool tools that are coming out that's going to help address some of the gaps. What can I try out? That's always as I go back to my development roots, first in mind, but then very quickly it comes down to what's going to help me do my job easier, better, faster, at lower cost. And I think again, I keep going back to that theme of automation, declarative automation, automation at scale, governance at scale, these are going to be top of the mind for both developers and ops teams. >> We'll be there covering it like a blanket like we always do from day one, present at creation at KubeCon we are going to be covering again for the consecutive year in a row. We love the CNCF. We love what they do. We thank the developers this year, again continue going mainstream closer and closer to the front lines as the company is the application. As we say, here on theCUBE we'll be there bringing you all the signal. Thanks for coming in and sharing your thoughts on KubeCon 2022. >> Thank you for having me. >> Okay. I'm John Furrier here in theCUBE in Palo Alto, California. Thanks for watching. (upbeat music)

>> Narrator: The cube presents, the Kubecon and Cloudnativecon Europe, 2022 brought to you by Red Hat, the cloud native computing foundation and its ecosystem partners. >> Welcome to Valencia, Spain in Kubecon and Cloudnativecon Europe, 2022. I'm your host Keith Townsend. It's been a amazing day, three days of coverage 7,500 people, 170 sponsors, a good mix of end user organizations, vendors, just people with open source at large. I've loved the conversations. We're not going to stop that coverage just because this is the last session of the conference. Colin Murphy, senior software engineer, Adobe, >> Adobe. >> Oh, wow. This is going to be fun. And then Liam Randall, the chair of CNCF Cloud Native WebAssembly Day. >> That's correct. >> And CNCF & CEO of Cosmonic. >> That's right. >> All right. First off, let's talk about the show. How has this been different than other, if at all of other Kubecons? >> Well, first I think we all have to do a tremendous round of applause, not only for the vendors, but the CNC staff and all the attendees for coming out. And you have to say, Kubecon is back. The online experiences have been awesome but this was the first one, where Hallwaycon was in full effect. And you had the opportunity to sit down and meet with so many intelligent and inspiring peers and really have a chance to learn about all the exciting innovations that have happened over the last year. >> Colin. >> Yeah, it's been my most enjoyable Kubecon I've ever been to. And I've been to a bunch of them over the last few years. Just the quality of people. The problems that we're solving right now, everywhere from this newer stuff that we're talking about today with WebAssembly but then all these big enterprises trying to getting involved in Kubernetes >> Colin, to your point about the problems that we're solving, in many ways the pandemic has dramatically accelerated the pace of innovation, especially inside the CNCF, which is by far the most critical repository of open source projects that enterprises, governments and individuals rely on around the world, in order to deliver new experiences and to have coped and scaled out within the pandemic over the last few years. >> Yeah, I'm getting this feel, this vibe of the overall show that feels like we're on the cuff for something. There's other shows throughout the year, that's more vendor focused that talk about cloud native. But I think this is going to be the industry conference where we're just getting together and talking about it and it's going to probably be, in the next couple of years, the biggest conference of the year, that's just my personal opinion. >> I actually really strongly agree with you. And I think that the reason for that is the diversity that we get from the open source focus of Kubecon Kubecon has started where the industry really started which was in shared community projects. And I was the executive at Capital One that led the donation of cloud custodian into the CNCF. And I've started and put many projects here. And one of the reasons that you do that is so that you can build real scalable communities, Vendors that oftentimes even have competing interest but it gives us a place where we can truly collaborate where we can set aside our personal agendas and our company's agendas. And we can focus on the problems at hand. And how do we really raise the bar for technology for everybody. >> Now you two are representing a project that, you know as we look at kind of, how the web has evolved the past few decades, there's standards, there's things that we know that work, there's things that we know that don't work and we're beyond cloud native, we're kind of resistant to change. Funny enough. >> That's right. >> So WebAssembly, talk to me about what problem is WebAssembly solving that need solving? >> I think it's fitting that here on the last day of Kubecon, we're starting with the newest standard for the web and for background, there's only four languages that make up what we think of as the modern web. There's JavaScript, there's HTML, there's CSS, and now there's a new idea that's WebAssembly. And it's maybe not a new idea but it's certainly a new standard, that's got massive adoption and acceleration. WebAssembly is best thought of as almost like a portable little virtual machine. And like a lot of great ideas like JavaScript, it was originally designed to bring new experiences to browsers everywhere. And as organizations looked at the portability and security value props that come from this tiny little virtual machine, it's made a wonderful addition to backend servers and as a platform for portability to bring solutions all the way out to the edge. >> So what are some of the business cases for WebAssembly? Like what problem, what business problem are we solving? >> So it, you know, we would not have been able to bring Photoshop to the web without WASM. >> Wow. >> And just to be clear, I had nothing to do with that effort. So I want to make sure everybody understands, but if you have a lot of C++ or C code and you want to bring that experience to the web browser which is a great cost savings, cause it's running on the client's machines, really low latency, high performance experiences in the browser, WASM, really the only way to go. >> So I'm getting hints of fruit berry, Java. >> Liam: Yeah, absolutely. >> Colin: Definitely. >> You know, the look, WebAssembly sounds similar to promises you've heard before, right ones, run anywhere. The difference is, is that WebAssembly is not driven by any one particular vendor. So there's no one vendor that's trying to bring a plug in to every single device. WebAssembly was a recognition, much like Kubecon, the point that we started with around the diversity of thought ideas and representation of shared interest, of how do we have a platform that's polyglot? Many people can bring languages to it, and solutions that we can share and then build from there. And it is unlocking some of the most amazing and innovative experiences, both on the web backend servers and all the way to the edge. Because WebAssembly is a tiny little virtual machine that runs everywhere. Adobe's leadership is absolutely incredible with the things that they're doing with WebAssembly. They did this awesome blog post with the Google Chrome team that talked about other performance improvements that were brought into Chrome and other browsers, in order to enable that kind of experience. >> So I get the general concept of WebAssembly and it's one of those things that I have to ask the question, and I appreciate that Adobe uses it but without the community, I mean, I've dedicated some of my team's resources over the years to some really cool projects and products that just died on the buying cause there was no community around. >> Yeah. >> Who else uses WebAssembly? >> Yeah, I think so. We actually, inside the CNCF now, have an entire day devoted just to WebAssembly and as the co-chair of the CNCF Cloud Native WebAssembly Day, we really focus on bringing those case studies to the forefront. So some of the more interesting talks that we had here and at some of the precursor weekend conferences were from BMW, for example, they talked about how they were excited about not only WebAssembly, but a framework that they use on WebAssembly called WASM cloud, that lets them a flexibly scale machine learning models from their own edge, in their own vehicles through to their developer's workstations and even take that data onto their regular cloud Kubernetes and scale analysis and analytics. They invested and they just released a machine learning framework for one of the many great WebAssembly projects called WASM cloud, which is a CNCF project, a member project here in the CNCF. >> So how does that fit in overall landscape? >> So think of WebAssembly, like you think of HTML. It's a technology that gives you a lot of concept and to accelerate your journey on those technologies, people create frameworks. For example, if you were going to write a UI, you would not very likely start with an empty document you'd start with a react or view. And in a similar vein, if you were going to start a new microservice or backend application, project for WebAssembly, you might use WASM cloud or you might use ATMO or you might use a Spin. Those are three different types of projects. They all have their own different value props and their own different opinions that they bring to them. But the point is is that this is a quickly evolving space and it's going to dramatically change the type of experiences that we bring, not only to web browsers but to servers and edges everywhere. >> So Colin, you mentioned C+ >> Colin: Yeah. >> And other coding. Well , talk to me about the ramp up. >> Oh, well, so, yeah, so, C++ there was a lot of work done in scripting, at Adobe. Taking our C++ code and bringing it into the browser. A lot of new instructions, Cimdi, that were brought to make a really powerful experience, but what's new now is the server side aspect of things. So, just what kind of, what Liam was talking about. Now we can run this stuff in the data center. It's not just for people's browsers anymore. And then we can also bring it out to the edge too, which is a new space that we can take advantage of really almost only through WebAssembly and some JavaScript. >> So wait, let me get this kind of under hook. Before, if I wanted a rich experience, I have to run a heavy VDI instance on the back end so that I'm basically getting remote desktop calls from a light thin client back to my backend server, that's heavy. >> That is heavy. >> WebAssembly is alternative to that? >> Yes, absolutely. Think of WebAssembly as a tiny little CPU that is a shim, that we can take the places that don't even traditionally have a concept of a processor. So inside the browser, for example, traditionally cloud native development on the backend has been dominated by things like Docker and Docker is a wonderful technology and Container is a wonderful technology that really drove the last 10 years of cloud native with the great lift and shift, if you will. Take our existing applications, package them up in this virtual desktop and then deliver them. But to deliver the next 10 years of experiences, we need solutions that let us have portability first and a security model that's portable across the entire landscape. So this isn't just browsers and servers on the back end, WebAssembly creates an a layer of equality from truly edge to edge. It's can transcend different CPUs, different operating systems. So where containers have this lower bound off you need to be running Linux and you need to be in a place where you're going to bring Kubernetes. WebAssembly is so small and portable, it transcends that lower bound. It can go to places like iOS. It can go to places like web browsers. It can even go to teeny tiny CPUs that don't even traditionally have a full on operating systems inside them. >> Colin: Right, places where you can't run Docker. >> So as I think about that, and I'm a developer and I'm running my back end and I'm running whatever web stack that I want, how does this work? Like, how do I get started with it? >> Well, there's some great stuff Liam already mentioned with WASM cloud and Frmion Spin. Microsoft is heavily involved now on providing cloud products that can take advantage of WebAssembly. So we've got a lot of languages, new languages coming in.net and Ruby, Rust is a big one, TinyGo, really just a lot of places to get involved. A lot of places to get started. >> At the highest level Finton Ryan, when he was at Gartner, he's a really well known analyst. He wrote something profound a few years ago. He said, WebAssembly is the one technology, You don't need a strategy to adopt. >> Mm. >> Because frankly you're already using it because there's so many wonderful experiences and products that are out there, like what Adobe's doing. This virtual CPU is not just a platform to run on cloud native and to build applications towards the edge. You can embed this virtual CPU inside of applications. So cases where you would want to allow your users to customize an application or to extend functionality. Give you an example, Shopify is a big believer in WebAssembly because while their platform covers, two standard deviations or 80% of the use cases, they have a wonderful marketplace of extensions that folks can use in order to customize the checkout process or apply specialized discounts or integrate into a partner ecosystem. So when you think about the requirements for those scenarios, they line up to the same requirements that we have in browsers and servers. I want real security. I want portability. I want reuseability. And ultimately I want to save money and go faster. So organizations everywhere should take a few minutes and do a heads up and think about one, where WebAssembly is already in their environment, inside of places like Envoy and Istio, some of the most popular projects in the cloud native ecosystem, outside of Kubernetes. And they should perhaps consider studying, how WebAssembly can help them to transform the experiences that they're delivering for their customers. This may be the last day of Kubecon, but this is certainly not the last time we're going to be talking about WebAssembly, I'll tell you that. >> So, last question, we've talked a lot about how to get started. How about day two, when I'm thinking about performance troubleshooting and ensuring clients have a great experience what's day two operation like? >> That's a really good question. So there's, I know that each language kind of brings their own tool chain and their, and you know we saw some great stuff on, on WASM day. You can look it up around the .net experience for debugging, They really tried to make it as seamless and the same as it was for native code. So, yeah, I think that's a great question. I mean, right now it's still trying to figure out server side, It's still, as Liam said, a shifting landscape. But we've got some great stuff out here already >> You know, I'd make an even bigger call than that. When I think about the last 20 years as computing has evolved, we've continued to move through these epics of tech that were dominated by a key abstraction. Think about the rise of virtualization with VMware and the transition to the cloud. The rise of containerization, we virtualized to OS. The rise of Kubernetes and CNCF itself, where we virtualize cloud APIs. I firmly believe that WebAssembly represents the next epic of tech. So I think that day two WebAssembly continues to become one of the dominant themes, not only across cloud native but across the entire technical computing landscape. And it represents a fundamentally gigantic opportunity for organizations such as Adobe, that are always market leading and at the cutting edge of tech, to bring new experiences to their customers and for vendors to bring new platforms and tools to companies that want to execute on that opportunity. >> Colin Murphy, Liam Randall, I want to thank you for joining the Cube at Kubecon Cloudnativecon 2022. I'm now having a JavaScript based app that I want to re-look at, and maybe re-platforming that to WebAssembly. It's some lot of good stuff there. We want to thank you for tuning in to our coverage of Kubecon Cloudnativecon. And we want to thank the organization for hosting us, here from Valencia, Spain. I'm Keith Townsend, and you're watching the Cube, the leader in high tech coverage. (bright music)

(upbeat music) >> Narrator: theCUBE presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain, in KubeCon, CloudNativeCon Europe 2022. It's near the end of the day, that's okay. We have plenty of energy because we're bringing it. I'm Keith Townsend, along with my cohost, Paul Gillon. Paul, this has been an amazing day. Thus far we've talked to some incredible folks. You got a chance to walk the show floor. >> Yeah. >> So I'm really excited to hear what's the vibe of the show floor, 7,500 people in Europe, following the protocols, but getting stuff done. >> Well, at first I have to say that I haven't traveled for two years. So getting out to a show by itself is an amazing experience. But a show like this with all the energy and the crowd too, enormously crowded at lunchtime today. It's hard to believe how many people have made it all the way here. Out on the floor the booth are crowded, the demonstrations are what you would expect at a show like this. Lots of code, lots of block diagrams, lots of architecture. I think the audience is eating it up. They're on their laptops, they're coding on their laptops. And this is very much symbolic of the crowd that comes to a KubeCon. And it's just a delight to see them out here having so much fun. >> So speaking of lots of code, we have Varun Talwar, co-founder of Tetrate. But, I just saw I didn't realize this, Istio becoming part of CNCF. What's the latest on Istio? >> Yeah, Istio is, it was always one of those service mesh projects which was very widely adopted. And it's great to see it going into the Cloud Native Computing Foundation. And, I think what happened with Kubernetes like just became the de-facto container orchestrator. I think similar thing is happening with Istio and service mesh. >> So. >> I'm sorry, go ahead Keith. What's the process like of becoming adopted by and incubated by the CNCF? >> Yeah, I mean, it's pretty simple. It's an application process into the foundation where you say, what the project is about, how diverse is your contributor base, how many people are using it. And it goes through a review of, with TOC, it goes through a review of like all the users and contributors, and if you see a good base of deployments in production, if you see a diverse community of contributors, then you can basically be part of the CNCF. And as you know, CNCF is very flexible on governance. Basically it's like bring your own governance. Then the projects can basically seamlessly go in and get into incubation and gradually graduate. >> Another project close and dear to you, Envoy. >> Yes. >> Now I've always considered Envoy just as what it is. It's a, I've always used it as a low balancer type thing. So, I've always considered it some wannabe gateway of proxy. But Envoy gateway was announced last week. >> Yes. So Envoy is, basically won the data plane war of in cloud native workloads, right? And, but, and this was over the last five years. Envoy was announced even way before Istio, and it is used in various deployment models. You can use it as a front load balancer, you can use it as an ingress in Kubernetes, you can use it as a side car in a service mesh like Istio. And it's lightweight, dynamically programmable, very open with the right community. But, what we looked at when we looked at the Envoy base was, it still wasn't very approachable for application developers. Like, when you still see like the nouns that it uses in terms of clusters and so on is not what an application developer was used to. And, so Envoy gateway is really an effort to make Envoy even more stronger out of the box for an application developer to use it as an API gateway, right? Because if you think about it, ultimately people, developers, start deploying workloads onto their Kubernetes clusters, they need some functionality like an API gateway to expose their services and you want to make it really, really easy and simple, right? I often say like, what Engine X was to like static websites, like Envoy gateway will be to like APIs. And it's really, the community coming together, we are a big part, but also VMware, and as well as end users, like in this case Fidelity, who is investing heavily into Envoy and API gateway use cases, joining forces saying, let's do this in upstream Envoy. >> I'd like to go back Istio, because this is a major step in Istio's development. Where do you see Istio coming into the picture? And Kubernetes is already broadly accepted, is Istio generally adopted as an after, an after step to Kubernetes, or are they increasingly being adopted together? >> Yeah. So, usually it's adopted as a follow on step. And, the reason is, primarily the learning curve, right? It's just to get used to all the Kubernetes and, it takes a while for people to understand the concepts, get applications going, and then, Istio was made to basically solve, three big problems there, right? Which is around, observability, traffic management, and security, right? So as people deploy more services they figure out, okay, how do I connect them? How do I secure all the connections? And how do I do more fine grain routing? I'm doing more frequent deployments with Kubernetes, but I would like to do canary releases, to make safer roll outs, right? And those are the problems that Istio solves. And I don't really want to know the metrics of like, yes, it'll be, it's good to know all the node level, and CPO level metrics, but really what I want to know is, how are my services performing? Where is the latency, right? Where is the error rate? And those are the things that Istio gives out of the box. So that's like a very natural next step for people using Kubernetes. And, Tetrate was really formed as a company to enable enterprises to adopt Istio, Envoy, and service mesh in their environment, right? So we do everything from, run an academy for like courses and certifications on Envoy and Istio, to a distribution, which is, compliant with various rules and tooling, as well as a whole platform on top of Istio, to make it usable in deployment in a large enterprise. >> So paint the end to end for me for Istio and Envoy. I know they can be used in similar fashions as like side cars, but how do they work together to deliver value? >> Yeah. So if you step back from technology a little bit, right? And you make sort of, look at what customers are doing and facing, right? Really it is about, they have applications, they have some applications that new workloads going into Kubernetes and cloud native, they have a lot of legacy workloads, a lot of workloads in VMs, and with different teams in different clouds or due to acquisitions, they're very heterogeneous, right? Now our mission, Tetrate's mission is power the world's application traffic. But really the business value that we are going after is consistency of application operations, right? And I'll tell you how powerful that is. Because the more places you can deploy Envoy into, the more places you can deploy Istio into, the more consistency you can get for the value pillars of observability, traffic management, and security, right? And really if you think about what is the journey for an enterprise to migrate from VM workloads into Kubernetes, or from data centers into cloud, the challenges are around security and connectivity, right? Because if it's Kubernetes fabric, the same Kubernetes app and data center can be deployed exactly as it is in cloud, right? >> Keith: Right. >> So why is it hard to migrate to cloud, right? The challenges come in the security and networking layer, right? >> So let's talk about that with some granularity and you can maybe give me some concrete examples. >> Right. >> Because as I think about the hybrid infrastructure, where I have VMs on-premises, cloud native stuff running in the public cloud or even cloud native next to VMs. >> Varun: Right. >> I do security differently when I'm in the VM world. I say, you know what? This IP address can't talk to this Oracle database server. >> Right. >> Keith: That's not how cloud native works. >> Right. >> I can't say, if I have a cloud native app talking to a Oracle database, there's no IP address. >> Yeah. >> Keith: But how do I secure the communication between the two? >> Exactly. So I think you hit it, well, straight on the head. So which is, with things like Kubernetes IP is no longer a really a valid noun, where you can say because things will auto scale either from Kubernetes or the cloud autoscalers. So really the noun that is becoming now is service. So, and I could have many instances of it. They could, will scale up and down. But what I'm saying is, this service, which you know some app server, some application can talk to the Oracle service. >> Keith: Hmm. >> And what we have done with the Tetrate Service Bridge which is why we call our platform service bridge, because it's all about bridging all the services, is whatever you're running on the VM can be onboarded onto the mesh, like as if it were a Kubernetes service, right? And then my policy around this service can talk to this service, is same in Kubernetes, is same for Kubernetes talking to VM, it's same for VM to VM, both in terms of access control. In terms of encryption what we do is, because it's, the Envoy proxy goes everywhere and the traffic is going through them we actually take care of distributing certs, encrypting everything, and it becomes, and that is what leads to consistent application operations. And that's where the value is. >> We're seeing a lot of activity around observability right now, a lot of different tools, both open source and proprietary Istio, certainly part of the open telemetry project, and I believe you're part of that project? >> Yes. >> But the customers are still piecing together a lot of tools on their own. >> Right. >> Do you see a more coherent framework forming around observability? >> I think very much so. And there are layers of observability, right? So the thing is, like if we tell you there is latency between these two services at L seven layer, the first question is, is it the service? Is it the Envoy? Or is it the network? It sounds like a very simple question. It's actually not that easy to answer. And that is one of the questions we answer in like platforms like ours, right? But even that is not the end. If it's neither of these three, it could be the node, it could be the hardware underneath, right? And those, you realize like those are different observability tools that work on each layer. So I think there's a lot of work to be done to enable end users to go from IP, like from top to bottom, to make, reduce what is called MPTR or meantime to, resolution of an issue where is the problem. But I think with tools like what is being built now, it is becoming easier, right? It is because, one of the things we have to realize is with things like Kubernetes we made the development of microservices easier, right? And that's great, But as a result, what is happening is that more things are getting broken down. So there is more network in between. So there's, harder it gets to troubleshoot, harder it gets to secure everything, harder it gets to get visibility from everywhere, right? So I often say like, actually if you're going, embarking down microservices journey, you actually are... You better have a platform like this. Otherwise, you're taking on operational cost. >> Wow, Jevons paradox, the more accessible we make something, the more it get used, the more complex it is. That's been a theme here at KubecCon, CloudNativeCon Europe 2022, from Valencia, Spain. I'm Keith Townsend, along with my cohost Paul Gillon. And you're watching theCUBE, the leader in high tech coverage. (upbeat music)

>>The cube presents, Coon and cloud native con Europe, 22 brought to you by the cloud native computing foundation. >>Welcome to ity of Spain and cube con coup con cloud native con Europe 2022 is near the end of the day. That's okay. We, we, we have plenty of energy because we're bringing it. I'm Keith Townsend, along with my coho, Paul Gillon Paul, this has been an amazing day. Thus far. We've talked to some incredible folks. You got a chance to walk the show floor. Yeah. So I'm really excited to hear what's the vibe of the show floor, 7,500 people in Europe following the protocols, but getting stuff done. >>Well, first I have to say that I haven't traveled for two years. So getting out to a show by, by itself is, is an amazing experience, but a show like this with all of the energy and the crowd, she is enormously crowded at lunchtime today. It's hard to believe how many people have made it, made it all the way here out on the floor. The boots are crowded. The, the demonstrations are what you would expect at a show like this. Lots of code, lots of, lots of block diagrams, lots of architecture. I think the audience is eating it up. You know, when they're, they're on their laptops, they're coding on their laptops. And this is very much symbolic of the crowd that comes to a cubic con. And it's, it's a, just a delight to see them outta here. I so much fun. >>So speaking of lots of gold, we have Bome Toro co-founder of pet trade, but, you know, just saw, didn't realize this Isto becoming part of CNCF was the latest on infield. >>Yeah. Is still is, you know, it was always one of those service mesh projects, which was very widely adopted. And it's great to see that going into the cloud native computing foundation. And I think what happened with Kubernetes, like just became the defacto container orchestrator. I think similar thing is happening with Isto and service mesh. >>What, >>So I'm sorry, Keith, what's the process like of becoming adopted by and incubated by the CNCF? >>Yeah, I mean, it's pretty simple. It's an application process into the foundation where you say, you know what the project is about, how diverse is your contributor base, how many people are using it. And it goes through a review of with TC. It goes through a review of like all the users and contributors. And if you see a good base of deployments in production, if you see a diverse of contributors, then you can basically be part of the CNCF. And as you know, CNCF is very flexible on governance. Basically it's like, bring your own governance. And then the projects can basically seamlessly go in and, you know, get into incubation and gradually graduate >>Another project close and dear to you Envoy. Yes. Now I've always considered Envoy just as what it is. It's a, I've always used it as, as a load balancer type thing. So I've always considered it somewhat of a gateway proxy, but Envoy gateway was announced last week. Yes. >>So Envoy is basically won the data plane war of in cloud native workloads. Right. And, but, and this was over the last five years, Envoy was announced even way before Rio and it is used in various deployment models. You can use it as a front load balancer. You can use it as an Ingres in Kubernetes. You can use it as a side car and a service mesh like steel, and it's lightweight dynamically, programmable, very open with a white community. But what we looked at when we looked at the Envoy base, was it still, wasn't very approachable for application developers. Like when you still see like the nouns that it uses in terms of clusters and so on is not what an application developer was used to. And so Envoy gateway is really an effort to make Envoy even more stronger out of the box for an application developer to use it as an API gateway. >>Right? Because if you think about it, ultimately, you know, people de developers start deploying workloads onto their Kubernetes clusters. They need some functionality like an API gateway to expose their services and you wanna make it really, really easy and simple. Right? I often say like what, what engine X was to like static websites like Envoy gateway will be to like, you know, APIs and it's really few the community coming together. We are a big part, but also VMware and as well as end users, like in this case, fidelity who is investing heavily into Envoy and API gateway use cases, joining forces saying, let's do this in upstream Envoy. >>I'd like to go back to IIO because this is a major step in IIOS development. Where do you see SIO coming into the picture? And Kubernetes is already broadly accepted. Is IIO generally adopted as an after an after step to, to Kubernetes or are they increasingly being adopted together? >>Yeah. So usually it's adopted as a follow on step and the reason is primarily the learning curve, right. It's just get used to all the Kubernetes and, you know, it takes a while for people to understand the concepts, get applications going, and then, you know, studio was made to basically solve, you know, three big problems there. Right. Which is around observability traffic management and security. Right. So as people deploy more services, they figure out, okay, how do I connect them? How do I secure all the connections and how do I do more fine grain routing? I'm doing more frequent deployments with Kubernetes, but I would like to do Canary releases to make safer rollouts. Right. And those are the problems that Isto solves. And I don't really want to know the metrics of like, yes, it'll be, I it's good to know all the node level and CPO level metrics. >>But really what I want to know is how are my services performing? Where is the latency, right? Where is the error rate? And those are the things thatto gives out of the box. So that's like a very natural next step for people using Kubernetes. And, you know, Tetra was really formed as a company to enable enterprises, to adopt STO Envoy and service mission, their environment. Right? So we do everything from run an academy for like courses and certifications on Envoy and STO to a distribution, which is, you know, compliant with various bills and tooling as well as a whole platform on top of STO to make it usable and deployment in a large enterprise. >>So paint the end to end for me, for STO in Envoy. I know they can be used in similar fashions is like side cars, but how they work together to deliver value. >>Yeah. So if you step back from technology a little bit, right, and you like, sort of look at what customers are doing and facing, right. Really it is about, they have applications. They have some applications that new workloads going into Kubernetes and cloud native. They have a lot of legacy workloads, a lot of workloads on VMs and with different teams in different clouds or due to acquisitions. They're very heterogeneous right now. Our mission Tetrad's mission is power. The world's application traffic, but really the business value that we are going after is consistency of application operations. Right? And I'll tell you how powerful that is because the more places you can deploy Envoy into the more places you can deploy studio into, the more consistency you can get for the value pillars of observability, traffic management, and security. Right. And really, if you think about what is the journey for an enterprise to migrate from workloads into Kubernetes or from data centers into cloud, the challenges are around security and connectivity, right? Because if it's Kubernetes fabric, the same Kubernetes app and data center can be deployed exactly as is it in cloud. Right. Right. So why is it hard to migrate to cloud, right. The challenges come in the security and networking layer. >>Right. So let's talk about that with some granularity and you can maybe gimme some concrete examples, right? Because it, as I think about the hybrid infrastructure where I have VMs on premises, cloud, native stuff, running in the public cloud, or even cloud native next to VMs, right. I do security differently when I'm in the VM world. I say, you know what, this IP address, can't talk to this Oracle database server. Right. That's not how cloud native works. Right. I, I can't say if I have a cloud, if I have a cloud native app talking to a Oracle database, there's no IP address. Yeah. But how do I, how, how do I secure the communication between the two? Exactly. >>So I think you hit it straight on the head. So which is with things like Kubernetes, IP is no longer a really a valid noun where you can say, because things will auto scale either from Kubernetes or, you know, the cloud autoscales. So really the noun that is becoming now is service. So, and I could have many instances of it. They could go scale up and down. But what I'm saying is this service, which, you know, some app server, some application can talk to the article service. Hmm. And what we have done with the te trade service bridge, which is why we call our platform service bridge, because it's all about bridging all the services is whatever you're running on, the VM can be onboarded onto the mesh, like as if it were a ity service. Right. And then my policy around this service can talk to this service is same in Kubernetes is same for Kubernetes talking to VM it's same for VM to VM, both in terms of access control in terms of encryption. What we do is because it's the Envoy, proxy goes everywhere and the traffic is going through them. We actually take care of distributing, certs, encrypting, everything, and it becomes, and that is what leads to consistent application operations. And that's where the value is. >>We're seeing a lot of activity around observ observability right now, a lot of different tools, both open source and proprietary STO certainly part of the open telemetry project, I believe. Are you part of that? Yes. But the customers are still piecing together a lot of tools on their own. Right. Do you see a, a more coherent framework forming around observability? >>I think very much so. And there are layers of observability, right? So the thing is like, if we tell you there is latency between these two services at L seven layer, the first question is, is it the service? Is it the Envoy? Or is it the network? It sounds like a very simple question. It's actually not that easy to answer. And that is one of the questions we answer in like platforms like ours. Right. But even that is not the end. It, if it's neither of these three, it could be the node. It could be the hardware underneath. Right. And those, you realize like those are different observability tools that work on each layer. So I think there's a lot of work to be done, to enable end users to go from app, like from top to bottom to make, reduce what is called MTTR or meantime to, you know, resolution of an issue, where is the problem. >>But I think with tools like what is being built now, it is becoming easier, right? It is because one of the things we have to realize is with things like Kubernetes, we made the development of microservices easier. Right. And that's great. But as a result, what is happening is that more things are getting broken down. So there is more network in between. So that's harder. It gets to troubleshoot harder. It gets to secure everything harder. It gets to get visibility from everywhere. Right. So I often say like, actually, if you're going embarking down microservices journey, you actually are, you better have a platform like this. Otherwise, you know, you're, you're taking on operational cost. >>Wow. J's paradox. The more accessible we make something, the more it gets used, the more complex it is. That's been a theme here at KU con cloud native con Europe, 2022 from Licia Spain. I'm Keith Townsend, along with my host, Paul Gillman. And you're watching the queue, the leader in high tech coverage.

(upbeat music) >> Hello, and welcome to this startup showcase. It's great to be here and talk about some of the innovations we are doing at AWS, how we work with our partner community, especially our open source partners. My name is Deepak Singh. I run our compute services organization, which is a very vague way of saying that I run a number of things that are connected together through compute. Very specifically, I run a container services organization. So for those of you who are into containers, ECS, EKS, fargate, ECR, App Runner Those are all teams that are within my org. I also run the Amazon Linux and BottleRocketing. So anything AWS does with Linux, both externally and internally, as well as our high-performance computing team. And perhaps very relevant to this discussion, I run the Amazon open source program office. Serving at AWS for over 13 years, almost 14, involved with compute in various ways, including EC2. What that has done has given me a vantage point of seeing how our customers use the services that we build for them, how they leverage various partner solutions, and along the way, how AWS itself has gotten involved with opensource. And I'll try and talk to you about some of those factors and how they impact, how you consume our services. So why don't we get started? So for many of you, you know, one of the things, there's two ways to look at AWS and open-source and Amazon in general. One is the number of contributors you may have. And the number of repositories that contribute to. Those are just a couple of measures. There are people that I work with on a regular basis, who will remind you that, those are not perfect measures. Sometimes you could just contribute to one thing and have outsized impact because of the nature of that thing. But it address being what it is, increasingly we'll look at different ways in which we can help contribute and enhance open source 'cause we consume a lot of it as well. I'll talk about it very specifically from the space that I work in the container space in particular, where we've worked a lot with people in the Kubernetes community. We've worked a lot with people in the broader CNCF community, as well as, you know, small projects that our customers might have got started off with. For example, I want to like talking about is Argo CD from Intuit. We were very actively involved with helping them figure out what to do with it. And it was great to see how into it. And we worked, etc, came together to think about get-ups at the Kubernetes level. And while those are their projects, we've always been involved with them. So we try and figure out what's important to our customers, how we can help and then take because of that. Well, let's talk about a little bit more, here's some examples of the kinds of open source projects that Amazon and AWS contribute to. They arranged from the open JDK. I think we even now have our own implementation of Java, the Corretto open source project. We contribute to projects like rust, where we are very active in the rest foundation from a leadership role as well, the robot operating system, just to pick some, we collaborate with Facebook and actively involved with the pirates project. And there's many others. You can see all the logos in here where we participate either because they're important to us as AWS in the services that we run or they're important to our customers and the services that they consume or the open source projects they care about and how we get to those. How we get and make those decisions is often depends on the importance of that particular project. At that point in time, how much impact they're having to AWS customers, or sometimes very feel that us contributing to that project is super critical because it helps us build more robust services. I'll talk about it in a completely, you know, somewhat different basis. You may have heard of us talk about our new next generation of Amazon Linux 2022, which is based on fedora as its sub stream. One of the reasons we made this decision was it allows us to go and participate in the preneurial project and make sure that the upstream project is robust, stays robust. And that, that what that ends up being is that Amazon Linux 2022 will be a robust operating system with the kinds of capabilities that our customers are asking for. That's just one example of how we think about it. So for example, you know, the Python software foundation is something that we work with very closely because so many of our customers use Python. So we help run something like PyPy which is many, you know, if you're a Python developer, I happened to be a Ruby one, but lots of our customers use Python and helping the Python project be robust by making sure PyPy is available to everybody is something that we help provide credits for help support in other ways. So it's not just code. It can mean many different ways of contributing as well, but in the end code and operations is where we hang our happens. Good examples of this is projects that we will create an open source because it makes sense to make sure that we open source some of the core primitives or foundations that are part of our own services. A great example of that, whether this be things that we open source or things that we contribute to. And I'll talk about both and I'll talk about things near and dear to my heart. There's many examples I've picked the two that I like talking about. The first of these is firecracker. Many of you have heard about it, a firecracker for those of you who don't know is a very lightweight virtual machine manager, which allows you to run these micro VMs. And why was this important many years ago when we started Lambda and quite honestly, Fugate and foggy, it still runs quite a bit in that mode, we used to have to run on VMs like everything else and finding the right VM for the size of tasks that somebody asks for the size of function that somebody asks for is requires us to provision capacity ahead of time. And it also wastes a lot of capacity because Lambda function is small. You won't even if you find the smallest VM possible, those can be a little that can be challenging. And you know, there's a lot of resources that are being wasted. VM start at a particular speed because they have to do a whole bunch of things before the operating system spins up and the virtual machine spins up and we asked ourselves, can we do better? come up with something that allows us to create right size, very lightweight, very fast booting. What's your machines, micro virtual machine that we ended up calling them. That's what led to firecracker. And we open source the project. And today firecrackers use, not just by AWS Lambda or foggy, but by a number of other folks, there's companies like fly IO that are using it. We know people using firecracker to run Kubernetes on prem on bare metal as an example. So we've seen a lot of other folks embrace it and use it as the foundation for building their own serverless services, their own container services. And we think there's a lot of value and learnings that we can bring to the table because we get the experience of operating at scale, but other people can bring to the table cause they may have specific requirements that we may not find it as important from an AWS perspective. So that's firecracker an example of a project where we contribute because we feel it's fundamentally important to us as continually. We were found, you know, we've been involved with continuity from the beginning. Today, we are a whole team that does nothing else, but contribute to container D because container D underlies foggy. It underlies our Kubernetes offerings. And it's increasingly being used by customers directly by their placement. You know, where they're running container D instead of running a full on Docker or similar container engine, what it has allowed us to do is focus on what's important so that we can operate continuously at scale, keep it robust and secure, add capabilities to it that AWS customers need manifested often through foggy Kubernetes, but in the end, it's a win-win for everybody. It makes continuously better. If you want to use containers for yourself on AWS, that's a great way to you. You know, you still, you still benefit from all the work that we're doing. The decision we took was since it's so important to us and our customers, we wanted a team that lived in breathed container D and made sure a super robust and there's many, many examples like that. No, that we ended up participating in, either by taking a project that exists or open sourcing our own. Here's an example of some of the open source projects that we have done from an AWS on Amazon perspective. And there's quite a few when I was looking at this list, I was quite surprised, not quite surprised I've seen the reports before, but every time I do, I have to recount and say, that's a lot more than one would have thought, even though I'd been looking at it for such a long time, examples of this in my world alone are things like, you know, what work had to do with Amazon Linux BottleRocket, which is a container host operating system. That's been open-sourced from day one. Firecracker is something we talked about. We have a project called AWS peril cluster, which allows you to spin up high performance computing clusters on AWS using the kind of schedulers you may use to use like slum. And that's an open source project. We have plenty of source projects in the web development space, in the security space. And more recently things like the open 3d engine, which is something that we are very excited about and that'd be open sourced a few months ago. And so there's a number of these projects that cover everything from tooling to developer, application frameworks, all the way to database and analytics and machine learning. And you'll notice that in a few areas, containers, as an example, machine learning as an example, our default is to go with open source option is where we can open source. And it makes sense for us to do so where we feel the product community might benefit from it. That's our default stance. The CNCF, the cloud native computing foundation is something that we've been involved with quite a bit. You know, we contribute to Kubernetes, be contribute to Envoy. I talked about continuity a bit. We've also contributed projects like CDK 8, which marries the AWS cloud development kit with Kubernetes. It's now a sandbox project in Kubernetes, and those are some of the areas. CNCF is such a wide surface area. We don't contribute to everything, but we definitely participate actively in CNCF with projects like HCB that are critical to eat for us. We are very, very active in just how the project evolves, but also try and see which of the projects that are important to our customers who are running Kubernetes maybe by themselves or some other project on AWS. Envoy is a good example. Kubernetes itself is a good example because in the end, we want to make sure that people running Kubernetes on AWS, even if they are not using our services are successful and we can help them, or we can work on the projects that are important to them. That's kind of how we think about the world. And it's worked pretty well for us. We've done a bunch of work on the Kubernetes side to make sure that we can integrate and solve a customer problem. We've, you know, from everything from models to work that we have done with gravity on our arm processor to a virtual GPU plugin that allows you to share and media GPU resources to the elastic fabric adapter, which are the network device for high performance computing that it can use at Kubernetes on AWS, along with things that directly impact Kubernetes customers like the CDKs project. I talked about work that we do with the container networking interface to the Amazon control of a Kubernetes, which is an open source project that allows you to use other AWS services directly from Kubernetes clusters. Again, you notice success, Kubernetes, not EKS, which is a managed Kubernetes service, because if we want you to be successful with Kubernetes and AWS, whether using our managed service or running your own, or some third party service. Similarly, we worked with premetheus. We now have a managed premetheus service. And at reinvent last year, we announced the general availability of this thing called carpenter, which is a provisioning and auto-scaling engine for Kubernetes, which is also an open source project. But here's the beauty of carpenter. You don't have to be using EKS to use it. Anyone running Kubernetes on AWS can leverage it. We focus on the AWS provider, but we've built it in such a way that if you wanted to take carpenter and implemented on prem or another cloud provider, that'd be completely okay. That's how it's designed and what we anticipated people may want to do. I talked a little bit about BottleRocket it's our Linux-based open-source operating system. And the thing that we have done with BottleRocket is make sure that we focus on security and the needs of customers who want to run orchestrated container, very focused on that problem. So for example, BottleRocket only has essential software needed to run containers, se Linux. I just notice it says that's the lineups, but I'm sure that, you know, Lena Torvalds will be pretty happy. And seeing that SE linux is enabled by default, we use things like DM Verity, and it has a read only root file system, no shell, you can assess it. You can install it if you wanted to. We allowed it to create different bill types, variants as we call them, you can create a variant for a non AWS resource as well. If you have your own homegrown container orchestrator, you can create a variant for that. It's designed to be used in many different contexts and all of that is open sourced. And then we use the update framework to publish and secure repository and kind of how this transactional system way of updating the software. And it's something that we didn't invent, but we have embraced wholeheartedly. It's a bottle rockets, completely open source, you know, have partners like Aqua, where who develop security tools for containers. And for them, you know, something I bought in rocket is a natural partnership because people are running a container host operating system. You can use Aqua tooling to make sure that they have a secure Indiana environment. And we see many more examples like that. You may think so over us, it's all about AWS proprietary technology because Lambda is a proprietary service. But you know, if you look peek under the covers, that's not necessarily true. Lambda runs on top of firecracker, as we've talked about fact crackers and open-source projects. So the foundation of Lambda in many ways is open source. What it also allows people to do is because Lambda runs at such extreme scale. One of the things that firecracker is really good for is running at scale. So if you want to build your own firecracker base at scale service, you can have most of the confidence that as long as your workload fits the design parameters, a firecracker, the battle hardening the robustness is being proved out day-to-day by services at scale like Lambda and foggy. For those of you who don't know service support services, you know, in the end, our goal with serverless is to make sure that you don't think about all the infrastructure that your applications run on. We focus on business logic as much as you can. That's how we think about it. And serverless has become its own quote-unquote "Sort of environment." The number of partners and open-source frameworks and tools that are spun up around serverless. In which case mostly, I mean, Lambda, API gateway. So it says like that is pretty high. So, you know, number of open source projects like Zappa server serverless framework, there's so many that have come up that make it easier for our customers to consume AWS services like Lambda and API gateway. We've also done some of our own tooling and frameworks, a serverless application model, AWS jealous. If you're a Python developer, we have these open service runtimes for Lambda, rust dot other options. We have amount of number of tools that we opened source. So in general, you'll find that tooling that we do runtime will tend to be always be open-sourced. We will often take some of the guts of the things that we use to build our systems like firecracker and open-source them while the control plane, etc, AWS services may end up staying proprietary, which is the case in Lambda. Increasingly our customers build their applications and leverage the broader AWS partner network. The AWS partner network is a network of partnerships that we've built of trusted partners. when you go to the APN website and find a partner, they know that that partner meets a certain set of criteria that AWS has developed, and you can rely on those partners for your own business. So whether you're a little tiny business that wants some function fulfill that you don't have the resources for or large enterprise that wants all these applications that you've been using on prem for a long time, and want to keep leveraging them in the cloud, you can go to APN and find that partner and then bring their solution on as part of your cloud infrastructure and could even be a systems integrator, for example, to help you solve this specific development problem that you may have a need for. Increasingly, you know, one of the things we like to do is work with an apartment community that is full of open-source providers. So a great one, there's so many, and you have, we have a panel discussion with many other partners as well, who make it easier for you to build applications on AWS, all open source and built on open source. But I like to call it a couple of them. The first one of them is TIDELIFT. TIDELIFT, For those of you who don't know is a company that provides SAS based tools to curate track, manage open source catalogs. You know, they have a whole network of maintainers and providers. They help, if you're an independent open developer, or a smart team should probably get to know TIDELIFT. They provide you benefits and, you know, capabilities as a developer and maintainer that are pretty unique and really help. And I've seen a number of our open source community embraced TIDELIFT quite honestly, even before they were part of the APN. But as part of the partner network, they get to participate in things like ISP accelerate and they get to they're officially an advanced tier partner because they are, they migrated the SAS offering onto AWS. But in the end, if you're part of the open source supply chain, you're a maintainer, you are a developer. I would recommend working with TIDELIFT because their goal is making all of you who are developing open source solutions, especially on AWS, more successful. And that's why I enjoy this partnership with them. And I'm looking to do a lot more because I think as a company, we want to make sure that open source developers don't feel like they are not supported because all you have to do is read various forums. It's challenging often to be a maintainer, especially of a small project. So I think with helping with licensing license management, security identification remediation, helping these maintainers is a big part of what TIDELIFT to us and it was great to see them as part of a partner network. Another partner that I like to call sysdig. I actually got introduced to them many years ago when they first launched. And one of the things that happened where they were super interested in some of our serverless stuff. And we've been trying to figure out how we can work together because all of our customers are interested in the capabilities that cystic provides. And over the last few years, he found a number of areas where we can collaborate. So sysdig, I know them primarily in a security company. So people use cystic to secure the bills, detect, you know, do threat response, threat detection, completely continuously validate their posture, get this continuous analytics signal on how they're doing and monitor performance. At the end of it, it's a SAS platform. They have a very nice open source security stack. The one I'm most familiar with. And I think most of you are probably familiar with is Falco. You know, sysdig, a CNCF project has been super popular. It's just to go SSS what 3, 37, 40 million downloads by now. So that's pretty, pretty cool. And they have been a great partner because we've had to do make sure that their solution works at target, which is not a natural place for their software to run, but there was enough demand and interest from our customers that, you know, or both companies leaned in to make sure they can be successful. So last year sister got a security competency. We have a number of specific competencies that we for our partners, they have integration and security hub is great. partners are lean in the way cystic has onto making our customer successful. And working with us are the best partners that we have. And there's a number of open source companies out there built on open source where their entire portfolio is built on open source software or the active participants like we are that we love working with on a day to day basis. So, you know, I think the thing I would like to, as we wind this out in this presentation is, you know, AWS is constantly looking for partnerships because our partners enable our customers. They could be with companies like Redis with Mongo, confluent with Databricks customers. Your default reaction might be, "Hey, these are companies that maybe compete with AWS." but no, I mean, I think we are partners as well, like from somebody at the lower end of the spectrum where people run on top of the services that I own on Linux and containers are SE 2, For us, these partners are just as important customers as any AWS service or any third party, 20 external customer. And so it's not a zero sum game. We look forward to working with all these companies and open source projects from an AWS perspective, a big part of how, where my open source program spends its time is making it easy for our developers to contribute, to open source, making it easy for AWS teams to decide when to open source software or participate in open source projects. Over the last few years, we've made significant changes in how we reduce the friction. And I think you can see it in the results that I showed you earlier in this stock. And the last one is one of the most important things that I say and I'll keep saying that, that we do as AWS is carry the pager. There's a lot of open source projects out there, operationalizing them, running them at scale is not easy. It's not all for whatever reason. It may not have anything to do with the software itself. But our core competency is taking that and being really good at operating it and becoming experts at operating it. And then ideally taking that expertise and experience and operating that project, that software and contributing back upstream. Cause that makes it better for everybody. And I think you'll see us do a lot more of that going forward. We've been doing that for the last few years, you know, in the container space, we do it every day. And I'm excited about the possibilities. With that. Thank you very much. And I hope you enjoy the rest of the showcase. >> Okay. Welcome back. We have Deepak sing here. We just had the keynote closing keynote vice-president of compute services. Deepak. Great to a great keynote, great wisdom and insight from that session. A very notable highlights and cutting edge trends and product information. Thanks for sharing. >> No, anytime it's always good to be here. It's too bad that we still doing this virtually, but always good to talk to you, John. >> We'll get hopefully through this way pretty quickly, I want to jump right in. Cause we don't have a lot of time. I want to get some quick question. You've brought up a good things. Open source innovation. Okay. Going next level. You've seen the rise of super clouds and super apps developing at open source. You're seeing big companies contributing, you know, you mentioned Argo into it. You're seeing that dynamic where companies are forming around this. This is a rising tide. This is, this is actually real. It's not the old school of, okay, here's a project. And then someone manages support and commercialization of it. It's actually platform in cloud scale. This is next gen. >> Yeah. And actually I think it started a few years ago. We can talk about a company that, you know, you're very familiar with as part of this event, which is armory many years ago, Netflix spun off this project called Spinnaker. A Spinnaker is CISED you know, CSED system that was developed at Netflix for their own purposes, but they chose to open solicit. And since then, it's become very popular with customers who want to use it even on prem. And you have a company that spun up on it. I think what's making this world very unique is you have very large companies like Facebook that will build things for themselves like VITAS or Netflix with Spinnaker and open source them. And you can have a lot of discussion about why they chose to do so, etc. But increasingly that's becoming the default when Amazon or Netflix or Facebook or Mehta, I guess you call them these days, build something for themselves for their own needs. The first question we ask ourselves is, should it be opensource? And increasingly we are all saying yes. And here's what happens because of that. It gives an opportunity depending on how you open source it for innovation through commercial deployments, so that you get SaaS companies, you know, that are going to take that product and make it relevant and useful to a very broad number of customers. You build partnerships with cloud providers like AWS, because our customers love this open source project and they need help. And they may choose an AWS managed service, or they may end up working with this partner on a day-to-day basis. And we want to work with that partner because they're making our customers successful, which is one reason all of us are here. So you're having this set of innovation from large companies from, you know, whether they are just consumer companies like Metta infrastructure companies like us, or just random innovation that's happening in an open source project that which ends up in companies being spun up and that foster that innovative innovation and that flywheel that's happening right now. And I think you said that like, this is unique. I mean, you never saw this happen before from so many different directions. >> It really is a nice progression on the business model side as well. You mentioned Argo, which is a great organic thing that was Intuit developed. We just interviewed code fresh. They just presented here in the showcase as well. You seeing the formation around these projects develop now in the community at a different scale. I mean, look at code fresh. I mean, Intuit did it Argo and they're not just supporting it. They're building a platform. So you seeing the dynamics of tools and now emerging the platforms, you mentioned Lambda, okay. Which is proprietary for AWS and your talk powered by open source. So again, open source combined with cloud scale allows for new potential super applications or super clouds that are developing. This is a new phenomenon. This isn't just lift and shift and host on the cloud. This is actually a construction production developer workflow. >> Yeah. And you are seeing consumers, large companies, enterprises, startups, you know, it used to be that startups would be comfortable adopting some of these solutions, but now you see companies of all sizes doing so. And I said, it's not just software it's software, the services increasingly becoming the way these are given, delivered to customers. I actually think the innovation is just getting going, which is why we have this. We have so many partners here who are all in inventing and innovating on top of open source, whether it's developed by them or a broader community. >> Yeah. I liked, I liked the represent container. Do you guys have, did that drove that you've seen a lot of changes and again, with cloud scale and open source, you seeing the dynamics change, whether you're enabling that, and then you see kind of like real big change. So let's take snowflake, a big customer of AWS. They started out as a startup too, but they weren't a data warehouse. They were bringing data warehouse like functionality and then changing everything differently and making it consumable for the cloud. And hence they're huge. So that's a disruption into an incumbent leader or sector. Then you've got new capabilities emerging. What's your thoughts, Deepak? Can you share your vision on how you have the disruption to existing leaders, old guard, if you will, as you guys call them and then new capabilities as these new platforms emerge at a net new functionality, how do you see that emerging? >> Yeah. So I speak from my side of the world. I've lived in over the last few years, which has containers and serverless, right? There's a lot of, if you go to any enterprise and ask them, do you want to modernize the infrastructure? Do you want to take advantage of automated software delivery, continuous delivery infrastructure as code modern observability, all of them will say yes, but they also are still a large enterprise, which has these enterprise level requirements. I'm using the word enterprise a lot. And I usually it's a trigger word for me because so many customers have similar requirements, but I'm using it here as large company with a lot of existing software and existing practices. I think the innovation that's coming and I see a lot of companies doing that is saying, "Hey, we understand the problems you want to solve. We understand the world where you live in, which could be regulated." You want to use all these new modalities. How do we allow you to use all of them? Keep the advantages of switching to a Lambda or switching to, and a service running on far gate, but give you the same capabilities. And I think I'll bring up cystic here because we work so closely with them on Falco. As an example, I just talked about them in my keynote. They could have just said, "Oh no, we'll just support the SE2 and be done with it." They said, "No, we're going to make sure that serverless containers in particular are something that you're going to be really good at because our customers want to use them, but requires us to think differently. And then they ended up developing new things like Falco that are born in this new world, but understand the requirements of the old world. If you get what I'm saying. And I think that a real example. >> Yeah. Oh, well, I mean, first of all, they're smart. So that was pretty obvious for most people that know, sees that you can connect the dots on serverless, which is a great point, but not everyone can see that again, this is what's new and and systig was just found in his backyard. As I found out on my interview, a great, great founder, they would do a new thing. So it was a very easy to connect the dots there again, that's the trend. Well, I got to ask if they're doing that for serverless, you mentioned graviton in your speech and what came out of you mentioned graviton in your speech and what came out of re-invent this past year was all the innovation going on at the compute level with gravitron at many levels in the Silicon. How should companies and open source developers think about how to innovate with graviton? >> Yeah, I mean, you've seen examples from people blogging and tweeting about how fast their applications run and grab it on the price performance benefits that they get, whether it's on, you know, whether it's an observability or other places. something that AWS is going to embrace across a compute something that AWS is going to embrace across a compute portfolio. Obviously you can go find EC2 instances, the gravitron two instances and run on them and that'll be great. But we know that most of our customers, many of our customers are building new applications on serverless containers and serveless than even as containers increasingly with things like foggy, where they don't want to operate the underlying infrastructure. A big part of what we're doing is to make sure that graviton is available to you on every compute modality. You can run it on a C2 forever. You've been running, being able to use ECS and EKS and run and grab it on almost since launch. What do you want me to take it a step further? You elastic Beanstalk customers, elastic Beanstalk has been around for a decade, but you can now use it with graviton. people running ECS on for gate can now use graviton. Lambda customers can pick graviton as well. So we're taking this price performance benefits that you get So we're taking this price performance benefits that you get from graviton and basically putting it across the entire compute portfolio. What it means is every high level service that gets built on compute infrastructure. And you get the price performance benefits, you get the price performance benefits of the lower power consumption of arm processes. So I'm personally excited like crazy. And you know, this has graviton 2 graviton 3 is coming. >> That's incredible. It's an opportunity like serverless was it's pretty obvious. And I think hopefully everyone will jump on that final question as the time's ticking here. I want to get your thoughts quickly. If you look at what's happened with containers over the past say eight years since the original founding of the first Docker instance, if you will, to how that's evolved and then the introduction of Kubernetes and the cloud native wave we're seeing now, what is, how would you describe the relationship between the success Docker, seeing now with Kubernetes in the cloud native construct what's different and why is this combination so successful? >> Yeah. I often say that containers would have, let me rephrase that. what I say is that people would have adopted sort of the modern way of running applications, whether containers came around or not. But the fact that containers came around made that migration and that journey is so much more efficient for people. So right from, I still remember the first doc that Solomon gave Billy announced DACA and starting to use it on customers, starting to get interested all the way to the more sort of advanced orchestration that we have now for containers across the board. And there's so many examples of the way you can do that. Kubernetes being the most, most well-known one. Here's the thing that I think has changed. I think what Kubernetes or Docker, or the whole sort of modern way of building applications has done is it's taken people who would have taken years adopting these practices and by bringing it right to the fingertips and rebuilding it into the APIs. And in the case of Kubernetes building an entire sort of software world around it, the number of, I would say number of decisions people have to take has gone smaller in many ways. There's so many options, the number of decisions that become higher, but the com the speed at which they can get to a result and a production version of an application that works for them is way low. I have not seen anything like what I've seen in the last 6, 7, 8 years of how quickly the most you know, the most I would say is, you know, a company that you would think would never adopt modern technology has been able to go from, this is interesting to getting a production really quickly. And I think it's because the tooling makes it So, and the fact that you see the adoption that you see right and the fact that you see the adoption that you see right from the fact that you could do Docker run Docker, build Docker, you know, so easily back in the day, all the way to all the advanced orchestration you can do with container orchestrator is today. sort of taking all of that away as well. there's never been a better time to be a developer independent of whatever you're trying to build. And I think containers are a big central part of why that's happened. >> Like the recipe, the combination of cloud-scale, the timing of Kubernetes and the containerization concepts just explode as a beautiful thing. And it creates more opportunities and will challenges, which are opportunities that are net new, but it solves the automation piece that we're seeing this again, it's only makes things go faster. >> Yes. >> And that's the key trend. Deepak, thank you so much for coming on. We're seeing tons of open cloud innovations, thanks to the success of your team at AWS and being great participants in the community. We're seeing innovations from startups. You guys are helping enabling that. Of course, they want to live on their own and be successful and build their super clouds and super app. So thank you for spending the time with us. Appreciate. >> Yeah. Anytime. And thank you. And you know, this is a great event. So I look forward to people running software and building applications, using AWS services and all these wonderful partners that we have. >> Awesome, great stuff. Great startups, great next generation leaders emerging. When you see startups, when they get successful, they become the modern software applications platforms out there powering business and changing the world. This is the cube you're watching the AWS startup showcase. Season two episode one open cloud innovations on John Furrier your host, see you next time.

(bright music) >> Hi, everyone. Welcome to the CUBE's presentation of the AWS Startup Showcase around open cloud innovations. It's the season two episode one of the ongoing series covering exciting startups from the AWS ecosystem and talking about open source and innovation. I'm John Furrier, your host. Today, we're joined by two great guests. Dan Garfield, chief open source officer and co-founder of Codefresh IO, and Raziel Tabib, CEO and co-founder. Two co-founders in the middle of all the innovation. Gentlemen thanks for coming on. >> Thank you. >> So you guys have a great platform and as cloud native goes mainstream in the enterprise and for developers, the big topic is unification, end-to-end, horizontally scalable, leveraging data. All these things around agile that I call agile cloud next level. This is kind of what we're seeing. The CNCF is growing. You've seen KubeCon every year is more about these kinds of things. Words like orchestration, Kubernetes, container, security. All of those complexities are now at the center of making things easier for developers. This is a key value proposition and you guys at Codefresh are offering really the first enterprise delivery solution powered by Argo, which is an open source project. Again, open source driving really big changes. So let's get into it. And first of all, congratulations, and thanks for working on this project. What's so special about- >> Thank you for that. >> Argo the project, and why have you guys decided to build a platform on it, and where is this coming together? Take us through why this is so important. >> I think Argo has been a very fast growing open source project for multiple reasons. A, it has been built for the new way of building and deploying an application. It's cloud native. You mentioned Kubernetes becoming kind of the de facto way of running application. It's the de facto way to run automation and pipeline. But also Argo has been built from the ground up to the latest practices of how we deploy software. We deploy software now differently. We deploy it using a GitOps practice. We're deploying it using canary blue-green progressive deployment. And Argo has been built around these practices, around these technologies, and has been very much widely adopted by the community. In the past, the KubeCon you've mentioned, Argo was all over the place. And we were very glad to be working with the community to talk about what the next steps with Argo. >> Yeah, it's a really good point. I would like to just follow up on that because you see this being talked about. It always comes up, where is open source really outside of a pure contributors matter? And when you have corporations contributing, you seeing this has been the trend. You saw it with Lyft, with Envoy, companies doing more and more open source. This is part of a big collaboration. And again, this comes back down to this whole why it's relevant and why it's so special with Argo. Continue to talk about relationship because it's not just you guys, it's now community. >> Yeah, I can speak to that. The Argo project is something that we maintain in partnership with several other companies and really our relationship with it is that this is something that we're actively contributing to. This is something that we're helping build the roadmap on and planning the events around and all those kinds of things. And we're doing that because we really believe in this technology and we've built our platform on it. So when you deploy Codefresh, you're deploying technology that's built directly on Argo and is designed specifically to solve that problem that you spoke to at the top of the hour. We all want to deliver software faster. We all want to have fewer regressions. We want to have fewer breaking changes. We want software to be super reliable. We want to be comfortable with what we're doing. That's really why we picked Argo because that technology that we have it is to Raziel's point delivered in this new way. It's delivered using GitOps. And that's a whole revolution and change in the way that people build and deploy software. And bringing cohesion into that experience is so critical to building the confidence that lets you actually deploy often and frequently and more. >> Dan, if you don't mind just expanding on that one point about the problem you solve, because to me, this has been kind of that evolution. It's almost like, yeah, there's been problems, plural, and opportunities that you saw with those in growing markets like this with DevOps and DevSecOps and now cloud native. What is the catalyst behind all of this? What was the epiphany behind it? How did it get so much momentum? What was it really doing under the covers? >> Well, it's a very simple and easy to use set of tools. And that's one of the big things is that if you look at the ideas of GitOps and there's actually a foundation around this that were part of called open GitOps to GitOps working group under the CNCF. And those principles of, I want to, yes, do my software defined as code. I want to do my infrastructure defined as code and I need something monitoring by production run times and making sure that the declared desired state is always matching the actual state. Those principles have actually been around for a number of years. And with Kubernetes, we really unlocked an API that allowed us to start doing GitOps and this is why we bring in Argo and you see the rise of Argo CD and other workflows and what we've been doing is really because that technology has been unlocked now. So the ability to define how your software is supposed to run and now your entire software delivery stack should run, all defined and then monitored and then kept in check using the GitOps operator. That critical unlock is what's really driving the massive adoption. And like Raziel said, Argo is the fastest growing and most popular open source project for delivering software. And it's not even close. >> Yeah, this is really great point. And I want to get into that 'cause I want to know why, what you guys do on your platform versus the open source and get that relationship settled? Before we get there, though, I want to get your reaction to some of the commentary in the industry 'cause GitOps trend has been exploding into new directions. I mean, it used to be a term about 10 years ago called big data. And at the beginning where data was all big data. Now it was DevOps revolution around data as well. But now you're hearing people talk about big code. Like, I mean, the code bases are becoming so huge. So as a developer, you're leveraging large open source code. This idea of the software delivery with existing code and new code just adds to more code. There's more code being developed every day. >> There is more code delivered every day. And I think that organization realize today, almost in every industry that they have to pace up how fast and how frequent they update their software delivery. We're living in a world in which every aspect of our life has been disrupted by software and organization realize that they have to keep up and figure out how to deploy software more frequent and more lively. And I think, you mentioned that really Kubernetes, the cloud native became the de facto way of running application. I think most of organization has made that decision to move into cloud native. The second question is after, is okay, now we have all applications running, how fast and how more frequent we can deploy applications to the cloud native? And that's the stage in which we're super excited about Argo and our up platform because that's basically streamline the building application for these cloud native, deploying applications for the cloud native, and so on. >> Yeah, and I think that highlights the business value. You getting a lot of the conversations with businesses that say they want the modern application on the cloud scale. And at the end of the day, it comes down to speed and security. So how fast can I get the app out? How well does it work? Does it run performance? And does it have security? And I don't want a slow. >> Exactly. Exactly. It kind of oversimplifies it, but that's kind of the net net. So when you look at Argo open source, what's that's done and kind of where you guys are taking it. Can you talk about the differences between your enterprise version and the open source version and the interplay there, the relationship, the business model health customers can play on both sides or understand the difference? >> Sure. >> Go ahead. >> Go ahead, Raziel. Okay, so I think Argo, as you mentioned, is probably the most advanced technology today to both run pipelines. They're like events to trigger pipelines and Argo work for the one that pipelines, the Argo CD for GitOps and Rollout, for Canary blue-green strategies. And the adoption is really exploding. Just as an Advocate that we had in December, we have worked with the community and organized ArgoCon events in which we had initially kind of thought about 500 attendees. And so we have more than 4,000 registrants and majority of them are coming from enterprise. Now as we have talked to the community during this conference and figure out, okay, so what are the things that you're still missing? And that will help you take the benefit that you get from Argo to the next level. The few things that came up. One is Argo is a great technology. However, Argo now is fragmented into four projects. There is an advance. There is workflow. There is Argo CD. And there is Argo Rollout. And there is a need to bring them all together into a solid platform, solid one run time that can be easily installed, monitor all of these in a single UI, in a single control plane. That's one aspect. The second is the scalability. Really being able to manage it centrally across multiple clusters, not in one cluster. And what we bring in with the new one, we're so excited about this platform, is we're bringing that big. The first to get all of these four projects in one runtime, and one control plane, but also allow the community to run it across multiple cluster from one place getting into the solution, not just as a technology. >> If I may add to that, the value of bringing these projects together, it provides so many insights. So when you're trying to figure out, there's some breaking change that has been made, but you don't necessarily know where it is because you have a lot of microservices that are out there. You have a lot of teams working on it. By bringing all of these things together, we're able to look at all of the commits, all of the deployments, all of the Jira issues. All of these components combined together, so you really get a single view where you can see everything that's going on. And this is another element where when you're trying to deploy software at scale, you're trying to deliver it faster. People are getting a little bit overwhelmed because there are so many updates and so many different services and so many teams working that they're starting to miss that visibility. So this is what we want to bring into the ecosystem is we really want them that visibility to be super clear. And by bringing all of the Argo components, the Argo tools together, we're able to do that in a single dashboard. >> Yeah, so if I get this right, let me just double click on that because it sounds like, yeah, Argo's great. It's been organically growing, a lot of different components to it, but when you start getting into pushing code in an organization, you have, I call the old-school version control kind of vibe going on where it's like you don't know what's out there and how that affects the system as it's a distributed system, which cloud is. There are consequences when stuff breaks. So we all know that. Is that kind of where you guys are getting at? The challenge is actually the opportunity at the same time where it's all goodness, but then when you start looking at scale and the system impact, is that kind of where the open source and you guys pick up, is that right? >> This is one aspect. I think the second one is that again, when you look at each individual component of Argo, each provide a lot of value by itself. But when you sum it, the value of the sum is greater than the value of the individual. So when you're taking, really the events and workflow, Argo CD and Argo Rollout, and you bring them all together into single runtime. The value of its time is really automation all the way from code to cloud. It's not breaking into, there is like an automation for CI, there's an automation for CD, there's information for progressive delivery. It's actually automated all the way from the Git commit through the GitOps through the deployment strategy, and so on. And being able to monitor it and scale it in the enterprise scale. So, of course, it's helping enterprise and make Argo to some level more crucial for enterprise, if I may say, but second is really bringing all of these components together and get the outcome be greater than the individual parts. >> Yeah, that's a good point. Yeah, make it make a commercial grade, if you will, for enterprise who wants to have support and consistency and whatnot. What other problems are you solving? Dan, can you chime in on the whole, how you guys resolve some of these challenges for the enterprise? Because, again, some stability is key as well, but also the business benefit has got to be there for the development teams. >> Yeah. So there's several. One aspect is that the way that most people operate today is they essentially do a bunch of commands and engage with systems. And then hopefully at the end, they write those things to Git. And this is a little bit backwards if you think about it because there's a situation where you can end up with things in production that were never checked in, or maybe somebody is operating and they're making a change. If we look at most of the downtime that's occurred over the last two years, it's because people have flubbed a key when they were typing in a command or something like that. The way that this system works is that we provide an interface, both the CLI and the GUI, where those operations interactions actually end with a Git commit. So rather than doing an operation and then hopefully committing to Git, most of the operations are actually done first in Git, or if there is something that can't be done first in Git, it's maybe bootstrapped and then committed to Git as part of a single command. So this means you have end-to-end traceability. It also means your auditability is way better. And then the second, the other component that we're adding is that security and scale layer. So we are securing these things, we're building in single sign-on, and all those robust security things you would expect to have across all these instances. So many organizations, when they're building their software delivery tools, they have to deploy instances in many locations. And so this is how you end up with companies that have 5,000 instances that are all out of date and insecure. Well with Codefresh, if you need to deploy a component onto this end cluster or something like that, you may have thousands of them. All of those are monitored and taken care of in a centralized way, so I can do all of my updates at once. I can make sure they're all up to date. I'm not running with a bunch of known CVEs or something like that and it's clear. The components are also designed in an architectural way. So that only the information that is needed is ever passed out. So I can have a cluster that is remotely managed, that checks out code, that the control plane never has access to. So this hybrid model has been really popular with our customers. We have customers in healthcare, we have customers in defense and in financial services, all these regulated industries. The flow of information is really critical. So this hybrid model allows you to deploy something that has the ease of a SaaS solution, but has the security of an on-prem solution while being centrally managed and easy to take care of. >> Yeah, it's a platform. It's what it is. It's not a tool. It's not a tool anymore. It's a platform. >> Exactly. >> I think the foundational aspect of this is critical. And you mentioned automation before. If you're going to go end-to-end automation, you have some stuff in the system that whether it hasn't been checked in yet. I mean, we know what this leads to. Disaster or a lot of troubleshooting and disruption. That's what it seems to solve. Am I getting that right? Is that right? >> Yeah. >> Go ahead. >> Yeah, it helps automate the whole process. But as you say, it's really like identify what needs not to be going all the way to production and really kind of avoid vulnerabilities or any flaws in the software. So it automates everything, but in a way that the automation can identify issues and avoid them from coming into the production. >> Well, great stuff here. I've got to ask you guys now that you've got that settled. It's really, I see the value there, how you guys are letting it grow organically and with Argo and then building that platform for businesses and developers. It's really cool. And I see the foundational value there. It just only gets better. How you guys contributing back to open source and helping the wider GitOps and Argo communities? Because this is, again, the rising tide that's bringing all the boats into the harbor, so to speak. So this is a good trend and people will acknowledge that. So how's this going to work as you guys work back into the open source community? >> So we work closely with both myself and the other maintainers worked closely with the community on the roadmap and making sure that we're addressing issues. I think if you look in the last quarter, we probably have upwards of 40 or 50 different issues that we've solved in terms of fixing a bug or adding features or things like that. So making sure that these tools, which are really the undergirding components of our platform, they have to be really robust. They have to be really strong. And so we're contributing those things back. And then when it comes to the scalability side, these are things that we can build into the platform. So the value should be really clear. I can deploy this, I can manage it myself, I can build tools on top of it. And if I want to start doing it at scale, maybe I want support. That's when I really am going to go to Codefresh and start saying, let's get the enterprise little platform. >> Awesome. GitOps, a lot of people like some naysayers may say, Hey, it's the latest fad. Is it here to stay? We were talking about big code earlier. GitOps, obviously seeing open source. Just every year, just get better and better and growth. I mean, I remember when I was breaking into the business, you have to sell under the table. Now it's all free and open and getting better every year. Just the growth of code. Is GitOps a fad? How do you talk to people who say that? I mean, besides slapping around saying wake up. I mean, how do you guys address that when people say it's just the latest fad? >> So if I may comment here and Dan feel free to chime in, I think that the GitOps is a continuation of a trend that everything is a source code. As a developer, many years ago myself and still writing code, always both code and code was the source of tool that's where we write the code. But now code actually is also describing how our application is running in production. And we've already seen kind of where it's get next. We also hear about infrastructure as a code. So now actually we storing the code the way the infrastructure should be. And I think that the benefit of storing all this configuration in a source code, which has been built to track changes, to be enabled to roll back, that is just going to be here to stay. And I think that's the new way of doing things. >> All right, gentlemen, great. Closing statements. Please share an update on the company. What it's all about? What event you got coming? I know you got a big launch. Can you take us through? Take us home. >> Join on February 1st, we're going to be launching the Codefresh software delivery platform. Raziel and I will be hosting the event. We've got a number of customers, a number of members of the community who are going to be joining us to show off that platform. So you're going to be able to see it in action, see how the features work, and understand the value of it. And you'll see how it works with GitOps. You'll see how it helps you deliver software at scale. That's February 1st. You can get information at codefresh.io. >> Raziel, Dan, thanks for coming on. >> Thank you. >> Pretty good showcase. Thanks for sharing. Congratulations. Great venture. Loved the approach. Love the growth in cloud native and you guys sure on the cutting edge. Fresh code, people love fresh code, codefresh.io. Thanks for coming on. >> Thank you. Thank you. >> Okay, this is the AWS Startup Showcase Open Cloud Innovations. Cloud scale, software, data. That's the future of modern applications being developed, changing the game to the next level. This is the CUBE's coverage season two episode one of the ongoing AWS Startup series here in theCUBE.

>>Welcome to the cube conversation here. I'm Sean ferry with the cube in Palo Alto, California. We've got two great guests here featuring armory who has with them Patrion open-source and talking open source and the enterprise. I'm your host, John ferry with the cube. Thanks for watching guys. Thanks for coming on. Really appreciate. I've got two great guests, Ben mapping, and SVP, a strategic partner in the armory and Ian Della horn, S staff SRE at Patrion gentlemen, you know, open source and enterprise is here and we wouldn't talk about thanks for coming. I appreciate it. >>Yeah. Thank you, John. Really happy to be here. Thank you to the Cuban and your whole crew. I'll start with a quick intro. My name is Ben Mappin, farmers founders, lead strategic partnerships. As John mentioned, you know, it all, it really starts with a premise that traditional businesses, such as hotels, banks, car manufacturers are now acting and behaving much more like software companies than they did in the past. And so if you believe that that's true. What does it mean? It means that these businesses need to get great at delivering their software and specifically to the cloud, like AWS. And that's exactly what armory aims to do for our customers. We're based on opensource Spinnaker, which is a continuous delivery platform. And, and I'm very happy that Ian from Patrion is here to talk about our journey together >>And introduce yourself what you do at Patriot and when Patrion does, and then why you guys together here? What's the, what's the story? >>Absolutely. Hi, John and Ben. Thanks for, thanks for having me. So I am Ian. I am a site reliability engineer at Patrion and Patrion is a membership platform for creators. And what we're our mission is to get creators paid, changing the way the art is valued so that creators can make money by having a membership relationship with, with fans. And we are, we're built on top of AWS and we are using Spinnaker with armory to deploy our applications that, you know, help, help creators get paid. Basically >>Talk about the original story of Ben. How are you guys together? What brought you together? Obviously patron is well-known in the creator circles. Congratulations, by the way, all your success. You've done a great service for the industry and have changed the game you were doing creators before it was fashionable. And also you got some cutting-edge decentralization business models as well. So again, we'll come back to that in a minute, but Ben, talk about how this all comes together. Yeah, >>Yeah. So Ian's got a great kind of origin story on our relationship together. I'll give him a lead in which is, you know, what we've learned over the years from our large customers is that in order to get great at deploying software, it really comes down to three things or at least three things. The first being velocity, you have to ship your software with velocity. So if you're deploying your software once a quarter or even once a year, that does no good to your customers or to your business, like just code sitting in a feature branch on a shelf, more or less not creating any business value. So you have to ship with speed. Second, you have to ship with reliability. So invariably there will be bugs. There will be some outages, but you know, one of the things that armory provides with Spinnaker open sources, the ability to create hardened deployment pipeline so that you're testing the right things at the right times with the right folks involved to do reviews. >>And if there is hopefully not, but if there is a problem in production, you're isolating that problem to a small group of users. And then we call this the progressive deployment or Canary deployment where you're deploying to a small number of users. You measure the results, make sure it's good, expand it and expand it. And so I think, you know, preventing outages is incredibly incredibly important. And then the last thing is being able to deploy multi target multi-cloud. And so in the AWS ecosystem, we're talking about ECS, EKS Lambda. And so I think that these pieces of value or kind of the, the pain points that, that enterprises face can resonate with a lot of companies out there, including ENN Patriot. And so I'll, I'll, I'll let you tell the story. >>Yeah, go ahead. Absolutely. Thanks. Thanks for the intro, man. So background background of our partnership with armory as back in the backend, February of 2019, we had a payments payments slowed down for payments processing, and we were risking not getting creators paid on time, which is a doc great for creators because they rely on us for income to be able to pay themselves, pay their rent or mortgage, but also pay staff because they have video editors, website admins, people that nature work with them. And there were, they're a very, there's a very many root causes to this, to this incident, all kind of culminate at once. One of the things that we saw was that deploying D point fixes to remediate. This took too long or taking at least 45 minutes to deploy a new version of the application. And so we've had continuous delivery before using a custom custom home built, rolling deploy. >>We needed to get that time down. We also needed to be secure in our knowledge of like that deploy was stable. So we had had to place a break in the middle due to various factors that that can happen during the deploy previously, I had used a Spinnaker at previous employers. I have been set it up myself and introduced it. And I knew about, I knew like, oh, this is something we could, this would be great. But the Patriot team, the patron SRE team at that time was two people. So I don't have the ability to manage Spinnaker on my own. It's a complex open-source product. It can do a lot of things. There's a lot of knobs to tweak a lot of various settings and stuff you need to know about tangentially. One of the co-founders of, of armory had been, had to hit, had hit me up earlier. I was like, Hey, have you heard of armory? We're doing this thing, opens our Spinnaker, we're packaging this and managing it, check us out if you want. I kind of like filed it away. Like, okay, well that might be something we can use later. And then like two weeks later, I was like, oh wait, this company that does Spinnaker, I know of them. We should probably have a conversation with them and engage with them. >>And so you hit him up and said, Hey, too many knobs and buttons to push what's the deal. >>Yeah, exactly. Yeah. So I was, I was like, Hey, so by the way, I about that thing, how, how soon can you get someone get someone over here? >>So Ben take us through the progression. Cause that really is how things work in the open source. Open source is really one of those things where a lot of community outreach, a lot of people are literally a one degree or two separation from someone who either wrote the project or is involved in the project. Here's a great example. He saw the need for Spinnaker. The business model was there for him to solve. Okay. Fixes rolling deployments, homegrown all the things, pick your pick, your use case, but he wanted to make it easier. This tends to, this is kind of a pattern. What did you guys do? What's the next step? How did this go from here? >>Yeah. You know, Spinnaker being source is critical to armory's success. Many companies, not just pastry on open source software, I think is not really debatable anymore in terms of being applicable to enterprise companies. But the thing with selling open source software to large companies is that they need a backstop. They need not just enterprise support, but they need features and functionality that enable them to use that software at scale and safely. And so those are really the things that, that we focus on and we use open source as a really, it's a great community to collaborate and to contribute fixes that other companies can use. Other companies contribute fixes and functionality that we then use. But it's, it's really a great place to get feedback and to find new customers that perhaps need that enhanced level of functionality and support. And, and I'm very, very happy that Patrion was one of those companies. >>Okay. So let's talk about the Patrion. Okay. Obviously scaling is a big part of it. You're an SRE site, reliability engineers with folks who don't know what that is, is your, your job is essentially, you know, managing scale. Some say you the dev ops manager, but that's not really right answer. What is the SRE role at patriotics share with folks out there who are either having an SRE. They don't even know it yet or need to have SRS because this is a huge transition that, and new, new and emerging must have role in companies, >>Right? Yeah. We're the history of Patrion covers a lot. We cover a wide swath of a wide swath of, of, of things that we work with and, and areas that we consider to be our, our purview. Not only are we working on working with our AWS environment, but we also are involved in how can we make the site more reliable or performance so that, so that creators fans have a good experience. So we work with our content delivery numbers or caching strategies for caching caching assets. We work inside the application itself for doing performance performance, a hassle. This is also in proving observability with distributed tracing and metrics on a lot of that stuff, but also on the build and deploy side, if we can, if we can get that deploy time faster, like give engineers faster feedback on features that they're working on or bug fixes and also being secure and knowing that the, the code that they're working on it gets delivered reliably. >>Yeah. I think I, you have the continuous delivery is always the, the, the killer killer workflow as both the Spinnaker question here. Well, how has Spinnaker, well, what, how, how does Spinnaker being an open source project help you guys? I mean, obviously open source code is great. How has that been significant and beneficial for both armory and Patrion? >>Yeah, I'll take the first stab at this one. And it starts at the beginning. Spinnaker was created by Netflix and since Netflix open source that four or five years ago, there have been countless and significant contributions from many other companies, including armory, including AWS and those contributions collectively push the industry forward and allow the, the companies that, you know, that use open-source Spinnaker or armory, they can now benefit from all of the collective effort together. So just that community aspect working together is huge. Absolutely huge. And, you know, open source, I guess on the go-to-market side is a big driver for us. You know, there's many, many companies using open-source Spinnaker in production that are not our customers yet. And we, we survey them. We want to know how they're using open-source Spinnaker so that we can then improve open-source Spinnaker, but also build features that are critical for large companies to run at scale, deploy at scale, deploy with velocity and with reliability. >>Yeah. What's your take on, on the benefits of Spinnaker being open source? >>A lot of what Ben, it's been really beneficial to be able to like, be able to go in and look at the source code for components. I've been wondering something like, why is this thing working like this? Or how did they solve this? It's also been useful for, I can go ask the community for, for advice on things. If armory doesn't has the, it doesn't have the time or bandwidth to work on some things I've been able to ask the special interest groups in the source community. Like, can we, can we help improve this or something like that. And I've also been able to commit simple bug fixes for features that I've, that I've needed. I was like, well, I don't need to, I don't need to go engage are very on this. I can just like, I can just write up a simple patch on and have that out for review. >>You know, that's the beautiful thing about open sources. You get the source code and that's, and some people just think it's so easy, Ben, you know, just, Hey, just give me the open source. I'll code it. I got an unlimited resource team. Not, not always the case. So I gotta ask you guys on Patrion. Why use a company like armory, if you have the open source code and armory, why did you build a business on the open source project? Like Spinnaker? >>Yeah. Like I see. Absolutely. Yeah. Like I, like I said earlier, the atrium, the Patrion SRE team was wasn't is fairly small. There's two people. Now we're six. People are still people down. We're six people now. So being sure we could run a Spinnaker on our own if we, if we wanted to. And, but then we'd have no time to do anything else basically. And that's not the best use of our, of our creators money. Our fans, the fans being the creators artists. We have obviously take a percentage on top of that. And we, we need to spend our, that money well, and having armory who's dedicated to the Spinnaker is dedicated, involved the open source project. But also there are experts on this Sunday. It was something that would take me like a week of stumbling around trying to find documentation on how to set this thing up. They done this like 15, 20 times and they can just go, oh yeah, this is what we do for this. And let me go fix it for you >>At score. You know, you've got a teammate. I think that's where, what you're getting at. I got to ask you what other things is that free you up? Because this is the classic business model of life. You know, you have a partner you're moving fast, it slows you down to get into it. Sure. You can do it yourself, but why it's faster to go with it, go together with a partner and a wing man as we will. What things did does that free you up to work on as an SRE? >>Oh, that's freed me up to work on a bigger parts of our build and deploy pipeline. It's freed me up to work on moving from a usage based deploys onto a containerization strategy. It's freed me up to work on more broader observability issues instead of just being laser-focused on running an operating spending. >>Yeah. And that really kind of highlights. I'm glad you said that because it highlights what's going on. You had a lot of speed and velocity. You've got scale, you've got security and you've got new challenges you got to fix in and move fast. It's a whole new world. So again, this is why I love cloud native. Right? So you got open source, you got scale and you guys are applying directly to the, to the infrastructure of the business. So Ben, I got to ask you armory. Co-founder why did you guys build your business on an open source project? Like Spinnaker? What was the mindset? How did you attack this? What did you guys do? Take us through that piece because this is truly a great entrepreneurial story about open source. >>Yeah. Yeah. I'll give you the abridged version, which is that my co-founders and I, we solved the same problem, which is CD at a previous company, but we did it kind of the old fashioned way we home role. We handled it ourselves. We built it on top of Jenkins and it was great for that company, but, and that was kind of the inspiration for us to then ask questions. Hey, is this bigger? We, when at the time we found that Spinnaker had just been, you know, dog food inside of Netflix and they were open sourcing it. And we thought it was a great opportunity for us to partner. But the bigger reason is that Spinnaker is a platform that deploys to other platforms like AWS and Kubernetes and the sheer amount of surface area that's required to build a great product is enormous. And I actually believe that the only way to be successful in this space is to be open source, to have a community of large companies and passionate developers that contribute the roads if you will, to deploy into various targets. >>And so that's the reason, number one for it being open source and us wanting to build our business on top of open source. And then the second reason is because we focus almost exclusively on solving enterprise scale problems. We have a platform that needs to be extensible and open source is by definition extensible. So our customers, I mean, Ian just had a great example, right? Like he needed to fix something he was able to do so solve it in open source. And then, you know, shortly thereafter that that fix in mainline gets into the armory official build and then he can consume his fix. So we see a lot of that from our other customers. And then even, you know, take a very, very large company. They may have custom off that they need to integrate with, but that doesn't, that's not in open-source Spinnaker, but they can go and build that themselves. >>Yeah, it's real. It really is the new modern way to develop. And I, you know, last 80 with startup showcase last season, Emily Freeman gave a talk on, you know, you know, retiring, I call it killing the software, SDLC, the lifecycle of how software was developed in the past. And I got to ask you guys, and, and this cube conversation is that this is kind of like the, the kind of the big wave we're on now is cloud scale, open source, cloud, native data security, all being built in on this in the pipelines to your point is SRS enabling a new infrastructure and a new environment for people to build essentially SAS. So I got to ask you guys as, and you mentioned it Ben, the old way you hand rolled something, Netflix, open source, something, you got to look at Lyft with Envoy. I mean, large-scale comes, are donating their stuff into open source and people getting on top of it and building it. So the world's changed. So we've got to ask you, what's the difference between standing up a SAS application today versus say five to eight years ago, because we all see salesforce.com. You know, they're out there, they built their own data center. Cloud skills changed the dynamics of how software is being built. And with open-source accelerating every quarter, you're seeing more growth in software. How has building a platform for applications changed and how has that changed? How people build SAS applications, Ben, what's your take on this? It's kind of a thought exercise here. >>Yeah. I mean, I wouldn't even call it a thought exercise. We're seeing it firsthand from our customers. And then I'll, you know, I'll, I'll give my answer and you can weigh in on like practical, like what you're actually doing at Patrion with SAS, but the, the costs and the kind of entry fee, if you will, for building a SAS application has tremendously dropped. You don't need to buy servers and put them inside data centers anymore. You just spin up a VM or Kubernetes cluster with AWS. AWS has led the way in public cloud to make this incredible easy. And the tool sets being built around cloud native, like armory and like many other companies in the space are making it even easier. So we're just seeing the proliferation of, of software being developed and, and hopefully, you know, armory is playing a role in, in making it easier and better. >>So before we get to Unum for a second, I just want to just double down on it because there's great conversation that implies that there's going to be a new migration of apps everywhere, right. As tsunami of clutter good or bad, is that good or bad or is it all open source? Is it all good then? >>Absolutely good. For sure. There will be, you know, good stuff developed and not so good stuff developed, but survival of the fittest will hopefully promote those, the best apps with the highest value to the end user and, and society at large and push us all forward. So, >>And what's your take, obviously, Kubernetes, you seeing things like observability talking about how we're managing stateful and services that are being deployed and tear down in real time, automated, all new things are developing. How does building a true scalable SAS application change today versus say five, eight years ago? >>I mean, like you said, there's a, there's a lot, there's a lot of new, both open source. So SAS products available that you can use to build a scale stuff. Like if you're going to need that to build like secure authentication, instead of having to roll that out and you could go with something like Okta raw zero, you can just pull that off the shelf stuff for like managing push notifications before that was like something really hard to really hard to do. Then Firebase came on the scene and also for manic state and application and stuff like that. And also for like being, being able to deliver before >>You had Jenkins, maybe even for that, you didn't really have anything Jenkins came along. And then now you have open-source products like Spinnaker that you can use to deliver. And then you have companies built around that, that you can just go and say, Hey, can you please help us deliver this? Like you just help us, enable us to be able to build, build our products so that we can focus on delivering value to our creators and fans instead of having to focus on, on other things. >>So bill it builds faster. You can compose stuff faster. You don't have to roll your own code. You can just roll your own modules basically, and then exactly what prietary on top of it. Absolutely. Yeah. And that's why commercial open source is booming. Guys. Thank you so much, Ben, congratulations on armory and great to have you on from Patrion well-known success. So we'll accompany you congratulate. If we don't know patriarch, check it out, they have changed the game on creators and leading the industry. Ben. Great, great shot with armory and Spinnaker. Thanks for coming on. Thank you >>So much. Thank you >>So much. Okay. I'm Sean Ferrer here with the cube conversation with Palo Alto. Thanks for watching.

(upbeat music) >> Hello and welcome to this CUBE conversation here presenting the "AWS Startup Showcase: "New Breakthroughs in DevOps, Data Analytics "and Cloud Management Tools" featuring Opsani for the cloud management and migration track here today, I'm your host John Furrier. Today, we're joined by Patrick Conte, Chief Commercial Officer, Opsani. Thanks for coming on. Appreciate you coming on. Future of AI operations. >> Thanks, John. Great to be here. Appreciate being with you. >> So congratulations on all your success being showcased here as part of the Startups Showcase, future of AI operations. You've got the cloud scale happening. A lot of new transitions in this quote digital transformation as cloud scales goes next generation. DevOps revolution as Emily Freeman pointed out in her keynote. What's the problem statement that you guys are focused on? Obviously, AI involves a lot of automation. I can imagine there's a data problem in there somewhere. What's the core problem that you guys are focused on? >> Yeah, it's interesting because there are a lot of companies that focus on trying to help other companies optimize what they're doing in the cloud, whether it's cost or whether it's performance or something else. We felt very strongly that AI was the way to do that. I've got a slide prepared, and maybe we can take a quick look at that, and that'll talk about the three elements or dimensions of the problem. So we think about cloud services and the challenge of delivering cloud services. You've really got three things that customers are trying to solve for. They're trying to solve for performance, they're trying to solve for the best performance, and, ultimately, scalability. I mean, applications are growing really quickly especially in this current timeframe with cloud services and whatnot. They're trying to keep costs under control because certainly, it can get way out of control in the cloud since you don't own the infrastructure, and more importantly than anything else which is why it's at the bottom sort of at the foundation of all this, is they want their applications to be a really a good experience for their customers. So our customer's customer is actually who we're trying to solve this problem for. So what we've done is we've built a platform that uses AI and machine learning to optimize, meaning tune, all of the key parameters of a cloud application. So those are things like the CPU usage, the memory usage, the number of replicas in a Kubernetes or container environment, those kinds of things. It seems like it would be simple just to grab some values and plug 'em in, but it's not. It's actually the combination of them has to be right. Otherwise, you get delays or faults or other problems with the application. >> Andrew, if you can bring that slide back up for a second. I want to just ask one quick question on the problem statement. You got expenditures, performance, customer experience kind of on the sides there. Do you see this tip a certain way depending upon use cases? I mean, is there one thing that jumps out at you, Patrick, from your customer's customer's standpoint? Obviously, customer experience is the outcome. That's the app, whatever. That's whatever we got going on there. >> Sure. >> But is there patterns 'cause you can have good performance, but then budget overruns. Or all of them could be failing. Talk about this dynamic with this triangle. >> Well, without AI, without machine learning, you can solve for one of these, only one, right? So if you want to solve for performance like you said, your costs may overrun, and you're probably not going to have control of the customer experience. If you want to solve for one of the others, you're going to have to sacrifice the other two. With machine learning though, we can actually balance that, and it isn't a perfect balance, and the question you asked is really a great one. Sometimes, you want to over-correct on something. Sometimes, scalability is more important than cost, but what we're going to do because of our machine learning capability, we're going to always make sure that you're never spending more than you should spend, so we're always going to make sure that you have the best cost for whatever the performance and reliability factors that you you want to have are. >> Yeah, I can imagine. Some people leave services on. Happened to us one time. An intern left one of the services on, and like where did that bill come from? So kind of looked back, we had to kind of fix that. There's a ton of action, but I got to ask you, what are customers looking for with you guys? I mean, as they look at Opsani, what you guys are offering, what's different than what other people might be proposing with optimization solutions? >> Sure. Well, why don't we bring up the second slide, and this'll illustrate some of the differences, and we can talk through some of this stuff as well. So really, the area that we play in is called AIOps, and that's sort of a new area, if you will, over the last few years, and really what it means is applying intelligence to your cloud operations, and those cloud operations could be development operations, or they could be production operations. And what this slide is really representing is in the upper slide, that's sort of the way customers experience their DevOps model today. Somebody says we need an application or we need a feature, the developers pull down something from get. They hack an early version of it. They run through some tests. They size it whatever way they know that it won't fail, and then they throw it over to the SREs to try to tune it before they shove it out into production, but nobody really sizes it properly. It's not optimized, and so it's not tuned either. When it goes into production, it's just the first combination of settings that work. So what happens is undoubtedly, there's some type of a problem, a fault or a delay, or you push new code, or there's a change in traffic. Something happens, and then, you've got to figure out what the heck. So what happens then is you use your tools. First thing you do is you over-provision everything. That's what everybody does, they over-provision and try to soak up the problem. But that doesn't solve it because now, your costs are going crazy. You've got to go back and find out and try as best you can to get root cause. You go back to the tests, and you're trying to find something in the test phase that might be an indicator. Eventually your developers have to hack a hot fix, and the conveyor belt sort of keeps on going. We've tested this model on every single customer that we've spoken to, and they've all said this is what they experience on a day-to-day basis. Now, if we can go back to the side, let's talk about the second part which is what we do and what makes us different. So on the bottom of this slide, you'll see it's really a shift-left model. What we do is we plug in in the production phase, and as I mentioned earlier, what we're doing is we're tuning all those cloud parameters. We're tuning the CPU, the memory, the Replicas, all those kinds of things. We're tuning them all in concert, and we're doing it at machine speed, so that's how the customer gets the best performance, the best reliability at the best cost. That's the way we're able to achieve that is because we're iterating this thing in machine speed, but there's one other place where we plug in and we help the whole concept of AIOps and DevOps, and that is we can plug in in the test phase as well. And so if you think about it, the DevOps guy can actually not have to over-provision before he throws it over to the SREs. He can actually optimize and find the right size of the application before he sends it through to the SREs, and what this does is collapses the timeframe because it means the SREs don't have to hunt for a working set of parameters. They get one from the DevOps guys when they send it over, and this is how the future of AIOps is being really affected by optimization and what we call autonomous optimization which means that it's happening without humans having to press a button on it. >> John: Andrew, bring that slide back up. I want to just ask another question. Tuning in concert thing is very interesting to me. So how does that work? Are you telegraphing information to the developer from the autonomous workload tuning engine piece? I mean, how does the developer know the right knobs or where does it get that provisioning information? I see the performance lag. I see where you're solving that problem. >> Sure. >> How does that work? >> Yeah, so actually, if we go to the next slide, I'll show you exactly how it works. Okay, so this slide represents the architecture of a typical application environment that we would find ourselves in, and inside the dotted line is the customer's application namespace. That's where the app is. And so, it's got a bunch of pods. It's got a horizontal pod. It's got something for replication, probably an HPA. And so, what we do is we install inside that namespace two small instances. One is a tuning pod which some people call a canary, and that tuning pod joins the rest of the pods, but it's not part of the application. It's actually separate, but it gets the same traffic. We also install somebody we call Servo which is basically an action engine. What Servo does is Servo takes the metrics from whatever the metric system is is collecting all those different settings and whatnot from the working application. It could be something like Prometheus. It could be an Envoy Sidecar, or more likely, it's something like AppDynamics, or we can even collect metrics off of Nginx which is at the front of the service. We can plug into anywhere where those metrics are. We can pull the metrics forward. Once we see the metrics, we send them to our backend. The Opsani SaaS service is our machine learning backend. That's where all the magic happens, and what happens then is that service sees the settings, sends a recommendation to Servo, Servo sends it to the tuning pod, and we tune until we find optimal. And so, that iteration typically takes about 20 steps. It depends on how big the application is and whatnot, how fast those steps take. It could be anywhere from seconds to minutes to 10 to 20 minutes per step, but typically within about 20 steps, we can find optimal, and then we'll come back and we'll say, "Here's optimal, and do you want to "promote this to production," and the customer says, "Yes, I want to promote it to production "because I'm saving a lot of money or because I've gotten "better performance or better reliability." Then, all he has to do is press a button, and all that stuff gets sent right to the production pods, and all of those settings get put into production, and now he's now he's actually saving the money. So that's basically how it works. >> It's kind of like when I want to go to the beach, I look at the weather.com, I check the forecast, and I decide whether I want to go or not. You're getting the data, so you're getting a good look at the information, and then putting that into a policy standpoint. I get that, makes total sense. Can I ask you, if you don't mind, expanding on the performance and reliability and the cost advantage? You mentioned cost. How is that impacting? Give us an example of some performance impact, reliability, and cost impacts. >> Well, let's talk about what those things mean because like a lot of people might have different ideas about what they think those mean. So from a cost standpoint, we're talking about cloud spend ultimately, but it's represented by the settings themselves, so I'm not talking about what deal you cut with AWS or Azure or Google. I'm talking about whatever deal you cut, we're going to save you 30, 50, 70% off of that. So it doesn't really matter what cost you negotiated. What we're talking about is right-sizing the settings for CPU and memory, Replica. Could be Java. It could be garbage collection, time ratios, or heap sizes or things like that. Those are all the kinds of things that we can tune. The thing is most of those settings have an unlimited number of values, and this is why machine learning is important because, if you think about it, even if they only had eight settings or eight values per setting, now you're talking about literally billions of combinations. So to find optimal, you've got to have machine speed to be able to do it, and you have to iterate very, very quickly to make it happen. So that's basically the thing, and that's really one of the things that makes us different from anybody else, and if you put that last slide back up, the architecture slide, for just a second, there's a couple of key words at the bottom of it that I want to want to focus on, continuous. So continuous really means that we're on all the time. We're not plug us in one time, make a change, and then walk away. We're actually always measuring and adjusting, and the reason why this is important is in the modern DevOps world, your traffic level is going to change. You're going to push new code. Things are going to happen that are going to change the basic nature of the software, and you have to be able to tune for those changes. So continuous is very important. Second thing is autonomous. This is designed to take pressure off of the SREs. It's not designed to replace them, but to take the pressure off of them having to check pager all the time and run in and make adjustments, or try to divine or find an adjustment that might be very, very difficult for them to do so. So we're doing it for them, and that scale means that we can solve this for, let's say, one big monolithic application, or we can solve it for literally hundreds of applications and thousands of microservices that make up those applications and tune them all at the same time. So the same platform can be used for all of those. You originally asked about the parameters and the settings. Did I answer the question there? >> You totally did. I mean, the tuning in concert. You mentioned early as a key point. I mean, you're basically tuning the engine. It's not so much negotiating a purchase SaaS discount. It's essentially cost overruns by the engine, either over burning or heating or whatever you want to call it. I mean, basically inefficiency. You're tuning the core engine. >> Exactly so. So the cost thing is I mentioned is due to right-sizing the settings and the number of Replicas. The performance is typically measured via latency, and the reliability is typically measured via error rates. And there's some other measures as well. We have a whole list of them that are in the application itself, but those are the kinds of things that we look for as results. When we do our tuning, we look for reducing error rates, or we look for holding error rates at zero, for example, even if we improve the performance or we improve the cost. So we're looking for the best result, the best combination result, and then a customer can decide if they want to do so to actually over-correct on something. We have the whole concept of guard rail, so if performance is the most important thing, or maybe some customers, cost is the most important thing, they can actually say, "Well, give us the best cost, "and give us the best performance and the best reliability, "but at this cost," and we can then use that as a service-level objective and tune around it. >> Yeah, it reminds me back in the old days when you had filtering white lists of black lists of addresses that can go through, say, a firewall or a device. You have billions of combinations now with machine learning. It's essentially scaling the same concept to unbelievable. These guardrails are now in place, and that's super cool and I think really relevant call-out point, Patrick, to kind of highlight that. At this kind of scale, you need machine learning, you need the AI to essentially identify quickly the patterns or combinations that are actually happening so a human doesn't have to waste their time that can be filled by basically a bot at that point. >> So John, there's just one other thing I want to mention around this, and that is one of the things that makes us different from other companies that do optimization. Basically, every other company in the optimization space creates a static recommendation, basically their recommendation engines, and what you get out of that is, let's say it's a manifest of changes, and you hand that to the SREs, and they put it into effect. Well, the fact of the matter is is that the traffic could have changed then. It could have spiked up, or it could have dropped below normal. You could have introduced a new feature or some other code change, and at that point in time, you've already instituted these changes. They may be completely out of date. That's why the continuous nature of what we do is important and different. >> It's funny, even the language that we're using here: network, garbage collection. I mean, you're talking about tuning an engine, am operating system. You're talking about stuff that's moving up the stack to the application layer, hence this new kind of eliminating of these kind of siloed waterfall, as you pointed out in your second slide, is kind of one integrated kind of operating environment. So when you have that or think about the data coming in, and you have to think about the automation just like self-correcting, error-correcting, tuning, garbage collection. These are words that we've kind of kicking around, but at the end of the day, it's an operating system. >> Well in the old days of automobiles, which I remember cause I'm I'm an old guy, if you wanted to tune your engine, you would probably rebuild your carburetor and turn some dials to get the air-oxygen-gas mix right. You'd re-gap your spark plugs. You'd probably make sure your points were right. There'd be four or five key things that you would do. You couldn't do them at the same time unless you had a magic wand. So we're the magic wand that basically, or in modern world, we're sort of that thing you plug in that tunes everything at once within that engine which is all now electronically controlled. So that's the big differences as you think about what we used to do manually, and now, can be done with automation. It can be done much, much faster without humans having to get their fingernails greasy, let's say. >> And I think the dynamic versus static is an interesting point. I want to bring up the SRE which has become a role that's becoming very prominent in the DevOps kind of plus world that's happening. You're seeing this new revolution. The role of the SRE is not just to be there to hold down and do the manual configuration. They had a scale. They're a developer, too. So I think this notion of offloading the SRE from doing manual tasks is another big, important point. Can you just react to that and share more about why the SRE role is so important and why automating that away through when you guys have is important? >> The SRE role is becoming more and more important, just as you said, and the reason is because somebody has to get that application ready for production. The DevOps guys don't do it. That's not their job. Their job is to get the code finished and send it through, and the SREs then have to make sure that that code will work, so they have to find a set of settings that will actually work in production. Once they find that set of settings, the first one they find that works, they'll push it through. It's not optimized at that point in time because they don't have time to try to find optimal, and if you think about it, the difference between a machine learning backend and an army of SREs that work 24-by-seven, we're talking about being able to do the work of many, many SREs that never get tired, that never need to go play video games, to unstress or whatever. We're working all the time. We're always measuring, adjusting. A lot of the companies we talked to do a once-a-month adjustment on their software. So they put an application out, and then they send in their SREs once a month to try to tune the application, and maybe they're using some of these other tools, or maybe they're using just their smarts, but they'll do that once a month. Well, gosh, they've pushed code probably four times during the month, and they probably had a bunch of different spikes and drops in traffic and other things that have happened. So we just want to help them spend their time on making sure that the application is ready for production. Want to make sure that all the other parts of the application are where they should be, and let us worry about tuning CPU, memory, Replica, job instances, and things like that so that they can work on making sure that application gets out and that it can scale, which is really important for them, for their companies to make money is for the apps to scale. >> Well, that's a great insight, Patrick. You mentioned you have a lot of great customers, and certainly if you have your customer base are early adopters, pioneers, and grow big companies because they have DevOps. They know that they're seeing a DevOps engineer and an SRE. Some of the other enterprises that are transforming think the DevOps engineer is the SRE person 'cause they're having to get transformed. So you guys are at the high end and getting now the new enterprises as they come on board to cloud scale. You have a huge uptake in Kubernetes, starting to see the standardization of microservices. People are getting it, so I got to ask you can you give us some examples of your customers, how they're organized, some case studies, who uses you guys, and why they love you? >> Sure. Well, let's bring up the next slide. We've got some customer examples here, and your viewers, our viewers, can probably figure out who these guys are. I can't tell them, but if they go on our website, they can sort of put two and two together, but the first one there is a major financial application SaaS provider, and in this particular case, they were having problems that they couldn't diagnose within the stack. Ultimately, they had to apply automation to it, and what we were able to do for them was give them a huge jump in reliability which was actually the biggest problem that they were having. We gave them 5,000 hours back a month in terms of the application. They were they're having pager duty alerts going off all the time. We actually gave them better performance. We gave them a 10% performance boost, and we dropped their cloud spend for that application by 72%. So in fact, it was an 80-plus % price performance or cost performance improvement that we gave them, and essentially, we helped them tune the entire stack. This was a hybrid environment, so this included VMs as well as more modern architecture. Today, I would say the overwhelming majority of our customers have moved off of the VMs and are in a containerized environment, and even more to the point, Kubernetes which we find just a very, very high percentage of our customers have moved to. So most of the work we're doing today with new customers is around that, and if we look at the second and third examples here, those are examples of that. In the second example, that's a company that develops websites. It's one of the big ones out in the marketplace that, let's say, if you were starting a new business and you wanted a website, they would develop that website for you. So their internal infrastructure is all brand new stuff. It's all Kubernetes, and what we were able to do for them is they were actually getting decent performance. We held their performance at their SLO. We achieved a 100% error-free scenario for them at runtime, and we dropped their cost by 80%. So for them, they needed us to hold-serve, if you will, on performance and reliability and get their costs under control because everything in that, that's a cloud native company. Everything there is cloud cost. So the interesting thing is it took us nine steps because nine of our iterations to actually get to optimal. So it was very, very quick, and there was no integration required. In the first case, we actually had to do a custom integration for an underlying platform that was used for CICD, but with the- >> John: Because of the hybrid, right? >> Patrick: Sorry? >> John: Because it was hybrid, right? >> Patrick: Yes, because it was hybrid, exactly. But within the second one, we just plugged right in, and we were able to tune the Kubernetes environment just as I showed in that architecture slide, and then the third one is one of the leading application performance monitoring companies on the market. They have a bunch of their own internal applications and those use a lot of cloud spend. They're actually running Kubernetes on top of VMs, but we don't have to worry about the VM layer. We just worry about the Kubernetes layer for them, and what we did for them was we gave them a 48% performance improvement in terms of latency and throughput. We dropped their error rates by 90% which is pretty substantial to say the least, and we gave them a 50% cost delta from where they had been. So this is the perfect example of actually being able to deliver on all three things which you can't always do. It has to be, sort of all applications are not created equal. This was one where we were able to actually deliver on all three of the key objectives. We were able to set them up in about 25 minutes from the time we got started, no extra integration, and needless to say, it was a big, happy moment for the developers to be able to go back to their bosses and say, "Hey, we have better performance, "better reliability. "Oh, by the way, we saved you half." >> So depending on the stack situation, you got VMs and Kubernetes on the one side, cloud-native, all Kubernetes, that's dream scenario obviously. Not many people like that. All the new stuff's going cloud-native, so that's ideal, and then the mixed ones, Kubernetes, but no VMs, right? >> Yeah, exactly. So Kubernetes with no VMs, no problem. Kubernetes on top of VMs, no problem, but we don't manage the VMs. We don't manage the underlay at all, in fact. And the other thing is we don't have to go back to the slide, but I think everybody will remember the slide that had the architecture, and on one side was our cloud instance. The only data that's going between the application and our cloud instance are the settings, so there's never any data. There's never any customer data, nothing for PCI, nothing for HIPPA, nothing for GDPR or any of those things. So no personal data, no health data. Nothing is passing back and forth. Just the settings of the containers. >> Patrick, while I got you here 'cause you're such a great, insightful guest, thank you for coming on and showcasing your company. Kubernetes real quick. How prevalent is this mainstream trend is because you're seeing such great examples of performance improvements. SLAs being met, SLOs being met. How real is Kubernetes for the mainstream enterprise as they're starting to use containers to tip their legacy and get into the cloud-native and certainly hybrid and soon to be multi-cloud environment? >> Yeah, I would not say it's dominant yet. Of container environments, I would say it's dominant now, but for all environments, it's not. I think the larger legacy companies are still going through that digital transformation, and so what we do is we catch them at that transformation point, and we can help them develop because as we remember from the AIOps slide, we can plug in at that test level and help them sort of pre-optimize as they're coming through. So we can actually help them be more efficient as they're transforming. The other side of it is the cloud-native companies. So you've got the legacy companies, brick and mortar, who are desperately trying to move to digitization. Then, you've got the ones that are born in the cloud. Most of them aren't on VMs at all. Most of them are on containers right from the get-go, but you do have some in the middle who have started to make a transition, and what they've done is they've taken their native VM environment and they've put Kubernetes on top of it so that way, they don't have to scuttle everything underneath it. >> Great. >> So I would say it's mixed at this point. >> Great business model, helping customers today, and being a bridge to the future. Real quick, what licensing models, how to buy, promotions you have for Amazon Web Services customers? How do people get involved? How do you guys charge? >> The product is licensed as a service, and the typical service is an annual. We license it by application, so let's just say you have an application, and it has 10 microservices. That would be a standard application. We'd have an annual cost for optimizing that application over the course of the year. We have a large application pack, if you will, for let's say applications of 20 services, something like that, and then we also have a platform, what we call Opsani platform, and that is for environments where the customer might have hundreds of applications and-or thousands of services, and we can plug into their deployment platform, something like a harness or Spinnaker or Jenkins or something like that, or we can plug into their their cloud Kubernetes orchestrator, and then we can actually discover the apps and optimize them. So we've got environments for both single apps and for many, many apps, and with the same platform. And yes, thanks for reminding me. We do have a promotion for for our AWS viewers. If you reference this presentation, and you look at the URL there which is opsani.com/awsstartupshowcase, can't forget that, you will, number one, get a free trial of our software. If you optimize one of your own applications, we're going to give you an Oculus set of goggles, the augmented reality goggles. And we have one other promotion for your viewers and for our joint customers here, and that is if you buy an annual license, you're going to get actually 15 months. So that's what we're putting on the table. It's actually a pretty good deal. The Oculus isn't contingent. That's a promotion. It's contingent on you actually optimizing one of your own services. So it's not a synthetic app. It's got to be one of your own apps, but that's what we've got on the table here, and I think it's a pretty good deal, and I hope your guys take us up on it. >> All right, great. Get Oculus Rift for optimizing one of your apps and 15 months for the price of 12. Patrick, thank you for coming on and sharing the future of AIOps with you guys. Great product, bridge to the future, solving a lot of problems. A lot of use cases there. Congratulations on your success. Thanks for coming on. >> Thank you so much. This has been excellent, and I really appreciate it. >> Hey, thanks for sharing. I'm John Furrier, your host with theCUBE. Thanks for watching. (upbeat 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 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)

>>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, cloud >>Native Computing foundation >>and ecosystem partners. >>Welcome back to the cubes coverage of coupon 21 cloud native con 21 part of the C N C s annual event this year. It's Virtual. Again, I'm john Kerry host of the cube and we have two great guests from the C N C. F. Cheryl Hung VP of ecosystems and Katie Manji who's the ecosystem advocate for C N C F. Thanks for coming on. Great to see you. I wish we were in person soon, maybe in the fall. Cheryl Katie, thanks for coming on. >>Um, definitely hoping to be back in person again soon, but john great to see you and great to be back on the >>cube. You know, I have to say one of the things that really surprised me is the resilience of the community around what's been happening with the virtual in the covid. Actually, a lot of people have been, um, you know, disrupted by this, but you know, the consensus is that developers have used to been working remotely and virtually in a home and so not too much disruption, but a hell of a lot of productivity. You're seeing a lot more cloud native, um, projects, you're seeing a lot more mainstreaming and the enterprise, you're starting to see cloud growth, just a really kind of nice growth. And we've been saying for years, rising tide floats, all boats, Cheryl, but this year you're starting to see real mainstream adoption with cloud native and this has really been part of the work of the community you guys have done. So what's your take on this? Because we're going to be coming out of this Covid pretty soon. There's a post covid light at the end of the tunnel. What's your view? >>Yeah, definitely, fingers crossed on that. I mean, I would love Katie to give her view on this. In fact, because she came from Conde Nast and American Express, both huge companies that were adopting have adopted cloud Native successfully. And then in the middle of the pandemic, in the middle of Covid, she joined CN CF. So Katie really has a view from the trenches and Katie would love to hear your thoughts. >>Yeah, absolutely. Uh, definitely cloud native adoption when it comes to the tooling has been more permanent in the enterprises. And that has been confirmed of my role at American Express. That is the role I moved from towards C N C F. But the more surprising thing is that we see big companies, we see banks and financial organization that are looking to adopt open source. But more importantly, they're looking for ways to either contribute or actually to direct it more into these areas. So from that perspective, I've been pretty much at the nucleus of enterprise of the adoption of cloud Native is definitely moving, it's slow paced, but it's definitely forward moving as well. Um and now I think while I'm in the role with C N C F as an ecosystem advocate and leading the end user community, there has been definitely uh the community is growing um always intrigued to find out more about the cloud Native usage is one of the things that I find quite intriguing is the fact that not one cloud native usage, like usage of covering just one platform, which is going to be called, the face is going to be the same. So it's always intriguing to find new use cases, find those extremist cases as well, that it really pushes the community forward. >>I want to do is unpack. The end user aspect of this has been a hallmark of the CNC F for years, always been a staple of the organization. But this year, more than ever it's been, seems to be prominent as people are integrating in what about the growth? I mean from last year this year and the use and user ecosystem, how have you guys seen the growth? Is there any highlights because have any stats and or observations around how the ecosystem is growing around the end user piece? >>Sure, absolutely. I mean, I can talk directly about C N C F and the C N C F. End user community, much like everything else, you know, covid kind of slowed things down, so we're kind of not entirely surprised by that, But we're still going over 2020 and in fact just in the last few months have brought in some really, really big names like Peloton, Airbnb, Citibank, um, just some incredible organizations who are, who have really adopted card native, who have seen the success and the benefits of it. And now we're looking to give back to the community, as Katie said, get involved with open source and be more than just a passive consumer of the technologies, but actually become leaders in their own right, >>Katie talk about the dynamic of developers that end user organizations. I mean, you have been there, you're now you've been on both sides of the table if you will not to the sides of the table, it's more like a round table if you will, but community driven. But traditional, uh, end user organizations, not the early adopters, not the hyper scale is, but the ones now are really embedding hybrid, um, are changing how I t to how modern applications being built. That's a big theme in these mainstream organizations. What's the dynamic going on? What's your view? >>I think for any organization, the kind of the core, what moves the organization towards cloud Native is um pretty much being ahead of your competitors. And now we have this mass of different organization of the cloud native and that's why we see more kind of ice towards this area. So um definitely in this perspective when it comes to the technology aspect, companies are looking to deploy complex application in an easier manner, especially when it comes to pushing them to production system securely faster. Um and continuously as well. They're looking to have this competitive edge when it comes to how can they quickly respond to customer feedback? And as well they're looking for this um hybrid element that has been, has been talked about. Again, we're talking about enterprise is not just about public cloud, it's about how can we run the application security and getting both an element of data centers or private cloud as well. And now we see a lot of projects which are balancing around that age but more importantly there is adoption and where there's adoption, there is a feedback loop and that's how which represents the organic growth. >>That's awesome. Cheryl like you to define what you mean when you say end user driven open source, what does that mean? >>Mm This is a really interesting dynamic that I've seen over the last couple of years. So what we see is that more and more of the open source project, our end users who who are solving their own problems and creating their own projects and donating these back to the community. An early example of this was Envoy and lift and Yeager from Uber but Spotify also recently donated backstage, which is a developer portal which has really taken off. We've also got examples from Intuit Donating Argo. Um I'm sure there are some others that I've just forgotten. But the really interesting thing I see about this is that class classically right. Maybe a few years ago, if you were an end user organization, you get involved through a vendor, you'd go to a red hat or something and say, hey, you fix this on my behalf because you know that's what I'm paying you to do. Whereas what I see now is and user saying we want to keep this expertise in house and we want to be owners of our own kind of direction and our own fate when it comes to these open source projects. And that's been a big driver for this trend of open source and user driven, open source. >>It's really the open model is just such a great thing. And I think one of the interesting thing is that fits in with a lot of people who want to work from mission driven companies, but here there's actually a business benefit as you pointed out as in terms of the dynamic of bringing stuff to the community. This is interesting. I'm sure that the ability to do more collaboration, um, either hiring or contributing kind of increases when you have this end user dynamic because that's a pretty big decision to donate and bring something into the open source. What's the playbook though? If I'm sitting in an end user organization like american express Katie or a big company, say, hey, you know, we really developed this really killer use cases niche to us, but we want to bring it to the community. What do they do? Is there like a, like a manager? Do they knock on someone's door? Zara repo is, I mean, how does someone, I mean, how does an end user get this done? >>Mm. Um, I think one of the best resources out there is called the to do group, which is a organization underneath the Linux foundation. So it's kind of a sister group to C N C F, which is about open source program offices. And how do you formalize such an open source program? Because it's pretty easy to say, oh well just put something on get hub. But that's not the end of the story, right? Um, if you want to actually build a community, if you want other people to contribute, then you do actually have to do more than just drop it and get up and walk away. So I would say that if you are an end user company and you have created something which scratches your own itch and you think other people could benefit from it then definitely come. And like you could email me, you could email Chris and chick who is the ceo of C N C F and just get in touch and sort of ask around about what are the things that you could do in terms of what you have to think about the licensing, How do you develop a community governance program, um, trademark issues, all of these things. >>It's interesting how open source is growing so much now, chris has got so much action going on. New verticals are opening up, you know, so, so much action Cheryl you had posted on the internet predictions for cloud native, which I found interesting because there's so much action going on, you have to break things out into pillars, tech devops and ecosystem, each one kind of with a slew event of key trends. So take us through the mindset, why break it out like that? You got tech devops and ecosystem tradition that was all kind of bundled in one. Why? Why the pillars? And is it because there's so much action, what's, what's the basis behind the prediction? >>Um so originally this was just a giant list of things I had seen from talking to people and reading around and seeing what people are talking about on social media. Um And when, once I invested at these 10, I thought about what, what does this actually mean for the people who are going to look at this list and what should they care about? So I see tech trends as things related to tools, frameworks. Um, perhaps architects I see develops as people who are more as a combination of process, things that a combination of process and people and culture best practices and then ecosystem was kind of anything else broader than that. Things that happened across organizations. So you can definitely go to my twitter, you can go to at boy Chevelle, O I C H E R Y L and take a look at this and This is my list of 10. I would love to hear from you whether you agree with it, whether you think there are other things that I've missed or what would your >>table. I love. I love the top. Well, first of all I think this is very relevant. The one that I would ask you on is more rust and cloud native. That's the number one item. Um, I think cross cloud is definitely totally happening, I think people are really starting to think about that and so I'd love to get your comments on that. But I think the thing that jumped out at me was the devops piece because this is a trend that I've been seeing a lot more certainly even in academic institutions, for folks in school, right? Um going to college for computer science and engineering. This idea of, sorry, large scale, cloud is not so much an IT practice, it's much more of a cloud native mindset. So I think this idea of of ops so much more about scale. I use SRE only because I can't think of a better word around it and certainly the edge pieces with kubernetes, I think this is the, I think the biggest story to me that's where all the action seems to be when I talk to people around what they're working on in terms of training new people on boarding and what not Katie, you're shaking your head, you're like Yeah, what's your thoughts? Yeah, >>I have definitely been uh through all of these stages from having a team where the develops, I think it's more of a culture of like a pattern to adopt within an organization more than anything. So I've been pre develops within develops and actually during the evolution of it where we actually added an s every team as well. Um I think having these cultural changes with an organization, they are necessary, especially they want to iterate iterate quicker and actually deliver value to the customers with minimal agency because what it actually does there is the collaboration between teams which were initially segregated. And that's why I think there is a paradigm nowadays which is called deficit ops, which actually moves security more to its left. This has been very popular, especially in the, in the latest a couple of months. Lots of talks around it and even there is like a security co located event of Yukon just going to focus on that mainly. Um, but as well within the Devil's area, um, one of the models that has been quite permanent has been get ups as well, which pretty much uses the power of gIT repositories to describe the state of the applications, how it actually should be within the production system and within the cloud native ecosystem. There are two main tools that pretty much leave this area and there's going to be Argo City which has been donated by, into it, which is our end user And we have flux as well, which has been donated by we've works and both of these projects currently are within the incubation stage, which pretty much by default um showcases there is a lot of adoption from the organizations um more than 100 of for for some of them. So there is a wider adoption um, and everything I would like to mention is the get ups working group which has emerged I think between que con europe and north America last year and that again is more to define a manifest of how exactly get expert and should be adopted within organizations. So there is a lot of, I would say initiatives and this is further out they confirmed with the tooling that we have within the ecosystem. >>That's really awesome insight. I want to just, if you don't mind follow up on that, why is getups so important right now, Is it because the emphasis of security is that the emphasis of more scale, Is it just because it's pretty much kid was okay just because storing it over there, Is it because there's so much more inspections are going on around it? I mean code reviews have been going on for a long time. What's what's the big deal? Why is it so hot right now? In your opinion? >>I think there is definitely a couple of aspects that are quite important. You mentioned security, that's definitely one of them with the get ups battery. And there is a pool model rather than a push model. So you have the actual tool, for example, our great city of flux watching for repository and if any changes are identified is going to pull those changes automatically. So the first thing that we actually can see from this model is that we always will have a delta between what's within our depositors and the production system. Usually if you have a pool model, you can pull it uh can push the changes towards death staging environment but not always the production because you have the change window sometimes with the get ups model, you'll always be aware of what's the Dell. Can you have quite a nice way to visualize that especially for your city, which has the UI as well as well with the get ups pattern, there is less necessity to share the credentials with the actual pipeline tool. All of because Argo flux there are natively build around communities, all the secrets are going to be residing within the cluster. There is no need to share any extra credentials or an extra permissions with external tools as well. There are scale, there is again with kids who have historical data points which allows us to easily revert um to stable points of the applications in the past. So multiple, multiple benefits I would say, but definitely secured. I think it's one of the main one and it has been talked about quite a lot as well. >>A lot of these end user stories revolve around these dynamics and the ones you guys are promoting and from your members as well as in the community at large is I hate to use the word day two operations, but that really is the issue like okay, we're up and running. I want more automation. This is again tops kind of vibe here where it's like okay we gotta go troubleshoot all this, but it should be working as more stuff comes in. This becomes more and more the dynamic is that is that because of just more edges, more things, more devices, what's what's the what's the push behind all these stories around this automation and day to operation things? What do you guys think? >>I think, I think the expectations are getting higher and higher to be honest, a few years ago it was enough to use containers and start using the barest minimum, you know, to orchestrate those containers. But now what we see is that, you know, it's easy to choose the technology, it's easy to install it and even configure it. But as you said, john those data operations are really, really hard. For example, one of the ones that we've seen up and coming and we care about from CNCF is kubernetes on the edge. And we see this as enabling telco use cases and 5G and IOT and really, really broad, difficult use cases that just a few years ago would have been nice on impossible, Katie, your zone, Katie Katie, you also talk about edge. Right? >>Absolutely. I think I I really like to watch some of the talks that keep going, especially given by the big organizations that have to manage thousands or tens of thousands, hundreds of thousands of customers. And they have to deliver a cluster to these to these teams. Now, from their point of view, they pretty much have to manage clusters at scale. There is definitely the edge out there and they really kind of pushing the technology towards how can we get closer to the physical devices within the customers? Kind of uh, let's say bubble or area in surface. So age has been definitely something which has been moving a lot when it comes to the cloud native ecosystem. We've had a lot of projects moving to towards the incubation stage, carefree as has been there, um, for for a while and again, has a lot of adoption is known for its stability. But another thing that I would like to mention is that now currently we have a lot of projects that are age focus but within some box, so there is again, a lot of potential if there's gonna be a higher demand for this, I would expect this tools move from sandbox to incubation and even graduation. So that's definitely something which, uh, it's moving and there is dynamism around it. >>Well, Cheryl kid, you guys are awesome, love the work you're doing. I gotta ask the final question since you brought it up about the expectations. Cheryl, if you guys could both end the segment with the comment around expectations as the industry and companies and developers and participants continue to grow. What, what's changed with C N C F koo Kahne cloud, native khan as the expectation has been growing and the stakes are higher too, frankly, I mean you've got security, you mentioned these things edge get up, so you start to see the maturation of this ecosystem, what's new and what's expected of you guys, What do you see and how are you guys organizing? >>I think we can definitely say the ecosystem has matured a lot compared to a few years ago. Same with CNTF, same with Cuba con, I think the very first cubic on I went to was Berlin, which was about 1800 people. Um, the kind of mind boggling to see how much, how much it's grown since then. I mean one of the things that we try and do is to expand the number of people who can reach the community. So for example, we launched kubernetes community days and we launched, that means community organized events in africa, for example, for people who couldn't come to large events in north America or europe, um we also launching things to help students. I actually love talking to students because quite often now you talk to them and they say, oh, I've never run software in anything other than a container. You're like, yeah, well this was a new thing, this is brand new a few years ago and now you can be 18 and have never tried anything else. So it's pretty amazing. But yeah, there's definitely, there's always space to go to the community. >>Yeah, once you go cloud native, it's like, you know, like you've never load Lennox on them server before. I mean, what, what's going on? Get your thoughts as expectations go higher And certainly there's more in migration, not only for young folks because they're jumping into this was that engineering meets computer science is now cross discipline. You're seeing scale, you mentioned scaling up those are huge factors, you've got younger, you got cross training, you got cybersecurity and you've got Fin tech ops that's chris is working on so much is happening. What, what, what you guys keep up with your, how you gonna raise the ball? >>Absolutely. I think there's definitely technology moving forward, but I think nowadays there is a more need for actual end user stories while at the beginning of cube cons there is a lot of focus on the technical aspects. How can you fix this particular problem of deploying between two clusters are deploying at scale. There is like a lot of technical aspects nowadays they're looking for the stories because as I mentioned before, not one platform is gonna be the same when it comes to cloud native and I think there's still, the community is still trying to look for some patterns or some standards and we actually can see like especially when it comes to the open standards, we can see this moving within um the observe abilities like that application delivery will have for example cross plane and Que Bella we have open metrics and open tracing as well, which focuses on observe ability and all of the interfaces that we had around um, Cuban directory service men and so forth. All of these pretty much try to bring a benchmark, making it easier to integrate these special use cases um when it comes to actual extreme technology kind of solutions that you need to provide and um, I was mentioning the end user stories that are there more in demand nowadays mainly because these are very, very necessary from the community like for example the six or the project maintainers, they require feedback to actually move forward. And as part of that, I would like to mention that we've recently soft launched the injuries lounge, which really focuses on this particular aspect of end user stories. We try to pretty much question our end users and really understand what really moved them to adopt, coordinative, what keeps them on this path and what like future challenges they would like to um to tackle or are they facing the moment I would like to solve in the future. So we're trying to create the speed back home between the inducers and the projects out there. So I think this is something which needs to be a bit more closely together these two spheres, which currently are segregated, but we're trying to just solve that. >>Also you guys do great work, great job. Cheryl wrap us up real, take a minute to put a plug in for the C. N. C. F. In the ecosystem. What's the fashion this year? What's hot? What's the trend? What are you guys doing? Share some quick update on what's going on the ecosystem from your perspective? >>Yeah, I mean the ecosystem, even though I just said that we're maturing, you know, the growth has not stopped now, what we're seeing is these as Casey was saying, you know, more specific use cases, even bigger, even more demanding environments, even more kind of crazy use cases. I mean I love the story from the U. S. Department of Defense about putting kubernetes on their fighter jets and putting ston fighter jets, you know, it's just absurd to think about it, but I would say definitely come and be part of the community, share your stories, share what you know, help other people um if you are end user of these technologies then go to see NCF dot io slash and user and just come and be part of our community, you know, meet your peers and hear what everybody else is doing >>well. Having kubernetes and stu on jets, that's the Air Force, I would call that technical edge Katie to you know, bring, bring back the edge carol kitty, thank you so much for sharing the inside ecosystem is robust. Rising tide is floating all the boats as we always say here in the cube, it's been great to watch and continue to watch the rise. I think it's just the beginning, we're starting to see post pandemic visibility cloud native, more standards, more visibility into the economics and value and great to see the ecosystem rising up with the end users as well. So congratulations and thanks for coming up. >>Thank you so much, john it's a pleasure, appreciate >>it. Thank you for having us, john >>Great to have you on. I'm john for with the cube here for Coop Con Cloud, Native Con 21 virtual soon we'll be back in real life. Thanks for watching. Mhm.