Hello, everyone. It's my pleasure to introduce
to you Doctor Yousef Khalidi. Yousef, as I
call him graduated from Georgia Tech in
1989. And and then after he graduated from
Georgia Tech with a PhD in computer science, and I'm very proud to say that he
was my first PhD student. He went to work for Sun Microsystems where he was
developing multiprocessor operating systems and then at
some point of time Microsoft found him.
And he moved to Microsoft and while he was at Sun he was the CTO
of the Solaris MC product. And some of which we saw in our own discussion of
structure of operating systems early on. And and then he moved to Microsoft and
in Microsoft he developed the current he developed the cloud platform which is
called the Microsoft Azure cloud platform, and
that's the one that he'd been leading.
He was a distinguished engineer at Sun Microsystems and then, now he is
a distinguished engineer at Microsoft. And so, it's a great pleasure to have you
>> Thank you Kishore for having me, and I just want
to say that Kishore was a great professor. But a tough professor.
>> [LAUGH] And I want him to tell, tell that to my students even now. [LAUGH]
>> I'm sorry, but that's the truth.
>> So Yousef, it's a pleasure always to meet you and, and see
you. And, and, and the thing that is really exciting for me is
being able to bring you back to this interview because this is, interview's
going to be part of the course
that I'm developing in advanced operating systems,
and and, and you contributed a lot to that. And
so what I want to do is first sort of rewind.
>> 'Kay.
>> Back to the the mid to late 80s. When you were a PhD student and
and you developed, as part of your dissertation
work, the cloud's distributed operating system. And then
fast forward to 2013. You're heading the cloud Azure platform at
Microsoft. Talk to us about your journey and, and if you
can, connect the dots from what you did back then, to what you're doing now.
>> You know, in many way, things have changed. In many other
ways things have not changed at all. So the fundamentals are the same.
The structure of an OS, the way you
layer the system, the basic concepts of security, isolation.
All these high separation policy of mechanisms, simplicity of
design, recovery from failures and the like, all these
concepts still apply. But at the same time, things
have changed quite a bit. Give you an example.
The product you mentioned that you and I worked
on, clouds and, for 85, 86, to 89, it
was a distributed system, true, but we had exactly
three machines. Growing, it grew to four or five machines
later on. That was it. I mean we had
to manage three, four, five machines. Lots of algorithms that
are very similar today but the SK wasn't the
same. Fast forward to today. I can't even tell you
how many machines, how many VMs run in a
public lot. Millions, millions of VMs run all over the
place. So the scale have been going up by orders
and orders of magnitude. So the fundamentals are the same,
but the problem at hand has changed, and of course, the physics and the
how the industry moved. before, a given machine was what? A vax 11 750.
>> Mm-hm.
>> This is an old machine now of course.
>> Mm-hm.
>> Well, I mean, there many, many students
may not even know about vax 11 750.
>> You find them in the, in the history museum now. It used to be as big as a
>> And the company doesn't exist. That we.
>> Company's gone. The machine is gone but it was the best machine
there was for awhile. As big as this. And probably my
watch or my phone has order of magnitude more power than
this. So, you know, again this is just how the industry
moved. So again, the, the concepts are the same, the fundamentals
are the same. Some of the papers that we now teach
and learn from, are the same ones that were written back
then, even before. But their application now has been applied to
a much, much bigger scale. So, so my short answer here.
And this scale, of course, you see everywhere. All
of us have some devices, some smart phone, or some
machine, or a PC and the like. And all these
services out there are using the the, the, the connectivity,
the computing, the power of the collective if you
will. That's new as well. Before we used to apply
all these concepts in the small. To a given machine.
To a server. Now we apply them to a collective.
>> So, is it fair to say
that some of the techniques that were invented in the 80s,
and the 90s are still applicable today? It is just that the scale has gone up.
>> Very much so. I mean, the fundamentals of
distributed computing, replication algorithms,
consistence, leader election, synchronization, all
these are of course the bread and butter of what we do. It's a given. But at the
same time since things have changed, when we
scale changes by one, two, three orders of
magnitude some other things break. So we have
to think in terms of maybe loose consistency instead
of very absolute consistency. You would need to
think of handling failures in a different way.
Optimized for mean time to recovery versus making
it perfect the first time through. So, as you
know, in computer science, when change by this much, some
things have to move, but the fundamentals are the same.
>> That's a very comforting piece of news for
the students because some of the papers that we
read are from the 90s and the 80s and
the classic papers and I tell them why they are.
>> The classic even goes before that as you know.
>> Right. Exactly.
>> It, somebody said that was, wasn't me that nothing has
been invented in our field for the last 20 years or so.
>> Mm-hm.
>> And, again, they're partially right.
>> Mm-hm.
>> The fundamentals are the same.
>> Mm-hm.
>> So you have to start with the basics.
>> Mm-hm.
>> And you build on top of them.
>> Right, right. So, I, I wanted to ask specifically with respect to
Microsoft Azure it uses the platform as a service model for the cloud.
Now discuss why that model is the one that you chose.
And what are the pros and cons of
that, that model, vis-a-vis other kinds of models?
>> Sure. So, I just want to tell you, in Azure we
have the whole spectrum now. Platform as a service, infrastructure as a service,
all combined to build, basically, services,
so-called software as a service. First I
want to start by telling you I'm not a fan of these terms.
>> Okay.
>> They are not technical at all. The industry at
times wants to put things into separate segments. Separate segments.
>> Mm-hm.
>> But by, you know what the definition
of them are. Platform services you typically have
APIs and other services out of which you
compose other services. Whereas infrastructure service is typically just
comp, built VMs, virtual machines, and instantiate them.
Real life, of course, is more complex than that.
It's a combination. And Azure, like other systems
support both. The long-term direct, direction, though, many applications
are not written from scratch anymore. You compose existing
components. There was a time, before I was in
this field, you know? People used to write machine
language, then assembly language. You wrote things like maybe in
C and so forth. And you started with a
program out of scratch from nothing. Now fast forward to
today. Everything's composed. So you may have some storage
services, some database services, some caching services, some identity services.
And you compose your application out of that.
>> Mm-hm.
>> And that's really the way to go from now on.
>> Right.
>> And you compose things out those compositions.
>> Mm-hm.
>> To restful APIs and the like.
>> Mm-hm.
>> So in this spectrum I, that's why I am not a very fan of
those terms. You know, yes they have a definition. Yes, you can look at them and
apply them. But what's more interesting is
to have a very large, scalable, reliable platform
with rich services that allows you to run, if you want to, VMs, all the way
to compose apps at a very high level.
>> So in, in that sense what I'm hearing you
say is that these distinctions are, are not that important.
>> Architecturally, scientifically, whatever.
>> There is no.
>> I don't think so.
>> There is more of a marketing.
>> Marketing or, or a way to simplify concepts.
>> Okay.
>> Remember cloud computing is still early on. And
we feel early sometimes people have to define terms
just to be able to reason about the concepts. To me speaking
for myself I really think it's far more important to look at the
actual services APIs have and what can you do with them to
make your life easier to develop applications and to run reliably at scale.
>> Now students get to know about these giant scale
services and how cloud computing is enabling the giant scale services.
What do you see as the future evolution of
system structure for providing distributed services? Is it going
to be the same, more of the same, or
is it going to be drastically different in the future?
>> To be honest if I knew exactly I'd be probably
lying. We, nobody knows, exactly. But we can look at the trend.
>> Mm-hm.
>> And the trend, as I alluded to, shifted from
the old days where we used to have three machines
in our data center.
>> Mm-hm.
>> You and I used to have three machines.
>> Yeah.
>> We used to have mainframes bigger than this room we're in at the
moment. Is shifting to more of a scale out model. Where it's built out
of smaller servers, off the shelf components,
and many, many of them. That's dictating
a trend in application structure and format
that's different than before. You are no longer
looking at big SAP boxes and an app that optimizes a
big SAP box. Looking at an application that may have multiple
cores in a box but has to live across boxes, across
servers, and has to deal with failures, and has to deal with
the network, as as a, as a reality. Latency is there and so forth. So the shift
will be more and more towards scale out, horizontal scaling, versus scale up.
And more trend towards simplicity where failures
will happen and you have to optimize for
recovery from failures and to make forward progress.
Said differently all our apps today are what?
You know, back end services to your phone, to your
PC, to your laptop, to your pad, et cetera. They
expect the network to be always there. They expect the
servers to be always there. Of course, this is not
true, but you have to design it as it, to
make sure it can handle failures, for it to appear
to be always there. So this disconnected operation of the
network is important. Caching and, and, the, and the host stack
is important. And when a component fails,
you need to have to state somewhere else.
>> Mm-hm.
>> The truth has to be in the network, not anywhere else.
>> Mm-hm. Mm-hm.
>> So those, I think, trends will only accelerate.
>> Mm-hm. Mm-hm. Mm-hm.
>> Exactly where they're going to be in ten years from now, I'm not sure.
>> Mm-hm.
>> Five years, probably like I described.
>> Mm-hm. Now, so I think you started touching on this already in your
answer. So what do you see changing in the data centers for catering to these
kinds of future evolution of distributed services?
>> Uh,a number of things are changing in a data center. First given the
accounts of scale you have by having the horizontal model, you have a, an
increasing concentration of computing power in a, effectively in a flat network.
>> So, when you said horizontal model.
>> Yes.
>> Perhaps you may want to elaborate it for the students.
>> Okay, so on a horizontal model if you want extra
capacity you end up adding more servers to a
network. So, you may start with one server with maybe
one CPU with multiple cores and a fixed amount
of memory. If you want more capacity, like extra memory
or extra cores, you don't open up the box
and add to it. There's nothing to add to it,
the box is closed. You add more boxes. I'm
being figurative here, but you know what I mean. So,
this is as, to contrast how it used to be
in the past where you bought one big mainframe, one big
chassis, and you added more stuff inside it to make it
bigger. So, you have to know networks. You have to know
distributed systems. It's a fact of life, basically. So the trend
is basically to go that way. If, if you go to
a modern data center now, a truly modern one, you're going
to find a network which is fairly flat network where it,
it caters both to south, east traffic, and west,
east, west traffic. Which in different words, it can
do well to take requests in and send them
back out, or to do traffic within the network.
>> Meaning computations that are going inside.
>> Computation and data replication.
>> Okay.
>> So that's a trend that's definitely happening, so,
scale out model of many, many servers. Typically commodity service,
which is fairly small. They increase of course
with Moore's law, but still are fairly small. A
network which is fairly flat, so you you
can do a lot of traffic between them. And
applications that are basically laid over that network.
And with the app itself is mostly, mostly structured
in way it can withstand any piece going
down. And the state, replicated in different data tiers.