>> Live from San Francisco. It's theCUBE. Covering DevNet Create 2017. Brought to you by Cisco. >> Welcome back everyone. We're here live in San Francisco for theCUBE's exclusive two days of coverage for Cisco Systems' inaugural event called DevNet Create extension. DevNet their classic developer program, for the Cisco install base of network routers. Now going to the cloud, native, going to the developer where dev-ops and the enterprise are connecting. I'm John Furrier, my cohost Peter Burris. Next is Dan Kohn, who is the Executive Director of the Cloud Native Compute Foundation, CNCF. Formerly known as Kubecon. Which is the event, Kubecon.io. Dan, great to see you. Executive Director, how's business, is going good? >> Fantastic! (John laughs) Yeah, six months ago we chatted at our last event in Seattle. And it's just amazing to see the progress since then. Projects members. >> It's been a whirlwind. Even I can't keep track. You guys are announcing all these new projects. What's the current count of projects that you guys have under the Cloud Native Compute Foundation? >> So we're up to 10. I should definitely start with the fact that Kubernetes is the anchor 10 in our original project. In a lot of ways, foundation was setup around that. And that project is just continuing to do incredibly well. Where it's one of the highest velocity projects in the history of open source. In terms of number of authors, number of commits, poll requests, issues. But now we have a constellation of other projects that are in support of that one. It can be used in a lot of different ways. >> John: Yeah. >> That we've been adding in. >> We had Craig McLuckie on earlier. Now he's with Heptio. Again, when he was doing that work, at Google, back in the days with what's his name from Microsoft now. >> Peter: Brendan Burns. >> Brendan Burns, yeah. >> Now it's an interesting question, where you say, oh, wait a minute, the three sort of key people behind Kubernetes, Craig McLuckie, Joe Beda, who's his co-founder at Heptio, then Brendan Burns, they all left Google. Is this a bad sign for the project and the technology? >> John: No, I don't think so. >> And we would say it's a spectacularly good sign. Now, if they had left and said, ah you know, containers, I'm going to do virtual machines. But in fact they said, there's such an enormous market for this. And to have Microsoft and Azure step in and say, we really want to invest in this space and we want to bring on one of the co-founders, Brendan. And for the other two co-founders, say, hey Google is making a huge investment. But we also think there's an opportunity for independent venture funded startup. >> Craig is completely passionate about this because there is an interoperability ethos that's always been around the open web. >> Dan: Umhmm. >> And certainly open source has the same ethos. Cloud Native brings an interesting thing, and it's clear now to people that there's not going to be one cloud winning them all. >> It's a multi-could world. >> Dan: Right. >> How is the Cloud Native Foundation floating in the open source world? Is it gravitating towards more infrastructure, more edge, software edge? Are you guys kind of in the middle? Are you guys the glue layer? How do you view that? >> Sure. So one way of looking at what we're doing is, helping to build a stack of software. That allows you to run your applications either on bare metal in your own data center or on any of the public clouds. Or hybrid solution where you're mixing back and forth. But the key idea is that all the core parts of that are open source. They're supported by multiple different vendors. And what that means is, you get to avoid lock-it. So today, Amazon web services has some of the most extraordinary engineering. They have all these great services that make it very easy to go onboard. But if you build your whole architecture around that, then you're stuck with AWS forever. And when time goes up, time to renegotiate your contract in a year or two, you're back again and don't have a lot of leverage. Where we think AWS is fantastic platform to run Kubernetes, to run our other projects on top of. But we don't think you want to lock-in to those services to such a degree. >> Okay, when I'm on, first of all, pretend I'm Amazon, I'm a competitive strategist, lock-in, I got to get you locked-in. I'm just going to run Kubernetes on Amazon. Why don't I just do that? >> We think that's a great solution. >> John: You do? >> Heptio and lots other folks make it very easy to run Kubernetes on Amazon. But we also think you should at least look at Kubernetes on Bluemix, on Google, on Azure. And know that in the future when you're negotiation comes up, even if you never leave, you at least threaten to leave. That you're not locked into that one vendor forever. >> So if you think about how the cloud industry structure is starting to layout, you knew we were going to have IAAS. >> Dan: Umhmm. >> SAS has been around for quite sometime. >> Dan: Right. >> The big question is what happens with that platform as a service. >> The developer world. >> Dan: Yeah. Some people think it's going to end up in the IAS element. >> Dan: Umhmm. Some people end up in the SAS. If it ends up in the IAS, you got the lock-in. Do you see a world going forward where developers have their own place, where they go and build and create software independent of either target but then add it to the various platforms. Is that a direction that you think this is all going to end up in? >> I do. Our view is that Heroku, which really invented this platform as a service concept or popularized it. You do, get push Heroku and magically your application's up. And then Cloud Foundry which came along and created a open source version of that. Those were two building blocks. But the Cloud Native essentially taking that scenario and saying, hey, that continuous integration, continuous deployment pipeline, that ability to deploy your software dozens of times per day, that's an absolute table ante for being a modern company. Not just a software company but arguably every company today needs to be doing software development like that. And then Cloud Native is a whole set of infrastructure around that to allow you to, not just have that environment in development but also to push it into production. >> So compare and contrast, based on your vision >> Dan: Umhmm. >> of how things are going to play out. A developer spends her time today doing this, and in three years, she's going to spend her time doing that. Kind of give us a sense of how >> Dan: Sure. >> you think it's going to play out. >> The simplest way to say it is that, Docker came along a few years ago, and was incredibly transformative technology for software development. It solved this really basic problem that, you hire a new employee and does it take her an entire day or entire week to get her environment together. Or can she just copy over the document container and be ready to go. And so I would argue it had the fastest uptake of any developer technology in history. But now when you have all those pieces running, okay, that's great in development, how do you get it in production? And my goal is that in a few years, hopefully much sooner, that those developers that are getting the container, they're getting the different pieces of microservices working. And then it's this tiny little YAML file that just says, here's the requirements for my application, here's what kind of redundancy it needs, what is backend databases, other sorts of things. And they're deploying it up. For most developers they can get out of that business of dev-ops. Of having to worry about all those issues. Your dev-ops team can be so much more efficient cuz Kubernetes and the related platform really enables that. >> I got to ask you, I just Tweeted cuz I had, make sure I captured it. I'm blown away by your success on the sponsorship participation. And usually it's a sign of opportunity. Because there's money making to be made, having the big vendors in there. But the growth of Kubernetes as you mentioned, all the success, we're well aware of that. But you got a lot going on. You're like got the tiger by the tail, your hair's blown back, you're running as hard as you can. Why are you guys successful? What is your gut? As executive director, you got to have the 20 mile stare but you also implement the here and now. >> Dan: Sure. >> How are you rationalizing the success? >> The most important point is, there's not some sort of magic formula, that CNCF has done or the Linux Foundation. And we're just so much better promoting or marketing it. At the end of the day, it really comes down to the developers behind Kubernetes. They've built a tool that tons and tons of people want to use. And that leverages 15 years of work that Google has done on containerization. Work that IBM and Docker and all of our other member companies, RedHat, have put together. And now, I think tiger by the tail is the right analogy. That we just happen to be, luckily, do have the technology and the constellation technology that a lot of folks want to do. The biggest thing we're trying to deal with is, some of the challenges around scaling. There's over 17 hundred authors. Individual developers contributed to Kubernetes in the last 12 months. Trying to figure out how can we get good reviews of all their codes, better documentation. >> There is a secret formula if you look at it. In away, relevance is one of them. >> Dan: Umhmm. >> Being relevant and being an awesome technology. But what I want get your thoughts in is, I looked at Kubernetes right out of the gate and said, hmm, will this be a MapReduced moment for Google. >> Dan: Yeah. >> And interesting enough, they didn't pull the same move. They didn't just let Cloud Air, walk away with or someone. >> Dan: Right, exactly. >> They made sure that if they preserved it. Google kind of let MapReduced >> Dan: Yeah, I think-- >> on the side of the road. >> Dan: No, no, I think this-- >> Cloud Air ran with it. >> Google had something that they replaced it with. I mean the -- >> SPAN is pretty damn good. >> And that's an interesting thing because in a world of strategy, across technology, and this is related to this, is that it used to be, you define a process, and then let's call it the end level process, and then you would go off and you make it obsolete because you had something that was more efficient, more effective. And then you license the old technology. And that way, the industry built capacity around the old technology and you had the new, more efficient technology that drove your business forward. And I think that, I'm not saying that's exactly, I'm not saying that Google did that, that's the tremendous >> Google knew. >> effect it will have. >> John: I have sources that tell me that. I investigated this story three years ago or maybe four, maybe three years ago. Google had conversations going up to the Eric Schmidt level, and Larry Page level, do we keep Kubernetes, do we open source it? And it went all the way to the top. And they almost wanted, they were afraid of MapReduced. Because MapReduced was a lost opportunity. Now they made it up but-- >> Now I would argue that there's a slightly subtler decision they had to make, where they have this internal system board, that is just tons of engineering and analysis and improvement has gone into it. They wrote Kubernetes as essentially next generation version of that. I think they kind of had four paths. Craig McLuckie was one of the key people behind that. Where they could have made it a proprietary service that if you're a customer of Google cloud, you get access to it. That's essentially what Amazon and Elastic Container Services today. Or they could have said, hey, we're going to open source it but we're still keep control of it. Essentially that's the path they went with the Go language. Where lots of people use it, lots of people contribute to it, but it's Google who decides at the end of the day, which direction it goes. Or they could have gone and created a Kubernetes Foundation. And if they'd gone to the Linux Foundation and said, we want to create a Kubernetes Foundation, they absolutely could have and that would have been a home for it. But when you look at all the complementary technologies that have come in, they would never have gone into a Kubernetes Foundation. So instead, they really chose the most open path of saying, no we want to have a Cloud Native Computing Foundation. Have Kubernetes be the anchor tenant for it. But then have a place that companies like Mesophere with Mesos and Docker with Docker Swarm and other partners can come in and agree on something. So today, we're really pleased to announce the container network interface, just got accepted as our 10th project. And that's used by those and also by Cloud Foundry. And then they can disagree on others, about the orchestration- >> So it's a liberating move, really, if you think about it. Because at the time this happened, there was a lot of land grab talk going on. >> Dan: Umhmm. >> Until Amazon was winning big the hockey stick was going up. >> Dan: Right. You saw the numbers, and financial performance. But there was a fear of lock-in. To your point. >> Dan: Right, exactly. >> Then Kubernetes provides a nice layer. And you guys as a group, are looking holistically and saying, choice and multi-cloud. Is that the vision? >> Definitely. But, I mean you can see, strategically why Google decided to do it. Because if you pick an open source platform, and say, hey, this is the best of breed approach. Now, you're actually willing to evaluate the cloud on what the prices are, the supplementary services, et cetera. Where before that, you might have just said, ah, AWS is the safe service, I'm going just go with that. >> But Kubernetes is an invasive technology. And I don't mean that in a bad way. (Dan laughs) >> When you decide to move with Kubernetes, you are foreclosing other options at your disposal. And so, I think what you're saying is that, Google wanted to ensure that it remained a consistent coherent thing. While at the same time, making it obvious to all those around them that also wanted to invest in it, that their investments were going to be safe and sound going forward. >> I think that's fair but on the other hand, I do want to say that very few companies have moved their entire business and all of their IT over to Kubernetes. >> Peter: Oh, I'm not saying that they would. >> We do recommend that they start with a stable service. >> Peter: But Meso and some of those other companies are now investing in Kubernetes as a platform. Or making a bet on Kubernetes, want to make sure that their bets are as good as their company is. >> Sure. But there are other orchestration plateforms still. So Kubernetes has plenty of competition. And our biggest competition of course is Enertia. Of folks not changing into anything. >> I got to ask you a question. So Leonard, our producer is just telling me, Kubernetes is boring per Craig McLuckie. So Craig said earlier in theCUBE today, Kubernetes needs to be boring. He said his biggest problem with Kubernetes is it's too exciting right now. >> Dan: That's great. Now what he means by that is, he's kind of making a play on words but his point is, it should be obstracted away. >> Dan: Yeah. In terms of Kubernetes. But that's a problem you have. It's too exciting. >> Dan: Umhmm. What's your reaction to his comment that Kubernetes needs to be boring. >> He and I did a little Google trends comparison of Kubernetes and TensorFlow, which is another open source project out of Google. TensorFlow is something like three or four acts. And artificial intelligence is just so much more interesting and exciting. And yeah, I certainly would love to see a situation. We have this metaphor for Linux, with the Linux Foundation. That we describe it as plumbing. Where it's so intrinsic to almost every piece of technology in existence. And like plumbing, you'll get very upset when if it stops working. And you'll know it and you'll complain. But there's a huge piece of what we're trying to do which is the infrastructure to make things work. >> Here's an idea. Marketing idea. Just call it AI for containers. >> Dan: That's good. >> It'll be the hottest thing on the planet. >> Dan, great to-- >> Peter: Probably be more be more exciting. >> Dan, great to see you. Congratulations on your success. >> Yeah. So I do want to just make a quick mention December sixth through eighth is CloudNativeCon and KubeCon. It's our biggest annual conference. We're looking to actually triple in size from Seattle to three thousand people or more. We have every expert coming in. Michelle Noorali and Kelsey Hightower are the co-chairs and are going to be speaking there. We would love to see a lot of you guys. >> John: In Austin. >> In Austin. >> We hope you'll be there. >> TheCUBE will be there. >> We'll definitely be there. >> Dan: As well to ah, >> We've been to the inaugural >> Dan: Exactly. >> show for KubeCon and Cloud Native conference. We'll defintely be there. December sixth through the eighth, in December, in Austin. Great time of the year to be in Texas. Congratulations on all your success. And as Kubernetes and nine other projects continue to get traction. Still exciting times. And as they say, we live in interesting times. (Dan laughs) This is theCUBE with more interesting, exciting, not boring stuff coming back from the inaugural event here at Cisco DevNet Create. I'm John Ferrier, Peter Burris. Stay with us.

(upbeat music) >> Hello everyone, welcome back to theCUBE's coverage of Cloud Native SecurityCon North America 2023. Obviously, CUBE's coverage with our CUBE Center Report. We're not there on the ground, but we have folks and our CUBE Alumni there. We have entrepreneurs there. Of course, we want to be there in person, but we're remote. We've got Ben Hirschberg, CTO and Co-Founder of Armo, a cloud native security startup, well positioned in this industry. He's there in Seattle. Ben, thank you for coming on and sharing what's going on with theCUBE. >> Yeah, it's great to be here, John. >> So we had written on you guys up on SiliconANGLE. Congratulations on your momentum and traction. But let's first get into what's going on there on the ground? What are some of the key trends? What's the most important story being told there? What is the vibe? What's the most important story right now? >> So I think, I would like to start here with the I think the most important thing was that I think the event is very successful. Usually, the Cloud Native Security Day usually was part of KubeCon in the previous years and now it became its own conference of its own and really kudos to all the organizers who brought this up in, actually in a short time. And it wasn't really clear how many people will turn up, but at the end, we see a really nice turn up and really great talks and keynotes around here. I think that one of the biggest trends, which haven't started like in this conference, but already we're talking for a while is supply chain. Supply chain is security. I think it's, right now, the biggest trend in the talks, in the keynotes. And I think that we start to see companies, big companies, who are adopting themselves into this direction. There is a clear industry need. There is a clear problem and I think that the cloud native security teams are coming up with tooling around it. I think for right now we see more tools than adoption, but the adoption is always following the tooling. And I think it already proves itself. So we have just a very interesting talk this morning about the OpenSSL vulnerability, which was I think around Halloween, which came out and everyone thought that it's going to be a critical issue for the whole cloud native and internet infrastructure and at the end it turned out to be a lesser problem, but the reason why I think it was understood that to be a lesser problem real soon was that because people started to use (indistinct) store software composition information in the environment so security teams could look into, look up in their systems okay, what, where they're using OpenSSL, which version they are using. It became really soon real clear that this version is not adopted by a wide array of software out there so the tech surface is relatively small and I think it already proved itself that the direction if everyone is talking about. >> Yeah, we agree, we're very bullish on this move from the Cloud Native Foundation CNCF that do the security conference. Amazon Web Services has re:Invent. That's their big show, but they also have re:Inforce, the security show, so clearly they work together. I like the decoupling, very cohesive. But you guys have Kubescape of Kubernetes security. Talk about the conversations that are there and that you're hearing around why there's different event what's different around KubeCon and CloudNativeCon than this Cloud Native SecurityCon. It's not called KubeSucSecCon, it's called Cloud Native SecurityCon. What's the difference? Are people confused? Is it clear? What's the difference between the two shows? What are you hearing? >> So I think that, you know, there is a good question. Okay, where is Cloud Native Computing Foundation came from? Obviously everyone knows that it was somewhat coupled with the adoption of Kubernetes. It was a clear understanding in the industry that there are different efforts where the industry needs to come together without looking be very vendor-specific and try to sort out a lot of issues in order to enable adoption and bring great value and I think that the main difference here between KubeCon and the Cloud Native Security Conference is really the focus, and not just on Kubernetes, but the whole ecosystem behind that. The way we are delivering software, the way we are monitoring software, and all where Kubernetes is only just, you know, maybe the biggest clog in the system, but, you know, just one of the others and it gives great overview of what you have in the whole ecosystem. >> Yeah, I think it's a good call. I would add that what I'm hearing too is that security is so critical to the business model of every company. It's so mainstream. The hackers have a great business model. They make money, their costs are lower than the revenue. So the business of hacking in breaches, ransomware all over the place is so successful that they're playing offense, everyone's playing defense, so it's about time we can get focus to really be faster and more nimble and agile on solving some of these security challenges in open source. So I think that to me is a great focus and so I give total props to the CNC. I call it the event operating system. You got the security group over here decoupled from the main kernel, but they work together. Good call and so this brings back up to some of the things that are going on so I have to ask you, as your startup as a CTO, you guys have the Kubescape platform, how do you guys fit into the landscape and what's different from your tools for Kubernetes environments versus what's out there? >> So I think that our journey is really interesting in the solution space because I think that our mode really tries to understand where security can meet the actual adoption because as you just said, somehow we have to sort out together how security is going to be automated and integrated in its best way. So Kubescape project started as a Kubernetes security posture tool. Just, you know, when people are really early in their adoption of Kubernetes systems, they want to understand whether the installation is is secure, whether the basic configurations are look okay, and giving them instant feedback on that, both in live systems and in the CICD, this is where Kubescape came from. We started as an open source project because we are big believers of open source, of the power of open source security, and I can, you know I think maybe this is my first interview when I can say that Kubescape was accepted to be a CNCF Sandbox project so Armo was actually donating the project to the CNCF, I think, which is a huge milestone and a great way to further the adoption of Kubernetes security and from now on we want to see where the users in Armo and Kubescape project want to see where the users are going, their Kubernetes security journey and help them to automatize, help them to to implement security more fast in the way the developers are using it working. >> Okay, if you don't mind, I want to just get clarification. What's the difference between the Armo platform and Kubescape because you have Kubescape Sandbox project and Armo platform. Could you talk about the differences and interaction? >> Sure, Kubescape is an open source project and Armo platform is actually a managed platform which runs Kubescape in the cloud for you because Kubescape is part, it has several parts. One part is, which is running inside the Kubernetes cluster in the CICD processes of the user, and there is another part which we call the backend where the results are stored and can be analyzed further. So Armo platform gives you managed way to run the backend, but I can tell you that backend is also, will be available within a month or two also for everyone to install on their premises as well, because again, we are an open source company and we are, we want to enable users, so the difference is that Armo platform is a managed platform behind Kubescape. >> How does Kubescape differ from closed proprietary sourced solutions? >> So I can tell you that there are closed proprietary solutions which are very good security solutions, but I think that the main difference, if I had to pick beyond the very specific technicalities is the worldview. The way we see that our user is not the CISO. Our user is not necessarily the security team. From our perspective, the user is the DevOps and the developers who are working on the Kubernetes cluster day to day and we want to enable them to improve their security. So actually our approach is more developer-friendly, if I would need to define it very shortly. >> What does this risk calculation score you guys have in Kubscape? That's come up and we cover that in our story. Can you explain to the folks how that fits in? Is it Kubescape is the platform and what's the benefit, what's the purpose? >> So the risk calculation is actually a score we are giving to clusters in order for the users to understand where they are standing in the general population, how they are faring against a perfect hardened cluster. It is based on the number of different tests we are making. And I don't want to go into, you know, the very specifics of the mathematical functions, but in general it takes into account how many functions are failing, security tests are failing inside your cluster. How many nodes you are having, how many workloads are having, and creating this number which enables you to understand where you are standing in the global, in the world. >> What's the customer value that you guys pitching? What's the pitch for the Armo platform? When you go and talk to a customer, are they like, "We need you." Do they come to you? Is it word of mouth? You guys have a strategy? What's the pitch? What's so appealing to the customers? Why are they enthusiastic about you guys? >> So John, I can tell you, maybe it's not so easy to to say the words, but I nearly 20 years in the industry and though I've been always around cyber and the defense industry and I can tell you that I never had this journey where before where I could say that the the customers are coming to us and not we are pitching to customers. Simply because people want to, this is very easy tool, very very easy to use, very understandable and it very helps the engineers to improve security posture. And they're coming to us and they're saying, "Well, awesome, okay, how we can like use it. Do you have a graphical interface?" And we are pointing them to the Armor platform and they are falling in love and coming to us even more and we can tell you that we have a big number of active users behind the platform itself. >> You know, one of the things that comes up every time at KubeCon and Cloud NativeCon when we're there, and we'll be in Amsterdam, so folks watching, you know, we'll see onsite, developer productivity is like the number one thing everyone talks about and security is so important. It's become by default a blocker or anchor or a drag on productivity. This is big, the things that you're mentioning, easy to use, engineering supporting it, developer adoption, you know we've always said on theCUBE, developers will be the de facto standards bodies by their choices 'cause developers make all the decisions. So if I can go faster and I can have security kind of programmed in, I'm not shifting left, it's just I'm just having security kind of in there. That's the dream state. Is that what you guys are trying to do here? Because that's the nirvana, everyone wants to do that. >> Yeah, I think your definition is like perfect because really we had like this, for a very long time we had this world where we decoupled security teams from developers and even for sometimes from engineering at all and I think for multiple reasons, we are more seeing a big convergence. Security teams are becoming part of the engineering and the engineering becoming part of the security and as you're saying, okay, the day-to-day world of developers are becoming very tangled up in the good way with security, so the think about it that today, one of my developers at Armo is creating a pull request. He's already, code is already scanned by security scanners for to test for different security problems. It's already, you know, before he already gets feedback on his first time where he's sharing his code and if there is an issue, he already can solve it and this is just solving issues much faster, much cheaper, and also you asked me about, you know, the wipe in the conference and we know no one can deny the current economic wipe we have and this also relates to security teams and security teams has to be much more efficient. And one of the things that everyone is talking, okay, we need more automation, we need more, better tooling and I think we are really fitting into this. >> Yeah, and I talked to venture capitalists yesterday and today, an angel investor. Best time for startup is right now and again, open source is driving a lot of value. Ben, it's been great to have you on and sharing with us what's going on on the ground there as well as talking about some of the traction you have. Just final question, how old's the company? How much funding do you have? Where you guys located? Put a plug in for the company. You guys looking to hire? Tell us about the company. Were you guys located? How much capital do you have? >> So, okay, the company's here for three years. We've passed a round last March with Tiger and Hyperwise capitals. We are located, most of the company's located today in Israel in Tel Aviv, but we have like great team also in Ukraine and also great guys are in Europe and right now also Craig Box joined us as an open source VP and he's like right now located in New Zealand, so we are a really global team, which I think it's really helps us to strengthen ourselves. >> Yeah, and I think this is the entrepreneurial equation for the future. It's really great to see that global. We heard that in Priyanka Sharma's keynote. It's a global culture, global community. >> Right. >> And so really, really props you guys. Congratulations on Armo and thanks for coming on theCUBE and sharing insights and expertise and also what's happening on the ground. Appreciate it, Ben, thanks for coming on. >> Thank you, John. >> Okay, cheers. Okay, this is CUB coverage here of the Cloud Native SecurityCon in North America 2023. I'm John Furrier for Lisa Martin, Dave Vellante. We're back with more of wrap up of the event after this short break. (gentle upbeat music)

(lively music) >> Good afternoon cloud community and welcome back to beautiful Las Vegas, Nevada. We are here at AWS re:Invent, day four of our wall to wall coverage. It is day four in the afternoon and we are holding strong. I'm Savannah Peterson, joined by my fabulous co-host Paul Gillen. Paul, how you doing? >> I'm doing well, fine Savannah. You? >> You look great. >> We're in the home stretch here. >> Yeah, (laughs) we are. >> You still look fresh as a daisy. I don't know how you do it. >> (laughs) You're too kind. You're too kind, but I'm vain enough to take that compliment. I'm very excited about the conversation that we're going to have up next. We get to get a little DevRel and we got a little swagger on the stage. Welcome, Austin. How you doing? >> Hey, great to be here. Thanks for having me. >> Savannah: Yeah, it's our pleasure. How's the show been for you so far? >> Busy, exciting. Feels a lot like, you know it used to be right? >> Yeah, I know. A little reminiscent of the before times. >> Well, before times. >> Before we dig into the technical stuff, you're the most intriguingly dressed person we've had on the show this week. >> Austin: I feel extremely underdressed. >> Well, and we were talking about developer fancy. Talk to me a little bit about your approach to fashion. Wasn't expecting to lead with this, but I like this but I like this actually. >> No, it's actually good with my PR. You're going to love it. My approach, here's the thing, I give free advice all the time about developer relations, about things that work, have worked, and don't work in community and all that stuff. I love talking about that. Someone came up to me and said, "Where do you get your fashion tips from? What's the secret Discord server that I need to go on?" I'm like, "I will never tell." >> Oh, okay. >> This is an actual trait secret. >> Top secret. Wow! Talk about. >> If someone else starts wearing the hat, then everyone's going to be like, "There's so many white guys." Look, I'm a white guy with a beard that works in technology. >> Savannah: I've never met one of those. >> Exactly, there's none of them at all. So, you have to do something to kind stand out from the crowd a little bit. >> I love it, and it's a talk trigger. We're talking about it now. Production team loved it. It's fantastic. >> It's great. >> So your DevRel for Lightstep, in case the audience isn't familiar tell us about Lightstep. >> So Lightstep is a cloud native observability platform built at planet scale, and it powers observability at some places you've heard of like Spotify, GitHub, right? We're designed to really help developers that are working in the cloud with Kubernetes, with these huge distributed systems, understand application performance and being able to find problems, fix problems. We're also part of the ServiceNow family and as we all know ServiceNow is on a mission to help the world of work work better by powering digital transformation around IT and customer experiences for their many, many, many global 2000 customers. We love them very much. >> You know, it's a big love fest here. A lot of people have talked about the collaboration, so many companies working together. You mentioned unified observability. What is unified observability? >> So if you think about a tradition, or if you've heard about this traditional idea of observability where you have three pillars, right? You have metrics, and you have logs, and you have traces. All those three things are different data sources. They're picked up by different tools. They're analyzed by different people for different purposes. What we believe and what we're working to accomplish right now is to take all that and if you think those pillars, flip 'em on their side and think of them as streams of data. If we can take those streams and integrate them together and let you treat traces and metrics and logs not as these kind of inviolate experiences where you're kind of paging between things and going between tab A to tab B to tab C, and give you a standard way to query this, a standard way to display this, and letting you kind of find the most relevant data, then it really unlocks a lot of power for like developers and SREs to spend less time like managing tools. You know, figuring out where to build their query or what dashboard to check, more just being able to like kind of ask a question, get an answer. When you have an incident or an outage that's the most important thing, right? How quickly can you get those answers that you need so that you can restore system health? >> You don't want to be looking in multiple spots to figure out what's going on. >> Absolutely. I mean, some people hear unified observability and they go to like tool consolidation, right? That's something I hear from a lot of our users and a lot of people in re:Invent. I'll talk to SREs, they're like, "Yeah, we've got like six or seven different metrics products alone, just on services that they cover." It is important to kind of consolidate that but we're really taking it a step lower. We're looking at the data layer and trying to say, "Okay, if the data is all consistent and vendor neutral then that gives you flexibility not only from a tool consolidation perspective but also you know, a consistency, reliability. You could have a single way to deploy your observability out regardless of what cloud you're on, regardless if you're using Kubernetes or Fargate or whatever else. or even just Bare Metal or EC2 Bare Metal, right? There's been so much historically in this space. There's been a lot of silos and we think that unify diversability means that we kind of break down those silos, right? The way that we're doing it primarily is through a project called OpenTelemetry which you might have heard of. You want to talk about that in a minute? . >> Savannah: Yeah, let's talk about it right now. Why don't you tell us about it? Keep going, you're great. You're on a roll. >> I am. >> Savannah: We'll just hang out over here. >> It's day four. I'm going to ask the questions and answer the questions. (Savannah laughs) >> Yes, you're right. >> I do yeah. >> Open Tele- >> OpenTelemetry . >> Explain what OpenTelemetry is first. >> OpenTelemetry is a CNCF project, Cloud Native Computing Foundation. The goal is to make telemetry data, high quality telemetry data, a builtin feature of cloud native software right? So right now if you wanted to get logging data out, depending on your application stack, depending on your application run time, depending on language, depending on your deployment environment. You might have a lot... You have to make a lot of choices, right? About like, what am I going to use? >> Savannah: So many different choices, and the players are changing all the time. >> Exactly, and a lot of times what people will do is they'll go and they'll say like, "We have to use this commercial solution because they have a proprietary agent that can do a lot of this for us." You know? And if you look at all those proprietary agents, what you find very quickly is it's very commodified right? There's no real difference in what they're doing at a code level and what's stopped the industry from really adopting a standard way to create this logs and metrics and traces, is simply just the fact that there was no standard. And so, OpenTelemetry is that standard, right? We've got dozens of companies many of them like very, many of them here right? Competitors all the same, working together to build this open standard and implementation of telemetry data for cloud native software and really any software right? Like we support over 12 languages. We support Kubernetes, Amazon. AWS is a huge contributor actually and we're doing some really exciting stuff with them on their Amazon distribution of OpenTelemetry. So it's been extremely interesting to see it over the past like couple years go from like, "Hey, here's this like new thing that we're doing over here," to really it's a generalized acceptance that this is the way of the future. This is what we should have been doing all along. >> Yeah. >> My opinion is there is a perception out there that observability is kind of a commodity now that all the players have the same set of tools, same set of 15 or 17 or whatever tools, and that there's very little distinction in functionality. Would you agree with that? >> I don't know if I would characterize it that way entirely. I do think that there's a lot of duplicated effort that happens and part of the reason is because of this telemetry data problem, right? Because you have to wind up... You know, there's this idea of table stakes monitoring that we talk about right? Table stakes monitoring is the stuff that you're having to do every single day to kind of make sure your system is healthy to be able to... When there's an alert, gets triggered, to see why it got triggered and to go fix it, right? Because everyone has the kind of work on that table stake stuff and then build all these integrations, there's very little time for innovation on top of that right? Because you're spending all your time just like working on keeping up with technology. >> Savannah: Doing the boring stuff to make sure the wheels don't fall off, basically. >> Austin: Right? What I think the real advantage of OpenTelemetry is that it really, from like a vendor perspective, like it unblocks us from having to kind of do all this repetitive commodified work. It lets us help move that out to the community level so that... Instead of having to kind of build, your Kubernetes integration for example, you can just have like, "Hey, OpenTelemetry is integrated into Kubernetes and you just have this data now." If you are a commercial product, or if you're even someone that's interested in fixing a, scratching a particular itch about observability. It's like, "I have this specific way that I'm doing Kubernetes and I need something to help me really analyze that data. Well, I've got the data now I can just go create a project. I can create an analysis tool." I think that's what you'll see over time as OpenTelemetry promulgates out into the ecosystem is more people building interesting analysis features, people using things like machine learning to analyze this large amount, large and consistent amount of OpenTelemetry data. It's going to be a big shakeup I think, but it has the potential to really unlock a lot of value for our customers. >> Well, so you're, you're a developer relations guy. What are developers asking for right now out of their observability platforms? >> Austin: That's a great question. I think there's two things. The first is that they want it to just work. It's actually the biggest thing, right? There's so many kind of... This goes back to the tool proliferation, right? People have too much data in too many different places, and getting that data out can still be really challenging. And so, the biggest thing they want is just like, "I want something that I can... I want a lot of these questions I have to ask, answered already and OpenTelemetry is going towards it." Keep in mind it's the project's only three years old, so we obviously have room to grow but there are people running it in production and it works really well for them but there's more that we can do. The second thing is, and this isn't what really is interesting to me, is it's less what they're asking for and more what they're not asking for. Because a lot of the stuff that you see people, saying around, "Oh, we need this like very specific sort of lower level telemetry data, or we need this kind of universal thing." People really just want to be able to get questions or get questions answered, right? They want tools that kind of have these workflows where you don't have to be an expert because a lot of times this tooling gets locked behind sort of is gate kept almost in a organization where there are teams that's like, "We're responsible for this and we're going to set it up and manage it for you, and we won't let you do things outside of it because that would mess up- >> Savannah: Here's your sandbox and- >> Right, this is your sandbox you can play in and a lot of times that's really useful and very tuned for the problems that you saw yesterday, but people are looking at like what are the problems I'm going to get tomorrow? We're deploying more rapidly. We have more and more intentional change happening in the system. Like it's not enough to have this reactive sort of approach where our SRE teams are kind of like or this observability team is building a platform for us. Developers want to be able to get in and have these kind of guided workflows really that say like, "Hey, here's where you're starting at. Let's get you to an answer. Let's help you find the needle in the haystack as it were, without you having to become a master of six different or seven different tools." >> Savannah: Right, and it shouldn't be that complicated. >> It shouldn't be. I mean we've certainly... We've been working on this problem for many years now, starting with a lot of our team that started at Google and helped build Google's planet scale monitoring systems. So we have a lot of experience in the field. It's actually one... An interesting story that our founder or now general manager tells BHS, Ben Sigelman, and he told me this story once and it's like... He had built this really cool thing called Dapper that was a tracing system at Google, and people weren't using it. Because they were like, "This is really cool, but I don't know how to... but it's not relevant to me." And he's like, the one thing that we did to get to increase usage 20 times over was we just put a link. So we went to the place that people were already looking for that data and we added a link that says, "Hey, go over here and look at this." It's those simple connections being able to kind of draw people from like point A to point B, take them from familiar workflows into unfamiliar ones. You know, that's how we think about these problems right? How is this becoming a daily part of someone's usage? How is this helping them solve problems faster and really improve their their life? >> Savannah: Yeah, exactly. It comes down to quality of life. >> Warner made the case this morning that computer architecture should be inherently event-driven and that we are moving toward a world where the person matters less than what the software does, right? The software is triggering events. Does this complicate observability or simplify it? >> Austin: I think that at the end of the day, it's about getting the... Observability to me in a lot of ways is about modeling your system, right? It's about you as a developer being able to say this is what I expect the system to do and I don't think the actual application architecture really matters that much, right? Because it's about you. You are building a system, right? It can be event driven, can be support request response, can be whatever it is. You have to be able to say, "This is what I expect to... For these given inputs, this is the expected output." Now maybe there's a lot of stuff that happens in the middle that you don't really care about. And then, I talk to people here and everyone's talking about serverless right? Everyone... You can see there's obviously some amazing statistics about how many people are using Lambda, and it's very exciting. There's a lot of stuff that you shouldn't have to care about as a developer, but you should care about those inputs and outputs. You will need to have that kind of intermediate information and understand like, what was the exact path that I took through this invented system? What was the actual resources that were being used? Because even if you trust that all this magic behind the scenes is just going to work forever, sometimes it's still really useful to have that sort of lower level abstraction, to say like, "Well, this is what actually happened so that I can figure out when I deployed a new change, did I make performance better or worse?" Or being able to kind of segregate your data out and say like... Doing AB testing, right? Doing canary releases, doing all of these things that you hear about as best practices or well architected applications. Observability is at the core of all that. You need observability to kind of do any of, ask any of those higher level interesting questions. >> Savannah: We are here at ReInvent. Tell us a little bit more about the partnership with AWS. >> So I would have to actually probably refer you to someone at Service Now on that. I know that we are a partner. We collaborate with them on various things. But really at Lightstep, we're very focused on kind of the open source part of this. So we work with AWS through the OpenTelemetry project, on things like the AWS distribution for OpenTelemetry which is really... It's OpenTelemetry, again is really designed to be like a neutral standard but we know that there are going to be integrators and implementers that need to package up and bundle it in a certain way to make it easy for their end users to consume it. So that's what Amazon has done with ADOT which is the shortening for it. So it's available in several different ways. You can use it as like an SDK and drop it into your application. There's Lambda layers. If you want to get Lambda observability, you just add this extension in and then suddenly you're getting OpenTelemetry data on the other side. So it's really cool. It's been a really exciting to kind of work with people on the AWS side over the past several years. >> Savannah: It's exciting, >> I've personally seen just a lot of change. I was talking to a PM earlier this week... It's like, "Hey, two years ago I came and talked to you about OpenTelemetry and here we are today. You're still talking about OpenTelemetry." And they're like, "What changes?" Our customers have started coming to us asking for OpenTelemetry and we see the same thing now. >> Savannah: Timing is right. >> Timing is right, but we see the same thing... Even talking to ServiceNow customers who are... These very big enterprises, banks, finance, healthcare, whatever, telcos, it used to be... You'd have to go to them and say like, "Let me tell you about distributed tracing. Let me tell you about OpenTelemetry. Let me tell you about observability." Now they're coming in and saying, "Yeah, so we're standard." If you think about Kubernetes and how Kubernetes, a lot of enterprises have spent the past five-six years standardizing, and Kubernetes is a way to deploy applications or manage containerized applications. They're doing the same journey now with OpenTelemetry where they're saying, "This is what we're betting on and we want partners we want people to help us go along that way." >> I love it, and they work hand in hand in all CNCF projects as well that you're talking about. >> Austin: Right, so we're integrated into Kubernetes. You can find OpenTelemetry and things like kept in which is application standards. And over time, it'll just like promulgate out from there. So it's really exciting times. >> A bunch of CNCF projects in this area right? Prometheus. >> Prometheus, yeah. Yeah, so we inter-operate with Prometheus as well. So if you have Prometheus metrics, then OpenTelemetry can read those. It's a... OpenTelemetry metrics are like a super set of Prometheus. We've been working with the Prometheus community for quite a while to make sure that there's really good compatibility because so many people use Prometheus you know? >> Yeah. All right, so last question. New tradition for us here on theCUBE. We're looking for your 32nd hot take, Instagram reel, biggest theme, biggest buzz for those not here on the show floor. >> Oh gosh. >> Savannah: It could be for you too. It could be whatever for... >> I think the two things that are really striking to me is one serverless. Like I see... I thought people were talking about servers a lot and they were talking about it more than ever. Two, I really think it is observability right? Like we've gone from observability being kind of a niche. >> Savannah: Not that you're biased. >> Huh? >> Savannah: Not that you're biased. >> Not that I'm biased. It used to be a niche. I'd have to go niche thing where I would go and explain what this is to people and nowpeople are coming up. It's like, "Yeah, yeah, we're using OpenTelemetry." It's very cool. I've been involved with OpenTelemetry since the jump, since it was started really. It's been very exciting to see and gratifying to see like how much adoption we've gotten even in a short amount of time. >> Yeah, absolutely. It's a pretty... Yeah, it's been a lot. That was great. Perfect soundbite for us. >> Austin: Thanks, I love soundbites. >> Savannah: Yeah. Awesome. We love your hat and your soundbites equally. Thank you so much for being on the show with us today. >> Thank you for having me. >> Savannah: Hey, anytime, anytime. Will we see you in Amsterdam, speaking of KubeCon? Awesome, we'll be there. >> There's some real exciting OpenTelemetry stuff coming up for KubeCon. >> Well, we'll have to get you back on theCUBE. (talking simultaneously) Love that for us. Thank you all for tuning in two hour wall to wall coverage here, day four at AWS re:Invent in fabulous Las Vegas, Nevada, with Paul Gillin. I'm Savannah Peterson and you're watching theCUBE, the leader in high tech coverage. (lively 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 and KubeCon, CloudNativeCon Europe, 2022. I'm Keith Townsend, and we're continuing the conversation with builders, startups, large enterprise, customers, small customers, the whole community. Just got a interesting stat earlier in the day, 7.1 million community members in the CNCF foundation, and we're been interacting with 7,500 of them. But we're bringing the signal, separating the signal from the noise. We have a Kube alum who's been on both sides of the table, Omri Gazitt co-founder and CEO of Aserto. Welcome to the show. >> Thank you so much, Keith. >> So identity management, you know it's, it's critical need to the enterprise cloud native but there's plenty of solutions on the market, what unique problem are you solving you know how are you solving the problem in a unique way that we don't go to some of the big named vendors in this space? >> Yeah, we, my co-founder and I, were veterans of large clouds. We helped start Azure at Microsoft. We in fact helped build what became Azure Active Directory and those solutions entirely focus on one part, the "I" part, the identity part of the problem. They completely ignore the access management part and you could argue that is a larger problem and it is far from solved. So we completely agree. Identity management, a problem that's been solved over the last 15 years and solved well by great companies like Microsoft and Okta and Auth0. And we're best friends with them. We basically pick up where they leave off. We do the access management part. >> So the access management part, what specifically, what what am I getting when I engage with your team and your product? >> Yep. So basically I, authentication is all about proving that you are, who you say you are through a password or something else, you know, biometric. And that part is done. We basically pick up where that leaves off. So once you know who you are, once you've proven to a system that you are Keith. Now, what can Keith do? What roles, what permissions, , what operations can Keith perform on what resources? That's a harder problem. And that's the problem that we focus on. So for example, if you have a SaaS app - let's say you're building, you know an applicant tracking system and you Keith are an owner of some job descriptions and you have some candidates, but  somebody else has a different set of candidates and an admin, maybe has visibility at everything. How do you build that system? That actually is a pretty hard problem. And how do you build it to enterprise grade? That's where we come in. We basically have an end-to-end solution that gives you cloud native, end-to-end authorization that's built to enterprise grade. >> So when I think of this capability, I can't help but to think of AWS IAM and I'm in AWS IAM, I get my security role, and now I can assign to an EC2 instance, the ability to access some other AWS service or identity. So role based identity - are you giving me that type of capability? >> For everything else. So AWS IAM for AWS resources right? Google IAM for Google Resources. Azure has a similar system but they're all infrastructure focused. And what we're trying to do is bring that to your domain specific resources, right? So you, as an application builder, you have the things that correspond  you're not doing VMs, you're not doing storage arrays, you're not doing networks. You have higher level constructs, right. You know, like I said, if you're building Lever or Greenhouse, you have candidates and jobs and reports and things like that. So we basically allow you to create this fine grained access control, but for your own objects. >> So where's the boundaries? Let's say that I have a container or microservice that is a service and it has a role, it has an identity on my network. And there is a cloud based service, let's say a, a cloud SQL. And I want to do authentication across the two or can I only have the boundaries within my private infrastructure or does that boundary extend to the public cloud as well? >> It extends everywhere, right. So basically, you know, if you think about all the different hops here, you know, Zero Trust is the, the rage, right? And that encourages defense in depth. So you have an access proxy that does some type of authorization. Then you have an API Gateway that has a little bit more context, a little bit more authorization. For us we live inside of the application. So the application calls us, we give you a sidecar, you deploy it right next to your application. It gives you, you know, sub-millisecond response time, a hundred percent availability, all the authorization decisions are done with full context about who the user is and what resource they're trying to access. And so our sidecar will give you a response back, allow or deny, and then downstream from us, you could basically talk to another microservice. And at that point you're doing machine identities, right? So you may have a different authorization policy for those, only you know these particular services, are allowed to talk to these other services. And so we solve both the, you know authorization for machine identities as well as authorization for human identities. >> All right Omri are you ready for Q Clock? >> I sure am! >> Oh, I like the energy. >> Bring it on. >> You know, there have been many before you, they have failed the test. >> All right. I mean, they brought, they've brought the energy. You have the energy but do you have the ability to survive the clock? >> I'm going to do my best. >> So I'm going to say start the clock. I haven't said, said start cube clock yet, but when I say it, you have 60 seconds. There's no start overs. There's no repeats. The pressure's on, you ready? >> All right. I'm ready. >> Ready? Start Cube Clock. >> All right. If you are a VP of Engineering or a CTO or run a security or engineering organization what are you doing for roles and permissions? You're building it on your own, right? >> Tough times never last, tough people always do, and you're, you're delaying, you're letting me break you up. >> All right, I'm not going to let you break me up. Great. So you don't want to build it yourself. You don't want to build it yourself. Why would you spend engineering time? Why would you spend, you know, the- >> You deserve a seat at the table. >> No but look, why would you ever spend your time building something that is not differentiating your application? Instead use something like Aserto, just dear God use something, use a developer API. Don't build it yourself because what are you doing? You're reinventing the wheel, you know. You want to get out of the business of reinventing the wheel. >> Crawl before you walk. (Omri laughs) >> You think so? I think, I think you have to go you know, make sure that you spend your engineering resources on the things that matter and the things that matter are. >> Time up. >> Yep. >> You know what? You threw three great curve balls and struck me out. Great job. (Omri laughs) You, you, you just knocked it out the park. Great job Omri, I appreciate you coming in, stopping by, sharing your company's journey about authorization and authorization services and getting kind of this cloud capability, the cloud native. >> I appreciate your time as well Keith, always a pleasure. >> From Valencia Spain, I'm Keith Townsend, and you're watching theCUBE, the leader in high tech coverage. (soft instrumental 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, KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend, your host. And we're continuing the conversations around ecosystem cloud native, 7,500 people here, 170 plus show for sponsors. It is for open source conference, I think the destination. I might even premise that this may be, this may eventually roll to the biggest tech conference in the industry, maybe outside of AWS re:Invent. My next guest is Nick van Wiggeren. >> Wiggeren. >> VP engineering of PlanetScale. Nick, I'm going to start off the conversation right off the bat PlanetScale cloud native database, why do we need another database? >> Well, why don't you need another database? I mean, are you happy with yours? Is anyone happy with theirs? >> That's a good question. I don't think anyone is quite happy with, I don't know, I've never seen a excited database user, except for guys with really (murmurs) guys with great beards. >> Yeah. >> Keith: Or guys with gray hair maybe. >> Yeah. Outside of the dungeon I think... >> Keith: Right. >> No one is really is happy with their database, and that's what we're here to change. We're not just building the database, we're actually building the whole kind of start to finish experience, so that people can get more done. >> So what do you mean by getting more done? Because MySQL has been the underpinnings of like massive cloud database deployments. >> 100% >> It has been the de-facto standard. >> Nick: Yep. >> For cloud databases. >> Nick: Yep. >> What is PlanetScale doing in enabling us to do that I can't do with something like a MySQL or a SQL server? >> Great question. So we are MySQL compatible. So under the hood it's a lot of the MySQL you know and love. But on top of that we've layered workflows, we've layered scalability, we've layered serverless. So that you can get all of the the parts of the MySQL, that dependability, the thing that people have used for 20, 30 years, right? People don't even know a world before MySQL. But then you also get this ability to make schema changes faster. So you can kind of do your work quicker get to the business objectives faster. You can scale farther. So when you get to your MySQL and you say, well, can we handle adding this one feature on top? Can we handle the user growth we've got? You don't have to worry about that either. So it's kind of the best of both worlds. We've got one foot in history and we've got one foot in the new kind of cloud native database world. We want to give everyone the best of both. >> So when I think of serverless because that's the buzzy world. >> Yeah. >> But when I think of serverless I think about developers being able to write code. >> Yep. >> Deploy the code, not worry about VM sizes. >> Yep. >> Amount of disk space. >> Yep. >> CPU, et cetera. But we're talking about databases. >> Yep. >> I got to describe what type of disk I want to use. I got to describe the performance levels. >> Yep. >> I got all the descriptive stuff that I have to do about infrastructures. Databases are not... >> Yep. >> Keith: Serverless. >> Yep. >> They're the furthest thing from it. >> So despite what the name may say, I can guarantee you PlanetScale, your PlanetScale database does run on at least one server, usually more than one. But the idea is exactly what you said. So especially when you're starting off, when you're first beginning your, let's say database journey. That's a word I use a lot. The furthest thing from your mind is, how many CPUs do I need? How many disk iOS do I need? How much memory do I need? What we want you to be able to do is get started on focusing on shipping your code, right? The same way that Lambda, the same way that Kubernetes, and all of these other cloud native technologies just help people get done what they want to get done. PlanetScale is the same way, you want a database, you sign up, you click two buttons, you've got a database. We'll handle scaling the disk as you grow, we'll handle giving you more resources. And when you get to a spot where you're really starting to think about, my database has got hundreds of gigabytes or petabytes, terabytes, that's when we'll start to talk to you a little bit more about, hey, you know it really does run on a server, we ain't got to help you with the capacity planning, but there's no reason people should have to do that up front. I mean, that stinks. When you want to use a database you want to use a database. You don't want to use, 747 with 27 different knobs. You just want to get going. >> So, also when I think of serverless and cloud native, I think of stateless. >> Yep. >> Now there's stateless with databases, help me reconcile like, when you say it's cloud native. >> Nick: Yep. >> How is it cloud native when I think of cloud native as stateless? >> Yeah. So it's cloud native because it exists where you want it in the cloud, right? No matter where you've deployed your application on your own cloud, on a public cloud, or something like that, our job is to meet you and match the same level of velocity and the same level of change that you've got on your kind of cloud native setup. So there's a lot of state, right? We are your state and that's a big responsibility. And so what we want to do is, we want to let you experiment with the rest of the stateless workloads, and be right there next to you so that you can kind of get done what you need to get done. >> All right. So this concept of clicking two buttons... >> Nick: Yeah. >> And deploying, it's a database. >> Nick: Yep. >> It has to run somewhere. So let's say that I'm in AWS. >> Nick: Yep. >> And I have AWS VPC. What does it look like from a developer's perspective to consume the service? >> Yeah. So we've got a couple of different offerings, and AWS is a great example. So at the very kind of the most basic database unit you click, you get an endpoint, a host name, a password, and the username. You feed that right into your application and it's TLS secure and stuff like that, goes right into the database no problem. As you grow larger and larger, we can use things like AWS PrivateLink and stuff like that, to actually start to integrate more with your AWS environment, all the way over to what we call PlanetScale Managed. Which is where we actually deploy your data plan in your AWS account. So you give us some permissions and we kind of create a sub-account and stuff like that. And we can actually start sending pods, and hold clusters and stuff like that into your AWS account, give you a PrivateLink, so that everything looks like it's kind of wrapped up in your ownership but you still get the same kind of PlanetScale cloud experience, cloud native experience. >> So how do I make calls to the database? I mean, do I have to install a new... >> Nick: Great question. >> Like agent, or do some weird SQL configuration on my end? Or like what's the experience? >> Nope, we just need MySQL. Same way you'd go, install MySQL if you're on a Mac or app store to install MySQL on analytics PC, you just username, password, database name, and stuff like that, you feed that into your app and it just works. >> All right. So databases are typically security. >> Nick: Yep. >> When my security person. >> Nick: Yep. >> Sees a new database. >> Nick: Yep. >> Oh, they get excited. They're like, oh my job... >> Nick: I bet they do. >> My job just got real easy. I can find like eight or nine different findings. >> Right. >> How do you help me with compliance? >> Yeah. >> And answering these tough security questions from security? >> Great question. So security's at the core of what we do, right? We've got security people ourselves. We do the same thing for all the new vendors that we onboard. So we invest a lot. For example, the only way you can connect to a PlanetScale database even if you're using PrivateLink, even if you're not touching the public internet at all, is over TLS secured endpoint, right? From the very first day, the very first beta that we had we knew not a single byte goes over the internet that's not encrypted. It's encrypted at rest, we have audit logging, we do a ton internally as well to make sure that, what's happening to your database is something you can find out. The favorite thing that I think though is all your schema changes are tracked on PlanetScale, because we provide an entire workflow for your schema changes. We actually have like a GitHub Polar Request style thing, your security folks can actually look and say, what changes were made to the database day in and day out. They can go back and there's a full history of that log. So you actually have, I think better security than a lot of other databases where you've got to build all these tools and stuff like that, it's all built into PlanetScale. >> So, we started out the conversation with two clicks but I'm a developer. >> Nick: Yeah. >> And I'm developing a service at scale. >> Yep. >> I want to have a SaaS offering. How do I automate the deployment of the database and the management of the database across multiple customers? >> Yeah, so everything is API driven. We've got an API that you can use supervision databases to make schema changes, to make whatever changes you want to that database. We have an API that powers our website, the same API that customers can use to kind of automate any part of the workflow that they want. There's actually someone who did talk earlier using, I think, wwww.crossplane.io, or they can use Kubernetes custom resource definitions to provision PlanetScale databases completely automatically. So you can even do it as part of your standard deployment workflow. Just create a PlanetScale database, create a password, inject it in your app, all automatically. >> So Nick, as I'm thinking about scale. >> Yep. >> I'm thinking about multiple customers. >> Nick: Yep. >> I have a successful product. >> Nick: Yep. >> And now these customers are coming to me with different requirements. One customer wants to upgrade once every 1/4, another one, it's like, you know what? Just bring it on. Like bring the schema changes on. >> Yep. >> I want the latest features, et cetera. >> Nick: Right. >> How do I manage that with PlanetScale? When I'm thinking about MySQL it's a little, that can be a little difficult. >> Nick: Yeah. >> But how does PlanetScale help me solve that problem? >> Yeah. So, again I think it's that same workflow engine that we've built. So every database has its own kind of deploy queue, its own migration system. So you can automate all these processes and say, on this database, I want to change this schema this way, on this database I'm going to hold off. You can use our API to drive a view into like, well, what's the schema on this database? What's schema on this database? What version am I running on this database? And you can actually bring all that in. And if you were really successful you'd have this single plane of glass where you can see what's the status of all my databases and how are they doing, all powered by kind of the PlanetScale API. >> So we can't talk about databases without talking about backup. >> Nick: Yep. >> And recovery. >> Yep. >> How do I back this thing up and make sure that I can fall back? If someone deleted a table. >> Nick: Yep. >> It happens all the time in production. >> Nick: Yeah, 100%. >> How do I recover from it? >> So there's two pieces to this, and I'm going to talk about two different ways that we can help you solve this problem. One of them is, every PlanetScale database comes with backups built in and we test them fairly often, right? We use these backups. We actually give you a free daily backup on every database 'cause it's important to us as well. We want to be able to restore from backup, we want to be able to do failovers and stuff like that, all that is handled automatically. The other thing though is this feature that we launched in March called the PlanetScale Rewind. And what Rewind is, is actually a schema migration undo button. So let's say, you're a developer you're dropping a table or a column, you mean to drop this, but you drop the other one on accident, or you thought this column was unused but it wasn't. You know when you do something wrong, you cause an incident and you get that sick feeling in your stomach. >> Oh, I'm sorry. I've pulled a drive that was written not ready file and it was horrible. >> Exactly. And you kind of start to go, oh man, what am I going to do next? Everyone watching this right now is probably squirming in their seat a bit, you know the feeling. >> Yeah, I know the feeling >> Well, PlanetScale gives you an undo button. So you can click, undo migration, for 30 minutes after you do the migration and we'll revert your schema with all the data in it back to what your database looked like before you did that migration. Drop a column on accident, drop a table on accident, click the Rewind button, there's all the data there. And, the new rights that you've taken while that's happened are there as well. So it's not just a restore to a point in time backup. It's actually that we've replicated your rights sent them to both the old and the new schema, and we can get you right back to where you started, downtime solved. >> Both: So. >> Nick: Go ahead. >> DBAs are DBAs, whether they've become now reformed DBAs that are cloud architects, but they're DBAs. So there's a couple of things that they're going to want to know, one, how do I get my zero back up in my hands? >> Yeah. >> I want my, it's MySQL data. >> Nick: Yeah. >> I want my MySQL backup. >> Yeah. So you can just take backups off the database yourself the same way that you're doing today, right? MySQL dump, MySQL backup, and all those kinds of things. If you don't trust PlanetScale, and look, I'm all about backups, right? You want them in two different data centers on different mediums, you can just add on your own backup tools that you have right now and also use that. I'd like you to trust that PlanetScale has the backups as well. But if you want to keep doing that and run your own system, we're totally cool with that as well. In fact, I'd go as far as to say, I recommend it. You never have too many backups. >> So in a moment we're going to run Kube clock. So get your... >> Okay, all right. >> You know, stand tall. >> All right. >> I'll get ready. I'm going to... >> Nick: I'm tall, I'm tall. >> We're both tall. The last question before Kube clock. >> Nick: Yeah. >> It is, let's talk a little nerve knobs. >> Nick: Okay. >> The reform DBA. >> Nick: Yeah. >> They want, they're like, oh, this query ran a little bit slow. I know I can squeeze a little bit more out of that. >> Nick: Yeah. >> Who do they talk to? >> Yeah. So that's a great question. So we provide you some insights on the product itself, right? So you can take a look and see how are my queries performing and stuff like that. Our goal, our job is to surface to you all the metrics that you need to make that decision. 'Cause at the end of the day, a reform DBA or not it is still a skill to analyze the performance of a MySQL query, run and explain, kind of figure all that out. We can't do all of that for you. So we want to give you the information you need either knowledge or you know, stuff to learn whatever it is because some of it does have to come back to, what's my schema? What's my query? And how can I optimize it? I'm missing an index and stuff like that. >> All right. So, you're early adopter of the Kube clock. >> Okay. >> I have to, people say they're ready. >> Nick: Ooh, okay. >> All the time people say they're ready. >> Nick: Woo. >> But I'm not quite sure that they're ready. >> Nick: Well, now I'm nervous. >> So are you ready? >> Do I have any other choice? >> No, you don't. >> Nick: Then I am. >> But are you ready? >> Sure, let's go. >> All right. Start the Kube clock. (upbeat music) >> Nick: All right, what do you want me to do? >> Go. >> All right. >> You said you were ready. >> I'm ready, all right, I'm ready. All right. >> Okay, I'll reset. I'll give you, I'll give, see people say they're ready. >> All right. You're right. You're right. >> Start the Kube clock, go. >> Okay. Are you happy with how your database works? Are you happy with the velocity? Are you happy with what your engineers and what your teams can do with their database? >> Follow the dream not the... Well, follow the green... >> You got to be. >> Not the dream. >> You got to be able to deliver. At the end of the day you got to deliver what the business wants. It's not about performance. >> You got to crawl before you go. You got to crawl, you got to crawl. >> It's not just about is my query fast, it's not just about is my query right, it's about, are my customers getting what they want? >> You're here, you deserve a seat at the table. >> And that's what PlanetScale provides, right? PlanetScale... >> Keith: Ten more seconds. >> PlanetScale is a tool for getting done what you need to get done as a business. That's what we're here for. Ultimately, we want to be the best database for developing software. >> Keith: Two, one. >> That's it. End it there. >> Nick, you took a shot, I'm buying it. Great job. You know, this is fun. Our jobs are complex. >> Yep. >> Databases are hard. >> Yep. >> It is the, where your organization keeps the most valuable assets that you have. >> Nick: A 100%. >> And we are having these tough conversations. >> Nick: Yep. >> Here in Valencia, you're talking to the leader in tech coverage. From Valencia, Spain, I'm Keith Townsend, and you're watching theCUBE, the leader in high tech coverage. (upbeat music)

>> Announcer: "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 and "Kubecon + Cloudnativecon Europe, 2022." I'm Keith Townsend, and we're continuing the conversations with amazing people doing amazing things. I think we've moved beyond a certain phase of the hype cycle when it comes to Kubernetes. And we're going to go a little bit in detail with that today, and on all the sessions, I have today with me, Taylor Dolezal. New head of CNCF Ecosystem. So, first off, what does that mean new head of? You're the head of CNCF Ecosystem? What is the CNCF Ecosystem? >> Yeah. Yeah. It's really the end user ecosystem. So, the CNCF is comprised of really three pillars. And there's the governing board, they oversee the budget and fun things, make sure everything's signed and proper. Then there's the Technical Oversight Committee, TOC. And they really help decide the technical direction of the organization through deliberation and talking about which projects get invited and accepted. Projects get donated, and the TOC votes on who's going to make it in, based on all this criteria. And then, lastly, is the end user ecosystem, that encompasses a whole bunch of different working groups, special interest groups. And that's been really interesting to kind of get a deeper sense into, as of late. So, there are groups like the developer experience group, and the user research group. And those have very specific focuses that kind of go across all industries. But what we've seen lately, is that there are really deep wants to create, whether it be financial services user group, and things like that, because end users are having trouble with going to all of the different meetings. If you're a company, a vendor member company that's selling authentication software, or something in networking, makes sense to have a SIG network, SIG off, and those kinds of things. But when it comes down to like Boeing that just joined, does that make sense for them to jump into all those meetings? Or does it make sense to have some other kind of thing that is representative of them, so that they can attend that one thing, it's specific to their industry? They can get that download and kind of come up to speed, or find the best practices as quickly as possible in a nice synthesized way. >> So, you're 10 weeks into this role. You're coming from a customer environment. So, talk to me a little bit about the customer side of it? When you're looking at something, it's odd to call CNCF massive. But it is, 7.1 million members, and the number of contributing projects, et cetera. Talk to me about the view from the outside versus the view now that you're inside? >> Yeah, so honestly, it's been fun to kind of... For me, it's really mirrored the open-source journey. I've gone to Kubecon before, gotten to enjoy all of the booths, and trying to understand what's going on, and then worked for HashiCorp before coming to the CNCF. And so, get that vendor member kind of experience working the booth itself. So, kind of getting deeper and deeper into the stack of the conference itself. And I keep saying, vendor member and end user members, the difference between those, is end users are not organizations that sell cloud native services. Those are the groups that are kind of more consuming, the Airbnbs, the Boeings, the Mercedes, these people that use these technologies and want to kind of give that feedback back to these projects. But yeah, very incredibly massive and just sprawling when it comes to working in all those contexts. >> So, I have so many questions around, like the differences between having you as an end user and in inter-operating with vendors and the CNCF itself. So, let's start from the end user lens. When you're an end user and you're out discovering open-source and cloud native products, what's that journey like? How do you go from saying, okay, I'm primarily focused on vendor solutions, to let me look at this cloud native stack? >> Yeah, so really with that, there's been, I think that a lot of people have started to work with me and ask for, "Can we have recommended architectures? Can we have blueprints for how to do these things?" When the CNCF doesn't want to take that position, we don't want to kind of be the king maker and be like, this is the only way forward. We want to be inclusive, we want to pull in these projects, and kind of give everyone the same boot strap and jump... I missing the word of it, just ability to kind of like springboard off of that. Create a nice base for everybody to get started with, and then, see what works out, learn from one another. I think that when it comes to Kubernetes, and Prometheus, and some other projects, being able to share best practices between those groups of what works best as well. So, within all of the separations of the CNCF, I think that's something I've found really fun, is kind of like seeing how the projects relate to those verticals and those groups as well. Is how you run a project, might actually have a really good play inside of an organization like, "I like that idea. Let's try that out with our team." >> So, like this idea of springboarding. You know, is when an entrepreneur says, "You know what? I'm going to quit my job and springboard off into doing something new." There's a lot of uncertainty, but for enterprise, that can be really scary. Like we're used to our big vendors, HashiCorp, VMware, Cisco kind of guiding us and telling us like, what's next? What is that experience like, springboarding off into something as massive as cloud native? >> So, I think it's really, it's a great question. So, I think that's why the CNCF works so well, is the fact that it's a safe place for all these companies to come together, even companies of competing products. you know, having that common vision of, we want to make production boring again, we don't want to have so much sprawl and have to take in so much knowledge at once. Can we kind of work together to create all these things to get rid of our adminis trivia or maintenance tasks? I think that when it comes to open-source in general, there's a fantastic book it's called "Working in Public," it's by Stripe Press. I recommend it all over the place. It's orange, so you'll recognize it. Yeah, it's easy to see. But it's really good 'cause it talks about the maintainer journey, and what things make it difficult. And so, I think that that's what the CNCF is really working hard to try to get rid of, is all this monotonous, all these monotonous things, filing issues, best practices. How do you adopt open-source within your organization? We have tips and tricks, and kind of playbooks in ways that you could accomplish that. So, that's what I find really useful for those kinds of situations. Then it becomes easier to adopt that within your organization. >> So, I asked Priyanka, CNCF executive director last night, a pretty tough question. And this is kind of in the meat of what you do. What happens when you? Let's pick on service mesh 'cause everyone likes to pick on service mesh. >> XXXX: Yeah. >> What happens when there's differences at that vendor level on the direction of a CIG or a project, or the ecosystem around service mesh? >> Yeah, so that's the fun part. Honestly, is 'cause people get to hash it out. And so, I think that's been the biggest thing for me finding out, was that there's more than one way to do thing. And so, I think it always comes down to use case. What are you trying to do? And then you get to solve after that. So, it really is, I know it depends, which is the worst answer. But I really do think that's the case, because if you have people that are using something within the automotive space, or in the financial services space, they're going to have completely different needs, wants, you know, some might need to run Coball or Fortran, others might not have to. So, even at that level, just down to what your tech stack looks like, audits, and those kinds of things, that can just really differ. So, I think it does come down to something more like that. >> So, the CNCF loosely has become kind of a standards body. And it's centered around the core project Kubernetes? >> Mm-hmm. >> So, what does it mean, when we're looking at larger segments such as service mesh or observability, et cetera, to be Kubernetes compliant? Where's the point, if any, that the CNCF steps in versus just letting everyone hash it out? Is it Kubernetes just need to be Kubernetes compliant and everything else is free for all? >> Honestly, in many cases, it's up to the communities themselves to decide that. So, the groups that are running OCI, the Open Container Interface, Open Storage Interface, all of those things that we've agreed on as ways to implement those technologies, I think that's where the CNCF, that's the line. That's where the CNCF gets up to. And then, it's like we help foster those communities and those conversations and asking, does this work for you? If not, let's talk about it, let's figure out why it might not. And then, really working closely with community to kind of help bring those things forward and create action items. >> So, it's all about putting the right people in the rooms and not necessarily playing referee, but to get people in the right room to have and facilitate the conversation? >> Absolutely. Absolutely. Like all of the booths behind us could have their own conferences, but we want to bring everybody together to have those conversations. And again, sprawling can be really wild at certain times, but it's good to have those cross understandings, or to hear from somebody that you're like, "Oh, my goodness, I didn't even think about that kind of context or use case." So, really inclusive conversation. >> So, organizations like Boeing, Adobe, Microsoft, from an end user perspective, it's sometimes difficult to get those organizations into these types of communities. How do you encourage them to participate in the conversation 'cause their voice is extremely important? >> Yeah, that I'd also say it really is the community. I really liked the Kubernetes documentary that was put out, working with some of the CNCF folks and core, and beginning Kubernetes contributors and maintainers. And it just kind of blew me away when they had said, you know, what we thought was success, was seeing Kubernetes in an Amazon Data Center. That's when we knew that this was going to take root. And you'd rarely hear that, is like, "When somebody that we typically compete with, its success is seeing it, seeing them use that." And so, I thought was really cool. >> You know, I like to use this technology for my community of skipping rope. You see the girls and boys jumping double Dutch rope. And you think, "I can do that. Like it's just jumping." But there's this hesitation to actually, how do you start? How do you get inside of it? The question is how do you become a member of the community? We've talked a lot about what happens when you're in the community. But how do you join the community? >> So, really, there's a whole bunch of ways that you can. Actually, the shirt that I'm wearing, I got from the 114 Release. So, this is just a fun example of that community. And just kind of how welcoming and inviting that they are. Really, I do think it's kind of like a job breaker. Almost you start at the outside, you start using these technologies, even more generally like, what is DevOps? What is production? How do I get to infrastructure, architecture, or software engineering? Once you start there, you start working your way in, you develop a stack, and then you start to see these tools, technologies, workflows. And then, after you've kind of gotten a good amount of time spent with it, you might really enjoy it like that, and then want to help contribute like, "I like this, but it would be great to have a function that did this. Or I want a feature that does that." At that point in time, you can either take a look at the source code on GitHub, or wherever it's hosted, and then start to kind of come up with that, some ideas to contribute back to that. And then, beyond that, you can actually say, "No, I kind of want to have these conversations with people." Join in those special interest groups, and those meetings to kind of talk about things. And then, after a while, you can kind of find yourself in a contributor role, and then a maintainer role. After that, if you really like the project, and want to kind of work with community on that front. So, I think you had asked before, like Microsoft, Adobe and these others. Really it's about steering the projects. It's these communities want these things, and then, these companies say, "Okay, this is great. Let's join in the conversation with the community." And together again, inclusivity, and bringing everybody to the table to have that discussion and push things forward. >> So, Taylor, closing message. What would you want people watching this show to get when they think about ecosystem and CNCF? >> So, ecosystem it's a big place, come on in. Yeah, (laughs) the water's just fine. I really want people to take away the fact that... I think really when it comes down to, it really is the community, it's you. We are the end user ecosystem. We're the people that build the tools, and we need help. No matter how big or small, when you come in and join the community, you don't have to rewrite the Kubernetes scheduler. You can help make documentation that much more easy to understand, and in doing so, helping thousands of people, If I'm going through the instructions or reading a paragraph, doesn't make sense, that has such a profound impact. And I think a lot of people miss that. It's like, even just changing punctuation can have such a giant difference. >> Yeah, I think people sometimes forget that community, especially community-run projects, they need product managers. They need people that will help with communications, people that will help with messaging, websites updating. Just reachability, anywhere from developing code to developing documentation, there's ways to jump in and help the community. From Valencia, Spain, I'm Keith Townsend, and you're watching "theCUBE," the leader in high tech coverage. (bright upbeat music)

(upbeat music) >> Announcer: 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, a KubeCon, CloudNativeCon Europe, 2022. I'm your host, Keith Townsend alongside Paul Gillon, Senior Editor, Enterprise Architecture for SiliconANGLE. We are, I think at the half point way point this to be fair we've talked to a lot of folks in open source in general. What's the difference between open source communities and these closed source communities that we attend so so much? >> Well open source is just it's that it's open it's anybody can contribute. There are a set of rules that manage how your contributions are reflected in the code base. What has to be shared, what you can keep to yourself but the it's an entirely different vibe. You know, you go to a conventional conference where there's a lot of proprietary being sold and it's all about cash. It's all about money changing hands. It's all about doing the deal. And open source conferences I think are more, they're more transparent and yeah money changes hands, but it seems like the objective of the interaction is not to consummate a deal to the degree that it is at a more conventional computer conference. >> And I think that can create an uneven side effect. And we're going to talk about that a little bit with, honestly a friend of mine Alex Ellis, founder of OpenFaaS. Alex welcome back to the program. >> Thank you, good to see Keith. >> So how long you've been doing OpenFaaS? >> Well, I first had this idea that serverless and function should be run on your own hardware back in 2016. >> Wow and I remember seeing you at DockerCon EU, was that in 2017? >> Yeah, I think that's when we first met and Simon Foskett took us out to dinner and we got chatting. And I just remember you went back to your hotel room after the presentation. You just had your iPhone out and your headphones you were talking about how you tried to OpenWhisk and really struggled with it and OpenFaaS sort of got you where you needed to be to sort of get some value out of the solution. >> And I think that's the magic of these open source communities in open source conferences that you can try stuff, you can struggle with it, come to a conference either get some advice or go in another direction and try something like a OpenFaaS. But we're going to talk about the business perspective. >> Yeah. >> Give us some, like give us some hero numbers from the project. What types of organizations are using OpenFaaS and what are like the download and stars all those, the ways you guys measure project success. >> So there's a few ways that you hear this talked about at KubeCon specifically. And one of the metrics that you hear the most often is GitHub stars. Now a GitHub star means that somebody with their laptop like yourself has heard of a project or seen it on their phone and clicked a button that's it. There's not really an indication of adoption but of interest. And that might be fleeting and a blog post you might publish you might bump that up by 2000. And so OpenFaaS quite quickly got a lot of stars which encouraged me to go on and do more with it. And it's now just crossed 30,000 across the whole organization of about 40 different open source repositories. >> Wow that is a number. >> Now you are in ecosystem where Knative is also taken off. And can you distinguish your approach to serverless or FaaS to Knatives? >> Yes so, Knative isn't an approach to FaaS. That's simply put and if you listen to Aikas Ville from the Knative project, he was working inside Google and wished that Kubernetes would do a little bit more than what it did. And so he started an initiative with some others to start bringing more abstractions like Auto Scaling, revision management so he can have two versions of code and and shift traffic around. And that's really what they're trying to do is add onto Kubernetes and make it do some of the things that a platform might do. Now OpenFaaS started from a different angle and frankly, two years earlier. >> There was no Kubernetes when you started it. >> It kind of led in the space and and built out that ecosystem. So the idea was, I was working with Lambda and AWS Alexa skills. I wanted to run them on my own hardware and I couldn't. And so OpenFaaS from the beginning started from that developer experience of here's my code, run it for me. Knative is a set of extensions that may be a building block but you're still pretty much working with Kubernetes. We get calls come through. And actually recently I can't tell you who they are but there's a very large telecommunications provider in the US that was using OpenFaaS, like yourself heard of Knative and in the hype they switched. And then they switched back again recently to OpenFaaS and they've come to us for quite a large commercial deal. >> So did they find Knative to be more restrictive? >> No, it's the opposite. It's a lot less opinionated. It's more like building blocks and you are dealing with a lot more detail. It's a much bigger system to manage, but don't get me wrong. I mean the guys are very friendly. They have their sort of use cases that they pursue. Google's now donated the project to CNCF. And so they're running it that way. Now it doesn't mean that there aren't FaaS on top of it. Red Hat have a serverless product VMware have one. But OpenFaaS because it owns the whole stack can get you something that's always been very lean, simple to use to the point that Keith in his hotel room installed it and was product with it in an evening without having to be a Kubernetes expert. >> And that is and if you remember back that was very anti-Kubernetes. >> Yes. >> It was not a platform I thought that was. And for some of the very same reasons, I didn't think it was very user friendly. You know, I tried open with I'm thinking what enterprise is going to try this thing, especially without the handholding and the support needed to do that. And you know, something pretty interesting that happened as I shared this with you on Twitter, I was having a briefing by a big microprocessor company, one of the big two. And they were showing me some of the work they were doing in Cloud-native and the way that they stretch test the system to show me Auto Scaling. Is that they bought up a OpenFaaS what is it? The well text that just does a bunch of, >> The cows maybe. >> Yeah the cows. That does just a bunch of texts. And it just all, and I'm like one I was amazed at is super simple app. And the second one was the reason why they discovered it was because of that simplicity is just a thing that's in your store that you can just download and test. And it was open fast. And it was this big company that you had no idea that was using >> No >> OpenFaaS. >> No. >> How prevalent is that? That you're always running into like these surprises of who's using the solution. >> There are a lot of top tier companies, billion dollar companies that use software that I've worked on. And it's quite common. The main issue you have with open source is you don't have like the commercial software you talked about, the relationships. They don't tell you they're using it until it breaks. And then they may come in incognito with a personal email address asking for things. What they don't want to do often is lend their brands or support you. And so it is a big challenge. However, early on, when I met you, BT, live person the University of Washington, and a bunch of other companies had told us they were using it. We were having discussions with them took them to Kubecon and did talks with them. You can go and look at them in the video player. However, when I left my job in 2019 to work on this full time I went to them and I said, you know, use it in production it's useful for you. We've done a talk, we really understand the business value of how it saves you time. I haven't got a way to fund it and it won't exist unless you help they were like sucks to be you. >> Wow that's brutal. So, okay let me get this right. I remember the story 2019, you leave your job. You say I'm going to do OpenFaaS and support this project 100% of your time. If there's no one contributing to the project from a financial perspective how do you make money? I've always pitched open source because you're the first person that I've met that ran an open source project. And I always pitched them people like you who work on it on their side time. But they're not the Knatives of the world, the SDOs, they have full time developers. Sponsored by Google and Microsoft, etc. If you're not sponsored how do you make money off of open source? >> If this is the million dollar question, really? How do you make money from something that is completely free? Where all of the value has already been captured by a company and they have no incentive to support you build a relationship or send you money in any way. >> And no one has really figured it out. Arguably Red Hat is the only one that's pulled it off. >> Well, people do refer to Red Hat and they say the Red Hat model but I think that was a one off. And we quite, we can kind of agree about that in a business. However, I eventually accepted the fact that companies don't pay for something they can get for free. It took me a very long time to get around that because you know, with open source enthusiast built a huge community around this project, almost 400 people have contributed code to it over the years. And we have had full-time people working on it on and off. And there's some people who really support it in their working hours or at home on the weekends. But no, I had to really think, right, what am I going to offer? And to begin with it would support existing customers weren't interested. They're not really customers because they're consuming it as a project. So I needed to create a product because we understand we buy products. Initially I just couldn't find the right customers. And so many times I thought about giving up, leaving it behind, my family would've supported me with that as well. And they would've known exactly why even you would've done. And so what I started to do was offer my insights as a community leader, as a maintainer to companies like we've got here. So Casting one of my customers, CSIG one of my customers, Rancher R, DigitalOcean, a lot of the vendors you see here. And I was able to get a significant amount of money by lending my expertise and writing content that gave me enough buffer to give the doctors time to realize that maybe they do need support and go a bit further into production. And over the last 12 months, we've been signing six figure deals with existing users and new users alike in enterprise. >> For support >> For support, for licensing of new features that are close source and for consulting. >> So you have proprietary extensions. Also that are sort of enterprise class. Right and then also the consulting business, the support business which is a proven business model that has worked >> Is a proven business model. What it's not a proven business model is if you work hard enough, you deserve to be rewarded. >> Mmh. >> You have to go with the system. Winter comes after autumn. Summer comes after spring and you, it's no point saying why is it like that? That's the way it is. And if you go with it, you can benefit from it. And that's what the realization I had as much as I didn't want to do it. >> So you know this community, well you know there's other project founders out here thinking about making the leap. If you're giving advice to a project founder and they're thinking about making this leap, you know quitting their job and becoming the next Alex. And I think this is the perception that the misperception out there. >> Yes. >> You're, you're well known. There's a difference between being well known and well compensated. >> Yeah. >> What advice would you give those founders >> To be. >> Before they make the leap to say you know what I'm going to do my project full time. I'm going to lean on the generosity of the community. So there are some generous people in the community. You've done some really interesting things for individual like contributions etc but that's not enough. >> So look, I mean really you have to go back to the MBA mindset. What problem are you trying to solve? Who is your target customer? What do they care about? What do they eat and drink? When do they go to sleep? You really need to know who this is for. And then customize a journey for them so that they can come to you. And you need some way initially of funneling those people in qualifying them because not everybody that comes to a student or somebody doing a PhD is not your customer. >> Right, right. >> You need to understand sales. You need to understand a lot about business but you can work it out on your way. You know, I'm testament to that. And once you have people you then need something to sell them that might meet their needs and be prepared to tell them that what you've got isn't right for them. 'cause sometimes that's the one thing that will build integrity. >> That's very hard for community leaders. It's very hard for community leaders to say, no >> Absolutely so how do you help them over that hump? I think of what you've done. >> So you have to set some boundaries because as an open source developer and maintainer you want to help everybody that's there regardless. And I think for me it was taking some of the open source features that companies used not releasing them anymore in the open source edition, putting them into the paid developing new features based on what feedback we'd had, offering support as well but also understanding what is support. What do you need to offer? You may think you need a one hour SLA for a fix probably turns out that you could sell a three day response time or one day response time. And some people would want that and see value in it. But you're not going to know until you talk to your customers. >> I want to ask you, because this has been a particular interest of mine. It seems like managed services have been kind of the lifeline for pure open source companies. Enabling these companies to maintain their open source roots, but still have a revenue stream of delivering as a service. Is that a business model option you've looked at? >> There's three business models perhaps that are prevalent. One is OpenCore, which is roughly what I'm following. >> Right. >> Then there is SaaS, which is what you understand and then there's support on pure open source. So that's more like what Rancher does. Now if you think of a company like Buoyant that produces Linkerd they do a bit of both. So they don't have any close source pieces yet but they can host it for you or you can host it and they'll support you. And so I think if there's a way that you can put your product into a SaaS that makes it easier for them to run then you know go for it. However, we've OpenFaaS, remember what is the core problem we are solving, portability So why lock into my cloud? >> Take that option off the table, go ahead. >> It's been a long journey and I've been a fan since your start. I've seen the bumps and bruises and the scars get made. If you're open source leader and you're thinking about becoming as famous as Alex, hey you can do that, you can put in all the work become famous but if you want to make a living, solve a problem, understand what people are willing to pay for that problem and go out and sell it. Valuable lessons here on theCUBE. From Valencia, Spain I'm Keith Townsend along with Paul Gillon and you're watching theCUBE the leader in high-tech coverage. (Upbeat music)

(upbeat music) >> Announcer: 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. I'm your host Keith Townsend, along with Paul Gillon. And we're going to talk to some amazing folks. But first Paul, do you remember your college days? >> Vaguely. (Keith laughing) A lot of them are lost. >> I think a lot of mine are lost as well. Well, not really, I got my degree as an adult, so they're not that far past. I can remember 'cause I have the student debt to prove it. (both laughing) Along with us today is Kenneth Hoste, systems administrator at Ghent University, and Marcel Hild, senior manager software engineering at Red Hat. You're working in office of the CTO? >> That's absolutely correct, yes >> So first off, I'm going to start off with you Kenneth. Tell us a little bit about the research that the university does. Like what's the end result? >> Oh, wow, that's a good question. So the research we do at university and again, is very broad. We have bioinformaticians, physicists, people looking at financial data, all kinds of stuff. And the end result can be very varied as well. Very often it's research papers, or spinoffs from the university. Yeah, depending on the domain I would say, it depends a lot on. >> So that sounds like the perfect environment for cloud native. Like the infrastructure that's completely flexible, that researchers can come and have a standard way of interacting, each team just use it's resources as they would, the Navana for cloud native. >> Yeah. >> But somehow, I'm going to guess HPC isn't quite there yet. >> Yeah, not really, no. So, HPC is a bit, let's say slow into adopting new technologies. And we're definitely seeing some impact from cloud, especially things like containers and Kubernetes, or we're starting to hear these things in HPC community as well. But I haven't seen a lot of HPC clusters who are really fully cloud native. Not yet at least. Maybe this is coming. And if I'm walking around here at KubeCon, I can definitely, I'm being convinced that it's coming. So whether we like it or not we're probably going to have to start worrying about stuff like this. But we're still, let's say, the most prominent technologies of things like NPI, which has been there for 20, 30 years. The Fortran programming language is still the main language, if you're looking at compute time being spent on supercomputers, over 1/2 of the time spent is in Fortran code essentially. >> Keith: Wow. >> So either the application itself where the simulations are being done is implemented in Fortran, or the libraries that we are talking to from Python for example, for doing heavy duty computations, that backend library is implemented in Fortran. So if you take all of that into account, easily over 1/2 of the time is spent in Fortran code. >> So is this because the libraries don't migrate easily to, distributed to that environment? >> Well, it's multiple things. So first of all, Fortran is very well suited for implementing these type of things. >> Paul: Right. >> We haven't really seen a better alternative maybe. And also it'll be a huge effort to re-implement that same functionality in a newer language. So, the use case has to be very convincing, there has to be a very good reason why you would move away from Fortran. And, at least the HPC community hasn't seen that reason yet. >> So in theory, and right now we're talking about the theory and then what it takes to get to the future. In theory, I can take that Fortran code put it in a compiler that runs in a container? >> Yeah, of course, yeah. >> Why isn't it that simple? >> I guess because traditionally HPC is very slow at adopting new stuff. So, I'm not saying there isn't a reason that we should start looking at these things. Flexibility is a very important one. For a lot of researchers, their compute needs are very picky. So they're doing research, they have an idea, they want you to run lots of simulations, get the results, but then they're silent for a long time writing the paper, or thinking about how to, what they can learn from the results. So there's lots of peaks, and that's a very good fit for a cloud environment. I guess at the scale of university you have enough diversity end users that all those peaks never fall at the same time. So if you have your big own infrastructure you can still fill it up quite easily and keep your users happy. But this busty thing, I guess we're seeing that more and more or so. >> So Marcel, talk to us about, Red Hat needing to service these types of end users. That it can be on both ends I'd imagine that you have some people still in writing in Fortran, you have some people that's asking you for objects based storage. Where's Fortran, I'm sorry, not Fortran, but where is Red Hat in providing the underlay and the capabilities for the HPC and AI community? >> Yeah. So, I think if you look at the user base that we're looking at, it's on this spectrum from development to production. So putting AI workloads into production, it's an interesting challenge but it's easier to solve, and it has been solved to some extent, than the development cycle. So what we're looking at in Kenneth's domain it's more like the end user, the data scientist, developing code, and doing these experiments. Putting them into production is that's where containers live and thrive. You can containerize your model, you containerize your workload, you deploy it into your OpenShift Kubernetes cluster, done, you monitor it, done. So the software developments and the SRE, the ops part, done, but how do I get the data scientist into this cloud native age where he's not developing on his laptop or on a machine, where he SSH into and then does some stuff there. And then some system admin comes and needs to tweak it because it's running out of memory or whatnot. But how do we take him and make him, well, and provide him an environment that is good enough to work in, in the browser, and then with IDE, where the workload of doing the computation and the experimentation is repeatable, so that the environment is always the same, it's reliable, so it's always up and running. It doesn't consume resources, although it's up and running. Where it's, where the supply chain and the configuration of... And the, well, the modules that are brought into the system are also reliable. So all these problems that we solved in the traditional software development world, now have to transition into the data science and HPC world, where the problems are similar, but yeah, it's different sets. It's more or less, also a huge educational problem and transitioning the tools over into that is something... >> Well, is this mostly a technical issue or is this a cultural issue? I mean, are HPC workloads that different from more conventional OLTP workloads that they would not adapt well to a distributed containerized environment? >> I think it's both. So, on one hand it's the cultural issue because you have two different communities, everybody is reinventing the wheel, everybody is some sort of siloed. So they think, okay, what we've done for 30 years now we, there's no need to change it. And they, so it's, that's what thrives and here at KubeCon where you have different communities coming together, okay, this is how you solved the problem, maybe this applies also to our problem. But it's also the, well, the tooling, which is bound to a machine, which is bound to an HPC computer, which is architecturally different than a distributed environment where you would treat your containers as kettle, and as something that you can replace, right? And the HPC community usually builds up huge machines, and these are like the gray machines. So it's also technical bit of moving it to this age. >> So the massively parallel nature of HPC workloads you're saying Kubernetes has not yet been adapted to that? >> Well, I think that parallelism works great. It's just a matter of moving that out from an HPC computer into the scale out factor of a Kubernetes cloud that elastically scales out. Whereas the traditional HPC computer, I think, and Kenneth can correct me here is, more like, I have this massive computer with 1 million cores or whatnot, and now use it. And I can use my time slice, and book my time slice there. Whereas this a Kubernetes example the concept is more like, I have 1000 cores and I declare something into it and scale it up and down based on the needs. >> So, Kenneth, this is where you talked about the culture part of the changes that need to be happening. And quite frankly, the computer is a tool, it's a tool to get to the answer. And if that tool is working, if I have a 1000 cores on a single HPC thing, and you're telling me, well, I can't get to a system with 2000 cores. And if you containerized your process and move it over then maybe I'll get to the answer 50% faster maybe I'm not that... Someone has to make that decision. How important is it to get people involved in these types of communities from a researcher? 'Cause research is very tight-knit community to have these conversations and help that see move happen. >> I think it's very important to that community should, let's say, the cloud community, HPC research community, they should be talking a lot more, there should be way more cross pollination than there is today. I'm actually, I'm happy that I've seen HPC mentioned at booths and talks quite often here at KubeCon, I wasn't really expecting that. And I'm not sure, it's my first KubeCon, so I don't know, but I think that's kind of new, it's pretty recent. If you're going to the HPC community conferences there containers have been there for a couple of years now, something like Kubernetes is still a bit new. But just this morning there was a keynote by a guy from CERN, who was explaining, they're basically slowly moving towards Kubernetes even for their HPC clusters as well. And he's seeing that as the future because all the flexibility it gives you and you can basically hide all that from the end user, from the researcher. They don't really have to know that they're running on top of Kubernetes. They shouldn't care. Like you said, to them it's just a tool, and they care about if the tool works, they can get their answers and that's what they want to do. How that's actually being done in the background they don't really care. >> So talk to me about the AI side of the equation, because when I talk to people doing AI, they're on the other end of the spectrum. What are some of the benefits they're seeing from containerization? >> I think it's the reproducibility of experiments. So, and data scientists are, they're data scientists and they do research. So they care about their experiment. And maybe they also care about putting the model into production. But, I think from a geeky perspective they are more interested in finding the next model, finding the next solution. So they do an experiment, and they're done with it, and then maybe it's going to production. So how do I repeat that experiment in a year from now, so that I can build on top of it? And a container I think is the best solution to wrap something with its dependency, like freeze it, maybe even with the data, store it away, and then come to it back later and redo the experiment or share the experiment with some of my fellow researchers, so that they don't have to go through the process of setting up an equivalent environment on their machines, be it their laptop, via their cloud environment. So you go to the internet, download something doesn't work, container works. >> Well, you said something that really intrigues me you know in concept, I can have a, let's say a one terabyte data set, have a experiment associated with that. Take a snapshot of that somehow, I don't know how, take a snapshot of that and then share it with the rest of the community and then continue my work. >> Marcel: Yeah. >> And then we can stop back and compare notes. Where are we at in a maturity scale? Like, what are some of the pitfalls or challenges customers should be looking out for? >> I think you actually said it right there, how do I snapshot a terabyte of data? It's, that's... >> It's a terabyte of data. (both conversing) >> It's a bit of a challenge. And if you snapshot it, you have two terabytes of data or you just snapshot the, like and get you to do a, okay, this is currently where we're at. So that's why the technology is evolving. How do we do source control management for data? How do we license data? How do we make sure that the data is unbiased, et cetera? So that's going more into the AI side of things. But at dealing with data in a declarative way in a containerized way, I think that's where currently a lot of innovation is happening. >> What do you mean by dealing with data in a declarative way? >> If I'm saying I run this experiment based on this data set and I'm running this other experiment based on this other data set, and I as the researcher don't care where the data is stored, I care that the data is accessible. And so I might declare, this is the process that I put on my data, like a data processing pipeline. These are the steps that it's going through. And eventually it will have gone through this process and I can work with my data. Pretty much like applying the concept of pipelines through data. Like you have these data pipelines and then now you have cube flow pipelines as one solution to apply the pipeline concept, to well, managing your data. >> Given the stateless nature of containers, is that an impediment to HPC adoption because of the very large data sets that are typically involved? >> I think it is if you have terabytes of data. Just, you have to get it to the place where the computation will happen, right? And just uploading that into the cloud is already a challenge. If you have the data sitting there on a supercomputer and maybe it was sitting there for two years, you probably don't care. And typically a lot of universities the researchers don't necessarily pay for the compute time they use. Like, this is also... At least in Ghent that's the case, it's centrally funded, which means, the researchers don't have to worry about the cost, they just get access to the supercomputer. If they need two terabytes of data, they get that space and they can park it on the system for years, no problem. If they need 200 terabytes of data, that's absolutely fine. >> But the university cares about the cost? >> The university cares about the cost, but they want to enable the researchers to do the research that they want to do. >> Right. >> And we always tell researchers don't feel constrained about things like compute power, storage space. If you're doing smaller research, because you're feeling constrained, you have to tell us, and we will just expand our storage system and buy a new cluster. >> Paul: Wonderful. >> So you, to enable your research. >> It's a nice environment to be in. I think this might be a Jevons paradox problem, you give researchers this capability you might, you're going to see some amazing things. Well, now the people are snapshoting, one, two, three, four, five, different versions of a one terabytes of data. It's a good problem to have, and I hope to have you back on theCUBE, talking about how Red Hat and Ghent have solved those problems. Thank you so much for joining theCUBE. From Valencia, Spain, I'm Keith Townsend along with Paul Gillon. And you're watching theCUBE, the leader in high tech coverage. (upbeat music)

>> Announcer: "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 and KubeCon and CloudNativeCon Europe 2022. I'm Keith Townsend, my co-host, Paul Gillin, Senior Editor Enterprise Architecture for SiliconANGLE. We're going to talk, or continue to talk to amazing people. The coverage has been amazing, but also the city of Valencia is beautiful. I have to eat a little crow, I landed and I saw the convention center, Paul, have you got out and explored the city at all? >> Absolutely, my first reaction to Valencia when we were out in this industrial section was, "This looks like Cincinnati." >> Yes. >> But then I got on the bus second day here, 10 minutes to downtown, another world, it's almost a middle ages flavor down there with these little winding streets and just absolutely gorgeous city. >> Beautiful city. I compared it to Charlotte, no disrespect to Charlotte, but this is an amazing city. Naina Singh, Principal Product Manager at Red Hat, and Roland Huss, also Principal Product Manager at Red Hat. We're going to talk a little serverless. I'm going to get this right off the bat. People get kind of feisty when we call things like Knative serverless. What's the difference between something like a Lambda and Knative? >> Okay, so I'll start. Lambda is, like a function as a server, right? Which is one of the definitions of serverless. Serverless is a deployment platform now. When we introduced serverless to containers through Knative, that's when the serverless got revolutionized, it democratized serverless. Lambda was proprietary-based, you write small snippets of code, run for a short duration of time on demand, and done. And then Knative which brought serverless to containers, where all those benefits of easy, practical, event-driven, running on demand, going up and down, all those came to containers. So that's where Knative comes into picture. >> Yeah, I would also say that Knative is based on containers from the very beginning, and so, it really allows you to run arbitrary workloads in your container, whereas with Lambda you have only a limited set of language that you can use and you have a runtime contract there which is much easier with Knative to run your applications, for example, if it's coming in a language that is not supported by Lambda. And of course the most important benefit of Knative is it's run on top of Kubernetes, which allows you- >> Yes. >> To run your serverless platform on any other Kubernetes installation, so I think this is one of the biggest thing. >> I think we saw about three years ago there was a burst of interest around serverless computing and really some very compelling cost arguments for using it, and then it seemed to die down, we haven't heard a lot about serverless, and maybe I'm just not listening to the right people, but what is it going to take for serverless to kind of break out and achieve its potential? >> Yeah, I would say that really the big advantage of course of Knative in that case is that you can scale down to zero. I think this is one of the big things that will really bring more people onto board because you really save a lot of money with that if your applications are not running when they're not used. Yeah, I think also that, because you don't have this vendor log in part thing, when people realize that you can run really on every Kubernete platform, then I think that the journey of serverless will continue. >> And I will add that the event-driven applications, there hasn't been enough buzz around them yet. There is, but serverless is going to bring a new lease on life on them, right? The other thing is the ease of use for developers. With Knative, we are introducing a new programming model, the functions, where you don't even have to create containers, it would do create containers for you. >> So you create the servers, but not the containers? >> Right now, you create the containers and then you deploy them in a serverless fashion using Knative. But the container creation was on the developers, and functions is going to be the third component of Knative that we are developing upstream, and Red Hat donated that project, is going to be where code to cloud capability. So you bring your code and everything else will be taken care of, so. >> So, I'd call a function or, it's funny, we're kind of circular with this. What used to be, I'd write a function and put it into a container, this server will provide that function not just call that function as if I'm developing kind of a low code no code, not no code, but a low code effort. So if there's a repetitive thing that the community wants to do, you'll provide that as a predefined function or as a server. >> Yeah, exactly. So functions really helps the developer to bring their code into the container, so it's really kind of a new (indistinct) on top of Knative- >> on top op. >> And of course, it's also a more opinionated approach. It's really more closer coming to Lambda now because it also comes with a programming model, which means that you have certain signature that you have to implement and other stuff. But you can also create your own templates, because at the end what matters is that you have a container at the end that you can run on Knative. >> What kind of applications is serverless really the ideal platform? >> Yeah, of course the ideal application is a HTTP-based web application that has no state and that has a very non-uniform traffic shape, which means that, for example, if you have a business where you only have spikes at certain times, like maybe for Super Bowl or Christmas, when selling some merchandise like that, then you can scale up from zero very quickly at a arbitrary high depending on the load. And this is, I think, the big benefit over, for example, Kubernetes Horizontal Pod Autoscaling where it's more like indirect measures of value scaling based on CPR memory, but here, it directly relates one to one to the traffic that is coming in to concurrent request. Yeah, so this helps a lot for non-uniform traffic shapes that I think this has become one of the ideal use case. >> Yeah. But I think that is one of the most used or defined one, but I do believe that you can write almost all applications. There are some, of course, that would not be the right load, but as long as you are handling state through external mechanism. Let's say, for example you're using database to save the state, or you're using physical volume amount to save the state, it increases the density of your cluster because when they're running, the containers would pop up, when your application is not running, the container would go down, and the resources can be used to run any other application that you want to us, right? >> So, when I'm thinking about Lambda, I kind of get the event-driven nature of Lambda. I have a S3 bucket, and if a S3 event is driven, then my functions as the server will start, and that's kind of the listening servers. How does that work with Knative or a Kubernetes-based thing? 'Cause I don't have an event-driven thing that I can think of that kicks off, like, how can I do that in Kubernetes? >> So I'll start. So it is exactly the same thing. In Knative world, it's the container that's going to come up and your servers in the container, that will do the processing of that same event that you are talking. So let's say the notification came from S3 server when the object got dropped, that would trigger an application. And in world of Kubernetes, Knative, it's the container that's going to come up with the servers in it, do the processing, either find another servers or whatever it needs to do. >> So Knative is listening for the event, and when the event happens, then Knative executes the container. >> Exactly. >> Basically. >> So the concept of Knative source which is kind of adapted to the external world, for example, for the S3 bucket. And as soon as there is an event coming in, Knative will wake up that server, will transmit this event as a cloud event, which is another standard from the CNCF, and then when the server is done, then the server spins down again to zero so that the server is only running when there are events, which is very cost effective and which people really actually like to have this kind of way of dynamic scaling up from zero to one and even higher like that. >> Lambda has been sort of synonymous with serverless in the early going here, is Knative a competitor to Lambda, is it complimentary? Would you use the two together? >> Yeah, I would say that Lambda is a offering from AWS, so it's a cloud server there. Knative itself is a platform, so you can run it in the cloud, and there are other cloud offerings like from IBM, but you can also run it on-premise for example, that's the alternative. So you can also have hybrid set scenarios where you really can put one part into the cloud, the other part on-prem, and I think there's a big difference in that you have a much more flexibility and you can avoid this kind of Windows login compared to AWS Lambda. >> Because Knative provides specifications and performance tests, so you can move from one server to another. If you are on IBM offering that's using Knative, and if you go to a Google offering- >> A google offering. >> That's on Knative, or a Red Hat offering on Knative, it should be seamless because they're both conforming to the same specifications of Knative. Whereas if you are in Lambda, there are custom deployments, so you are only going to be able to run those workloads only on AWS. >> So KnativeCon, co-located event as part of KubeCon, I'm curious as to the level of effort in the user interaction for deploying Knative. 'Cause when I think about Lambda or cloud-run or one of the other functions as a servers, there is no backend that I have to worry about. And I think this is where some of the debate becomes over serverless versus some other definition. What's the level of lifting that needs to be done to deploy Knative in my Kubernetes environment? >> So if you like... >> Is this something that comes as based part of the OpenShift install or do I have to like, you know, I have to... >> Go ahead, you answer first. >> Okay, so actually for OpenShift, it's a code layer product. So you have this catalog of operator that you can choose from, and OpenShift Serverless is one part of that. So it's really kind of a one click install where you have also get a default configuration, you can flexibly configure it as you like. Yeah, we think that's a good user experience and of course you can go to these cloud offerings like Google Cloud one or IBM Code Engine, they just have everything set up for you. And the idea of other different alternatives, you have (indistinct) charts, you can install Knative in different ways, you also have options for the backend systems. For example, we mentioned that when an event comes in, then there's a broker in the middle of something which dispatches all the events to the servers, and there you can have a different backend system like Kafka or AMQ. So you can have very production grade messaging system which really is responsible for delivering your events to your servers. >> Now, Knative has recently, I'm sorry, did I interrupt you? >> No, I was just going to say that Knative, when we talk about, we generally just talk about the serverless deployment model, right? And the Eventing gets eclipsed in. That Eventing which provides this infrastructure for producing and consuming event is inherent part of Knative, right? So you install Knative, you install Eventing, and then you are ready to connect all your disparate systems through Events. With CloudEvents, that's the specification we use for consistent and portable events. >> So Knative recently admitted to the, or accepted by the Cloud Native Computing Foundation, incubating there. Congratulations, it's a big step. >> Thank you. >> Thanks. >> How does that change the outlook for Knative adoption? >> So we get a lot of support now from the CNCF which is really great, so we could be part of this conference, for example which was not so easy before that. And we see really a lot of interest and we also heard before the move that many contributors were not, started into looking into Knative because of this kind of non being part of a mutual foundation, so they were kind of afraid that the project would go away anytime like that. And we see the adoption really increases, but slowly at the moment. So we are still ramping up there and we really hope for more contributors. Yeah, that's where we are. >> CNCF is almost synonymous with open source and trust. So, being in CNCF and then having this first KnativeCon event as part of KubeCon, we are hoping, and it's a recent addition to CNCF as well, right? So we are hoping that this events and these interviews, this will catapult more interest into serverless. So I'm really, really hopeful and I only see positive from here on out for Knative. >> Well, I can sense the excitement. KnativeCon sold out, congratulations on that. >> Thank you. >> I can talk about serverless all day, it's a topic that I really love, it's a fascinating way to build applications and manage applications, but we have a lot more coverage to do today on "theCUBE" from Spain. From Valencia, Spain, I'm Keith Townsend along with Paul Gillin, and you're watching "theCUBE," the leader in high-tech coverage. (gentle upbeat music)

(upbeat music) >> theCUBE presents KubeCon and CloudNativeCon Europe 22, brought to you by the Cloud Native Computing Foundation. >> Valencia, Spain, a KubeCon, CloudNativeCon Europe 2022. I'm Keith Towns along with Paul Gillon, Senior Editor Enterprise Architecture for Silicon Angle. Welcome Paul. >> Thank you Keith, pleasure to work with you. >> We're going to have some amazing people this week. I think I saw stat this morning, 65% of the attendees, 7,500 folks. First time KubeCon attendees, is this your first conference? >> It is my first KubeCon and it is amazing to see how many people are here and to think of just a couple of years ago, three years ago, we were still talking about, what the Cloud was, what the Cloud was going to do and how we were going to integrate multiple Clouds. And now we have this whole new framework for computing that is just rifled out of nowhere. And as we can see by the number of people who are here this has become the dominant trend in Enterprise Architecture right now how to adopt Kubernetes and containers, build microservices based applications, and really get to that transparent Cloud that has been so elusive. >> It has been elusive. And we are seeing vendors from startups with just a few dozen people, to some of the traditional players we see in the enterprise space with 1000s of employees looking to capture kind of lightning in a bottle so to speak, this elusive concept of multicloud. >> And what we're seeing here is very typical of an early stage conference. I've seen many times over the years where the floor is really dominated by companies, frankly, I've never heard of that. The many of them are only two or three years old, you don't see the big dominant computing players with the presence here that these smaller companies have. That's very typical. We saw that in the PC age, we saw it in the early days of Unix and it's happening again. And what will happen over time is that a lot of these companies will be acquired, there'll be some consolidation. And the nature of this show will change, I think dramatically over the next couple or three years but there is an excitement and an energy in this auditorium today that is really a lot of fun and very reminiscent of other new technologies just as they requested. >> Well, speaking of new technologies, we have Dave Cole, CRO, Chief Revenue Officer. >> That's right. >> Chief Marketing Officer of Spectrum Cloud. Welcome to the show. >> Thank you. It's great to be here. >> So let's talk about this big ecosystem, Kubernetes. >> Yes. >> Solve problem? >> Well the dream is... Well, first of all applications are really the lifeblood of a company, whether it's our phone or whether it's a big company trying to connect with its customers about applications. And so the whole idea today is how do I build these applications to build that tight relationship with my customers? And how do I reinvent these applications rapidly in along comes containerization which helps you innovate more quickly? And certainly a dominant technology there is Kubernetes. And the question is, how do you get Kubernetes to help you build applications that can be born anywhere and live anywhere and take advantage of the places that it's running? Because everywhere has pluses and minuses. >> So you know what, the promise of Kubernetes from when I first read about it years ago is, runs on my laptop? >> Yeah. >> I can push it to any Cloud, any platforms. >> That's right, that's right. >> Where's the gap? Where are we in that phase? Like talk to me about scale? Is it that simple? >> Well, that is actually the problem is that today, while the technology is the dominant containerization technology in orchestration technology, it really still takes a power user, it really hasn't been very approachable to the masses. And so was these very expensive highly skilled resources that sit in a dark corner that have focused on Kubernetes, but that now is trying to evolve to make it more accessible to the masses. It's not about sort of hand wiring together, what is a typical 20 layer stack, to really manage Kubernetes and then have your engineers manually can reconfigure it and make sure everything works together. Now it's about how do I create these stacks, make it easy to deploy and manage at scale? So we've gone from sort of DIY Developer Centric to all right, now how do I manage this at scale? >> Now this is a point that is important, I think is often overlooked. This is not just about Kubernetes. This is about a whole stack of Cloud Native Technologies. And you who is going to integrate that all that stuff, piece that stuff together? Obviously, you have a role in that. But in the enterprise, what is the awareness level of how complex this stack is and how difficult it is to assemble? >> We see a recognition of that we've had developers working on Kubernetes and applications, but now when we say, how do we weave it into our production environments? How do we ensure things like scalability and governance? How do we have this sort of interesting mix of innovation, flexibility, but with control? And that's sort of an interesting combination where you want developers to be able to run fast and use the latest tools, but you need to create these guardrails to deploy it at scale. >> So where do the developers fit in that operation stack then? Is Kubernetes an AIOps or an ops task or is it sort of a shared task across the development spectrum? >> Well, I think there's a desire to allow application developers to just focus on the application and have a Kubernetes related technology that ensures that all of the infrastructure and related application services are just there to support them. And because the typical stack from the operating system to the application can be up to 20 different layers, components, you just want all those components to work together, you don't want application developers to worry about those things. And the latest technologies like Spectra Cloud there's others are making that easy application engineers focus on their apps, all of the infrastructure and the services are taken care of. And those apps can then live natively on any environment. >> So help paint this picture for us. I get AKS, EKS, Anthos, all of these distributions OpenShift, the Tanzu, where's Spectra Cloud helping me to kind of cobble together all these different distros, I thought distro was the thing just like Linux has different distros, Randy said different distros. >> That actually is the irony, is that sort of the age of debating the distros largely is over. There are a lot of distros and if you look at them there are largely shades of gray in being different from each other. But the Kubernetes distribution is just one element of like 20 elements that all have to work together. So right now what's happening is that it's not about the distribution it's now how do I again, sorry to repeat myself, but move this into scale? How do I move it into deploy at scale to be able to manage ongoing at scale to be able to innovate at-scale, to allow engineers as I said, use the coolest tools but still have technical guardrails that the enterprise knows, they'll be in control of. >> What does at-scale mean to the enterprise customers you're talking to now? What do they mean when they say that? >> Well, I think it's interesting because we think scale's different because we've all been in the industry and it's frankly, sort of boring old word. But today it means different things, like how do I automate the deployment at-scale? How do I be able to make it really easy to provision resources for applications on any environment, from either a virtualized or bare metal data center, Cloud, or today Edge is really big, where people are trying to push applications out to be closer to the source of the data. And so you want to be able to deploy it-scale, you want to manage at-scale, you want to make it easy to, as I said earlier, allow application developers to build their applications, but ITOps wants the ability to ensure security and governance and all of that. And then finally innovate at-scale. If you look at this show, it's interesting, three years ago when we started Spectra Cloud, there are about 1400 businesses or technologies in the Kubernetes ecosystem, today there's over 1800 and all of these technologies made up of open source and commercial all version in a different rates, it becomes an insurmountable problem, unless you can set those guardrails sort of that balance between flexibility, control, let developers access the technologies. But again, manage it as a part of your normal processes of a scaled operation. >> So Dave, I'm a little challenged here, because I'm hearing two where I typically consider conflicting terms. Flexibility, control. >> Yes. >> In order to achieve control, I need complexity, in order to choose flexibility, I need t-shirt, one t-shirt fits all and I get simplicity. How can I get both that just doesn't compute. >> Well, that's the opportunity and the challenge at the same time. So you're right. So developers want choice, good developers want the ability to choose the latest technology so they can innovate rapidly. And yet ITOps, wants to be able to make sure that there are guardrails. And so with some of today's technologies, like Spectra Cloud, it is, you have the ability to get both. We actually worked with dimensional research, and we sponsor an annual state of Kubernetes survey. We found this last summer, that two out of three IT executives said, you could not have both flexibility and control together, but in fact they want it. And so it is this interesting balance, how do I give engineers the ability to get anything they want, but ITOps the ability to establish control. And that's why Kubernetes is really at its next inflection point. Whereas I mentioned, it's not debates about the distro or DIY projects. It's not big incumbents creating siloed Kubernetes solutions, but in fact it's about allowing all these technologies to work together and be able to establish these controls. And that's really where the industry is today. >> Enterprise , enterprise CIOs, do not typically like to take chances. Now we were talking about the growth in the market that you described from 1400, 1800 vendors, most of these companies, very small startups, our enterprises are you seeing them willing to take a leap with these unproven companies? Or are they holding back and waiting for the IBMs, the HPS, the MicrosoftS to come in with the VMwares with whatever they solution they have? >> I think so. I mean, we sell to the global 2000. We had yesterday, as a part of Edge day here at the event, we had GE Healthcare as one of our customers telling their story, and they're a market share leader in medical imaging equipment, X-rays, MRIs, CAT scans, and they're starting to treat those as Edge devices. And so here is a very large established company, a leader in their industry, working with people like Spectra Cloud, realizing that Kubernetes is interesting technology. The Edge is an interesting thought but how do I marry the two together? So we are seeing large corporations seeing so much of an opportunity that they're working with the smaller companies, the latest technology. >> So let's talk about the Edge a little, you kind of opened it up there. How should customers think about the Edge versus the Cloud Data Center or even bare metal? >> Actually it's a... Well bare metal is fairly easy is that many people are looking to reduce some of the overhead or inefficiencies of the virtualized environment. But we've had really sort of parallel little white tornadoes, we've had bare metal as infrastructure that's been developing, and then we've had orchestration developing but they haven't really come together very well. Lately, we're finally starting to see that come together. Spectra Cloud contributed to open source a metal as a service technology that finally brings these two worlds together, making bare metal much more approachable to the enterprise. Edge is interesting, because it seems pretty obvious, you want to push your application out closer to your source of data, whether it's AI inferencing, or IoT or anything like that, you don't want to worry about intermittent connectivity or latency or anything like that. But people have wanted to be able to treat the Edge as if it's almost like a Cloud, where all I worry about is the app. So really, the Edge to us is just the next extension in a multi-Cloud sort of motif where I want these Edge devices to require low IT resources, to automate the provisioning, automate the ongoing version management, patch management, really act like a Cloud. And we're seeing this as very popular now. And I just used the GE Healthcare example of that, imagine a CAT scan machine, I'm making this part up in China and that's just an Edge device and it's doing medical imagery which is very intense in terms of data, you want to be able to process it quickly and accurately, as close to the endpoint, the healthcare provider is possible. >> So let's talk about that in some level of details, we think about kind of Edge and these fixed devices such as imaging device, are we putting agents on there, or we looking at something talking back to the Cloud? Where does special Cloud inject and help make that simple, that problem of just having dispersed endpoints all over the world simpler? >> Sure. Well we announced our Edge Kubernetes, Edge solution at a big medical conference called HIMMS, months ago. And what we allow you to do is we allow the application engineers to develop their application, and then you can de you can design this declarative model this cluster API, but beyond Cluster profile which determines which additional application services you need and the Edge device, all the person has to do with the endpoint is plug in the power, plug in the communications, it registers the Edge device, it automates the deployment of the full stack and then it does the ongoing versioning and patch management, sort of a self-driving Edge device running Kubernetes. And we make it just very easy. No IT resources required at the endpoint, no expensive field engineering resources to go to these endpoints twice a year to apply new patches and things like that, all automated. >> But there's so many different types of Edge devices with different capabilities, different operating systems, some have no operating system. I mean that seems, like a much more complex environment, just calling it the Edge is simple, but what you're really talking about is 1000s of different devices, that you have to run your applications on how are you dealing with that? >> So one of the ways is that we're really unbiased. In other words, we're OS and distro agnostic. So we don't want to debate about which distribution you like, we don't want to debate about which OS you want to use. The truth is, you're right. There's different environments and different choices that you'll want to make. And so the key is, how do you incorporate those and also recognize everything beyond those, OS and Kubernetes and all of that and manage that full stack. So that's what we do, is we allow you to choose which tools you want to use and let it be deployed and managed on any environment. >> And who's... >> So... >> I'm sorry Keith, who's responsible for making Kubernetes run on the Edge device. >> We do. We provision the entire stack. I mean, of course the company does using our product, but we provision the entire Kubernetes infrastructure stack, all the application services and the application itself on that device. >> So I would love to dig into like where pods happen and all that. But, provisioning is getting to the point that is a solve problem. Day two. >> Yes. >> Like you just mentioned HIMMS, highly regulated environments. How does Spectra Cloud helping with configuration management, change control, audit, compliance, et cetera, the hard stuff. >> Yep. And one of the things we do, you bring up a good point is we manage the full life cycle from day zero, which is sort of create, deploy, all the way to day two, which is about access control, security, it's about ongoing versioning in a patch management. It's all of that built into the platform. But you're right, like the medical industry has a lot of regulations. And so you need to be able to make sure that everything works, it's always up to the latest level have the highest level of security. And so all that's built into the platform. It's not just a fire and forget it really is about that full life cycle of deploying, managing on an ongoing basis. >> Well, Dave, I'd love to go into a great deal of detail with you about kind of this day two ops and I think we'll be covering a lot more of that topic, Paul, throughout the week, as we talk about just as we've gotten past, how do I deploy Kubernetes pod, to how do I actually operate IT? >> Absolutely, absolutely. The devil is in the details as they say. >> Well, and also too, you have to recognize that the Edge has some very unique requirements, you want very small form factors, typically, you want low IT resources, it has to be sort of zero touch or low touch because if you're a large food provider with 20,000 store locations, you don't want to send out field engineers two or three times a year to update them. So it really is an interesting beast and we have some exciting technology and people like GE are using that. >> Well, Dave, thanks a lot for coming on theCUBE, you're now KubeCon, you've not been on before? >> I have actually, yes its... But I always enjoy it. >> Great conversation. From Valencia, Spain. I'm Keith Towns, along with Paul Gillon and you're watching theCUBE, the leader in high tech coverage. (upbeat music)

>> Announcer: theCUBE presents "Kubecon and Cloudnativecon Europe 2022" brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to theCUBE coverage of Kubecon 2022, E.U. I'm here with my cohost, Paul Gillin. >> Pleased to work with you, Keith. >> Nice to work with you, Paul. And we have our first two guests. "theCUBE" is hot. I'm telling you we are having interviews before the start of even the show floor. I have with me, we got to start with the customers first. Enterprise Architect Adnan Khan, welcome to the show. >> Thank you so much. >> Keith: CUBE time first, now you're at CUBE-alumni. >> Yup. >> And Haseeb Budhani, CEO Arathi, welcome back. >> Nice to talk to you again today. >> So, we're talking all things Kubernetes and we're super excited to talk to MoneyGram about their journey to Kubernetes. First question I have for Adnan. Talk to us about what your pre-Kubernetes landscape looked like? >> Yeah. Certainly, Keith. So, we had a traditional mix of legacy applications and modern applications. A few years ago we made the decision to move to a microservices architecture, and this was all happening while we were still on-prem. So, your traditional VMs. And we started 20, 30 microservices but with the microservices packing. You quickly expand to hundreds of microservices. And we started getting to that stage where managing them without sort of an orchestration platform, and just as traditional VMs, was getting to be really challenging, especially from a day two operational. You can manage 10, 15 microservices, but when you start having 50, and so forth, all those concerns around high availability, operational performance. So, we started looking at some open-source projects. Spring cloud, we are predominantly a Java shop. So, we looked at the spring cloud projects. They give you a number of initiatives for doing some of those management. And what we realized again, to manage those components without sort of a platform, was really challenging. So, that kind of led us to sort of Kubernetes where along with our journey new cloud, it was the platform that could help us with a lot of those management operational concerns. >> So, as you talk about some of those challenges, pre-Kubernetes, what were some of the operational issues that you folks experienced? >> Yeah, certain things like auto scaling is number one. I mean, that's a fundamental concept of cloud native, right? Is how do you auto scale VMs, right? You can put in some old methods and stuff, but it was really hard to do that automatically. So, Kubernetes with like HPA gives you those out of the box. Provided you set the right policies, you can have auto scaling where it can scale up and scale back, so we were doing that manually. So, before, you know, MoneyGram, obviously, holiday season, people are sending more money, Mother's Day. Our Ops team would go and basically manually scale VMs. So, we'd go from four instances to maybe eight instances, but that entailed outages. And just to plan around doing that manually, and then sort of scale them back was a lot of overhead, a lot of administration overhead. So, we wanted something that could help us do that automatically in an efficient and intrusive way. That was one of the things, monitoring and and management operations, just kind of visibility into how those applications were during what were the status of your workloads, was also a challenge to do that. >> So, Haseeb, I got to ask the question. If someone would've came to me with that problem, I'd just say, "You know what? Go to the plug to cloud." How does your group help solve some of these challenges? What do you guys do? >> Yeah. What do we do? Here's my perspective on the market as it's playing out. So, I see a bifurcation happening in the Kubernetes space. But there's the Kubernetes run time, so Amazon has EKS, Azure as AKS. There's enough of these available, they're not managed services, they're actually really good, frankly. In fact, retail customers, if you're an Amazon why would you spin up your own? Just use EKS, it's awesome. But then, there's an operational layer that is needed to run Kubernetes. My perspective is that, 50,000 enterprises are adopting Kubernetes over the next 5 to 10 years. And they're all going to go through the same exact journey, and they're all going to end up potentially making the same mistake, which is, they're going to assume that Kubernetes is easy. They're going to say, "Well, this is not hard. I got this up and running on my laptop. This is so easy, no worries. I can do EKS." But then, okay, can you consistently spin up these things? Can you scale them consistently? Do you have the right blueprints in place? Do you have the right access management in place? Do you have the right policies in place? Can you deploy applications consistently? Do you have monitoring and visibility into those things? Do your developers have access when they need it? Do you have the right networking layer in place? Do you have the right chargebacks in place? Remember you have multiple teams. And by the way, nobody has a single cluster, so you got to do this across multiple clusters. And some of them have multiple clouds. Not because they want to be multiple clouds, because, but sometimes you buy a company, and they happen to be in Azure. How many dashboards do you have now across all the open-source technologies that you have identified to solve these problems? This is where pain lies. So, I think that Kubernetes is fundamentally a solve problem. Like our friends at AWS and Azure, they've solved this problem. It's like a AKS, EKS, et cetera, EGK for that matter. They're great, and you should use them, and don't even think about spinning up QB best clusters. Don't do it, use the platforms that exist. And commensurately on-premises, OpenShift is pretty awesome. If you like it, use it. But then when it comes to the operations layer, that's where today, we end up investing in a DevOps team, and then an SRE organization that need to become experts in Kubernetes, and that is not tenable. Can you, let's say unlimited capital, unlimited budgets. Can you hire 20 people to do Kubernetes today? >> If you could find them. >> If you can find 'em, right? So, even if you could, the point is that, see five years ago when your competitors were not doing Kubernetes, it was a competitive advantage to go build a team to do Kubernetes so you could move faster. Today, you know, there's a high chance that your competitors are already buying from a Rafay or somebody like Rafay. So, now, it's better to take these really, really sharp engineers and have them work on things that make the company money. Writing operations for Kubernetes, this is a commodity now. >> How confident are you that the cloud providers won't get in and do what you do and put you out of business? >> Yeah, I mean, absolutely. In fact, I had a conversation with somebody from HBS this morning and I was telling them, I don't think you have a choice, you have to do this. Competition is not a bad thing. If we are the only company in a space, this is not a space, right? The bet we are making is that every enterprise, they have an on-prem strategy, they have at least a handful of, everybody's got at least two clouds that they're thinking about. Everybody starts with one cloud, and then they have some other cloud that they're also thinking about. For them to only rely on one cloud's tools to solve for on-prem, plus that second cloud, they potentially they may have, that's a tough thing to do. And at the same time, we as a vendor, I mean, the only real reason why startups survive, is because you have technology that is truly differentiator. Otherwise, I mean, you got to build something that is materially interesting, right? We seem to have- >> Keith: Now. Sorry, go ahead. >> No, I was going to, you actually have me thinking about something. Adnan? >> Yes. >> MoneyGram, big, well known company. a startup, adding, working in a space with Google, VMware, all the biggest names. What brought you to Rafay to solve this operational challenge? >> Yeah. A good question. So, when we started out sort of in our Kubernetes, we had heard about EKS and we are an AWS shop, so that was the most natural path. And we looked at EKS and used that to create our clusters. But then we realized very quickly, that, yes, to Haseeb's point, AWS manages the control plane for you, it gives you the high availability. So, you're not managing those components which is some really heavy lifting. But then what about all the other things like centralized dashboard? What about, we need to provision Kubernetes clusters on multicloud, right? We have other clouds that we use, or also on-prem, right? How do you do some of that stuff? We also, at that time were looking at other tools also. And I had, I remember come up with an MVP list that we needed to have in place for day one or day two operations before we even launch any single applications into production. And my Ops team looked at that list and literally, there was only one or two items that they could check off with EKS. They've got the control plane, they've got the cluster provision, but what about all those other components? And some of that kind of led us down the path of, you know, looking at, "Hey, what's out there in this space?" And we realized pretty quickly that there weren't too many. There were some large providers and capabilities like Antos, but we felt that it was a little too much for what we were trying to do at that point in time. We wanted to scale slowly. We wanted to minimize our footprint, and Rafay seemed to sort of, was a nice mix from all those different angles. >> How was the situation affecting your developer experience? >> So, that's a really good question also. So, operations was one aspect to it. The other part is the application development. We've got MoneyGram is when a lot of organizations have a plethora of technologies from Java, to .net, to node.js, what have you, right? Now, as you start saying, okay, now we're going cloud native and we're going to start deploying to Kubernetes. There's a fair amount of overhead because a tech stack, all of a sudden goes from, just being Java or just being .net, to things like Docker. All these container orchestration and deployment concerns, Kubernetes deployment artifacts, (chuckles) I got to write all this YAML as my developer say, "YAML hell." (panel laughing) I got to learn Docker files. I need to figure out a package manager like HELM on top of learning all the Kubernetes artifacts. So, initially, we went with sort of, okay, you know, we can just train our developers. And that was wrong. I mean, you can't assume that everyone is going to sort of learn all these deployment concerns and we'll adopt them. There's a lot of stuff that's outside of their sort of core dev domain, that you're putting all this burden on them. So, we could not rely on them in to be sort of CUBE cuddle experts, right? That's a fair amount overhead learning curve there. So, Rafay again, from their dashboard perspective, saw the managed CUBE cuddle, gives you that easy access for devs, where they can go and monitor the status of their workloads. They don't have to figure out, configuring all these tools locally, just to get it to work. We did some things from a DevOps perspective to basically streamline and automate that process. But then, also Rafay came in and helped us out on kind of that providing that dashboard. They don't have to break, they can basically get on through single sign on and have visibility into the status of their deployment. They can do troubleshooting diagnostics all through a single pane of glass, which was a key key item. Initially, before Rafay, we were doing that command line. And again, just getting some of the tools configured was huge, it took us days just to get that. And then the learning curve for development teams "Oh, now you got the tools, now you got to figure out how to use it." >> So, Haseeb talk to me about the cloud native infrastructure. When I look at that entire landscape number, I'm just overwhelmed by it. As a customer, I look at it, I'm like, "I don't know where to start." I'm sure, Adnan, you folks looked at it and said, "Wow, there's so many solutions." How do you engage with the ecosystem? You have to be at some level opinionated but flexible enough to meet every customer's needs. How do you approach that? >> So, it's a really tough problem to solve because... So, the thing about abstraction layers, we all know how that plays out, right? So, abstraction layers are fundamentally never the right answer because they will never catch up, because you're trying to write a layer on top. So, then we had to solve the problem, which was, well, we can't be an abstraction layer, but then at the same time, we need to provide some, sort of like centralization standardization. So, we sort of have this the following dissonance in our platform, which is actually really important to solve the problem. So, we think of a stack as floor things. There's the Kubernetes layer, infrastructure layer, and EKS is different from AKS, and it's okay. If we try to now bring them all together and make them behave as one, our customers are going to suffer. Because there are features in EKS that I really want, but then if you write an abstraction then I'm not going to get 'em so not okay. So, treat them as individual things that we logic that we now curate. So, every time EKS, for example, goes from 1.22 to 1.23, we write a new product, just so my customer can press a button and upgrade these clusters. Similarly, we do this for AKS, we do this for GK. It's a really, really hard job, but that's the job, we got to do it. On top of that, you have these things called add-ons, like my network policy, my access management policy, my et cetera. These things are all actually the same. So, whether I'm EKS or AKS, I want the same access for Keith versus Adnan, right? So, then those components are sort of the same across, doesn't matter how many clusters, doesn't matter how many clouds. On top of that, you have applications. And when it comes to the developer, in fact I do the following demo a lot of times. Because people ask the question. People say things like, "I want to run the same Kubernetes distribution everywhere because this is like Linux." Actually, it's not. So, I do a demo where I spin up access to an OpenShift cluster, and an EKS cluster, and then AKS cluster. And I say, "Log in, show me which one is which?" They're all the same. >> So, Adnan, make that real for me. I'm sure after this amount of time, developers groups have come to you with things that are snowflakes. And as a enterprise architect, you have to make it work within your framework. How has working with Rafay made that possible? >> Yeah, so I think one of the very common concerns is the whole deployment to Haseeb's point, is you are from a deployment perspective, it's still using HELM, it's still using some of the same tooling. How do you? Rafay gives us some tools. You know, they have a command line Add Cuddle API that essentially we use. We wanted parity across all our different environments, different clusters, it doesn't matter where you're running. So, that gives us basically a consistent API for deployment. We've also had challenges with just some of the tooling in general that we worked with Rafay actually, to actually extend their, Add Cuddle API for us so that we have a better deployment experience for our developers. >> Haseeb, how long does this opportunity exist for you? At some point, do the cloud providers figure this out, or does the open-source community figure out how to do what you've done and this opportunity is gone? >> So, I think back to a platform that I think very highly of, which has been around a long time and continues to live, vCenter. I think vCenter is awesome. And it's beautiful, VMware did an incredible job. What is the job? It's job is to manage VMs, right? But then it's for access, it's also storage. It's also networking in a sec, right? All these things got done because to solve a real problem, you have to think about all the things that come together to help you solve that problem from an operations perspective. My view is that this market needs essentially a vCenter, but for Kubernetes, right? And that is a very broad problem. And it's going to spend, it's not about a cloud. I mean, every cloud should build this. I mean, why would they not? It makes sense. Anto exist, right? Everybody should have one. But then, the clarity in thinking that the Rafay team seems to have exhibited, till date, seems to merit an independent company, in my opinion, I think like, I mean, from a technical perspective, this product's awesome, right? I mean, we seem to have no real competition when it comes to this broad breadth of capabilities. Will it last? We'll see, right? I mean, I keep doing "CUBE" shows, right? So, every year you can ask me that question again, and we'll see. >> You make a good point though. I mean, you're up against VMware, You're up against Google. They're both trying to do sort of the same thing you're doing. Why are you succeeding? >> Maybe it's focused. Maybe it's because of the right experience. I think startups, only in hindsight, can one tell why a startup was successful. In all honesty, I've been in a one or two startups in the past, and there's a lot of luck to this, there's a lot of timing to this. I think this timing for a product like this is perfect. Like three, four years ago, nobody would've cared. Like honesty, nobody would've cared. This is the right time to have a product like this in the market because so many enterprises are now thinking of modernization. And because everybody's doing this, this is like the boots strong problem in HCI. Everybody's doing it, but there's only so many people in the industry who actually understand this problem, so they can't even hire the people. And the CTO said, "I got to go. I don't have the people, I can't fill the seats." And then they look for solutions, and via that solution, that we're going to get embedded. And when you have infrastructure software like this embedded in your solution, we're going to be around with the... Assuming, obviously, we don't score up, right? We're going to be around with these companies for some time. We're going to have strong partners for the long term. >> Well, vCenter for Kubernetes I love to end on that note. Intriguing conversation, we could go on forever on this topic, 'cause there's a lot of work to do. I don't think this will over be a solved problem for the Kubernetes as cloud native solutions, so I think there's a lot of opportunities in that space. Haseeb Budhani, thank you for rejoining "theCUBE." Adnan Khan, welcome becoming a CUBE-alum. >> (laughs) Awesome. Thank you so much. >> Check your own profile on the sound's website, it's really cool. From Valencia, Spain, I'm Keith Townsend, along with my Host Paul Gillin . And you're watching "theCUBE," the leader in high tech coverage. (bright upbeat music)

>> Narrator: theCUBE presents KubeCon and Cloud NativeCon Europe, 2022 brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain. A coverage of KubeCon, Cloud NativeCon, Europe, 2022. I'm Keith Townsend. Your host of theCUBE, along with Paul Gillum, Senior Editor Enterprise Architecture for Silicon Angle, Enrico, Senior IT Analyst for GigaOm . This has been a full day, 7,500 attendees. I might have seen them run out of food, this is just unexpected. I mean, it escalated from what I understand, it went from capping it off at 4,000 gold, 5,000 gold in it off finally at 7,500 people. I'm super excited for... Today's been a great dead coverage. I'm super excited for tomorrow's coverage from theCUBE, but first off, we'll let the the new person on stage take the first question of the wrap up of the day of coverage, Enrico, what's different about this year versus other KubeCons or Cloud Native conversations. >> I think in general, it's the maturity. So we talk a lot about day two operations, observability, monitoring, going deeper and deeper in the security aspects of the application. So this means that for many enterprises, Kubernetes is becoming real critical. They want to get more control of it. And of course you have the discussion around FinOps, around cost control, because we are deploying Kubernetes everywhere. And if you don't have everything optimized, control, monitored, costs go to the roof and think about deploying the Public Cloud . If your application is not optimized, you're paying more. But also in that, on-premises if you are not optimized, you don't have any clear idea what is going to happen. So capacity planning become the nightmare, that we know from the past. So there is a lot of going on around these topics, really exciting actually, less infrastructure, more application. That is what Kubernetes is in here. >> Paul help me separate some of the signal from the noise. There is a lot going on a lot of overlap. What are some of the big themes of takeaways for day one that Enterprise Architects, Executives, need to take home and really chew on? >> Well, the Kubernetes was a turning point. Docker was introduced nine years ago, and for the first three or four years it was an interesting technology that was not very widely adopted. Kubernetes came along and gave developers a reason to use containers. What strikes me about this conference is that this is a developer event, ordinarily you go to conferences and it's geared toward IT Managers, towards CIOs, this is very much geared toward developers. When you have the hearts and minds of developers the rest of the industry is sort of pulled along with it. So this is ground zero for the hottest area of the entire computing industry right now, is in this area building Distributed services, Microservices based, Cloud Native applications. And it's the developers who are leading the way. I think that's a significant shift. I don't see the Managers here, the CIOs here. These are the people who are pulling this industry into the next generation. >> One of the interesting things that I've seen when we've always said, Kubernetes is for the developers, but we talk with an icon from MoneyGram, who's a end user, he's an enterprise architect, and he brought Kubernetes to his front end developers, and they rejected it. They said, what is this? I just want to develop code. So when we say Kubernetes is for developers or the developers are here, how do we reconcile that mismatch of experience? We have Enterprise Architect here. I hear constantly that the Kubernetes is for developers, but is it a certain kind of developer that Kubernetes is for? >> Well, yes and no. I mean, so the paradigm is changing. Okay. So, and maybe a few years back, it was tough to understand how make your application different. So microservices, everything was new for everybody, but actually, everything has changed to a point and now the developer understands, is neural. So, going through the application, APIs, automation, because the complexity of this application is huge, and you have, 724 kind of development sort of deployment. So you have to stay always on, et cetera, et cetera. And actually, to the point of developers bringing this new generation of decision makers in there. So they are actually decision, they are adopting technology. Maybe it's a sort of shadow IT at the very beginning. So they're adopting it, they're using it. And they're starting to use a lot of open source stuff. And then somebody upper in the stack, the Executive, says what are... They discover that the technology is already in place is a critical component, and then it's transformed in something enterprise, meaning paying enterprise services on top of it to be sure support contract and so on. So it's a real journey. And these guys are the real decision makers, or they are at the base of the decision making process, at least >> Cloud Native is something we're going to learn to take for granted. When you remember back, remember the Fail Whale in the early days of Twitter, when periodically the service would just crash from traffic, or Amazon went through the same thing. Facebook went through the same thing. We don't see that anymore because we are now learning to take Cloud Native for granted. We assume applications are going to be available. They're going to be performant. They're going to scale. They're going to handle anything we throw at them. That is Cloud Native at work. And I think we forget sometimes how refreshing it is to have an internet that really works for you. >> Yeah, I think we're much earlier in the journey. We had Microsoft on, the Xbox team talked about 22,000 pods running Linkerd some of the initial problems and pain points around those challenges. Much of my hallway track conversation has been centered around as we talk about the decision makers, the platform teams. And this is what I'm getting excited to talk about in tomorrow's coverage. Who's on the ground doing this stuff. Is it developers as we see or hear or told? Or is it what we're seeing from the Microsoft example, the MoneyGram example, where central IT is getting it. And not only are they getting it, they're enabling developers to simply write code, build it, and Kubernetes is invisible. It seems like that's become the Holy Grail to make Kubernetes invisible and Cloud Native invisible, and the experience is much closer to Cloud. >> So I think that, it's an interesting, I mean, I had a lot of conversation in the past year is that it's not that the original traditional IT operations are disappearing. So it's just that traditional IT operation are giving resources to these new developers. Okay, so it's a sort of walled garden, you don't see the wall, but it's a walled garden. So they are giving you resources and you use these resources like an internal Cloud. So a few years back, we were talking about private Cloud, the private Cloud as let's say the same identical paradigm of the Public Cloud is not possible, because there are no infinite resources or well, whatever we think are infinite resources. So what you're doing today is giving these developers enough resources to think that they are unlimited and they can do automatic operationing and do all these kind of things. So they don't think about infrastructure at all, but actually it's there. So IT operation are still there providing resources to let developers be more free and agile and everything. So we are still in a, I think an interesting time for all of it. >> Kubernetes and Cloud Native in general, I think are blurring the lines, traditional lines development and operations always were separate entities. Obviously with DevOps, those two are emerging. But now we're moving when you add in shift left testing, shift right testing, DevSecOps, you see the developers become much more involved in the infrastructure and they want to be involved in infrastructure because that's what makes their applications perform. So this is going to cause, I think IT organizations to have to do some rethinking about what those traditional lines are, maybe break down those walls and have these teams work much closer together. And that should be a good thing because the people who are developing applications should also have intimate knowledge of the infrastructure they're going to run on. >> So Paul, another recurring theme that we've heard here is the impact of funding on resources. What have your discussions been around founders and creators when it comes to sourcing talent and the impact of the markets on just their day to day? >> Well, the sourcing talent has been a huge issue for the last year, of course, really, ever since the pandemic started. Interestingly, one of our guests earlier today said that with the meltdown in the tech stock market, actually talent has become more available, because people who were tied to their companies because of their stock options are now seeing those options are underwater and suddenly they're not as loyal to the companies they joined. So that's certainly for the startups, there are many small startups here, they're seeing a bit of a windfall now from the tech stock bust. Nevertheless, skills are a long term problem. The US educational system is turning out about 10% of the skilled people that the industry needs every year. And no one I know, sees an end to that issue anytime soon. >> So Enrico, last question to you. Let's talk about what that means to the practitioner. There's a lot of opportunity out there. 200 plus sponsors I hear, I think is worth the projects is 200 plus, where are the big opportunities as a practitioner, as I'm thinking about the next thing that I'm going to learn to help me survive the next 10 or 15 years of my career? Where you think the focus should be? Should it be that low level Cloud builder? Or should it be at those levels of extraction that we're seeing and reading about? >> I think that it's a good question. The answer is not that easy. I mean, being a developer today, for sure, grants you a salary at the end of the month. I mean, there is high demand, but actually there are a lot of other technical figures in the data center, in the Cloud, that could really find easily a job today. So, developers is the first in my mind also because they are more, they can serve multiple roles. It means you can be a developer, but actually you can be also with the new roles that we have, especially now with the DevOps, you can be somebody that supports operation because you know automation, you know a few other things. So you can be a sysadmin of the next generation even if you are a developer, even if when you start as a developer. >> KubeCon 2022, is exciting. I don't care if you're a developer, practitioner, a investor, IT decision maker, CIO, CXO, there's so much to learn and absorb here and we're going to be covering it for the next two days. Me and Paul will be shoulder to shoulder, I'm not going to say you're going to get sick of this because it's just, it's all great information, we'll help sort all of this. From Valencia, Spain. I'm Keith Townsend, along with my host Enrico Signoretti, Paul Gillum, and you're watching theCUBE, the leader in high tech coverage. (upbeat music)

>> Instructor: "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 and we're at KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend, and my co-host, Enrico Signoretti. Enrico's really proud of me. I've called him Enrico instead of Enrique every session. >> Every day. >> Senior IT analyst at GigaOm. We're talking to fantastic builders at KubeCon, CloudNativeCon Europe 2022 about the projects and their efforts. Enrico, up to this point, it's been all about provisioning, insecurity, what conversation have we been missing? >> Well, I mean, I think that we passed the point of having the conversation of deployment, of provisioning. Everybody's very skilled, actually everything is done at day two. They are discovering that, well, there is a security problem. There is an observability problem a and in fact, we are meeting with a lot of people and there are a lot of conversation with people really needing to understand what is happening. I mean, in their cluster work, why it is happening and all the questions that come with it. And the more I talk with people in the show floor here or even in the various sessions is about, we are growing so that our clusters are becoming bigger and bigger, applications are becoming bigger as well. So we need to now understand better what is happening. As it's not only about cost, it's about everything at the end. >> So I think that's a great set up for our guests, Matt Provo, founder and CEO of StormForge and Patrick Brixton? >> Bergstrom. >> Bergstrom. >> Yeah. >> I spelled it right, I didn't say it right, Bergstrom, CTO. We're at KubeCon, CloudNativeCon where projects are discussed, built and StormForge, I've heard the pitch before, so forgive me. And I'm kind of torn. I have service mesh. What do I need more, like what problem is StormForge solving? >> You want to take it? >> Sure, absolutely. So it's interesting because, my background is in the enterprise, right? I was an executive at UnitedHealth Group before that I worked at Best Buy and one of the issues that we always had was, especially as you migrate to the cloud, it seems like the CPU dial or the memory dial is your reliability dial. So it's like, oh, I just turned that all the way to the right and everything's hunky-dory, right? But then we run into the issue like you and I were just talking about, where it gets very very expensive very quickly. And so my first conversations with Matt and the StormForge group, and they were telling me about the product and what we're dealing with. I said, that is the problem statement that I have always struggled with and I wish this existed 10 years ago when I was dealing with EC2 costs, right? And now with Kubernetes, it's the same thing. It's so easy to provision. So realistically what it is, is we take your raw telemetry data and we essentially monitor the performance of your application, and then we can tell you using our machine learning algorithms, the exact configuration that you should be using for your application to achieve the results that you're looking for without over-provisioning. So we reduce your consumption of CPU, of memory and production which ultimately nine times out of 10, actually I would say 10 out of 10, reduces your cost significantly without sacrificing reliability. >> So can your solution also help to optimize the application in the long run? Because, yes, of course-- >> Yep. >> The lowering fluid as you know optimize the deployment. >> Yeah. >> But actually the long-term is optimizing the application. >> Yes. >> Which is the real problem. >> Yep. >> So, we're fine with the former of what you just said, but we exist to do the latter. And so, we're squarely and completely focused at the application layer. As long as you can track or understand the metrics you care about for your application, we can optimize against it. We love that we don't know your application, we don't know what the SLA and SLO requirements are for your app, you do, and so, in our world it's about empowering the developer into the process, not automating them out of it and I think sometimes AI and machine learning sort of gets a bad rap from that standpoint. And so, at this point the company's been around since 2016, kind of from the very early days of Kubernetes, we've always been, squarely focused on Kubernetes, using our core machine learning engine to optimize metrics at the application layer that people care about and need to go after. And the truth of the matter is today and over time, setting a cluster up on Kubernetes has largely been solved. And yet the promise of Kubernetes around portability and flexibility, downstream when you operationalize, the complexity smacks you in the face and that's where StormForge comes in. And so we're a vertical, kind of vertically oriented solution, that's absolutely focused on solving that problem. >> Well, I don't want to play, actually. I want to play the devils advocate here and-- >> You wouldn't be a good analyst if you didn't. >> So the problem is when you talk with clients, users, there are many of them still working with Java, something that is really tough. I mean, all of us loved Java. >> Yeah, absolutely. >> Maybe 20 years ago. Yeah, but not anymore, but still they have developers, they have porting applications, microservices. Yes, but not very optimized, et cetera, cetera, et cetera. So it's becoming tough. So how you can interact with this kind of old hybrid or anyway, not well engineered applications. >> Yeah. >> We do that today. We actually, part of our platform is we offer performance testing in a lower environment and stage and we, like Matt was saying, we can use any metric that you care about and we can work with any configuration for that application. So perfect example is Java, you have to worry about your heap size, your garbage collection tuning and one of the things that really struck me very early on about the StormForge product is because it is true machine learning. You remove the human bias from that. So like a lot of what I did in the past, especially around SRE and performance tuning, we were only as good as our humans were because of what they knew. And so, we kind of got stuck in these paths of making the same configuration adjustments, making the same changes to the application, hoping for different results. But then when you apply machine learning capability to that the machine will recommend things you never would've dreamed of. And you get amazing results out of that. >> So both me and Enrico have been doing this for a long time. Like, I have battled to my last breath the argument when it's a bare metal or a VM, look, I cannot give you any more memory. >> Yeah. >> And the argument going all the way up to the CIO and the CIO basically saying, you know what, Keith you're cheap, my developer resources are expensive, buy bigger box. >> Yeah. >> Yap. >> Buying a bigger box in the cloud to your point is no longer a option because it's just expensive. >> Yeah. >> Talk to me about the carrot or the stick as developers are realizing that they have to be more responsible. Where's the culture change coming from? Is it the shift in responsibility? >> I think the center of the bullseye for us is within those sets of decisions, not in a static way, but in an ongoing way, especially as the development of applications becomes more and more rapid and the management of them. Our charge and our belief wholeheartedly is that you shouldn't have to choose. You should not have to choose between costs or performance. You should not have to choose where your applications live, in a public private or hybrid cloud environment. And so, we want to empower people to be able to sit in the middle of all of that chaos and for those trade offs and those difficult interactions to no longer be a thing. We're at a place now where we've done hundreds of deployments and never once have we met a developer who said, "I'm really excited to get out of bed and come to work every day and manually tune my application." One side, secondly, we've never met, a manager or someone with budget that said, please don't increase the value of my investment that I've made to lift and shift us over to the cloud or to Kubernetes or some combination of both. And so what we're seeing is the converging of these groups, their happy place is the lack of needing to be able to make those trade offs, and that's been exciting for us. >> So, I'm listening and looks like that your solution is right in the middle in application performance, management, observability. >> Yeah. >> And, monitoring. >> Yeah. >> So it's a little bit of all of this. >> Yeah, so we want to be, the intel inside of all of that, we often get lumped into one of those categories, it used to be APM a lot, we sometimes get, are you observability or and we're really not any of those things, in and of themselves, but we instead we've invested in deep integrations and partnerships with a lot of that tooling 'cause in a lot of ways, the tool chain is hardening in a cloud native and in Kubernetes world. And so, integrating in intelligently, staying focused and great at what we solve for, but then seamlessly partnering and not requiring switching for our users who have already invested likely, in a APM or observability. >> So to go a little bit deeper. What does it mean integration? I mean, do you provide data to this, other applications in the environment or are they supporting you in the work that you do. >> Yeah, we're a data consumer for the most part. In fact, one of our big taglines is take your observability and turn it into action ability, right? Like how do you take that, it's one thing to collect all of the data, but then how do you know what to do with it, right? So to Matt's point, we integrate with folks like Datadog, we integrate with Prometheus today. So we want to collect that telemetry data and then do something useful with it for you. >> But also we want Datadog customers, for example, we have a very close partnership with Datadog so that in your existing Datadog dashboard, now you have-- >> Yeah. >> The StormForge capability showing up in the same location. >> Yep. >> And so you don't have to switch out. >> So I was just going to ask, is it a push pull? What is the developer experience when you say you provide developer this resolve ML learnings about performance, how do they receive it? Like, what's the developer experience. >> They can receive it, for a while we were CLI only, like any good developer tool. >> Right. >> And, we have our own UI. And so it is a push in a lot of cases where I can come to one spot, I've got my applications and every time I'm going to release or plan for a release or I have released and I want to pull in observability data from a production standpoint, I can visualize all of that within the StormForge UI and platform, make decisions, we allow you to set your, kind of comfort level of automation that you're okay with. You can be completely set and forget or you can be somewhere along that spectrum and you can say, as long as it's within, these thresholds, go ahead and release the application or go ahead and apply the configuration. But we also allow you to experience the same, a lot of the same functionality right now, in Grafana, in Datadog and a bunch of others that are coming. >> So I've talked to Tim Crawford who talks to a lot of CIOs and he's saying one of the biggest challenges or if not, one of the biggest challenges CIOs are facing are resource constraints. >> Yeah. >> They cannot find the developers to begin with to get this feedback. How are you hoping to address this biggest pain point for CIOs-- >> Yeah.6 >> And developers? >> You should take that one. >> Yeah, absolutely. So like my background, like I said at UnitedHealth Group, right. It's not always just about cost savings. In fact, the way that I look about at some of these tech challenges, especially when we talk about scalability there's kind of three pillars that I consider, right? There's the tech scalability, how am I solving those challenges? There's the financial piece 'cause you can only throw money at a problem for so long and it's the same thing with the human piece. I can only find so many bodies and right now that pool is very small, and so, we are absolutely squarely in that footprint of we enable your team to focus on the things that they matter, not manual tuning like Matt said. And then there are other resource constraints that I think that a lot of folks don't talk about too. Like, you were talking about private cloud for instance and so having a physical data center, I've worked with physical data centers that companies I've worked for have owned where it is literally full, wall to wall. You can't rack any more servers in it, and so their biggest option is, well, I could spend $1.2 billion to build a new one if I wanted to, or if you had a capability to truly optimize your compute to what you needed and free up 30% of your capacity of that data center. So you can deploy additional name spaces into your cluster, like that's a huge opportunity. >> So I have another question. I mean, maybe it doesn't sound very intelligent at this point, but, so is it an ongoing process or is it something that you do at the very beginning, I mean you start deploying this. >> Yeah. >> And maybe as a service. >> Yep. >> Once in a year I say, okay, let's do it again and see if something change it. >> Sure. >> So one spot, one single.. >> Yeah, would you recommend somebody performance test just once a year? Like, so that's my thing is, at previous roles, my role was to do performance test every single release, and that was at a minimum once a week and if your thing did not get faster, you had to have an executive exception to get it into production and that's the space that we want to live in as well as part of your CICD process, like this should be continuous verification, every time you deploy, we want to make sure that we're recommending the perfect configuration for your application in the name space that you're deploying into. >> And I would be as bold as to say that we believe that we can be a part of adding, actually adding a step in the CICD process that's connected to optimization and that no application should be released, monitored, and sort of analyzed on an ongoing basis without optimization being a part of that. And again, not just from a cost perspective, but for cost and performance. >> Almost a couple of hundred vendors on this floor. You mentioned some of the big ones Datadog, et cetera, but what happens when one of the up and comings out of nowhere, completely new data structure, some imaginative way to click to telemetry data. >> Yeah. >> How do, how do you react to that? >> Yeah, to us it's zeros and ones. >> Yeah. >> And, we really are data agnostic from the standpoint of, we're fortunate enough from the design of our algorithm standpoint, it doesn't get caught up on data structure issues, as long as you can capture it and make it available through one of a series of inputs, one would be load or performance tests, could be telemetry, could be observability, if we have access to it. Honestly, the messier the better from time to time from a machine learning standpoint, it's pretty powerful to see. We've never had a deployment where we saved less than 30%, while also improving performance by at least 10%. But the typical results for us are 40 to 60% savings and 30 to 40% improvement in performance. >> And what happens if the application is, I mean, yes Kubernetes is the best thing of the world but sometimes we have to, external data sources or, we have to connect with external services anyway. >> Yeah. >> So, can you provide an indication also on this particular application, like, where the problem could be? >> Yeah. >> Yeah, and that's absolutely one of the things that we look at too, 'cause it's, especially when you talk about resource consumption it's never a flat line, right? Like depending on your application, depending on the workloads that you're running it varies from sometimes minute to minute, day to day, or it could be week to week even. And so, especially with some of the products that we have coming out with what we want to do, integrating heavily with the HPA and being able to handle some of those bumps and not necessarily bumps, but bursts and being able to do it in a way that's intelligent so that we can make sure that, like I said, it's the perfect configuration for the application regardless of the time of day that you're operating in or what your traffic patterns look like, or, what your disc looks like, right. Like 'cause with our low environment testing, any metric you throw at us, we can optimize for. >> So Matt and Patrick, thank you for stopping by. >> Yeah. >> Yes. >> We can go all day because day two is I think the biggest challenge right now, not just in Kubernetes but application re-platforming and transformation, very, very difficult. Most CTOs and EASs that I talked to, this is the challenge space. From Valencia, Spain, I'm Keith Townsend, along with my host Enrico Signoretti and you're watching "theCube" the leader in high-tech coverage. (whimsical 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 Valencia Spain and coverage of Q con cloud native con Europe, 2022. I'm Keith Townsend. You're a host of the cube along with Paul Gillum, senior editor, enterprise architecture for Silicon angle, ENCO, senior ready, senior it analyst for giga own. Uh, this has been a full day, 7,500 attendees. I might have seen them run out of food. This is just unexpected. I mean, they, the, it escalated from what understand it went from four, capping it off to 4,000 gold, 5,000 gold in and off. Finally at 7,500 people. I'm super excited for, you know, today's been a great day of coverage. I'm super excited for tomorrow's coverage, uh, from the cube. But first off, we'll let the, the new person on stage take the, the first question of, of the wrap up of the day of coverage, UN Rico on Rico. What's different about this year versus other Q coupons or cloud native conversations. >>I, I think in general, it's the maturity. So we talk it a lot about day two operations, uh, observability monitoring, uh, going deeper and deeper in the security aspects of the application. So this means that for many enterprises, Kubernetes is becoming real critical. They want to, to get more control of it. And of course you have the discussion around Phen op around, you know, uh, cost control because we are deploying Kubernetes everywhere. And, and if you don't have everything optimized control, monitor it, you know, uh, cost to the roof and think about, uh, deploying the public cloud. If your application is not optimized, you're paying more, but also in the on premises, if you are not optimiz, you don't have the clear idea of what is going to happen. So capacity planning become the nightmare that we know from the past. So there is a lot of going on around these topics, uh, really exciting, actually less infrastructure, more replication. That is what Kubernetes is India. >>Paul help me separate some of the signal from the noise. Uh, there is a lot going on a lot of overlap. What are some of the big themes of takeaways for day one that enterprise architects executives need to take home and really chew >>On? Well, the Kubernetes was a turning point. You know, Docker was introduced nine years ago and for the first three or four years, it was an interesting technology that was not very widely adopted. Kubernetes came along and gave developers a reason to use containers. What strikes me about this conference is that this is a developer event, you know, ordinarily you go to conferences and it's geared toward it managers towards CIOs. This is very much geared toward developers when you have the hearts and minds of developers, the rest of the industry is sort of pulled along with it. So this is ground zero for the hottest, uh, the, the hottest area of the entire computing industry. Right now, I is in this area building distributed services, BA microservices based cloud native applications. And it's the developers who are leading the way. I think that's, that's a significant shift. I don't see the managers here, the CIOs here, these are the people who are, uh, who are pulling this industry into the next generation. >>Um, one of the interesting things that I've seen when we, you know, we've always said, Kubernetes is for the developers, but we talk with, uh, an icon from, uh, MoneyGram. Who's a end user, he's an enterprise architect. And he brought Kubernetes to his front end developers and they, they, they kind of rejected it. They said, what is this? I just wanna develop cold. So when we say Kubernetes is for developers, or the developers are here, where, how do we reconcile that mismatch of experience? We have enterprise architecture. I hear constantly that, that the, uh, Kubernetes is for developers, but is it a certain kind of developer that Kubernetes is for? >>Well, yes and no. I mean, so the paradigm is changing. Okay. So, and maybe a few years back, it was tough to understand how, you know, uh, uh, make your application different. So microservices, everything was new for everybody, but actually, so everything is changed to a point. Now, the developer understands, you know, it is neural. So, you know, going through the application APIs automation, because the complexity of this application is, is huge. And you have, you know, 7 24 kind of development, uh, sort of deployment. So you have to stay always on cetera, et cetera. And actually to the point of, you know, developers, uh, you know, bringing this new generation of, uh, decision makers in India. So they are actually decision, they are adopting technology. Maybe it's a sort of shadow it at the very beginning. So they're adopting it, they're using it. And they're starting to use a lot of open source stuff. And then somebody upper in the stack, the executive says, what are, yeah, they, they discover that the technology is already in place is, uh, is a critical component. And then it's, uh, you know, uh, transformed in something enterprise, meaning, you know, paying enterprise services on top of it to be sure con uh, contract and so on. So it's a real journey. And these are, these guys are the real decision makers. Oh, they are at the base of the decision making process. At least >>Cloud native is something we're gonna learn to take for granted. You know, when you remember back, remember the fail whale in the early days of Twitter, when periodically the service would just would just, uh, um, crash from, uh, from, uh, traffic or Amazon went through the same thing. Facebook went through the same thing. We don't see that anymore because we are now learning to take cloud native for granted. We assume applications are gonna be available. They're gonna be performant. They're gonna scale. They're gonna handle anything. We throw at them that is cloud native at work. And I think we, we forget sometimes how refreshing it is to have, uh, an internet that really works for you. >>Yeah. I, I think we're much earlier in the journey. You know, we have Microsoft, uh, on the Xbox team talked about 22,000 pods running ni D some of the initial problems and pain points of, uh, around those challenges. Uh, much of my hallway track conversation has been centered around as we talk about kind of the decision makers, the platform teams. And this is what I'm getting excited to talk about in tomorrow's coverage. Who's on the ground doing this stuff. Is it developers as we are, as, as we see or hear or told, or is it what we're seeing from the Microsoft example, the MoneyGram example where central it is kind of getting it, and not only are they getting it, they're enabling developers to, to simply write code, build it. And Kubernetes is invisible. It seems like that's become the holy grill to make Kubernetes invisible cloud native invisible, and the experience is much closer to cloud. >>So I, I think that, uh, um, it's an interesting, I mean, I had a lot of conversation in the past year is that it's not that the original, you know, traditional it operations are disappearing. So it's just that, uh, traditional it operation are giving resources to these new developers. Okay. So it's a, it's a sort of walled garden. You don't see the wall, but it's a walled garden. So they are giving you resources and you use these resources like an internal cloud. So a few years back, we were talking about private cloud, the private cloud, as, you know, as a, let's say, uh, the same identical paradigm of, of the public cloud. This is not possible because there are no infinite resources or, well, whatever we, we think are infinite resources. So what you're doing today is giving these developers enough resources to think that they are unlimited and they can, uh, do automatic provisioning and do all these kind of things. So they don't think about infrastructure at all, but actually it's there. So it operation are still there providing resources to let developers be more free and agile and everything. So we are still in a, I think in an interesting time for all of it, >>Kubernetes and cloud native in general, I think are blurring the lines, traditional lines development and operations always were separate entities, obviously through with DevOps. Those two are emerging, but now we're moving. When you add in shift left testing shift, right? Testing, uh, dev SecOps, you see the developers become much more involved in the infrastructure and they want to be involved in infrastructure because that's what makes their applications perform. So this is gonna, cause I think it organizations to have, do some rethinking about what those traditional lines are, maybe break down those walls and have these teams work, work much closer together. And that should be a good thing because the people who are developing applications should also have intimate knowledge of the infrastructure they're gonna run on. >>So Paul, another recurring theme that we've heard here is the impact of funding on resources. What have you, what have your discussions been around founders and creators when it comes to sourcing talent and the impact of the markets on just their day to day? >>Well, the sourcing talent has been a huge issue for the last year. Of course, really ever since the pandemic started interesting. We, uh, one of our, our guests earlier today said that with the meltdown in the tech stock market, actually talent has become more available because people who were tied to their companies because of their, their stock options are now seeing those options are underwater. And suddenly they're not as loyal to the companies they joined. So that's certainly for the, for the startups. Uh, there are many small startups here. Um, they're seeing a bit of a windfall now from the, uh, from the tech stock, uh, bust, um, nevertheless skills are a long term problem. The us, uh, educational system is turning out about 10% of the skilled people that the industry needs every year. And no one I know, sees an end to that issue anytime soon. >>So ENGO, last question to you, let's talk about what that means to the practitioner. There's a lot of opportunity out >>There. >>200 plus sponsors I hear here I think is, or the projects is 200 plus, where are the big opportunities as a practitioner, as I'm thinking about the next thing that I'm going to learn to help me survive the next 10 or 15 years of my career? Where, where do you think the focus should be? Should it be that low level, uh, cloud builder, or should it be at those Le levels of extraction that we're seeing and reading about? >>I, I think, I think that, uh, you know, it's, uh, it's a good question. The, the answer is not that easy. I mean, uh, being a developer today, for sure grants, you, you know, uh, a salary at the end of the month, I mean, there is high demand, but actually there are a lot of other technical, uh, figures in, in the, in, uh, in the data center in the cloud that could, you know, really find easily a job today. So developers is the first in my mind also because they are more, uh, they, they can serve multiple roles. It means you can be a developer, but actually you can be also, you know, with the new roles that we have, especially now with the DevOps, you can be, uh, somebody that supports operation because, you know, automation, you know, a few other things. So you can be a C admin of the next generation, even if you're a developer, even if when you start as a developer, >>Cuan 20, 22 is exciting. I don't care if you're a developer practitioner, a investor, a, uh, it decision maker is CIO CXO. They're so much to learn and absorb here and we're going to be covering it for the next two days. Me and Paul will be shoulder to shoulder. We will, you, I'm not gonna say you're gonna get sick of this because it's just, you know, it's all great information. We'll, we'll, we'll help sort all of this from Valencia Spain. I'm Keith Townsend, along with my host ENCO senior, the Paul Gillon. And you're watching the, you, the leader in high tech coverage.