 Hello everyone, welcome back to this CUBE Conversation here in Palo Alto, California. I'm John Furrier, host of theCUBE. Got a great conversation around cloud native, cloud native journey, how enterprises are looking at cloud native and putting it all together. And it comes down to operations, developer productivity and security. It's the hottest topic in technology. We've got Chris Jones here in the studio, director of product management for platform nine. Chris, thanks for coming in. Thanks. So when we always chat about when we're at KubeCon, KubeCon EU is coming up in a few months. The number one conversation is developer productivity and the developers are driving all the standards. It's interesting to see how they just throw everything out there and whatever gets adopted ends up becoming the standard, not the old school way of kind of getting stuff done. So that's cool. Security, Kubernetes and containers are all kind of now that next level. So you start to see the early adopters moving to the mainstream enterprises, a variety of different approaches. You guys are at the center of this. We've had a couple of conversations with your CEO and your tech team over there. What are you seeing? You're building the products. What's the core product focus right now for platform nine? What are you guys aiming for? The core is that blend of enabling your infrastructure and platform ops or DevOps teams to be able to go fast and run in a stable environment, but at the same time enable developers, right? We don't want people going back to what I've been calling shadow IT 2.0. It's, hey, I've been told to do something. I kicked off this container initiative. I need to run my software somewhere. I'm just going to go figure it out. We want to keep those people productive. At the same time, we want to enable velocity for our operations teams, be it platform ops or DevOps. Take us through in your mind and how you see the industry rolling out this cloud native journey. Where do you see customers out there? Because DevOps has been around. DevSecOps is rocking. You're seeing AI, hot trend now. Developers are still in charge. Is there a change to the infrastructure how developers get their coding done and the infrastructure setting up the DevOps as key? But when you add the cloud native journey for an enterprise, what changes? What is the cloud native journey for an enterprise these days? The cloud native journey or the change when? Let's start with what they want to do, right? What's the goal and then how does that happen? I think the goal is that promised land, right? Increased resiliency, better scalability and overall reduced costs, right? I've gone from physical to virtual that gave me a higher level of density, packing of resources. I'm moving to containers. I'm removing that OS layer again. I'm getting a better density again. But all of a sudden, I'm running Kubernetes. What does that fundamentally do to my operations? Does it magically give me scalability and resiliency? Or do I need to change what I'm running and how it's running so it fits that infrastructure? And that's the reality is you can't just take a container and drop it into Kubernetes and say, hey, I'm now cloud native. I've got reduced cost or I've got better resiliency. There's things that your engineering teams need to do to make sure that application is cloud native. And then there's what I think is one of the largest shifts of virtual machines to containers. When I was in the world of application performance monitoring, we would see customers saying, well, my engineering team have this Java app and they said it needs a VM with 12 gig of RAM and eight cores. That's what we gave it, but it's running slow. I'm working with the application team and you can see it's running slow. And they're like, well, it's all of its resources. One of those nice features of virtualization is over provisioning. So the infrastructure team would say, well, we gave it all the RAM it needed. And what's wrong with that being over provisioned? It's like, well, Java expects that RAM to be there. Now all of a sudden, when you move it to the world of containers, what we've got is that's not a set resource limit really as like it used to be in a VM, right? When you set it for a container, your application teams really need to be paying attention to your resource limits and constraints within the world of Kubernetes. So instead of just being able to say, I'm throwing over the fence and now it's just gonna run on a VM and that VM's got everything it needs, it's now really running on more, much more of a shared infrastructure where limits and constraints are going to impact the neighbors. They are going to impact who's making that decision around resourcing because that Kubernetes concept of over provisioning and the virtualization concept of over provisioning are not the same. So when I look at this problem, it's like, well, what changed? Well, I'll do my scale tests as an application developer and tester and I'll see what resources it needs. I asked for that in the VM, that sets the high watermark, job's done. Well, Kubernetes, it's no longer a VM, it's a Kubernetes manifest and well, who owns that? Who's writing it? Who's setting those limits? To me, that should be the application team. But then when it does in the operations world, they're like, well, that's that now us. Can we change those? So it's that amalgamation of the two that is saying, I'm a developer, I used to pay attention, but now I need to pay attention and an infrastructure person saying, I used to just give them what they wanted, but now I really need to know what they've wanted because it's going to potentially have a catastrophic impact on what I'm running. So what's the impact for the developer? Because infrastructure as code is what everybody wants, the developer just wants to get the code going and they got to pay attention to all these things. Or don't they? Is that where you guys come in? How do you guys see the problem? Actually, scope the problem that you guys solve because I think you're getting at the core issue here, which is got Kubernetes, I got containers, I got developer productivity that I want to focus on. What's the problem that you guys solve? Platform operation teams that are adopting cloud native in their environment, they've got that steep learning curve of Kubernetes plus this fundamental change of how an app runs. What we're doing is taking away the burden of needing to operate and run Kubernetes and giving them the choice of the flexibility of infrastructure and location. Be that an air gap environment, like let's say a telco provider that needs to run a containerized network function and containerized workloads of 5G. That's one thing that we can deploy and achieve in a completely inaccessible environment. All the way through to platform nine running traditionally as SaaS, as we were born, that's remotely managing and controlling your Kubernetes environments on-premise AWS, that hybrid cloud experience. That could be also bare metal, but it's our platform running your environments with our support there 24 by seven that's proactively reaching out. So it's removing a lot of that burden and the complications that come along with operating the environment and standing it up, which means all of a sudden your DevOps and platform operations teams can go and work with your engineers and application developers and say, hey, let's focus on the stuff that we need to be focused on, which is running our business and providing a service to our customers, not figuring out how to upgrade a Kubernetes cluster and add new nodes and configure all of the low level. I mean, there are, that's operations that just needs to work and it sounds like as they get into the cloud native kind of ops, there's a lot of stuff that kind of goes wrong. Or you go, oops, what do we buy into? Because you know, the CIS, let's go cloud native. We want to get set up for the future. We're going to be cloud, cloud native, not just lift and shift. And we're going to actually build it out right. Okay, that sounds good. And when we have to actually get done. You got to spin things up and stand up the infrastructure. What specific use case do you guys see that emerges for platform nine when people call you up and you go talk to customers and prospects? What's the one thing or use case or cases that you guys see that you guys solve the best? So I think one of the, one of the, I guess new use cases that are coming up now, you know, everyone's talking about economic pressures. I think the tap was open. Just get it done, right? CIO is saying, let's modernize, let's use the cloud. Now all of a sudden they're recognizing we're way. We're spending a lot of money now. We've opened that tap all the way. What do we do? So now they're looking at ways to control that spend. So we're seeing that as a big emerging trend. What we're also sort of seeing is people looking at their data centers and saying, well, I've got this huge legacy environment that's running a hypervisor, it's running VMs. Can we still actually do what we need to do? Can we modernize? Can we start this cloud native journey without leaving our data centers, our co-locations? Or if I do want to reduce costs, is that that thing that says maybe I'm repatriating or doing, you know, a reverse migration? Do I have to go back to my data center or are there other alternatives? And we're seeing that trend a lot and our roadmap and what we have in the product today was specifically built to handle those occurrences. So we brought in Kubevert in terms of virtualization. We have a long legacy doing OpenStack and private clouds and we've worked with a lot of those users and customers that we have and ask the questions. What's important? And today when we look at the world of cloud native, you can run virtualization within Kubernetes. So you can, instead of running two separate platforms, you can have one. So all of a sudden, if you're looking to modernize, you can start on that new infrastructure stack that can run anywhere, Kubernetes, and you can start bringing VMs over there as you are containerizing at the same time. So now you can keep your application operations in one environment. And this also helps if you're trying to reduce costs. If you really are saying we put that dev environment in AWS, we've got a huge amount of velocity out of it now, can we do that elsewhere? Is there a co-location we can go to? Is there a provider that we can go to where we can run that infrastructure or run the Kubernetes, but not have to run the infrastructure? It's going to be interesting too. When you see the edge come online, you're starting, we've got Mobile World Congress coming up, KubeCon events we're going to be at. The conversation is not just about public cloud. And you guys also solve a lot of do-it-yourself implementation hassles that emerge when people try to kind of stand up their own environment. And we hear from developers, consistency between code, managing new updates, making sure everything's all solid so they can go fast. That's the goal and then people can get standardized on that. But as you've got public cloud and do-it-yourself, kind of brings up like, okay, there's some gaps there as the architecture changes to be more distributed, computing. On-premises, cloud, it's cloud operations. That's cool for DevOps and cloud native. How do you guys differentiate from, say, the public cloud opportunities and the folks who are doing it themselves? How do you guys fit in that world? And what's the pitch or what's the story? The fit that we look at is that third alternative. Let's get your team focused on what's high value to your business and let us deliver that public cloud experience on your infrastructure or in the public cloud, which gives you that ability to still be flexible if you wanna make choices to run consistently for your developers in two different locations. So as I touched on earlier, instead of saying go figure out Kubernetes, how do you upgrade 100 worker nodes in place upgrade? We've solved that problem. That's what we do every single day of the week. Don't go and try to figure out how to upgrade a cluster and then upgrade all of the, what I call Kubernetes friends, right? Your core DNS is your metric server, your Kubernetes dashboard. These are all things that we package, we test, we version. So when you click upgrade, we've already handled that entire process. So it's saying, don't have your team focused on that lower level piece of work. Get them focused on what is important, which is your business services. Yeah, the infrastructure and getting that stood up. I mean, I think the thing that's interesting, if you look at the market right now, you mentioned cost savings and recovery, it's kind of a recession. I mean, people are tightening their belts for sure. I don't think the digital transformation in cloud native spend is going to plummet. It's going to probably be on hold and be squeezed a little bit, but to your point, people are refactoring, looking at how to get the best out of what they got. It's not just open the tap of spend the cash. Like it used to be a couple months or even a couple of years ago. So, okay, I get that. But then you look at what's coming, AI is seeing all the new data infrastructure that's coming. The containers, Kubernetes stuff, got to get stood up pretty quickly and it's got to be reliable. So, to your point, the teams need to get done with this and move on to the next thing. Because there's more coming. There's a lot coming for the apps, building into data native, AI native, cloud native. So, it seems that this Kubernetes thing needs to get solved. Is that kind of what you guys are focused on right now? So, I mean, to use a customer, we have a customer that's in AI ML and they run their platform at customer sites. And that's hardware bound, right? You can't run AI machine learning on anything anywhere. Well, with platform nine, they can. So, we're enabling them to deliver services into their customers that's running their AI ML platform in their customers' data centers, anywhere in the world on hardware that is purpose built for running that workload. They're not Kubernetes experts. That's what we are, right? We're bringing them that ability to focus on what's important and just delivering their business services. Whilst they're enabling our team and our 24 by seven proactive management, our always on assurance, to keep that up and running for them. So, when something goes bump at the night at 2 a.m., our guides get woken up, right? They're the ones that are reaching out to the customer saying, your environments have a problem. We're taking these actions to fix it. Obviously, sometimes, especially if it is running on bare metal, there's things you can't do remotely. So, you might need someone to go and do that. But even when that happens, you're not by yourself. You're not sitting there like I did when I worked for a bank in one of my first jobs, three o'clock in the morning saying, well, our end of day processing is stuck. Who else am I waking up? Right? Exactly, yeah. Gotta get that cash going. But this is a great use case. I want to get to the customer. What does some of the successful customers say to you? The folks watching that aren't yet a customer platform nine. What are some of the accolades and comments or anecdotes that you guys hear from customers that you have? It just works, which I think is probably one of the best ones you can get. Customers coming back and being able to show to their business that they've delivered growth, like business growth and productivity growth and keeping their organization size the same. So we started on our containerization journey. We went to Kubernetes. We've deployed all these new workloads and our operations team is still six people. We're doing way more with growth less. And I think that's also talking to the strength that we're bringing because we're augmenting that team. And they're spending less time on the really low level stuff and automating a lot of the growth activity that's involved. So when it comes to being able to grow their business, they can just focus on that. Not once again. Well, you guys do the heavy lifting and keep on top of the Kubernetes, make sure that all the versions are all done. Everything's stable and consistent so they can go on and do that, build out and provide their services. That seems to be what you guys are best at. Correct, correct. So what's on the roadmap? Product management. You get the keys to the kingdom. What is the focus? What's your focus right now? Honestly, Kubernetes is growing up, containers. We've been hearing a lot at GlassCubeCon about the security containers is getting better. You've seen verification, a lot more standards around some things. What are you focused on right now for a product over there? Edge is a really big focus for us. And I think in Edge you can look at it in two ways. The mantra that I drive is edge must be remote. If you can't do something remotely at the edge, you're using a human being, that's not edge, right? Our edge management capabilities that have been in the market for over two years are 100% remote. You wanna stand up a store, you just ship the server in there, it gets racked, the rest of it's remote, right? Imagine a store manager in, I don't know, KFC just plugging in the server, putting in the ethernet cable, pressing the power button. The rest of all that provisioning for that cloud native stack, Kubernetes, Kubevert for virtualization is done remotely. So we're continuing to focus on that. The next piece that is related to that is allowing people to run Platform 9 SaaS in their data centers. So we do AgApp today, and we've had a really strong focus on telecommunications and the containerized network functions that come along with that. So this next piece is saying, we're bringing what we run as SaaS into your data center so then you can run it. Because there are many people out there that are saying, we want these capabilities. And we want everything that the Platform 9 control plane brings and simplifies. But unfortunately, regulatory or compliance reasons means that we can't leverage SaaS. So they might be using a cloud, but they're saying that's still our infrastructure. We're still closed that network down, or they're still on-prem. So they're two big priorities for us this year, and that on-premise experience is paramount. Even to the point that we will be delivering a way that when you run on-premise, you can still say, wait a second. Well, I can send outbound alerts to Platform 9. So their support team can still be proactively helping me as much as they could, even though I'm running Platform 9's control plane. So it's sort of giving that blend of two experiences. They're big priorities. And the third pillar is all around virtualization. It's saying, if you have economic pressures, then I think it's important to look at what you're spending today. And realistically say, can that be reduced? And I think hypervisors and virtualization is something that should be looked at. Because if you can actually reduce that spend, you can bring in some modernization at the same time. Let's take some of those nodes that exist that are two years into their five-year hardware lifecycle. Let's turn that into a cloud-native environment, which is enabling your modernization in place. It's giving your engineers and application developers the new toys, the new experiences, and then you can start running some of those virtualized workloads with Qubvert there. So you're reducing cost and you're modernizing at the same time with your existing infrastructure. You know, Chris, the topic of this conference series that we're doing with you guys is finding the right path, trusting the right path to cloud-native. What does that mean? I mean, if you had to kind of summarize that phrase, trusting the right path to cloud-native, what does that mean? It means in terms of architecture, is it deployment, is it operations? What's the underlying main theme of that quote? What's the, how would you talk to a customer and say, what does that mean? If someone said, hey, what does that right path mean? I think the right path means focusing on what you should be focusing on. I've said it a hundred times, but if your entire operations team is trying to figure out the nuts and bolts of Kubernetes getting three months into a journey in discovering, oh, I need metric server to make something function. I wanna use horizontal pod autoscaler or vertical pod autoscaler, and I need this other thing. Now I need to manage that. That's not the right path. That's literally learning what other people have been learning for the last, you know, five, seven years that have been focused on Kubernetes solely. People have been grinding it out. I mean, that's what you're talking about here. They've been standing up when Kubernetes started, it was all the promise, and essentially manually kind of getting in the weeds and configuring it, now it's matured up, they want stability. Not everyone can get down and dirty with Kubernetes. It's not something that people want to generally do unless you're totally into it. I mean, ops teams, I mean, you know what I mean, it's not like, it's heavy lifting. It's important, just gotta get it going. I mean, if you're deploying with platform nine, your ops teams can tinker to their hearts content, right? Where completely compliant upstream Kubernetes. You can go and change an API server flag. Let's go and mess with the scheduler because we want to. You can still do that, but don't have your team investing in all this time to figure it out, that's been figured out. Get them focused on enabling velocity for your business. So it's not build, but run. It's more run Kubernetes, not necessarily figure out how to kind of get it all built up. You know, we've talked to a lot of customers out there that are saying, I want to be able to deliver a service to my users. Our response is, cool, let us run it. You can shoot it, therefore deliver it. And we're solving that in one hit versus figuring out how to first run it, then operate it, then turn that into a consumable service. So the alternative to platform nine is what? They got to do it themselves or use the cloud or what's the alternative to the customer for not using platform nine? Hiring more people to kind of work on it. What's that? People building that kind of past experience. Something that I've been very passionate about for the past year is looking at that world of sort of GitOps and what that means. And if you go out there and you sort of start asking the question, what's happening? Just generally with Kubernetes as well and GitOps in that scope, then you'll hear some people saying, well, I'm making it PaaS because Kubernetes is too complicated for my developers and we need to give them something. There's some great material out there from the likes of Intua and Adobe where for two big contributors to ARGO and the ARGO projects, they almost have, well, they do have different experiences. One is saying, we went down the PaaS route and it failed. The other one is saying, we've built a really stable PaaS and it's working. What are they trying to do? They're trying to deliver an outcome to make it easy to use and consume Kubernetes. So you could go out there and say, how am I gonna build a Kubernetes cluster? Sounds like ARGO CD is a great way to expose that to my developers so they can use Kubernetes without having to use Kubernetes and start automating things. That is an approach but you're going to be going completely open source and you're gonna have to bring in all the individual components or you could just lay it down and consume it as a service and not have to focus. And you mentioned Intua, they were the ones who brought that into the open. They did, Intua is the primary contributor to the ARGO set of products. How has that been received in the market? I mean, they had the event at the Computer History Museum last fall. What's the momentum there? What's the big takeaway from that project? To me growth, I mean, go and track the stars on that one. It's growth. It's unlocking machine learning. ARGO workflows can do more than just make things happen. ARGO CD, I think the approach they're taking is, hey, let's make this simple to use which I think can be lost. I think credit where credit is due, they're really pushing to bring in a lot of capabilities to make it easier to work with applications and microservices on Kubernetes. It's not just that, hey, here's a GitOps tool. It can take something from a Git repo and deploy it and maybe parameterize it and help you scale your operations from that perspective. It's taking a step back and saying, well, how did we get to production in the first place? And what can be done down there to help as well? I think it's growth expansion of features. I had a huge release just come out in, I think it was 2.6 that brought in things that, as a product manager that I don't often look at like really deep technical things and say, wow, that's powerful, but they have. They've got some great features in that release that really do solve real problems. And as the product person, who's the target buyer for you? Who's the customer? Who's making that? And you got decision maker, influencer and recommender. Take us through the customer persona for you guys. Is that platform DevOps space? The people that need to be delivering containers as a service out to their organization. But then it's also important to say, well, who else are our primary users? And that's developers, engineers, right? They shouldn't have to say, oh, I'll have access to a Kubernetes cluster. Do I have to use kubectl or do I need to go find some other tool? No, they can just log in to platform nine and it's integrated with your enterprise identity. They're the end customer at the end of the day, they're the user. Yeah, they can log in and they can see the clusters you've given them access to as a platform ops. So job well done for you guys in your mind as the developers are moving them fast, coding and happy. Yeah, yeah. And from a customer standpoint, you reduce the maintenance cost because you keep the ops smoother. So you got efficiency and maintenance costs kind of reduced or is that kind of the benefits? Yeah, yeah. And at two o'clock in the morning when things go inevitably be wrong, they're not there by themselves and we're proactively working with them. And that's the uptime issue. That is the uptime issue. And cloud doesn't solve that, right? Everyone experienced that clouds can go down. Entire regions can go offline. That's happened to all cloud providers. And what do you do then? Kubernetes isn't your recovery plan. It's part of it, right? But it's that piece. You know, Chris, the wrap up this interview, I will say that the queue is 12 years old now. We moved into OpenStack early days. We had you guys on when we were covering OpenStack and now cloud has just been booming. You got AI around the corner, AI ops. Now you got all this new data infrastructure. It's just amazing cloud growth, cloud native, security native, cloud native, data native, AI native. It's going to be all, you know, this is the new app environment, but there's also existing infrastructure. So, you know, going back to OpenStack, rolling our own cloud, building your own cloud, building infrastructure cloud in a cloud way is what the pioneers have done. I mean, this is where we're at. Now we're at this scale, next level, abstract it away and make it operational. It seems to be the key focus. We look at CNCF and KubeCon and what they're doing in the cloud security con, it's all about operations, right, ops. And, you know, it's going to sound counterintuitive because it's a developer open source environment, but you're starting to see that ops focus in a good way, infrastructure as code way. What's your reaction to that? How would you summarize where we are and the industry relative to, am I getting it right there? Is that the right view? What am I missing? What's the current state of the next level, next gen infrastructure? It's a good question. When I think back to sort of late 2019, I sort of had this aha moment as I saw what really truly is delivering infrastructure as code happening at platform nine. There's an open source project, Ironic, which is now also available within Kubernetes as Metal Cubed that automates bare metal as code, which means you can go from an empty server, lay down your operating system, lay down Kubernetes, and you've just done everything delivered to your customer as code with a cloud native platform. That to me was sort of the biggest realization that I had as I was moving into this industry was wait, it's there. This can be done. And the evolution of tooling and operations is getting to the point where that can be achieved and it's focused on by a number of different open source projects, not just Ironic and Metal Cubed, but that's a huge win. That is truly getting your infrastructure. That's an inflection point, really. If you think about it, because that's one of the problems we had with the bare metal piece was the automation and also making it cloud ops, cloud operations. Yeah, I mean, one of the things that I think Ironic did really well was saying let's just treat that piece of bare metal like a cloud VM or an instance. If you've got a problem with it, just give the person using it or whatever is using it a new one and re-image it. Just tell it to re-image itself and it will just go. You can do self-service with it. Right, in Platform 9, if you log into our SaaS Ironic, you can go and say, I want, I want that physical server to myself because I've got a giant workload. Or let's turn it into a Kubernetes cluster. That whole thing is automated. To me, that's infrastructure as code. I think one of the other important things that's happening at the same time is we're seeing GitOps, we're seeing things like Terraform. I think it's important for organizations to look at what they have and ask, am I using tools that are fit for tomorrow or am I using tools that are yesterday's tools to solve tomorrow's problems? And when especially it comes to modernizing infrastructure as code, I think that's a big piece to look at. Do you see Terraform as old or new? I see Terraform as old. It is a fantastic tool. It's capable of many great things and it can work with basically every single provider out there on the planet. It is able to do things. Is it best fit to run in a GitOps methodology? I don't think it is quiet at that point. In fact, if you went and looked at Flux, Flux has ways that make Terraform GitOps compliant, which is absolutely fantastic. It's using two tools, the best of breeds, which is solving that tomorrow problem with tomorrow's solutions. Is the new solutions old versus new? I like this old way, new way. I mean, Terraform is not that old. I mean, it's been around for about eight years or so, whatever, but actually, of course, doing a great job with that. I mean, so okay, but Terraform, what's the new address? Is it more complex environments? Because Terraform made sense when you had basic DevOps, but now it sounds like there's a whole another level of complexity. Are you going to say that new tools might- They're kind of an amalgamation of that application into infrastructure. Now my app team is paying way more attention to that manifest file, which is what GitOps is trying to solve. Let's templatize things. Let's version control our manifest, be it helm, customize, or just a straight up Kubernetes manifest file, plain and boring. Let's get that version controlled. Let's make sure that we know what is there, why it was changed. Let's get some auditability and things like that. And then let's get that deployment all automated. So that's predicated on the cluster existing. Well, why can't we do the same thing with the cluster? The inception problem. So even if you're in public cloud, the question is like, well, what's calling that API to call that thing to happen? Where is that file living? How well can I manage that in a large team? Oh my God, something just changed. Who changed it? Where is that file? And I think that's one of the big pieces to be solved. And you talked about Edge too and on-premises. I think one of the things I'm observing is certainly when DevOps was rocking and rolling and infrastructure as code was like the real push, it was pretty much the public cloud, right? And you did cloud native and you had stuff on-premises. Yeah, you did some lifting and shifting in the cloud, but the cool stuff was going in the public cloud and you ran DevOps. Okay, now you got on-premise, cloud operations, and Edge. Is that the new DevOps? I mean, because what you're kind of getting at with old new, old new Terraform examples, an interesting point because you're pointing out potentially that that was good DevOps back in the day, or it still is, but depending on how you define what DevOps is. So if you say I got the new DevOps with public on-premise and Edge, that's just not all public cloud. That's essentially distributed cloud native. Correct. Is that the new DevOps in your mind? Or is that oversimplifying it? Or is that that term where everyone's saying platform ops? Right, has it shifted? Well, you bring up a good point about Terraform. I mean, Terraform is well-proven. People love it. It's got great use cases and now this seems to be new things happening. We call things like super cloud emerging, which is multi-cloud and abstraction layers. So you're starting to see stuff being abstracted away for the benefits of moving to the next level so teams don't get stuck doing the same old thing. They can move on like what you guys are doing with platform nine is providing a service so that teams don't have to do it. That makes a lot of sense. So now it's running and then they move on to the next thing. Yeah. So what is that next thing? I think edge is a big part of that next thing, right? The propensity for someone to put up with a delay, I think is gone. For some reason we've all become fairly short-tempered, short-fused. I clicked a button that should happen now type people and for better or worse, hopefully it gets better and we all become a bit more patient but how do I get more effective and efficient at delivering that to that really demanding. I think you bring up a great point. I mean, it's not just people who get short-tempered. I think it's more of applications are being deployed faster. Security is more exposed if they don't see things quicker. You got data now infrastructure scaling up massively. So there's a double edged sword to scale. Yeah. I mean, maintenance, downtime, uptime security. So I think there's a tension around and one hand enthusiasm around pushing a lot of code and new apps, but is the confidence truly there? It's interesting. One little supply chain software, look at container security. Yeah. Yeah, it's big. I mean, it was codified. You agree that people, that's kind of an issue right now. Yeah. I mean, even the supply chain has been codified by the US federal government saying there's things we need to improve. We don't want to see software being a point of vulnerability and software includes that whole process of getting it to a running point. It's funny you mentioned remote and one of the things that you're passionate about certainly edge has to be remote. You don't want to roll a truck or have a labor at the edge. But I was doing a conversation with at remark last year about space. It's hard to do break, fix in space. It's hard to do it to roll someone to configure satellite. So Kubernetes is in space. We're seeing a lot of cloud native stuff and apps in space. So this example, this highlights the fact that this got to be automated. Is there a machine learning AI angle with all this chat GPT talk going on? You see all the AI go on the next level. Some pretty cool stuff. And it's only, I know it's the beginning but I've heard people using some of the new machine learning, large language models, large foundational models in areas I've never heard of, machine learning and data centers, machine learning and configuration management. A lot of different ways. How do you see as the product person you incorporating the AI piece into the products for platform nine? I think that's a lot about looking at the telemetry and the information that we get back. And to use one of those like old idle terms, that continuous improvement loop to feed it back in. And I think that's really where machine learning to start with comes into effect. As we run across all these customers, our system that helps it two o'clock in the morning has that telemetry. It's got that data. We can see what's changing and what's happening. So it's writing the right algorithms, creating the right machine learning to... So training will work for you guys. You have enough data and the telemetry to get that training data. Yeah, obviously there's a lot of investment required to get there. But that is something that ultimately that could be achieved with what we see in operating people's environments. Chris, great to have you here in the studio going wide ranging conversation on Kubernetes and platform nine. I guess my final question would be how do you look at the next five years out there because you got to run the product management. You got to have that 20 mile stay. You got to look at the customers. You got to look at what's going on in the engineering. And you got to kind of have that arc. This is the right path kind of view. What's the five year arc look like for you guys? How do you see this playing out? Because KubeCon's coming up and we're seeing Kubernetes kind of breakaways with security they had. They didn't call it KubeCon security. They called cloud native security column they just had in Seattle. An inaugural event seemed to go well. So security's kind of breaking out. You got Kubernetes. It's getting bigger. Certainly not going away but what's your five year arc of how platform nine and Kubernetes and ops evolve? It's to stay on that theme. It's focusing on what is most important to our users and getting them to a point where they can just consume it. So they're not having to operate it. So it's finding those big items and bringing that into our platform is something that's consumable. That's just taking care of that's tested with each release. So it's simplifying operations more and more, right? We've always said freedom and cloud computing. Well, we started on open stack and made that simple, right? Stable, easy, you just have it, it works. We're doing that with Kubernetes. We're expanding out that user, right? We're saying bring your developers in. They can download their KubeConfig. They can see those containers that are running there. They can access the events, the log files. They can log in and build a VM using Jubevert, right? They're self servicing. So it's alleviating pressures off of the ops team, removing the help desk systems that people still seem to rely on. So it's like, what comes in to that field that is the next biggest issue? Is it things like CI CD? Is it simplifying GitOps? Is it bringing in security capabilities to talk to that? Or is that a piece that is a best of breed? Is there a reason that it's been spun out to its own conference, right? Is this something that deserves a focus that should be a specialized capability instead of tooling and vendors that we work with, that we partner with, that could be brought in as a service? I think it's looking at those trends and making sure that what we bring in has the biggest impact to our users. That's awesome, thanks for coming in. I'll give you the last word. Put a plug in for Platform 9 for the people who are watching. What should they know about Platform 9 that they might not know about it? Or when should they call you guys? When should they engage? Take a minute to give the plug. The plug? I think it's if your operations team is focused on building Kubernetes, stop. That shouldn't be the cloud, that shouldn't be in the edge, that shouldn't be at the data center. They should be consuming it. If your engineering teams are all trying different ways and doing different things to use and consume cloud-native services and Kubernetes, they shouldn't be, right? You want consistency. That's how you get economies of scale. Provide them with a simple platform that's integrated with all of your enterprise identity where they can just start consuming instead of having to solve these problems themselves. It's those two personas where the problem is manifest. What are my operations teams doing and are they delivering to my company or are they building infrastructure again? And are my engineers sprinting or crawling? Because if they're not sprinting, you should be asked the question, do I have the right cloud-native tooling in my environment and how can I get them back? I think it's developer productivity, uptime security of the tell signs. You get that done, that's the goal of what you guys are doing, your mission. Great to have you on. Chris, thanks for coming on. I appreciate it. Thank you very much. Okay, this is theCUBE here. Finding the right path to cloud-native. I'm John Furrier, host of theCUBE. Thanks for watching.