>> Welcome to the Cloud Native Show.
So what is Cloud native?
It's APIs serverless and
containers all managed an immutable infrastructure.
I'm going to go find Brendan Burns and
find out what it really means.
[MUSIC]
>> Hi Brendan.
>> Hi, how is going?
>> Good to see you.
>> So what does Cloud native really mean?
We're using these terms serverless,
containers, and in all these words was thrown around.
But what does Cloud native mean you?
>> Yeah, I think in many respects these words that we're using,
they're just a shorthand that we can use to
discuss ideas and concepts that we understand together.
I think your definition maybe a
little bit different than my definition,
but in the general case,
it's going to be the same thing.
For me, there's
two really important characteristics for Cloud native.
One is that there's an expectation of API driven infrastructure.
So I'm going to be able to create a machine with an API call.
I can create a database and then API call.
I can do basically whatever I need to do in a programmatic way,
not in a I put a ticket into a system and
somebody got a physical machine and they came and they racked it,
it's much more like I'm only
wanted who is really necessary to create something.
>> Okay.
>> Via an API. I think the other piece of it is a notion of
elasticity and like fungibility,
meaning, if I needed a new VM,
I don't worry are there parts somewhere,
what's the what's Intel or AMD chain looking like?
I'd say and you didn't know machine and I
get a new machine and vice versa.
If I need to dispose something, I just dispose it.
So I was actually talking to somebody a while ago
about this idea of turn space.
In the datacenter, if you
are going to roll out a new infrastructure,
you have to think about like
how much physical space do I have in that datacenters a land of
the new machines alongside the old machines for
that today window or to our window,
when I'm taking on the old service and creating the new service.
>> Okay.
>> In a Cloud native world, you don't think about that.
You just like I'm going to create a new set of VMs.
I don't know where, they are there in the Cloud.
>> Right, East, West.
>> I'm not going to have to think about that.
I'm going to be able to do these elastic things.
>> Okay.
>> All right. I think this leads to these patterns
like Blue-Green Deployments.
Brendan, I don't think you could say that
Blue-Green Deployment could exist in a non-Cloud world,
because in order to be able to support that,
I have two copies of my application running at the same time.
In datacenter, I would need
two physical sets of servers to run that way, right?
>> Yeah.
>> But in a Cloud world,
I just create a new set of VMs,
they overlap for an hour,
and they throw him away at something for them on fine.
>> Yeah, right that's all you immutable.
>> So I think
Blue-Green Deployments is a great example of a Cloud,
like one of the very first I think
Cloud native patterns that happened out there.
So that's what I think are the essentials,
and then it's grown over time,
because we're just now starting to think
about how does it mean to develop
Cloud apps and scalability
and reliability and all this stuff setting.
Cloud native started with those concepts and then grew as
more and more people started to enter
the discussion and bring their own meanings for this.
[MUSIC]
>> So partly, as the CNCF have
their definition is we talk about microservices and containers,
and I look at microservices and I don't want to slight the term,
but is this really SOA redefined.
>> I think is certain amount of that and I
mean I think sometimes we always
redefine terms, I think there's differences.
>> Okay.
>> I think that there is a more of a focus on
not just the services but actually how you package and
deploy the services, and horizontal scalability.
>> Yeah.
>> So like in an SO is highly architecture,
I don't think a monolith versus micro,
I don't think I've entered into the discussion.
>> Yeah, okay.
>> I think it was really just about like,
hey let's define formally APIs for web services.
>> Right.
>> That was the first step.
So influences, I think microservices is
actually talking also about
how the systems are actually are implemented,
not just the APIs.
I may also think though that microservices and again it's one of
these terms that the meaning is very
broad and mix depending on who you are,
but I think people are also
starting to say things about like how you actually develop things.
Meaning the 68-person team size is really an ideal size.
So microservices isn't just saying,
''Hey you should expose some APIs.''
>> Yeah.
>> It's actually also saying, ''Hey,
if you want to be agile and be able
to successfully deploy your software,
your service scope should be right in the 68-person team size,
because that's the optimum in terms of development velocity.
>> Okay.
>> So you design your service is not just for the APIs,
but actually for the execution of the teams as well.
[MUSIC]
>> Are we going to get to the point
where we start calling things and
nano services and start doing something silly like that?
>> Are you sure that it's far more likely we're going
to go back in the other direction.
>> Okay.
>> If people are going to say, ''Oh my god,
I got this soup of rack,
I got 10 engineers,
and I've got 30 services like,'' that's going to be the new model.
The model that has a dirty word now,
and I think that
the next version of this will be when people are like,
''Oh my god, we have to consolidate.''
Consolidate and services there.
>> Yeah.
>> I don't know what the term OB. But I think there's going
to be a reaction,
I suspect it's going to be more of
a contraction than an expansion.
>> Well I think in this industry we've
I know we both been in the industry for a long time.
We've seen these, we put everything on the server.
We put everything on the client,
we bring everything apart, we put it back together.
I know this pattern, if you will,
of distributed applications and a ton of little parts,
and we've got our configuration in 12 different repos
and I've got seven clusters for every environment.
What is the hardest part
of where we're at right now? Is it tooling?
Is it everything's on the command line for me right now.
I'm typing you've got all [inaudible].
>> Yeah.
>> Is tooling the challenge?
>> I think tooling is an important challenge,
a really important challenge and I think
sometimes one of the challenges that we run
into in the industry is that
the people who are really excited about
the technology parts of it are
not necessarily excited about the tooling.
>> Yeah.
>> So finding those people who
deeply understand the tech but also
want to take the tech make it easy to use,
that's an important challenge,
and I think actually one of
the great strengths that we really have here at Microsoft.
>> Right.
>> I also think that one of the challenges is,
and I guess it's tooling in a way,
but it's around observability and debuggability.
We're decoupling everything for Team velocity.
>> Yeah.
>> But because of that, we're losing
the all up perfect visibility.
So we also have to build the things that help us better
understand what we're building and how to build it.
[MUSIC]
>> It's still just too hard. It's too long.
It's not that they can't do it,
it's just that I think we're still in
this assembly language phase
where typing out all these little instructions,
and there's no way that all of stuff that we use today
could exist if we were still programming
in assembly language. It would just take too long.
>> Yeah.
>> Even if you were smart enough, it would take too long.
>> But I get into situations
where I know what it takes to build a cluster.
I know what it takes a build a microservice.
I know what it takes to deploy all these things and doing it.
If it was a one man shop,
if I was a start-up,
I find this to be just completely overwhelming.
>> Yeah.
>> I think the biggest struggle for us even as engineers,
when something goes wrong,
I heard an analogy that
you'd mentioned to one of our colleagues of,
when do I reach for a book.
>> Yeah.
> I think that for me that's when I reach for a book is all great,
and then I might get some feedback where it's like,
you have to SSH into the node of your cluster to restart the VM,
and I think we
should be at a point where we don't have to think about that.
>> Yeah.
>> I mean, I think we're really pushing.
I mean, I'm trying to push very hard,
and I think Azure as a whole is trying to push
hard into that world.
I mean, I do it like,
what happens below the instruction set in the processor.
I've a friend from college who's
worked on processor microcode for 20 years.
The amount of stuff that happens
below that machine instruction is actually amazing,
but we never think about it.
>> Sure.
>> I mean, everyone's starting to think about it
when there's a bug, but it's very rare.
>> Right.
>> So I think the complexity is always going to be there.
The key is defining those abstraction layers so
that you can mostly ignore
it and we're not quite there with Cloud.
We haven't fully hidden the VM.
I don't think VMs are ever going to go away,
but we have to get to a place where they're really fully hidden
for say 99.99 percent of the population.
>> Right.
>> Right now, we're at a world where maybe that's
like 50 percent of the population,
and I think we have to keep pushing towards that.
I think we are pushing towards that with
Serverless containers and things
like that, functions as a service,.
>> Yeah.
>> But we're not done. Because the places where we've
done it are too narrow, too vertically defined.
So people keep having to go to raw infrastructure because they
need some library or they need some native code,
or whatever it is that the platform doesn't support they go
to a VM and now they're in
that world where they have to SSH together.
>> Do you thinking that they jumped down to
that VM because it's still what I know.
They go, well, I want to work in the Serverless.
I think that's what I should be doing
because that's what the industry is telling me.
But we have both I'm
sure talked to many enterprises where they're like, wait a minute,
I've got 12 VMs that are still
sitting in my server closet and that's what I know,
it's what I'm comfortable with.
How do I get to this next thing?
Maybe, I encounter that unless.
I think it's more people
have had their fingers burned too many times.
>> Right, okay.
>> Right they've gotten six months into
this new platform and they've loved it,
and then there was some NPM package that they wanted to pull in,
and that NPM package use some piece of native C code
and that didn't work on Functions as
a Service because of the Sandbox that they were using.
>> Okay.
>> Right. I think you do that two,
three times and you just get your fingers burned and you're like,
I'm not going to bother with these platforms.
>> Right.
>> I'm going to go the VM. Yeah, I know it'll be
hard but I know that I'm not going to get stuck.
So I think that the concern about people getting
stuck is bigger than the like this is what I know.
>> Right.
>> I do think it's really important. I mean,
I also think though that
if you want to introduce new ideas and new tech,
you can't make someone feel less powerful than they are currently.
So if you say, "Hey yeah great," learn this thing can take
you six months to get back to where you are
right now with VMs, and everyone.
>> Sure.
>> That person's going to stick with advanced for rest of
their lives. It's an important aspect.
I think we do a pretty good job with that in many cases.
Containers did a good job with
that. But it's an important consideration.
>> I think we'll get to a stability factor
right now with container I think,
if I go back I don't know maybe two,
three years ago, that containers was like that's still felt new.
>> Yeah.
>> It was are we'll doing Swarm,
or Mesos, or Kubernetes, what was the thing?
I think we have some clear winners there.
>> Yeah.
>> I think the tooling is getting better.
A lot of the IDE companies
have really good tooling and stories there.
Debugging is certainly better.
>> Yeah.
>> I think that's leveling off.
But now, it's like, what's the next level of
uncomfortableness for us as
developer engineers and that's where we're having to get to next.
>> Yeah.
>> Is where we're at now with Kubernetes and what we're
doing here at Microsoft
is that our end game or are we marching somewhere else?
>> Well, I mean I think it's two pieces.
I think when you talk about the tooling,
tooling requires consolidation.
So when there's four different orchestrator APIs,
it's really hard for you to have a great tooling.
>> Yeah.
>> Because the tools people don't know what to target.
I think there's still places, Service Mesh is a great example.
So one of the reasons why Microsoft and
a bunch of partners came out with the Service Mesh interface is
because it's very hard for the tools people to build
tools for service meshes if
there's three or four different implementations.
So I think all of these layers orchestrator,
now we have some consolidation.
>> Yeah.
>> But the next layers up to debugging, monitoring,
we're starting to see some consolidation
at least around like a Prometheus Interface for scraping.
So we can start in Service Mesh.
Hopefully, we'll see some consolidation
that enables better tooling,
that enables most people to just use it and not
be thinking about what's the implementation.
>> Sure.
>> Similarly with Serverless,
I think what we're really trying to do is to, hey,
how great we've identified that container.
Let's see if we can't make container,
the process for the Cloud.
Let's get rid of the VM.
Let's just say, if you give me a container,
you give me its requirements, we'll to run it for you.
You won't have to worry about where it
runs and that's the abstraction layer.
The container becomes the abstraction layer for
literally how you package
your executable. I'm hopeful that we'll get there.
We're not there yet but, we're hopeful
and in all of these things it's in
partnership because we can't just dictate.
It has to be something that the entire,
or at least the majority of the world decides to go and do.
Because companies are going to run in multiple Clouds.
Companies are going to run in their data center.
>> Sure.
>> We've got to embrace that hybrid world.
>> Containers is becoming
almost the factor standard of
how we at least package and deploy our apps,
at least the small apps, and small is an opinion,
I don't know what's small is.
Obviously, we got the Windows.
Windows is getting into that range.
But also when we talk about distributed apps,
and when I think about Cloud native in
my definition is it's really just distributed apps.
>> Yeah.
>> Because we can't just think about the Cloud.
Because now I can run a container on a drone.
I can can run it on Raspberry Pi
and that's related to distributed app.
>> Yeah.
>> So I'll ask you is like,
I know Cloud is not the end game,
but is there another place that you
think we'll end up other than Cloud?
I think IoT might be that next place.
>> Yeah. I mean, I think this is one of
those reasons why it's something like containers,
it's a very broad term.
Because there's the packaging parts of it,
and there's the deployment parts of it,
and there's the orchestration parts of it.
I'm not sure we're ever going to run Kubernetes on a drone.
>> Right, don't challenge anybody.
>> No seriously. I was just
actually talking to some people who are
talking about putting in cars,
I should never say never right.
>> Sure.
>> But we are going to talk about how do I
make some of the ideas around staged deployment.
Maybe not to wonder, or maybe I have a fleet of drones.
>> Sure.
>> The idea of a rolling deployment of a canary deployment.
Those concepts that are in Kubernetes make
a ton of sense across that drone fleet,
and I probably don't want to rebuild it.
So when the stuff we're seeing IoT do
with with Kubernetes for deployment
shows that you can take some of
the ideas that are in these orchestrators that
were built for distributed systems and actually take them to,
it is distributed but it's
a different distributed system if
you're rolling out software across a fleet of drones.
So I do think that's true.
I do think that one of the other themes that I see
a lot is and this is sort of microservices.
We built these things Kubernetes,
or ARM, or many of these systems for one purpose.
Now we're starting to see people say,
"Hey, could you break that piece out?"
>> Yeah.
>> I just want to have access to our back.
I just want to have access to
the extensibility of the communities API server.
I have some new API objects.
I don't even care about Kubernetes maybe,
but I want to create an API.
This seems like a really easy way for me to create an API.
Can I just use that part?
>> Yeah.
>> That's been really interesting to see as well.
>> Awesome. If somebody wanted to get started,
they're no understanding where we're at right now.
What's the advice that you would give to a start-up,
or somebody that was maybe a fresh engineer coming in?
Where would you lead them?
>> One of the first thing I always talked to everybody about is,
what is your pain at some level?
What is the thing that is holding you back?
Because we shouldn't just adopt tech,
because we're talking about it,
or because it's there,
it's in some magazine or some website or whatever.
You should adopt tech because you believe
that it's going to make your startup move faster,
or it's going to make your customers
happier because your products more reliable.
Your engineer's happier, your on call
happier because it automatically restarts stuff.
So I think that if you have
a clear understanding of what's your current pain.,
then you can take a look at
a technology like containers, and say, "Hey,
yeah we have a real pain point with our developers,
none of the code works on everybody's laptop,
because everybody installs different libraries."
>> Yeah.
>> This seems like run it on my laptop,
running in the Cloud isn't the same.
It doesn't work. Containers will help with that.
>> Sure.
>> It's a great example of some pain that they can help with.
Before you even get into deployment.
Before you even get into orchestration.
But you could also say, "Hey,
we don't know how to reliably roll-out software,
and we don't even trust our developers to reliably roll software.
We want to use a fully integrated CICD system.
We want them to push into Git whole bunch of tests to run.
Deployment is happens via automation."
Now Kubernetes is a great tool for
that as well as the CICD pipeline.
So I think identifying your pain first and then figuring out which
of the collection of technologies helps address that
pain is the best way to do it.
Honestly, Azure has a great set of
technologies from containers to container registry,
to the container service,
to container instances to
Azure DevOps that that can really
help address any of those pain points.
>> Awesome. I appreciate you taking the time.
>> Yeah, no worries.
>> Letting us know what you think Cloud native is.
>> Yes, everyone should form their own opinion though.
>> Form their own opinion. So that
was what is Cloud native
on the Cloud-Native show with Brendan Burns.
Be sure to check out aka.ms/cloudnativeshow
for future episodes, and thank you for joining us.
[MUSIC].
>> Thanks for watching the Cloud Native Show.
Be sure to subscribe,
watch for future episode,
and especially our streaming shows on Twitch where we build
apps based on the conversations
had right here. We'll see you next time.