[MUSIC]
>> Friends, it is live television.
We're having all kinds of fun doing things live here at
Build 2019 at the Washington Convention Center.
I've got Ralph Squillace. How are you, sir?
>> I am doing well.
The voice is barely there, but it's still there.
>> But you've got a beautiful head of hair,
so you've got that going for you.
>> I feel good.
>> Yeah, fantastic. So you do
all kinds of great things in the Cloud with AKS,
with the Azure Kubernetes Service.
>> Sure.
>> What does Kubernetes mean?
No one ever asked that question.
>> So Kubernetes is actually ancient Greek
for typically pilot or captain,
but it is also the word,
the root stem for governor, believe it or not.
So it's metaphorically the leader or
the guider and typically in maritime thing.
>> Okay. So I'm always hearing
this maritime or these nautical terms,
and I hear about things like Helm.
This is all part of the Kubernetes, the ship narrative.
>> It's the theme. So Helm is
what we're going to talk about a little bit today really quickly.
It's the default package manager
for most of the Kubernetes workloads.
So it's one of those tools that if you're already using,
you want to know about Helm 3.
If you're not using it yet or maybe you're in Windows and Windows
containers are coming into Kubernetes with 1.14,
then maybe you want to learn about Helm
a little bit more because it's going to be your operations tool.
>> There is an interesting keyword there,
though you said the default.
The default, does that mean
someone decided that Helm is the default?
>> No, no. It's a community open source ecosystem,
so there are lots of tools that you can use to
do your operations or deployment and management.
It just turns out that Helm started very early
as a way of compressing and making more efficient,
the distributed configuration for a large set of microservices.
So that you can just deploy them with
a one-line install instead of having to deploy
a number of things and
manually uses CLI to do your operations work.
But there's an extra bonus,
and that is Helm also allows you to share your describe Charts.
They're called Charts and other nautical theme.
Charts have repositories and so like Docker Hub or GitHub,
you can actually share your repository is publicly
or privately for corporate use
or government use or any private environment.
>> So when I have a chart and I've got it ready,
do I have a dev test and a production chart?
Or do I have a chart that has
different angles or different dimensions.
>> As with good software tools,
the answer is absolutely.
That's kind of unfortunate. Everybody wants
like this is the way to work it.
You can create charts where you flick an operational string.
You can set a custom flag when you
deploy into a developer environment,
and it uses certain configurations,
that are template it in through
your chart that will result in that.
Other people choose to keep the charts
completely separate so that they can do
operational work in different environments in different pipelines
without having to deal with the production chart,
for example, which might have
a lot more specific configuration to it.
So it's really flexible and works both ways.
>> Then if I have decided that Helm is the way I'm doing
things at my company and I've been doing a lot of work on-prem,
and I have moved over to AKS.
I'm going to find AKS to be very
comfortable because I already know how to use Helm.
>> Yes, because it's Kubernetes native operations tool.
So anywhere you have a Kubernetes cluster works.
So if you're a developer, you can use Helm and Kubernetes on
your laptop with MiniKube
or Docker for Windows or whatever it might be.
There's Windows binaries, for example,
for Helm as well as Linux binaries and Mac binaries.
So you can use it for many operating system,
and you can use it against Windows containers
in your cluster or Linux containers in your cluster.
It's extremely flexible.
So anywhere there's Kubernetes, there's Helm.
>> That's pretty exciting because I've
actually been working on my Windows machine,
and I found out that I can go into Docker for Windows,
and just click a checkbox,
it enables Kubernetes, fired up a little server here.
I've got a Raspberry Pi cluster
which is a little stack of Kubernetes.
Like six pies and a stack.
>> Envy.
>> It's very nice. It's the same one.
It's the same experiences, the same dashboard.
It's the same great experience. Then when I moved to AKS
because I had done that work locally, it felt very comfortable.
>> It should, and that's the way that
the community works when they come to
a consensus about tooling
or about the distributed container kernel,
which turns out to be the default choice is Kubernetes.
That means, you can not only do
your own work comfortably from place to place,
but also your colleagues and the way that
the knowledge base that we draw from in
the future going forward is going to have
more and more that default knowledge no matter where you are,
whether you're running in Windows,
with Windows containers or some other.
>> When you said consensus,
that idea of consensus really interesting
because it's the community deciding.
But then Microsoft still is running its service.
So how do you balance that?
>> That is a great question.
AKS service is fascinating,
especially in the history of Azure,
because the original service code Kubernetes,
the source code base is upstream.
We don't create it.
We contribute to it.
Then we make sure that
the implementation that runs in the service is the best that it
can possibly be and makes use of
the other Azure services that make
your experience as any other service in Azure;
rich, important, efficient, and cost-effective.
So you don't necessarily need to do everything in Kubernetes.
Frequently, that won't be the case.
For example, Cosmos DB gives you features
that Kubernetes cluster cannot do.
But you might want to use,
do execution in Kubernetes and AKS,
have us manage the cluster for you.
You only deal with the applications,
and one of your databases might be a service in Cosmos DB.
>> It's really interesting. The idea that you said it's upstream,
and this is important because the world
of open source as well as the world of
running a service that makes
money in a business in a giant company,
it's a business of
coopetition because we have
other people that are running Kubernetes services,
and they want to make theirs the best they can,
and then we all basically use
a nautical term like the water level rises all boats.
>> That's right, upstream really is upstream.
That's where the source comes from.
In that metaphor, everybody can participate.
The network effect of growing skill sets,
the collection of charts for Helm,
for example or Kubernetes manifests,
that have already been written may
actually add value to everybody.
Then the special value that
a Cloud provider like Microsoft can bring,
gives it even more special sauce for you,
or if you're a customer of Microsoft or of Azure specifically.
>> I don't know if I asked you this before,
but maybe I put you on the spot.
We've got about three minutes remaining.
Can you helm something in a few minutes?
>> Yeah, let's helm something.
>> In three minutes? You got three minutes to helm something.
>> Can you see the magic screen?
>> Let's go ahead and bring up your screen and see how
quickly you can cause some trouble.
Are you outputting?
>> Oh, we got the mirror. Let's do the mirror.
>> Up you're on another screen.
>> Yeah, we got another screen.
So this is helm.sh, all right?
>> Right.
>> That's where you go to learn about Helm,
but it's rendering a little large.
We'll just get drop it down really quickly.
>> There we go.
>> But the thing about Helm,
is this is where you'd go to start
your journey if you didn't know about it.
But if you click the charts,
what you'd go to his home hub,
and we'll drop it down again.
Helm Hub is any number of community charts for
almost all of the applications that you may have heard about.
For example, here's Cassandra, right?
So if we go over to a terminal,
which I will also move over there.
>> Yeah. If we could actually put
something up in two minutes, that'd be amazing.
>> That would be great. So we got big, big modes.
You're looking at a cluster over here,
and it's not scaled correctly,
but we'll work with it because we got two minutes.
So Helm, instead of actually knowing what I want to install,
I can actually search for it.
So I can do Helm search Mongo.
>> Oh, look at that.
>> MongoDB, and we can go,
and we'll find that the stable repository,
any number of charts.
If I want to install one,
I don't actually have to know how to install Mongo.
I just want to use it, actually the developer.
So I would just do Helm just like the app.
>> Yeah, for the Cloud.
>> It is app yet for the Cloud.
Helm, install.
>> I would be amazed.
>> Let's do name.
You know what?
I'm going to do word precedence instead.
>> Tab your way to glory.
>> WordPress being the, now,
if we're scaled out a little bit here,
but we're pointing at
a mixed cluster of Windows nodes and Linux nodes.
You can see we immediately get multiple services here.
We get multiple pods.
The pod is a logical word for a set of containers,
typically one, but it can have more.
>> Forty-five seconds, what URL is this at?
>> What URL? We may not make it.
So it is pending.
>> So it's pending, okay. So you fire
that up, you've put that into Kubernetes,
and it's in there now in the cluster IP,
but it has to go and allocate an external IP.
>> That's right. Because this is AKS,
this is one of those combinations between
the upstream implementation in Azure.
It's getting an Azure external LB
right now in which has to allocate the IP.
Sometimes, that takes 30 seconds,
which means we might fall just off the edge.
>> In the next eight seconds,
I'm going to tell you that you're awesome,
and that we're going to have you on the show
again to talk all about AKS.
I can learn about Helm and AKS on other episodes of Azure Friday.
>> Can we do it with Windows too?
>> We'll do all kinds of things and Windows.
>> Deal.
>> It's Azure Friday live.
That's live television people.
>> [MUSIC]