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