[MUSIC].
>> Hello and welcome back. My name is Seth Juarez.
We're going to be talking all about what's special
about Kubernetes on Azure.
I have Brendan Burns and Gabe Monroy,
sorry it came out super fast.
Why don't you introduce yourselves?
Tell us who you are and what you do. [inaudible]
>> Sure. I'm Brendan Burns.
I work for Azure in a variety of
different services including the Azure Kubernetes Service.
I also help create the Kubernetes project,
and help still sort of run the governance of that,
and the CNCF as well.
So a lot of open source. A lot of Cloud Native.
>> Fantastic.
>> That's about it.
>> Gabe.
>> Yeah, I'm Gabe. I lead the product side
of the Azure Container compute team.
So AKS, ACI, OpenShift service.
I also sit on the board of the CNCF,
where I do a lot of upstream,
foundation, open source work.
>> Awesome. So I'll start out with the easy maybe hard question.
My producer back there, she's like,
"Seth, we talk about Kubernetes all the time.
Can you just give me the 10,000 foot?
I want to talk to my grandparents about it. What is it?"
>> Sure. One of the ways I explain it is,
at this point, every computer out there has multiple cores.
When you double-click on an application to launch it,
it's not like the computer pops up a dialog and says,
"Which core would you like to run this program on?"
It it just finds one and runs it for you.
You have an application you want to run,
it's got resources to run
those applications, takes care of it for you.
So Kubernetes is the same sort of thing,
but for distributed systems across a large number of machines.
So you might have 10 or a hundred machines.
You have an application you want to run,
maybe you need 10 replicas of a front end or you need middleware.
You can declaratively say to Kubernetes,
"Hey, I want there to be 10 replicas
of this thing. Take care of it."
It'll find the right machine to put it on. It'll run it.
It'll create an Azure load balancer if it needs to.
It will mount disks if It needs to.
It just takes care of you
declaring that state of the world that you want to see,
and it'll take our the execution for
you as well as the healing of it.
So one of the other stories I tell that explain it
and you said earlier distributed systems are hard.
When I was a kid, I spent probably
six months buildings balsa model airplane remote control thing.
I took it out of the park,
ready to go fire up the engine,
15 seconds up into the air,
down into the concrete explodes.
My kids iPad and a drone,
there flying it around the house with
an iPad no skills. That's Kubernetes.
It is an online system that is like
the intelligence that keeps your application running successfully.
It makes it easier for you to build your application.
So that's the other piece of it.
It's like we use automation
in all of these places to make our lives
easier. Kubernetes is a system to
make distributed systems easier to run.
>> That's awesome. So I'm going to ask another question that may
seem counter-intuitive to everyone watching,
but I think it's important to ask this.
When should you not use Kubernetes?
Because I feel like everyone is like Kubernetes is
all the things and I feel like,
is that something that you would suggest?
>> Yeah. No, I mean, I think it's really
important. Let me cover different things there.
One is, if you're happy with the way you're
building and deploying software to the Cloud, like don't change.
It's like don't do resume-driven development.
>> That's a good point. Resume auto-test.
>> You don't want do resume-driven development.
So if you're really happy with it,
stick with whatever it is that's working for you
whether it's a high-level service like app services,
or functions, or it's low low-level VMs.
If you're happy with your ability to deploy software,
your reliability, productivity developers, stick with it.
I think Kubernetes has been built to solve some pain,
that we saw people having,
but if you don't have any of that pain then there's no point.
>> So could you specify what the pain might be?
>> Yes. So one of the things I'd point out is,
Kubernetes has really good set of features
for doing microservice based development.
Oftentimes, when I talk to customers and they're like,
"Yeah, we're doing microservices."
I look a little closer at the workloads,
I'm like actually that's two websites.
So there's this tendency to want to like
make a system more complicated than it needs to be,
and we've got great products like Azure Web Apps and
the App Services to run those simple workloads,
and I try to advise customers to use
the simplest possible product to get the job done.
>> Right.
>> Oftentimes that's not Kubernetes.
>> Yeah for sure.
>> So the situation that arises where you're using
the simple services that get the job done
when all of a sudden they stopped getting the job done.
Can you give me this smells for when the jobs stops getting done?
That might be a good use case for Kubernetes.
>> Yeah. I mean, I think there's a couple of different.
There's a lot of different axes on which that can happen.
So I mean, I think you can look at something like
the CAIDA announcement the Kubernetes is event-driven,
auto-scaling and that's what we did today which enables you to run
Azure functions code on top of a Kubernetes' cluster.
You might need to run that function suddenly on-prem.
You might need to run that function in
an edge situation on a Raspberry Pi cluster,
and Azure obviously may
not be able to go to a 4-node Raspberry Pi cluster,
but you can use Kubernetes
there to orchestrate your Azure function.
So you can take the same code and run it in both places.
So we now leave the place where Azure functions fell down if
you will is in that tiny little on-prem environment.
Sometimes it's around flexibility.
So it's around the fact that a PaaS platform may say like,
"Hey, you can't write to disk."
That's not something that we let you do.
You need to know and I actually I need
that ability and in those worlds.
I think one of the things we're seeing is more and more people
are having an ejection path,
so that you can take the code that was
in a more Platform as a Service and turn it into a container,
and then run it in something like
Kubernetes and more and more interrupt too.
So App Service, you can put it in a VNet,
Kubernetes can be in the same VNet.
Maybe you can make the two services talk to each other.
>> I see.
>> Yeah. One other example I point out is,
when you have services that needs a call other services.
That example I showed before
about two websites doing static serving,
there's not a lot of inner communication.
But when you actually have services calling
other services inside of a compute platform,
that's where some of the features around Kubernetes is like
service discovery and DNS,
and the networking model
inside of Kubernetes is really start to make it
easier to construct those more complex environments.
>> Yeah, and I think the other piece that I would say
is the ecosystem that we see I've seen grown up,
mean that it's become the lingua franca for deploying stuff.
>> Right.
>> So it's one thing if you're deploying your own software,
but let's say you want to use software that
another open source project is creating or a startup is creating.
The way they are going to package and that
is as a helm chart that deploys on to Kubernetes,
because that way their software has the broadest reach on Azure,
you can run an on-prem, you can run it on other Clouds.
So sometimes it's not necessarily about
the specifics of deploying the software,
it's actually about the fact that this platform will go anywhere.
>> So the next question I have and I've heard a lot,
with distributed systems it's always
hard with two things; storage and networking.
>> Yeah.
>> How does Kubernetes help with that?
>> Well, I think networking
is the obvious one where it helps a lot,
because we built in a lot of
integration with load balancing and Cloud load balancers,
and routing between applications.
Every application in the cluster has its own IP address.
So you're not doing weird port
forwarding stuff and stuff like that.
So I think that's a place where we do a lot of help.
Storage is harder, I mean there is a bunch of modeling of storage,
but even in Kubernetes,
I think we would suggest if you can use a Managed Storage Service,
if you can use the Cosmos DB or an Azure SQL,
that's a great choice, right?
Even if you can't, if you're on-prem,
get a team to focus on running storage for you.
Get a team to focused on running a database
as a service for your company or whatever.
There's a lot of work actually people have done,
HashiCorp and Consul have done a bunch
of work to make it easy for you to maybe
take a database running in a on-prem or even just a VM,
and integrate it with the Kubernetes cluster.
>> I see. Which brings us to the next question, right,
and I think this isn't natural,
but what makes Kubernetes special on Azure?
I know there was a lot of innovations
that happened like virtual cubelets,
for example, that happened
because of the stuff that we're working on.
Tell me how Azure is making Kubernetes special.
>> Why I think one of the most interesting things is,
Brendan got up on stage at QCon in Shanghai,
the last QCon event, and talked about
how the future of Kubernetes is serverless,
and painted the picture of this world
where you can have a Kubernetes portable API,
where the containers we're running on a serverless backend,
build per second, hypervisor isolated,
no virtual machines to manage.
But still through that same Kubernetes API,
that the community and the ecosystem is backing up now,
today and actually at Build, we've now at G8,
its support for what we call a Cast Virtual Nodes,
which is the productization of this feature.
So really excited, there are a lot of
folks in retail, for example,
take a look at the speed with which you can
do auto-scaling on top of something like virtual notes.
If you think about it, when you have a load event,
having to spin up and manage capacity at the VM layer
dynamically while your customers are waiting for page loads,
slow page loads to become faster.
That's a problem, right? Being able to burst
directly to the Azure compute fabric,
which is what Azure Container instances
offers is really compelling for a lot of use cases.
>> So let me see if I understand this feature
because I've just hearing those now.
I know the announcement was yesterday, was it?
>> Yeah.
>> Basically, what you're doing is you're having
the control plane be something that you start up in Azure,
but then everything else just happens, am I getting this right?
>> Well, I mean it's the containers themselves are
running on the Azure Fabric
instead of running on virtual machines.
>> Got it.
>> Right. So you don't see a virtual machine anywhere.
You just see your container running,
and it's good for this burst stuff.
It's also actually honestly good for a bunch of enterprises
we talked to because they no longer
have to worry about the operating system
as a layer that they have to manage and secure.
We are securing the operating system for them.
They just worry about the application
that's going inside of the container.
So we can provide
regulatory certification and other kinds of security,
they're patching and upgrades, and all that stuff.
>> That's nice for me as a developer because,
like if I built my container, I just, here.
>> Yeah. As a developer,
if you build your container and launch it, and there's no VM,
central IT isn't going to come along and be like,
what's up with that VM, and why didn't you
because there is no VM for them to introspect.
So it's easier for everybody.
>> When you do that,
though is it's still like you
slap this virtual private environment as well.
>> Yes, so the ACI, the Azure Container Instances,
they can run on the public Internet,
but they can also run in a VNET,
in your private network.
>> I see.
>> Yeah. So it's pretty cool.
>> Interesting.
>> I wanted to point out another thing that
we actually also launched here at Build,
which is support for policy in AKS,
and this is actually another collaboration with
an open source project to develop
the engine for policy enforcement from Kubernetes.
But then we've taken it and made it a part of the AKS product.
So just like you can do Azure policy for Azure,
you can use the Kubernetes policy to make rules,
say for example, whenever you create
a load balancer over the public IP address,
you need to also attach a ticket for your security review.
You need to make sure that,
if you're going to put something on the public Internet,
the Security Teams taken a look and
made sure you're doing the right things, right?
If you want to make sure that you only
pull from certain registry it's from.
Obviously, we are now, maybe I've always
known that running binaries from the Internet was a bad idea.
>> Right.
>> You want to make sure your cluster only
pulls from your private Azure Container Registry.
Policy is the way that you can enforce that,
not just on a single cluster,
but actually for an entire subscription or an entire tenant.
>> That's the second new part of the control plane then.
>> It's in the middle, where you can think,
it's called Gatekeeper actually,
which describes exactly what it does.
So you as the developer come and say,
I want you to create this and gatekeeper is
the auditor who looks at
that API automatically obviously, not a person.
Looks at that API introspects it,
applies a bunch of rules.
If it passes, let's it in.
If it doesn't pass, rejects it to you, and says, "Hey,
you need to have put a tag on it that was
your contact e-mail address or whatever else," right?
>> I don't want to hone in on something that Brendan said which
was that in order to solve this problem,
we decided that it was important that we did it
in the open-source community first, right?
So we have part of our team just go try and figure out how to
solve policy concerns for Kubernetes anywhere.
That project turned into a project called
gatekeeper that's now in the CNCF.
Then we went and build products on that,
and we've got the great fancy portal experience,
and great work with the Azure Policy Team.
I'm really excited to see that model of development,
where we go upstream first,
get the buy-in from the community,
and then bring that enterprise friendliness
to Microsoft and Azure customer.
>> Yeah. I think it's important to point out and get
contributions from the community too,
like the policy language that you use is this language called
ReGo that was developed by an open-source startup,
and we get to take advantage of all the thought that went into
designing that language for specifying these policies.
So I think it's there's a give and take relationship,
where they had a language, we figured
out how to marry it up with Kubernetes,
and then we turned it into a product in AKS.
That is the ideal way you work with open-source in my mind.
>> That's cool. So we have about a minute left.
What? If you have customers out, what do you want to tell them?
What's the best thing to do,
if they want to get started with
Kubernetes on Azure, watch the video.
>> We have a learning path that we just published,
and the learning path is
very structured set of steps from just one of the basics,
Brendan did a lot of Lightboard exercises,
recorded videos to help that,
and also lot of guided trainings,
and really can get you up and running and
familiar with Kubernetes' set of structured learning modules.
I'm definitely recommend checking that out.
I believe it's aka.ms/AKSlearningpaths.
>> Yeah.
>> Look at the links absolutely for people.
>> It's hard to click on a video?
>> Yeah.
>> But if we don't feel it.
>> Yeah, but I would also say there's
a lot of really great community resources out there too,
from local meetups to the Kubernetes.io.
There's a lot of great resources out there for
you as well as the books that people have written.
>> Awesome.
>> Myself included.
>> All right. Well, thank you so much for your time.
Thanks so much for watching.
We're here at the Microsoft Build live
stage at Microsoft Build 2019.
Thank you for watching, and we'll see you after the break.
[MUSIC]