AppDev Done Right Summit | Cracking the Kubernetes Code as Speed Meets Control

Clips
More from AppDev Done Right Summit

Haseeb Budhani

Co-founder & CEO

Rafay Systems

play_circle_outline Rafay's platform simplifies compute consumption across public and private cloud environments.

play_circle_outline Empowering Kubernetes Operations: Key Components of Rafay for Self-Service, Application Consumption, and True Multitenancy

play_circle_outline Enterprises struggle with Kubernetes complexity, impacting application delivery and management confidence.

play_circle_outline Enhancing Governance and Standardization in Rapidly Scaling Platform Teams to Overcome Reactive Problem-Solving Challenges

play_circle_outline Automation enhances developer velocity and reduces application environment setup time significantly.

play_circle_outline Misconfiguration and inconsistent security postures create significant risks for organizations.

Info
Transcript

Cracking the Kubernetes Code as Speed Meets Control

Haseeb Budhani

Co-founder & CEO Rafay Systems

Haseeb Budhani, co-founder and chief executive officer of Rafay Systems Inc., joins theCUBE’s Paul Nashawaty at the AppDev Done Right Summit to explore how modern platform teams are scaling Kubernetes operations without sacrificing control. The discussion focuses on governance, security and developer velocity in high-demand environments.

Budhani shares real-world strategies for optimizing enterprise Kubernetes infrastructure, with a strong emphasis on self-service and multitenant platform design. Backed by research from theCUBE, the segment spotlights ... Read more

explore Keep Exploring

What is Rafay's focus and current market trends regarding compute resources? add

What are the key characteristics that differentiate cloud services from traditional data centers? add

What percentage of enterprises report that managing Kubernetes infrastructure slows down application delivery, and how confident do organizations feel about managing Kubernetes at scale? add

What are the challenges and considerations for governing and managing a large-scale enterprise environment with multiple business units, teams, and developers working on diverse projects and shared infrastructure? add

What are the benefits of using automation in application environment setup and code deployment? add

What findings have been observed regarding container misconfigurations and their impact on security, and why is standardization important in securing environments? add

bolt Powered by CUBE AI

Cracking the Kubernetes Code as Speed Meets Control

search

Paul Nashawaty

>> Welcome to the AppDev Done Right Summit featured in Rafay. We'll explore how modern platforms teams are accelerating Kubernetes operations without sacrificing governance, security or developer velocity. As organizations scale in their application portfolios, they face growing pressures to standardize environments, streamline day-two operations, and enable self-service for developers, all while keeping complexity in check. Rafay's Kubernetes operation platform is a purpose-built environment to help address these challenges, offering automation, visibility, control across multi-clusters and multicloud environments. In this session, we'll help dive right into Rafay's value proposition that we just talked about, how it helps organizations deliver cloud data of applications faster, safer, and at enterprise scale. I'm joined today by Haseeb. Haseeb, welcome.

Haseeb Budhani

>> Paul, good to see you.

Paul Nashawaty

>> You too.

Haseeb Budhani

>> Thank you for having me on.

Paul Nashawaty

>> Of course. I probably didn't do that any justice, but I'll let you give some background of what I just said about Rafay and how it all comes together.

Haseeb Budhani

>> Happy to do it. So as Paul knows, and we have spent enough time talking about this, so Rafay is taking a step back from Kubernetes, fundamentally an orchestration company. We help both enterprises and service providers simplify the consumption of compute that they're managing. So the compute for an enterprise could be in a public cloud. It could be on-prem. For a source provider, it usually happens to be their own compute in a data center somewhere. The big driver for us at present is companies who are purchasing GPU-based hardware, so regular computing hardware, which is very expensive. And what they're looking for is a way to enable consumption of that compute as quickly as possible, do it at a high percentage as possible, and we make that happen in space. As part of the platform, we deliver three things that I believe are critical for any organization to behave as a cloud. The number one, we solved for self-service consumption. A developer from any one of your customers' environment should be able to go to a portal, press a button and get compute. If you aligned with that, by the way, you're not a cloud. You're a data center, not a cloud. Second, we enable application consumption. So if your customers, internal or external, are looking for a model as a service, okay. If you can't do that, by the way, you're not a cloud. Data center, great business, not a cloud. And the third thing is you should be able to behave in a truly multitenant fashion. And when I say multitenant, I don't mean I sell four servers at a time. No. If somebody wants a single GPU or if somebody wants to consume tokens to try out DeepSeek, you should be able to manage all of this user consumption in the same infrastructure, same server, in some cases, same GPU. It depends on the situation. If you can't deliver true multitenancy at the network level, at the compute level, at the application level, you're not a cloud. We enable these three things for the customer, and that's why we seem to be doing really well as a company, as Paul knows.

Paul Nashawaty

>> Haseeb, this is really exciting times, honestly, as you mentioned. Those three areas you just highlighted are really key to the success of a modern organization trying to drive towards their success. As you know, we've talked about it a number of times, I cover the AppDev's practice here at theCUBE Research, and when I look at the day practice, I focus on day zero, day one, day two, and DevSecOps in the CSV pipeline and everything that touches it across the SDLC. But when we look at these modernization efforts, I also talk about it in the context of past, present, and future. And the three elements you just mentioned are really tied to that moving from a heritage environment to a more modernized approach. So I want to start by expressing some research here that we've just recently fielded and has come back from the field. We found that 69% of enterprises report that managing Kubernetes infrastructure, the complexity around it, it slows down application delivery. That's one of the things that we see there's a challenge, but we also see, according to a number of sources, including the CNCF, as well as our research, we found that Kubernetes in production rose 96% in 2024, but only 34% of organizations feel confident to manage it at scale. So Haseeb, when we look at the biggest challenges here, one of those three things you mentioned are those three areas of focus. I do want to talk a little bit about the biggest challenges platform teams face with managing Kubernetes at scale, and how does Rafay address these challenges?

Haseeb Budhani

>> Look, Kubernetes, or any of these cloud capabilities, even if you're just providing VM as a service, surprisingly, or pipeline as a service, many of our customers end up doing that. The problem, Paul, you and I have talked about this before, is that when you have very little scale, a couple of developers make one team, it's all actually pretty easy. The question is not that one team. The question is, okay, you're an enterprise with many BUs. Each BU has many teams. Each team has many developers and all of them are working on different things, and sometimes they're working on shared infrastructure. Now, how do you govern this environment? And that's the problem. So when you think about that kind of a setup where things are so dynamic, what is your standardization strategy? What is your governance strategy? What's your configuration management strategy? These are simple questions, but they become massive tasks. And what happens in platform engineering, for right or wrong, this is how people do this, they solve a problem at a time. There's no essentially a roadmap. When you build a product, you have a roadmap. I'm going to do this today, but I need to deliver that thing, so I'm going to plan accordingly. Unfortunately, in platform engineering, we are all very reactive. So we work on that one guy who needs to solve that one problem, I need to connect GitLab to this one environment, and I guess we're done. Okay, but then tomorrow somebody's got GitHub or somebody else starts CircleCI, oh, by the way, this person is using VPCs in this way, but they use it another way, and then the IAM roles are different here and there, what's your strategy? And if you don't think about strategy on day one, what happens is you have a mishmash. And when you have a mishmash, consistently what happens is the subsequent problem you solve, it's going to take longer and longer for you to solve because you have to go back and solve for everything else that you already created. All this debt that you created in your company is why you slow down. It's all great at the beginning. Six months later, everybody hates it. And this is consistent. This is how it is. And then the first team leaves the company and the next one comes and says, "Everything they've built in the past was wrong. I'm going to do it all again." Let's not do this anymore. This is not okay. Let's focus on our core principles, right?

Paul Nashawaty

>> .

Haseeb Budhani

>> Who has the right to do it? , no.

Paul Nashawaty

>> Yeah, absolutely. That makes a lot of sense. I mean, when we think about it, you mentioned the governance and control. I want to talk a little bit about that. What we find is and research is showing that by 2026 that 75% of organizations are adopting an idP to help improve developer experience and speed. So that helps with the deployment models. But then we also find in our research that enterprise that are enabling self-service with guardrails to increase about a two and a half percent boost in developer velocity, but the problem is, is this governance and control has to be put into play. And if you don't have governance and control, that's an area of challenge. We've talked about this before where you're talking to CIOs and such, and their number one challenge that they run into is application modernization at scale, and they have to work with the entire organization in order to drive those results. So when we look at this, how do you recommend or how would you talk to your prospects, your customers about self-service capabilities for developers without compromising those governance and controls?

Haseeb Budhani

>> So I think this growth of idPs is also indicative of our reactive nature as a group. So people decided, I know what to do. If I just have a portal where people can press a button, I'm going to solve my problems. Okay, all right. So now there are portals. Okay, but what happens behind the portal? Have you thought about that? Because really the thing is not on the front, the thing is in the back, but it goes back to the same thing. Most of these idP platforms end of the day end up calling on Terraform. So now Terraform who wrote it, how many different variations of this do you have, and that becomes a problem. I think that fundamentally, this is what I think about a lot and when I talk to CIOs I encourage them to consider that on the product side of the house they run roadmaps different from the platform engineering side of the house. And the question is why? They're both products. Why do they behave differently when there's platform engineering versus actual products that you sell at the company? It's actually the same thing. Your platform engineering output should be treated the same way you treat the product for your company because this is the foundation of your business, but you don't behave that way. How many platform engineering teams have product managers? Very few. Why? Why not? You're bringing a product. Why don't you have a product manager? They don't think like that. And I think it would be awesome to encourage all of our peers in this industry to think like that. You should be a product manager. You have many of them for the product, this is also a product. But because they're not a product managers, they think it does again, today's problem, tomorrow's problem, the day after. What about what's your long-term strategy? idPs are great. Look again, they're awesome. Whatever you want to use, you should use it. They're all great. What happens behind the idP? And that's what the governance piece comes in. We chose to solve a hard problem, a problem that most companies actually don't want to solve. So my thesis on Stratus, by the way, if you solve these hard problems that are fundamentally boring, non-sexy problems that nobody wants to solve, look, end of the day you make that. So we're doing that. So we're doing this for everybody. And what I tell my customers, the way you need to solve this problem is the same as all these other companies who are already working with me. So the question you have to ask yourself is, do you have a competitive advantage in building this or do you have a competitive advantage in buying this? Actually, the answer is usually buy. Cheaper, faster, just go. Take your people, work on actually things that create value for the company. This is not going to create any value for you. I'm the commodity provider, buy the commodity and let's go from here, and this seems to work consistently now.

Paul Nashawaty

>> Absolutely. And time to value is critical. I mean, you can't focus. I think when I talk about the do-it-yourself rollout versus buying something, the devils are in the details, especially when you start looking at the complexity of a lot of these environments. When we look at things like monitoring and compliance across multi-clusters and multicloud worlds, we see in our research that 94% of organizations are using two and more clouds, 65% are using four or more clouds. So there's a lot of clouds out there that are being managed. And it's the complexity around this of knowing what's happening across these different environments, you have to be able to address the challenges, but you also have to have a fast time to value, a solution in order to do this. Then and when we see 78% of organizations operating multicloud and clusters, multi-clusters and multiple cloud creating day-two challenges for inconsistencies or consistencies around observability and life cycle management, that's a big challenge as well. And so when you start looking at all of these pieces, there's operational overhead that comes into play. There's just the ways teams are working together. So I think when I look at Rafay's way of doing this, you simplify, or from what I understand, one, it's not just the rapid time to value, which is absolutely the case. You have that, but it's also the simplifying that day-two operations, like those upgrades and the monitoring and the compliance. We talked about compliance, but all those other pieces for day two, that's a big factor here. Haseeb, what are your thoughts around that?

Haseeb Budhani

>> So 100%. The good news is we have customers on our platform who are single cloud users. The question always is, okay, if I have a single cloud, do you deliver any value? And the value in the governance, because even in a single cloud, you have multiple teams doing multiple things, how do you make sure they all look the same, feel the same? Otherwise, when things break, you don't know what to do next. Then it becomes a fishing expedition to figure out exactly what broke. But, you are right. So many companies are running multiple clouds and the burden of managing the multicloud strategy falls on the same platform engineering organization. And then they have a challenge. So between Azure and GCP and AWS, for example, how am I going to create standards? And the example I always use for this, and I use this again and again, is simple things. You have Prometheus. Everybody's using Prometheus and Kubernetes, and you are running multiple clusters in multiple clouds, how do you upgrade Prometheus if there's a ? What's your process? Let's have a conversation. How do you do it? And if you are able to tell me a very quick and easy solution where you can do this in, let's call it, let's not be too aggressive, one day. Okay, great, you are the master. But if you're telling me that it's going to take me six weeks to roll this out across, whatever, four regions and 80, 90, 100 clusters, which is not a lot, okay, you are on the right track, but you haven't really understood the purpose of governance and standardization. Standardization begets the ability for you to move fast. When you have standards, you can go superfast because everything's going to work. You won't have any outliers, and if you don't have outliers, who can go very fast. But at the same time, in a fleet as big as that, you still have to think about what people call steep management. How do you do this in stages? You and I have talked about the stage management of the infrastructure upgrades in the past. These are the places where our customers, by the time they get it right, they're on version two or version four of the platform engineering implementation. And the question is, okay, you've done this for five years, how much money have you spent already? $15, $20, $30 million have been spent on various time salaries, et cetera. Oh my God, look, our product's reasonably expensive. It's not that expensive. It's a pretty good deal. Let's just solve these problems. Let's focus on something that actually matters to the company, which is let's go build actual value in your applications so your customers are paying you more money. And yeah, look, it's amazing. So look, five, six years ago when I used to tell the story, when we were early in this market, we had frankly no product at the time, it was a hard sell because we were in very much of a DIY industry. But I think over the last couple of years when people had actually started going to production, back then people were just tinkering. Now people are in real applications running production, I think people see it. It's like, well, I want to find the fastest, easiest, most reliable way to go to production and not have churn happen in my application. If somebody can show me that, I'm all set.

Paul Nashawaty

>> Yeah, and I agree. I mean, actually it's not just you saying this. I mean, I was talking to your customers, and your customers were actually saying that they've reported reducing application environment setup time from weeks to minutes, and they're doing this through using Rafay's workflow automation and get-offs driven deployment. That's a way to help with that focus. What we're also seeing in our own research is high-performing team release code faster, four times faster when they place platform automation that's in place. So again, automation is a big factor here. Regardless, a lot of times organizations will say, "Well, yeah, I really would love to do automation, but my organization's not mature enough to do that right now." And automation doesn't mean you're taking completely a human out of the loop. I mean there's still a human in the loop, but I think when we talk about this, it is about that reducing that time to market and reducing the churn and everything you were just referring to. So when we look at automation, how does it support both the platform and engineering teams and application teams to reduce the automation and the time to market?

Haseeb Budhani

>> So here's something that we think about a lot here. So we always ask this question, who's your customer? And we've trained our sellers to do this. Who's your customer? And it's an interesting question because sometimes people are surprised by that question, actually. So platform engineering, who's your customer? It's developers. It's ops people, security people, right? Okay, so then you have to deliver experiences for all of them. What's your time? So mostly these people are thinking about developers. I get it. They're thinking about at some level of ops, usually they're not thinking about security. But I'll tell you what's interesting is that what they're thinking about first is not so much what their customers need, but what can they deliver, which is the wrong way to build any product. You don't deliver what you can do. You first figure out what your customers need. So your developers, as an example, a simple example. I write some code. I write Java code. I write some code. My application has a React front-end, and I use my SQL as my database. That's my work. And many banks, by the way, look like that, many, many banks. Okay? I wrote code. I just want to test it. What do I do next? Oh my God, this is a process now, by the way. Most banks, big banks, big well-known banks, top 50, this is their process now. But as one example what you've done with the customers who are on a platform already, a developer, all they have to do is in a portal they say, "Here's my code and this could ," and that's it. Nothing else, absolutely nothing else. Everything else should be matching. So that's perfection, how do you deliver it? See, automation sometimes is a burden if you don't understand what are you doing it for. So I'm doing it so that my developer can write code and test it 50 times a day, not every two weeks because he has to file a ticket. 50 times a day, five times a day, if you can do that, your people will move so fast that your company will actually benefit from the value. Then automation is not a means unto itself. It's benefiting the company's pipeline. And similarly for ops, I'll give you another example. I have developers coming to me as an ops guy saying, "I just need a landing zone on Amazon," or whatever, Azure or whatever. "How do you do that?" This is a project in companies, by the way. They have 21-day moratoriums on landing zone before they actually let people use them because they don't know exactly what they've done. They have automation, but no standards. Standardization is key. Automation without standardization and governance is useless. It's just a script. Nobody cares. Nobody should be using this. There has to be measurable, testable governance and standardization to get this right. When you do that, your ops teams move superfast, your developers move superfast. And to me, by the way, those are the two customers that matter for platform engineering. Who's your customer?

Paul Nashawaty

>> Absolutely. Yeah, absolutely. And I want to double-click a little bit on that because organization standards and security, securing the environment is really key to the success of a successful deployment. What we're seeing in our research is we're seeing 92% of containers have at least one misconfiguration, and this is inconsistent security postures across clusters, it was cited as a top risk. This is a challenge that we see often. And we also think, see that enabling policy as code helps with centralizing governance and also helps with reducing the enterprise's configuration drift by 60%, and that's a big factor as well. So maybe if you can touch a little bit, as we come to a close, we can touch a little bit why organizational standards and secure environments, maybe Kubernetes environments, maybe just multicloud environments, but overall, why is this important? And you've already started going down that path because it's repeatability and automation, but I think that that's something that we want to double-click down on here to make sure the audience fully understands standardization is a key to success.

Haseeb Budhani

>> So to me, security is, the way I think about security is the following. So there are certain solutions needed from a security perspective that have to do with external attacks, and then there's stupid stuff. There's actual attacks, real threats, and there's just stupid stuff. So we, as organizations, spend money on both though, and we see them both as security problems. I see the second one, which is the misconfiguration, the policies code stuff, this should be business as usual from an operation perspective. So if you have the right standards, if you have the right governance in place, you don't have these issues. You're not going to have a pod being able to access the host and doing silly things. It's just not going to happen if you have the right posture in place, if you have the right controls in place. And when we start with a customer, the first thing we do before we have them implement anything is we agree on what are your standards in your company? And if you don't have one, it's okay. We've done this in enough times now. I can actually show you what others, without naming, this is what others are doing. This is a standard now. We know now if you follow these things, you're in pretty good shape and your security team's going to be happy. Let's focus on the external threats, not the stupid stuff. And this is, by the way, this is really important if you have, and it all goes back to the same thing, standardization and governance. If you have the right standardization, the right governance in place, none of these things are going to happen. Your people can actually run free. Literally, if you have the right guardrails in place, they can go as fast as possible. People who say things like, "We're not ready for automation," they're actually more overconcerned about if they go too fast, what will happen that we don't know, so let's not let them run fast. That's not why you get a salary, my friend. You get a salary to help them go fast. Go figure your stuff out. And this is the thing. If you treat platform engineering as a product organization, these problems will go away. I tell you, oh, you and I got to write a paper on this. Platform engineering as a product org, problems go away.

Paul Nashawaty

>> All right, so you heard it first here, we will have a paper written on why platform engineering should be a product organization. Haseeb, this is great. I mean, this is really a lot to talk about, a lot to take in. What would you like to leave the audience here as they're just getting started and understanding where they should go? How should they get started with this?

Haseeb Budhani

>> Look, I mean short of pitching our platform, which is out there and really good, you should give it a shot, it's very nice, I think this notion of starting with some standards, starting with some best practices that others have adopted. So one of the things we've done in the company is we've set up a team, their job is to show customers what that means. So hey, no expectations, no string attached, we're happy to work with you, show you what is possible. And then if you like, it's great, we'd love to work with you. Obviously, we want to make money. My job is to help the company make money. But the first thing that I really think about a lot is if we can change the way people think about platform engineering in our industry, a lot of these problems will go away. And yeah, what Paul had just said, we're going to do this, man. We're going to write a paper, platform engineering as a product organization. If we do this in our industry, a lot of these problems will go away. I'm hoping we can solve that problem together.

Paul Nashawaty

>> Love it, love it. Haseeb, thank you for your time today. This has been awesome. And thank you for joining us with this session with Rafay at the AppDev Done Right Summit. By embracing these practices, organizations can really respond faster to these challenges and build resilient, ongoing, innovative culture, which is that's what we're trying to get to. We've been talking about it throughout the entire summit, is innovation, allowing developers to innovate. As we move forward, remember the key to operational excellence lies in the continuous learning and adaptation, and keeping your applications reliable, performant, and ready whatever comes next for them. So keep building, stay curious, and keep going. Thank you for attending our session today.