(bright upbeat music)
- Hey everyone,
it's great to be part of today's event.
My name's Gabe Monroy,
I'm the vice-president of the
Azure Developer Experience team
in Microsoft Developer Division.
Today, we're gonna show you
how you can use Azure Arc
to build Cloud Native applications that run anywhere.
Enabled by a single control plane
and the ability to bring
Azure services to any infrastructure.
Now, we know the future will be defined by
accelerated innovation.
We also know that much of this innovation will be digital
and will take the form of new applications.
Over the last year,
the technology industry has been called upon
to support those on the front lines,
from healthcare and education,
to public sector, manufacturing and retail.
It's inspiring to see how developers
are core to this transformation,
going above and beyond innovate
and help reimagine the world.
It's increasingly clear
that developers are strategic to every business
and are central to the next generation
of digital products in every industry.
Now, one story that comes to mind is ZEISS,
an international leader in optics
and opto-electronics technology.
Like many companies, ZEISS is a mix of applications.
Some are modernized monolithic apps,
some are PaaS services,
and many of their new applications are fully distributed
and running in containers.
Now ZEISS has customers around the world.
In some countries,
local regulations mandate that applications
and data needs to run in sovereign public clouds,
as well as on premises in some cases.
So how do companies like ZEISS
comply with these requirements,
without having to throw away all their existing investments
and build everything from scratch
for these new hybrid and on-prem scenarios?
The challenge ZEISS faces,
it's the same set of challenges
facing all modern developers.
Agility, reliability, and security,
even more so in the times we're living in today.
Developers need to build smarter and faster.
They need to move from idea, to code, to cloud seamlessly.
Developers need new applications to be resilient
in the face of failures
and scale dynamically based on load.
Developers need intelligent threat protection in real time
with fine grain security controls at every layer.
And what makes this even harder,
is that developers need to solve all these problems
across hybrid edge and multi-cloud environments.
Now, as we see with customers like ZEISS,
these hybrid capabilities are now critical
to solving problems like
data sovereignty, application modernization,
and localized data processing.
This is where Azure Arc comes in.
With Azure and Azure Arc,
we enable you to use the tools
and services you're already familiar with,
deploy your applications consistently
to multiple clusters, automate security
and governance across the entire environment
no matter where it's located.
Now, this gives you tremendous flexibility,
lets you deploy with high velocity
and enables you to have a single pane of glass
to easily manage your entire app and data estate.
Now, Azure Arc enabled services,
bring the Azure services you're using today.
Application services, data services,
ML services, to any environment.
So for example,
today, thousands of developers are using
Azure suite of application services,
including apps services, functions, logic apps,
developers love these services.
They're tailored to real-world app patterns,
loaded with unique features,
and optimized for developer productivity.
With Azure Arc,
you can now run these same Azure services
on premises, on the edge
and even on other clouds, like AWS or GCP.
When combined with the use
of Arc enable data services,
like Azure Postgres and Azure SQL,
which you heard about earlier today,
applications and their data,
can now run anywhere using fully managed cloud services
and industry first.
And the important thing to note
is that the way you deploy does not change,
you can still use your existing tools and practices
and benefit from a seamless, consistent experience.
Now to show you how this works,
let me hand it over to Brian,
a specialist on our Cloud Native team.
- Thanks Gabe.
Contoso Health sells medical
and pharmaceutical products
in retail stores all over the world.
They run back in infrastructure
and store applications entirely in Azure.
Customer orders come in from mobile apps
and they're sent to the appropriate store
where they're fulfilled.
For their application architecture,
Contoso uses Azure Kubernetes service
for hosting container based microservices,
including the accounting service,
which will be used later in our demos.
Contoso also takes advantage
of Azure PaaS services, wherever possible.
They host applications in Azure web apps and function apps,
and data is stored in Azure SQL, Cosmos DB
and Azure Blob Storage.
Contoso also uses
the distributed application runtime or Dapper.
Dapper provides building blocks
for common challenges faced
when building these microservices applications.
Dapper abstracts away a common tasks,
such as state management,
secret management, messaging and so forth,
which greatly simplifies the development process.
Let's take a deeper look at their core applications.
This is the corporate dashboard
where Contoso can see all store sales
and order volume over time.
This is a business critical web application
for Contoso Health.
The corporate dashboard is hosted
in Azure app service.
App service's a past platform
that allows them to focus on their applications
without having to manage VMs and infrastructure.
They can manage web apps security
and configuration settings.
Auto-scale, characteristics,
and concepts such as deployment slots,
which allow them to deploy
different versions of the application
to be deployed for testing in QA.
Microservices are hosted in AKS,
which provides a managed Kubernetes control plane
for simplified hosting of their containerized workloads.
As you can see,
there are eight container-based microservices
that make up the backend of the application.
They also have dashboards for each individual store
where they can see store performance of the local sites.
Store employees can see local order queue
and package order items to be picked up by customers.
As with any globally distributed network, outages can occur.
If the Contoso retail store can not reach Azure,
they would lose the ability to process orders.
To solve for this,
Contoso has decided to implement
Azure Stack HCI in each of their store locations.
Azure Stack HCI provides various hardware form factors
and delivers a platform connected to Azure
that can run during loss of network connectivity.
Now normally replicating this application pattern from Azure
would mean building custom solutions entirely from scratch,
which is clearly unproductive and not reliable.
However with Azure Arc, Contoso can save time
building out those applications at the edge
using portable application
and data services enabled by Azure Arc and AKS.
Now each site has its own AKS cluster,
running locally on Azure Stack HCI,
with Arc as a unified control plane.
Arc can manage our cluster with Azure policy,
and GitOps space configuration management
while also bringing Azure services
down to their local stores by Arc extensions.
For Contoso they now have,
an Azure consistent environment,
making it easy to deploy their entire store platform
to each site allowing for uninterrupted operations.
Here we see how they've implemented
Arc extensions for one of their sites.
Along with the app services and data extensions.
They've implemented infrastructure solutions
such as Azure Monitor, defender, policy
and the open service mesh out on.
This allows for a consistent management experience
between stores running on HCI
and there are other applications running in public Azure.
As you can see,
these extensions are bringing
many of the great Azure features
Contoso's store locations by the Azure Arc.
Let's take a look at
Azure application services on Kubernetes.
We have a new resource called
App Service Kubernetes environment,
which is hosted on their local Kubernetes cluster.
There's also a custom location called Contoso Chicago.
This allows them to deploy Azure web apps,
function apps, and logic apps,
in the same way they do in the Azure public cloud.
They just target the Contoso Chicago location
when they deploy.
Everything else is the same here.
Here we see on the Chicago dashboard
is deployed as an Azure web app,
but it is actually running in the local stores,
AKS cluster on Stack HCI.
The management and deployment experience
is the same as public Azure,
including the deployment slots
we saw with the corporate dashboard.
The same is true with Azure functions.
Here we can see how they use the local function
to process queued orders in the store.
Management of these functions in Kubernetes
would be the same as any other Azure function.
But in this case,
we've deployed it to our customer location Contoso Chicago.
Since Contoso has large number of stores,
application deployment to Kubernetes can be challenging.
For this Arc offers GitOps space deployments.
The entire store application stack,
can be deployed, maintain in any Git Repo,
and updates are pulled into each store
as code is tested in emerged.
Making it easy to consistently deploy their applications
to a large number of store locations.
Later you'll see a demo,
of how Contoso handles the interloop, development
and deployment process.
Back to you Gabe.
- That was awesome Brian.
Now, aside from the services themselves,
the second thing you want
is high velocity for your deployments.
While not compromising the stability of your systems.
And you can achieve this combination through GitOps.
Now, for those of you who are not familiar with this term,
GitOps is a way of continuous deployment
for Cloud Native applications.
The core idea is having a good repository
that always contains
the desired state of your infrastructure.
We then pair that with an agent
running in your Kubernetes clusters,
that ensure your workloads always match that desired state
you define in your Git repository.
And if you wanna deploy a new application
or update an existing one,
you just use a simple pull request to change the repository.
The automated process handles everything else.
Now the cool thing about GitOps,
is that it helps drive
strong collaboration between developers
and central IT,
or IT can set guardrails for governance
and security configurations using GitOps.
And the developers can also use GitOps
for their applications.
This helps drive consistency for your dev, test,
and production environments.
Now let's get back to Contoso's
retail application that Brian showed earlier.
What if Contoso had to implement a new program quickly
for their customers who shop at their branch locations
and you might think this is hard given all the components,
but check this out.
Let me hand it off to Lynn,
a technical specialist on our Cloud Native team.
- Thanks Gabe.
As Brian did demonstrated earlier,
it's easier than ever to deploy Kubernetes,
app service, functions, logic apps,
and API management at the edge,
all while managing it through the Azure portal.
Now let's talk a little bit about
the app dev side of the house.
As you may have noticed,
the dashboards are all displayed as zero value
for the average order fulfillment time.
Contoso has received a number of complaints from customers
that some stores are taking longer than usual
to fulfill their orders.
Management is asked to have that information surface
so they can monitor and take necessary action
to ensure a customer satisfaction.
Their front end developer Joey,
has already made the necessary changes to the UI
and the backend developer, you're truly,
needs to make the metric available in the rest operation.
I'm going to use GitHub code spaces,
powered by VS Code to make this change.
So here I am in the repository,
if you'll notice there's a code dropdown button here,
I'm just gonna go ahead and drop this down,
and say open with code spaces.
I've already got a code space created
so hopefully it won't take too long to spin up.
GitHub code spaces allows developers to focus
on what matters most.
Writing, building and testing their code
without worrying about ensuring
they've got 27 different dev tools installed,
15 different Docker containers running
and whether or not it only builds
and runs on their machine.
Code spaces will allow them to develop
wherever and whenever, even on constraint compute
as it relies on the power of Azure, GitHub,
and VS Code, to deliver a powerful developer experience.
The Contoso code space leverages.net5,
and Dapper, which includes Redis,
and Zipkin containers running in Docker.
Now the first thing we wanna have a look at,
is the existing data, the accounting services returning
as it's the keeper of all things metric related.
Let's start our Dapper sidecar,
since it's responsible for retrieving secrets
and connection string information for us.
It's also responsible for delivering
order messages to the service,
but we need not concern ourselves with that for now.
I'm gonna go ahead,
and bring up the command palette,
go to tasks, run task.
I've already created a task for the accounting service
so let's go ahead and fire that up right now.
Okay, the accounting service is up and running.
The next thing we want to do
is start to debug the accounting controller.
Let's go ahead,
and open up our debug view
of the accounting controller.
You can see here,
I've got a launch configuration set up
for debug accounting service.
Let's go ahead and kick that off,
while this is starting up,
I've already pre-written a rest sample
for us to query the end point with.
Let me go ahead
and kick off, this accounting service rest sample,
which will send a request to the accounting service,
order metrics end point, with the store ID of Denver.
As you can see the request as fired off,
we see some SQL output generation here
and our results are returned in Jason format.
Now if you'll notice, each one of these metrics
has a zero value for the average fulfillment seconds.
Let's go ahead
and make the changes necessary
to populate that with real values.
In order to do this,
I'm going to open up the accounting service controller
and I already have a pretty good idea
of where I need to make this code change
so we're just gonna hop right to it.
So we're gonna add a new field,
that's average fulfillment time of seconds.
That's it, that should be enough to get us going.
Let's go ahead and restart our debug session here.
Flip back over to our rest query,
and let's just make sure that we're actually
getting back data that we expect.
Look at that.
We've already got
our average fulfillment seconds filled in now.
The only thing left to do at this point in time
is commit our code
and push it back up to our repo.
In order to do that,
I'm gonna switch over to the source control view
of Visual Studio Code,
I am going to stage my changes to the accounting controller,
let me add a commit message here,
updates to accounting controller,
let's go ahead and check commit,
and then let's go ahead
and push our changes to our GitHub repository.
Looks like those changes are pushed,
so now the next thing we wanna do,
is let's go ahead and jump over to our repo here,
and if you'll notice we've got to GitHub action set up,
that's gonna go ahead and do a number of things for us.
The first thing it's going to do,
is it's going to build the accounting controller.
Next, it's going to create a Docker image
that's tagged with the short
show of the GitHub commit itself.
It's then going to take that Docker image,
push it to a GitHub container registry,
and finally, it's going to update the Kubernetes manifest
for the deployment service
so that our GitOps processes can pick them up
and update the appropriate deployments.
Now Contoso chose to use a GitOps process,
instead of the typical deployment pipeline,
because it has hundreds, if not thousands of stores
that need to update these changes locally.
In a typical deployment pipeline,
you would end up having to push those changes
individually to every single store,
but the GitOps approach, it flips that on its head,
and instead we can basically install an operator
in your Kubernetes cluster
that's constantly searching for changes
that are occurring in this GitHub repository.
If it locates a change, that needs to be applied,
it will go ahead and do a rolling update of that deployment,
hence all of the replicas will then update their images
and lo and behold we'll have new code up
and running in the cluster.
So it looks like this is complete now,
so let's just go ahead and click into it.
Everything looks great.
Let's go ahead and flip back over to our Denver store.
You can still see here that we've got
a fulfillment time of zero seconds
and that's okay.
What's happening is,
the operator that's running in the cluster
only polls every five minutes
or so to see if there's any changes,
but we can go ahead and prod it along if we want.
I've got a command prompt window pulled up here
that shows all of our pods that are currently running.
The one that we're interested in
is the accounting service pod.
Notice it's been up for about 43 minutes.
I'm gonna go ahead
and issue a command to tell the GitOps operator to go ahead
and refresh itself now,
rather than waiting for the scheduled time interval.
But we should see here in just a second is
it will have reached out to our GitHub repository,
as you can see now.
It has downloaded the new manifest,
it's downloaded a new container image.
It's now doing a rolling upgrade to the deployment,
so if you'll notice we haven't pulled down
the original version of the accounting service yet
because the new one isn't quite ready.
Notice there's two containers in this pod,
and only one of two of them is ready at this point in time.
Again, remember one of those
is our accounting service business logic itself,
and the other one is our Dapper container.
Now notice they've both come up, two of two,
the old accounting service is terminating
and look here,
we're now getting results in our fulfillment time.
39 seconds, that's pretty impressive.
So hopefully this has given you a quick glimpse
into what's possible from a developer perspective
with code spaces, Azure Arc and GitOps,
back to you Gabe.
- That was awesome to see how quickly
Lynn was able to deploy a new application in seconds
and an edge location,
with the same Cloud Native experiences
and tools that he's already familiar with.
And now finally, to route out your developer experience,
you get a modern management experience
through Azure Arc, for all of your applications,
no matter where or how they are deployed.
And we bring these to you
through something called extensions.
You can now turn on additional
Azure integrated services like security,
and monitoring services,
for your Arc enabled Kubernetes clusters,
right in the Azure portal or CLI,
and you only pay for what you use.
Extensions greatly simplify onboarding.
Customers can deploy Azure integrations
with just a few clicks or API calls.
Azure Arc enabled Kubernetes,
ensures you always have the latest bits
and can automatically apply updates
as soon as they become available.
Now, one such capability that is available for you is
Azure monitor for containers.
With this, you can monitor the performance
of your container workloads,
deployed in the cloud on AKS,
as well as on any Arc enabled Kubernetes cluster,
all directly in the Azure portal.
This enables a single pane of glass view
so that developers and operations teams,
can really track what's happening
across their environments in a single view.
You can expect more innovation in this space
and we are super excited
to see what you all build with this technology.