[MUSIC]
>> We're absolutely committed to supporting Windows containers,
they went GA, and Kubernetes,
went up 14 in the open source project.
Most of that code, and not all that code,
but a lot of that code was actually written by Microsoft.
We have Windows container support in
preview in the Azure Kubernetes Service today.
Obviously people wanted to be in general availability,
and we're in the process of finishing
up the work necessary to bring it to general availability.
So we're absolutely committed to both the Windows containers in
upstream Kubernetes and also
Windows containers in the Azure Kubernetes Service.
So Arc is a really interesting thing
because what we've realized the more we talk to
people is that Hybrid Cloud is a steady-state.
I think I used to think of it as being a way-point.
You're in a datacenter,
you're hybrid, now you're in the Cloud.
But what we've realized in talking to all these people
is hybrid is just the way they're going to do business.
If you're a retailer, you have a store,
we're not going to take that store and put it in our datacenter.
It's very hard for people to come in,
buy things from you if you're store is in the datacenter.
So we need to build tools that allow Azure to
span from our datacenters out to on-premise environments.
That's what Azure Arc is for.
So we talked to customers who say,
"I love using Arc, it's fantastic in Azure,
but I've got 500 stores
and there's a Kubernetes cluster in each store,
what are you going to do for me there?"
So Arc is a way of saying, look,
we can actually represent that Kubernetes cluster,
adopt it into Azure, if you will,
and start helping you manage it.
Tell you if you're out of date,
tell you if there's a security problem,
provide monitoring for the applications that you're running there,
image them to make sure that every single cluster,
and no matter whether it's an Azure or on-premise,
looks and feels exactly the same using GitOps.
So that's the promise of Arc.
I think one of the values that we want to deliver
there is that it's constantly improving.
So today we're going to give you some basic,
very basic management features.
In three months, more another few months, even more.
So I think we're always trying to,
we would love to get to a place where
the experience of AKS in
Azure and experience on-prem is identical.
That's a long way off, but that's the North Star.
When it comes to creating 5,000 node clusters,
and honestly with AKS in general,
what we really try and do is follow the customer need.
AKS actually used to be a lot smaller than 1,000 nodes,
and we worked with some of our biggest customers to make
the improvements necessary to
satisfy their need for 1,000 node clusters.
When you consider Azure is pushing 100 cores,
more than 100 cores on its largest VMs,
it's 100,000 cores across 1,000 node cluster.
It's a lot of compute.
So I think that we're always just going to focus on making
sure that the customers
that we have have the compute that they need,
and for now that's the sweet part for that is 1,000.
I don't think we want to get into
numbers competitions and things like that.
We'd much rather be customer driven
and how we did that scaling, how to make those decisions.
This is a big issue, I think at some level,
how do you maintain an enterprise that wants to standardize on
a particular version or
a particular release with
a community that's spitting out a new release every three months.
Honestly, although I will also say I've got also
some forward-looking enterprises who are on me,
when the new release comes out, when is it going to be out?
What does it be available for us?
So like it's this balance of people who want to
really fix and stay and people who
really want to be on the bleeding edge.
What we are working through is figuring
out how do we support both of those classes of customer,
because obviously we can't have
20 different versions that we support all the time, just too many.
So how can we have something that's more like
a long-term support version
and yet also maintain the bleeding edge.
That's an area that we're working on.
Now, I think there's also an argument to be said
for adopting more of a continuous upgrade strategy,
saying maybe we can get to a place where
a customer is so comfortable with our upgrades.
They just turn on auto upgrades and
they're standardizing on Azure community service,
they're not standardizing on
Azure Kubernetes Service version 1.15.4.
I hope that we can get people there because I feel like that's
the most important way to be because you're
always getting the latest security updates
related to reliability fixes.
That's obviously a challenge,
especially for lot traditional places that it can be a challenge.
So I think it's a combination of building the right product,
but also working with them to understand
how the Cloud changes things.
They're not necessarily when they use Azure SQL and as a service,
they're not necessarily as
focused on what version of Azure SQL it is.
So I think hopefully we can get there.
We have really, really good penetration into our top customers.
There's a lot of interest across the board in
Kubernetes and how it can
change the way that they build and deploy applications.
So we're really excited to partner with both the smaller companies
who've come up and who may be
the very first thing that they're building is containers,
as well as the large enterprises who are
figuring out how do I modernize my state,
how do I go through that digital transformation.
The truth is that you really learn a lot
from both sides and you can actually help both sides.
You can take some of that like, well,
have you thought about what it's going to be like when
you're trying to penetrate into the health care market,
and there's all this regulation.
You can also talk to the more incumbent large-scale
Fortune 500 companies and say,
"Hey, have you thought about doing
releases every day? What would that mean for you?"
So we really value customers across the spectrum.
I think that the premise of the question of
when do I choose App Services versus
Kubernetes assumes at some level that they're separate choices.
I really hope that we get to a place where
you choose a programming model like App Services for
a particular application and
it runs on Kubernetes and it can run next
to bear container or it can run
next to Azure function and running on Kubernetes.
I think we really need to get to a place where
the programming model that you choose
doesn't dictate the platform that you're running on,
because people want interoperability,
they don't want this choice to feel like it's
such a big deal They want to know
that if they chose one and it turns out not to be right,
it's easy to move all that stuff.
I think right now, these platforms,
they feel like really big choices,
and I want it to be a much smaller choice, much easier choice.
I think that the developer experience in the Azure ecosystem has
the amazing advantages of
the developer history that Microsoft has.
I think Microsoft is truly unique
history in developer tooling and developer productivity.
When you look at things like GitHub,
when you look at things like VS code,
in the Kubernetes ecosystem when you look at things like helm,
which is a an open-source project that we largely support,
you're looking at just a suite of
tools that people are using
no matter where they're using Kubernetes.
So then to know that those things are going to
be well integrated with the Azure Kubernetes Service,
are going to be built by
the same people who are using the Azure Kubernetes Service,
you just have that confidence that the end to end
flow from your code in GitHub all the way
through to your container running out in Azure is just going to be
a seamless experience organized
around your productivity as a developer.
I think that's truly unique,
and honestly the most exciting reason why I'm here.
We use GitOps in the Azure for the Arc service, as I said.
When people are talking about GitOps,
it's a logical extension of infrastructure as code.
So when you were doing infrastructure as code,
you're writing down a description of your infrastructure.
Well, if you write something down,
you need some place to put it.
Well, the place where we put
text files in general is version control,
and what do we think about version control,
that's Git and usually GitHub.
So then GitOps was basically an extension of that to say, well,
you're pushing the configuration into Git,
why not automatically then apply
that configuration out to a cluster.
So it's continuous delivery of that configuration,
making it just like Platform as
a Service might have a push to deploy model for code.
GitOps is saying, "Hey, we're going to have a git push
validate in GitHub actions,
and then deploy out to your cluster."
So I actually think it's a great model.
We have to get the right testing and the right validation so you
don't take out your production environment with one git push.
But I think that it's
just another iteration on
an evolution on the idea of infrastructure as code.