Narrator: You're listening to the Humans of DevOps Podcast, a

podcast focused on advancing the humans of DevOps through skills,

knowledge, ideas and learning, or the SKIL framework.

Haseeb Budhani: VR, even in this economy at a point where there's

not enough talent available in this space, who understands and

can operate Kubernetes not just bring up the cluster right?

Again, these are simple things, like truly running this at an

enterprise scale is a very hard scale.

Eveline Oehrlich: Welcome to the Humans of DevOps Podcast. I'm

Evelen Oehrlich, Chief Research Officer at DevOps Institute. The

name Kubernetes originates from Greek meaning Helmsman, or

pilot. I've also heard Kubernetes, often described as

the Linux of the cloud. And today is the most popular

container orchestration platform for multiple reasons. Kubernetes

burst onto the it developer scene in 2014, when Google

released it as an open source version of its Borg technology,

which which they developed as a way to run 1000s of jobs and

applications across multiple clusters and machines. Since

then, the technology actually has spread far and wide. It is a

key part of managing applications in data via

containers, and Gartner projects to reach this technology to

reach 944 million by 2024. Today, I'm excited to have with

us Haseeb Budhani, who is co founder and CEO at Rafay

Systems. Hello, welcome to the podcast. Haseeb.

Haseeb Budhani: Hi, everyone. Nice to talk to you. And thank

you for having me.

Eveline Oehrlich: Yes, I did some googling you and looked at

your of course, LinkedIn profile, you have done a lot of

things I had to scroll and scroll and scroll, all these

different types of things you will have been doing maybe give

us a cliff notes of what have you been up to before you were

advice systems, the CEO and founder?

Haseeb Budhani: Sure, since undergrad, I have been fortunate

enough. In fact, while I was I was a senior in college, I did a

number of internships in my in my time at USC. And the very

last internship I did was with a company that was writing

shopping cart software. This is back this fall of 99. Not going

to exactly how old I am. That was my senior in college. And

yeah, these guys were doing some crazy things, writing this thing

called a shopping cart. And they were desperately hiring

engineers. And they give me Yeah. And it was a lot of fun.

It was it was crazy. So before then I'd worked at Cisco and

done a set internship at Cisco and an internship at Ericsson.

And I had a sense for how those companies weren't, these are big

companies. But this other company, it was just crazy.

These people didn't sleep. They just kept burning code. And it

was awesome. So having once I finished that internship, then I

started applying for four full time jobs. I just wanted to work

at startups. I just wanted to find companies and I didn't have

the concept or appreciation as a 21 year or for for stock or

anything had no idea I cared about was about these these

companies. Well, you know, they pay well, they don't pay as well

as a Cisco perhaps. But wow, you get to work on some amazing

things. And that's what I did. My first job out of college was

at a start as a startup, which was called Publix. And that

solve for single sign on. It's one of the first companies that

were doing single sign on in our industry. So it was not a thing

at the time, but they were doing it under another startup. And in

the process. I think I just you know, good or bad, I learned a

lot of a lot of different things. And that's been you

know, it was a lot of fun. And truly, I believe that had I not

done those things, I would not have had the opportunity to work

on startups that last 1012 years that I've been, you know, in

some fashion of founder or whatever. Yeah, just small

decisions, or very small decisions can put you on these

paths. And I think back a lot to that one specific afternoon when

we had this career day. And I decided to talk to these crazy

people back at USC and that became you know, my pad had a

mountain that hadn't taken a job at Cisco because I had an offer

from Cisco when you when you graduate come work here and I

didn't take it. Yeah, I always worked at startups. Only work at

large companies through some pathway positions that have not

worked at I've never it's been a long time since I've actually

applied for a job in a large company. That's become my my

personality but the The most important thing I do here, or I

require companies is, as a CEO, my primary job is sales. Like my

job is to give our customers the clarity as to why the company

exists, why raffia exists? Well, like any other company, when

I've worked at why does this company need to exist, rather,

and how this can make their life better? By getting people to

their point of clarity so that they can go, I see how I could

use it. There's nothing like it. I mean, that's, that's what

drives me. Right? So I enjoy that more than anything else.

And particularly if you have the, you know, somewhat of a

technical background, I happen to have one. It's, it's great,

right? So anybody working on new technologies, we all have to

understand it. I mean, we can create technologies, we can sell

it, it doesn't really matter. It's like a tree that fell in

the forest, or it doesn't matter. But being able to build

something, and then being able to articulate why. And why

should you care? Right, that is, arguably the more important

thing. And if you can figure that out, you know, you're gonna

have a lot of fun in this industry.

Eveline Oehrlich: That leads me to one of the factoids, I found

rough AI systems was actually named as one of the hardest one

of the 10 Hottest humanity startups of 2022. By CNR. It's a

channel magazine, but that's great. So two questions for you.

What does Rafay Systems do? First, and what has put you on

the list of the top 10 startups and like you said, of course,

your startup, your passion for startups, probably has something

to do with it. But help help our listeners, as those are many of

them are developers, I owe, you know, geeks and good geeks. Help

them understand what does Rafay Systems do? And how did you make

it to this top 10 startups.

Haseeb Budhani: So Rafay is in the Kubernetes management space.

Kubernetes is, oh my god, there's like hundreds of

companies, something in Kubernetes. It's a very noisy,

very busy space. But when I think about what we do, like,

fundamentally, we solve a people problem in this company. Every

enterprise, we telco, any company that has software that

they're deploying, going forward, it will be

containerized, or some function, because they want move fast as a

company. And in many cases, majority of cases for companies

will pick Kubernetes, as our orchestration engine, you

describe Kubernetes has been the fastest growing container

orchestration platform out there. It's it's the de facto

standard, if not the standard presently. But it brings with it

a number of complications. Just because you have an

orchestration engine doesn't mean you as an enterprise can

consume it easily. You have a number of constituencies inside

your company, there's security, there's operations as

developers, there's all these other different people and

multiple development organizations inside every

enterprise. They all have to work together somehow. It's a

people problem, everything is a people problem. And to that end,

what you've what you've attempted to solve for, and it

seems like you've done a really good job, and you have a really

nice roster of customers who use the product daily, is that

they've thought through what it takes for an enterprise to

really build shared services platform for Kubernetes. How do

you deliver Kubernetes as a service inside your enterprise?

And what that means is not just the material cluster, that's the

easy part, building a cluster or creating a Kubernetes cluster.

That's not the issue. That's a solved problem. In my mind, the

real problem is, who has access to what do we know what they're

doing? Can we do this consistently? Can we can we

update patches consistently across our fleet of clusters?

can I provide different levels of access to different teams? If

certain teams have networking requirements that are different

from other network teams? How about how do I make that happen?

And how do I do all of this centrally with the right level

of governance? This is how enterprises pay. If you solve

that problem in the context of Kubernetes, of course, it's

solving a technology problem. But really, you're solving a

people problem. Because the skill set is it takes time to

build a skill set. We are even in this economy at a point where

there's not enough talent available in this space, who

understands and can operate Kubernetes not just bring up a

cluster right? Again, these are simple things like truly running

this at an enterprise scale is a very hard skill. Every

enterprise is looking for those people and they're not able to

find them. And what we are telling them is we will help you

augment your teams with software automation. That's what we sell.

Fundamentally what we're selling is automation that augments an

existing team. And the beauty of the right automation is that a

the enterprise they get up and running now. They don't need to

wait a while to hire Are people and then build a platform

because we sell them a platform. But to me the more important

thing, and this, I think, long term is the right way to think

about any technology, the people in the organization that are in

our customer, who are not experts at Kubernetes, by

working with our product, and by working with our support

organization, they actually ended up becoming experts. If

you can, in sort of, indirectly or perhaps as a byproduct, get

people, you know, sort of, you know, adept at Kubernetes, and

all the things that happened around it, right. That is, that

is generally good for our for our community, all right,

industry, right. So we sell a great product, the enterprise is

happy, because they can now move much faster, right? They're TCO

is lower because they can do this today, etc. They don't need

to wait to hire another 510 15 people. But the existing IT

engineers and I'm using the word it very loosely, we call them

DevOps, right depends on the on the function they have. And then

broadly speaking it, they all get to learn this new

technology, which is going to be with us for at least 10 years,

if not going to be all over time after learn this. And yeah, we

take pride in saying that our customers, their engineers, you

know, months into our engagement, Rafi, yes, the

enterprise is better off, but the engineers are better off to

Eveline Oehrlich: Yeah, we'll get to the future, hold that

thought on where this is going. Because that I want to dive into

that a little bit deeper. But back to what you were just

saying. So we do now 22 was a great year for Kubernetes. And

we've had in our organization, lots of questions for upskilling

in this topic. While it was initially viewed as something

only really large enterprises could benefit from, we know that

it has improved in usability, most likely because as you said,

skills have gone up. But there are still some challenges. Now,

there are some technical challenges with it. What would

you say if you think about your clients, those you speak to

every day? What are some of the biggest challenges leveraging

Kubernetes these days, and just for right now just focus on the

technology in itself? Because I know there's a few. And then

we'll move further on once we're done with that towards the you

already said that, which is music to my ears, the skills and

the skill development and the reduction of toil and all of

that? Well, we'll get to that right now. Let's just focus and

hone in a little bit on the technical challenges you you

see.

Haseeb Budhani: Yeah, absolutely. So many people ask,

you know, what does Rafay do, and I use the phrase Kubernetes

management, I didn't use the phrase Kubernetes for the

following reason. In my mind, the the biggest player in the

Kubernetes space is AWS, they provide an engine or product

called COVID PKS elastic Kubernetes. Service, which is,

as far as I know, the most used Kubernetes offering right now.

So Amazon is the Kubernetes company. So then what is rapid?

So once a customer decides I'm going to use maybe Amazon's

Kubernetes, maybe something else, Azure, then they start a

journey, where they have to now figure out, okay, how do I

automate the provisioning of these clusters? There's

automation for that, and then people who know different types

of technologies, right, TerraForm, etc, then I need to

understand how to upgrade these things. Okay, there's automation

for that, that you have to kind of figure out, then I need to

understand what are the components that need to run on

this Kubernetes cluster, so that my applications can consume it.

They're all sort of raw out of the gate. So then you have to

learn these things. Then Security says, Well, you really

need to make sure the right people have access to the right

thing. So we have to think about what based access control and

the right level of identity and the right level of access, tie

this back to the enterprise Single Sign On system. We should

really audit everything. who's doing what? Okay. All right,

let's go figure that out. While we're on the point of

Kubernetes, is deploy applications. So case, we should

have pipelines of some sort, connecting back to maybe GitHub

or GitLab. Right? So we got to figure that out. Hey, we have

certificates that we're pushing into these clusters, for, you

know, TLS termination, we really should think about some sort of

secrets management. Okay, well, let's go figure that out. And

chargebacks, service mesh, network policies and Kubernetes

policies, which is different from their policies, and then

really, developers need access. So we should really think about

it the right developer experience. And so each of these

things, and there's, depending on the situation, there could be

many other things to do. And this is a challenge right now in

this industry, right? Nobody's written a book. I'm sure there's

a Kubernetes for Dummies, I'm sure there is. But but it

doesn't talk about what it takes to not just get the toy up and

running. But to truly consume this as an enterprise. By that

framework, what I just described as a is a function of mine just

experience working with customers. But you know, there's

no Bible here. Maybe you should write one, I don't know. But

this is the challenge, right? And we're and the worry I have

right now is that when enterprises jumped into this,

they don't know all these things. Now, could they know,

they just started, right? And initially, everything seems

easy. What's the big deal? I just go to the console, I build

a cluster, boom, boom, boom, it's working. See, I can do

Kotlin. But then start the real challenge. Right, and now it

takes a year, who knows how long it's going to take depends on

the size of the company. And that's not okay. Right? This is

this is a detriment, right? This is going to get in the way of

progress. Right. So obviously, when when you see gaps startups

come about, and Rafi solve that problem, our job is a, we're

going to make for example, Eks, or Azure Kubernetes, which is

AKs, we're gonna make it out of the box enterprise ready, and

we're gonna help you manage n number of views across clouds if

you want. So we solve that specific gap. But but this is a

really hot technology promise. So our customers are pretty

sophisticated engineers, and they're all very smart people.

This is what I actually really enjoy about this, this specific

job. I'm not trying to, I don't need to convince anybody of the

problem, right? We have open conversations, and they get to

the point of clarity, I get what the gaps are. But but sometimes

they don't know what the gaps are, unless they experience

that. But experiential learning takes time. Right? You're going

to take a year, 18 months to figure out what you don't know,

or what is missing. But your company just launched 18 months,

this is the technology issue, right now in our industry. But

we're a small company, relatively speaking. So it's not

like I can I can solve this for everybody. But this is what I

think about all day long. By this. Sometimes we as an

industry have the you know, we do something that is bad, which

is reserved, you know, trivialize the the, you know,

the complexity. Everything is easy. Look how easy it is look,

one command, and it's all done. Now, let's just have real

conversations about yes, indeed, this is hard. That's okay.

Because it's hard doesn't mean it's bad. It just means I need

to step back and think about how am I going to solve for the

complexity? I think it's better to have that open conversation

versus try to kind of, you know, hide this or not hide as hide is

a strong word, but just, you know, trivializing this or, or

trying to minimalize This is not okay. Right. And I truly believe

that this is hurting a lot of enterprises or companies in

general, who are starting to join it because they are not

aware of how complex that technology is. And if they were,

they would make better decisions. And maybe some of

them will say, this is not for me, that's okay. But still, we

have to give them that clarity upfront, it's complex, here are

ways to solve it. That will over kind of, you know, at the macro

level that will help this industry more than a specific

vendor who's trying to get to a sale. Don't think like that, I

think at the at the macro level, give people that education and

that clarity, and I think that's good for all.

Narrator: SKILup IT Learning is the perfect online destination

to learn about DevOps and digital transformation anytime,

anywhere. A digital learning platform provides you with all

the resources you need to upskill and learn about these

important topics, including expert led course videos, access

to certification, prep courses, and a community of supportive

peers. A subscription based model makes it easy for you to

gain the skills needed for success in the modern workplace.

Visit DevOpsInstitute.com now and explore our different

learning plans, get 30% off, SKILup IT Learning Plus now,

claim your offer and start learning today with code Feb. 30

off, that's F E B three zero, o f f.

Eveline Oehrlich: And I think as technologists, I've seen this

over and over in conversations with CIOs and VPs where they

have been promised by their teams that oh, yeah, this shiny

new object can help us immediately to increase flow,

velocity, speed, quality, whatever. And those executives

promise that onto the partner in business, and six months into

the journey or 12 months, maybe longer even then they are all

disappointed because it hasn't achieved the outcome they have

been thinking about right. And I think you hit as we say in

Germany, the nail right on its head where we sit everywhere.

Yeah, we you need to be realistic about setting

expectations and making sure that we have these

conversations. Sometimes they're hard. You did mention a few

things earlier, around the challenges relative to people

and organizations, right you and in your examples, I could hear

some of that because we've still silos now Add sometimes a bad

word because we have experts in certain areas, right? Even

though we have dev SEC ops, the security team is not yet as

integrated as it should be. And so my curiosity is around people

and organizational challenges relative to Kubernetes. In

bringing in such technology, what do you see your clients do?

And what, what's what works? Because many of our listeners,

I'm sure say, Yeah, okay, we've done this, but it fell flat on

its head, and it hasn't failed. Because it's Cuban Eddie's which

didn't work. It failed for cultural reasons.

Haseeb Budhani: Yeah, there's, there's some influence we have.

And there's, of course, you know, as a vendor, some

influences we don't have when we get to see a lot of stuff. What

one investment we've made in this company, which is perhaps

unorthodox is that we built a service delivery team, in the

company. And the point of this organization is, when a customer

says, people do talk to them, we sort of, you know, agree that

they should try the product, and then we try the product. And so

this is pretty awesome, I should buy it. And then they buy it.

And then what, right, just because you did a POC doesn't

mean it's it's plugged into your into your company, right? That

that's a process, right? A lot of people have to be educated to

bring developers and say, Hey, here's a, here's a platform, and

you want to think about ABC. So So we saw that happen again, and

again, where the where the customers would basically go

through this internal process, right, where they try to build a

framework, and they try to invite developers and try to

sort of, you know, convince the developers internally, hey,

don't do this yourself anymore. It's waste of your time, here's

a better platform, and we're gonna give you all the

automations. So we decided, you know, what, we're gonna build a

program. We're just going to do it for you, for you, Mr.

Customer. So we build the program. So we kind of walk once

the deal is almost done, or whatever, it's in contracts, we

say, hey, look, we have a team, they're gonna engage with you.

And they're gonna help you get to that finish line, whatever

that means to you. Right? It could be bring these 10 teams

over to eat gas, perhaps Right? Or whatever, or on prem

Kubernetes doesn't. So we did this for the following reason,

because it is hard, right? Like, everything boils down to, this

is new. I know that we have been talking about Kubernetes as a

community for I don't even know, whatever, whatever, no, six

years something like that sucks. Yeah, I meet customers all the

time, who say, Oh, I've been working on this for seven years?

And I'd actually tell them honestly, seven years ago, I had

no idea. I never heard of it. I heard about Kubernetes, five

years. All right. Okay. So it's new, right? Even now, many,

many, many enterprises who are working on Kubernetes are

probably in the first year of using. So how can they know?

Right? These are things that are not obvious, right? How do you

build a practice? around Kubernetes? And this is where we

see a lot of toil, right? This is where we see projects fail.

in companies where they buy something, and then well,

nothing happens. Right. And it's not that the product is good or

bad, right? You've seen enough of our competitors kind of go

through this and we're learning from, you know, you know, we're

standing on the shoulders of giants, as they say, and we're

learning from others who have come before us. And the biggest

mistake, I see the two mistakes I see that have been made in

this industry by other vendors. One is that they really focus on

Kubernetes and not Kubernetes management. And this is what we

discussed earlier in the call, what is the distinction between

just a cluster and all the other things that need to happen. And

the second one was they did not invest in helping their

customers. They relied on, you know, systems integrators or

somebody else your problem, go figure. And that's a hit or

miss. Don't do that be happy to help our customers get up and

running. Selfishly, obviously, because you want to make money

and you don't want to see churn. But but more importantly,

because our customers spend two, three months doing a POC, they

spent money, we want to make sure they get value out of the

money, and not just park our solutions on our shelves or

whatever. Right? This is something that has been really

important. It's been a massive game changer for us as a

company. Because yeah, that customers actually use a product

and they're happy. And happy customers will people who are

right, because they're solving a problem. But this this is I'm

telling you the story because all of this ties back to the

complexity, the the the unknowns in this space, what do I have to

do? Right? And if we've seen this enough times are we have

enough customers, if we can essentially educate our

customers and we don't charge for this, right? This is part of

our our engagement, right? We're gonna help you come up with a

framework that we've seen work and I don't know 10s and 10s of

other companies who want to do something else that's okay. But

here's what others have done. Here's how their standard

operating procedure or center operating model ends up being as

it relates to Kubernetes management and you know, please

consider taking these actions under reality is most customer

said, This is awesome. This is going to make my life easy. I

don't need to invent a process, you are giving me a process. We

do this because of the problem you described, which is, yeah,

complexity. So many things that are not known people are

learning on the job, because well, how can they not happen to

know before? Right? We can't expect them to know these

things. Right? Now. It's possible. They've never done

this. It's unfair to expect this, from engineers who tell

perhaps a year ago, we're working on your cloud, or even

VMware infrastructure in our data center, we can't expect

them to become PhDs in Kubernetes, or that's completely

unfair. We have to help. Right? And we do. So I love

Eveline Oehrlich: it. So there's tons of knowledge transfer

during those projects, I'm assuming or do during the

activities. Now I've heard, we've heard platform

engineering. And we've seen quite a few organizations adopt

platform engineering, when we did a survey on sre. We saw that

a very, let's say, not predominant yet, but a very

popular way to shape and frame an organization. And then the

other term is developer experience. Those are two terms,

which every day we get a question on. Okay, how do we

start? What do we do? I would like you to just kind of reflect

a little bit on the two terms, developer experience, of course,

and then the platform engineering, particularly there,

maybe drill down a little bit into the pros and cons, what do

you see, relative to platform engineering?

Haseeb Budhani: Yeah, so our customer, in pretty much every

account is a platform engineer, to be sent to. And we look for

them. Sometimes the name of the team perhaps is not, not from

engineering. I mean, you know, they may call themselves

infrastructure engineering, or cloud operations or something,

but but they are the ones who are responsible for delivering,

essentially, these platform ties, concepts, and Kubernetes

is one of them, because they don't want to have and maybe we

can take a step back and think about why is this even

happening? Why does a baton exist, which, which is a, which

is a really interesting thing to think about what has happened

beforehand, at least in the context of Kubernetes, it

applies elsewhere, as well, I'm sure it's clearly applies to

cloud, what's happened is some development team, they decide,

hey, these container things are pretty awesome. They allow us to

move very fast. So you know what, we're gonna do this, we're

just gonna do this container saying and they go to it, or at

that time, maybe cloud engineering, and this entity

isn't anything like Kubernetes. And they probably say, No, this

is not something that we provide today, they go, no problem, I'll

just do it myself. But these developers essentially go to the

cloud and their developers, but they'll figure it out. They go

provision infrastructure, Kubernetes. And they now run

their applications. Okay, now a second team shows up and says,

Well, this is really cool, we should do the same. And then a

third one. Now, what's going to happen is the skill set is going

to perhaps vary between these and teams. But here's the most

important thing. You are now missing resources, by

definition, because three different teams are doing

business, in a sense is not good for your business. Somebody

should do this, if indeed multiple teams needed, it should

happen separately, is simple. It should happen centrally, why

would you have every team do this, because then the processes

are, are not standardized. We no one will use one methodology and

one will use another and why let them do the thing you pay them

for, which is not Kubernetes. It's the application, let them

write the app, you do the Kubernetes for them. In comes

about from engineering. But now the platform engineering

organization is not just solving for, I just need an app

deployed, they have to solve for the other enterprise problems

that we talked about earlier. Right, because they're part of

the IT function. And they have to think in terms of risk and

compliance and security. All these other things have to be

thought about as well that perhaps the developers will not

prioritized because they want to write their application. This is

why platform engineering teams exist. And these are the

customers that we sell to and we make them successful. But here's

the thing, we have to really understand who is our customers

customer? So our customers platform engineering, who is

their customer, the developer, if there are no developers who

want to use containers and Kubernetes. Well, there's no

need for any of this stuff. Right? What is the point of

Kubernetes? If no, nobody's ever going to run things, right? So

the developer has to actually be really happy with the experience

that they get when they interact with this new platform from

vendor x. Right. Let's not bring it off into this. So it behooves

us to understand what is the developer need? Because if

they're not happy, well, end of the day, there is no sale here.

So we have to invest time in this. And we have, what do they

need? What is their pipeline of choice? What is their experience

expectation around debugging of applications? What is the

experience expectation around self service, right, some things

they want to do themselves. And sometimes they want to do a lot

of things themselves, and the company is okay with it.

Sometimes the company makes a decision, these things platform

or do these other things developers can do. And look at

turns out, we have to be in the midst of that, if we are not,

we're very, very ignoring, actually the most important

constituent here, the developer, who is not our direct customer,

and that's okay. But he's our customer, customer, she or they

are our customers customer. And we have to understand what it

takes for the platform team to make their life better. And we

spend a lot we spend inordinate amount of time, try to make that

better and better and better. So today, we be proud a lot of

capabilities to make developers really happy in our platform.

And we continue to make investments like as an example

var, spending a lot of time looking at something like

backstage that I'm sure you're sure you've seen backstages? Or

is an overnight sensation in our industry to understand what does

it take to help teams Aaron backstages service in house and

then be, you know, make it easy for them to use the Kubernetes

or other plugins that they need to backstage and then allow them

to build their own dashboards with backstage? Yeah, this is

like the two words you describe map like from engineering and

developer experience. These are the two equally weighted, you

know, core tenets of our platform. If they're not, we're

never going to be a lasting company. You have soccer balls.

Eveline Oehrlich: Right, beautiful. I have two more

questions. One is technical one is fun. So let's do the

technical first, and we'll go to the fun. You alluded a little

bit to the future of Kubernetes. So if you have to bring out that

crystal ball, what do you see in the Kubernetes future?

Haseeb Budhani: I think Kubernetes is going to be here

for a while. So so the future of applications, or any any modern

application, you know, in the near term is going to have in my

opinion, you know, some functions component like a

lambda component in the application or some

microservices, there'll be some container containers. And then

there'll be some managed services, like they'll be using

rds, and AWS or whatever, right? So this was maybe these Kafka,

these are services that sort of outside of you. And my view of

the world is that the right infrastructure management

offering, I said, infrastructure management, like Kubernetes is

going to help customers orchestrate all of these things.

You must, because you have to help truly help somebody, you

know, deploy and operate an application and then enable

developers to do this pilot. So platform and developers, we're

going to be the two incidents. Today, RAF is a Kubernetes

company. Five years from now, it should not be recognized. Fibers

mineral raw fish should be a modern application

infrastructure company. Right.

Eveline Oehrlich: Yeah, holistically, you're saying I

love that the holistic management of infrastructure,

towards agility and whatever else is necessary at the

organization's.

Haseeb Budhani: I think that's where the mark is going for

sure. And you have to you have to go there to work today.

Eveline Oehrlich: Yep. Excellent. Now, the fun

question, what do you do? Yes. What do you find? If you don't

talk to customers, or you don't think about all these very geeky

things? What do you do for fun?

Haseeb Budhani: Who has the time? We have two kids. You have

a 13 year old and a 10 year oldso there's enough to this

that they have that we sort of you know, recently as you drive

them around, right, that's your job. Right. You're the

chauffeurs are here to bear. You know, we, you know, my son was

10 the a few months ago decided he's when I was a kid, I used to

play squash. He didn't like the like badminton. As a family big

to play badminton at Stanford. I live in Menlo Park seven blocks

away from Stanford. Do that, you know, these are the kinds of

things we do right. Everything is outside of work. It's the

family. I mean, why do we do all this work? Why do why do we work

this hard? It's because of the family so you know, all the rest

of the time goes.

Eveline Oehrlich: Excellent. That sounds like me. I spend a

lot of time on the soccer fields with my two daughters. When

Yeah, lots of watching soccer and feeling sad about myself

that I'm so old and I couldn't play it anymore.

Haseeb Budhani: Soccer last time I played I'm in my mid 40s

minor. My knees will give out.

Eveline Oehrlich: I know. Now we're watching it on TV and the

last this last session or the last championship was quite

exciting. Anyway, this has been great has said thank you so much

for joining me today on humans of DevOps podcast. I really

appreciate all of your insights and I know our listeners do that

as well. Again, we've been talking to Haseeb Budhani, co

founder and CEO of Rafay Systems. Humans of DevOps

Podcast is produced by DevOps Institute. Our audio production

team includes Julia Papp and Brendan Lay. I'm the Humans of

DevOps Podcast executive producer evolutionarily, if you

would like to join us on a podcast, please contact us at

humans of DevOps podcast at DevOps institute.com. That's a

mouthful. I know. I'm Eveline Oehrlich. Talk to you soon.

Narrator: Thanks for listening to this episode of the Humans of

DevOps Podcast. Don't forget to join our global community to get

access to even more great resources like this. Until next

time, remember, you are part of something bigger than yourself.

You belong