- Coming up, we're joined again by Matt McSpirit
to look at your options for migrating your apps
to a hybrid state with Azure Migrate and also Azure Arc,
so that your resources in the Cloud can work seamlessly
with resources on premises under a single management plane.
So Matt welcome back to Mechanics
with another migration topic.
- Thanks, it's good to be back on.
- And thanks so much for joining us today.
So we really wanted to do this show
because we cover migration a lot,
but it really isn't an all-or-nothing proposition.
- That's right, it isn't. And at the end of the day,
hybrid is going to be a reality for most organizations,
especially for those workloads that you have to keep
on-premises for whatever reason.
And the good news is with Azure Migrate now,
not only do we help you migrate,
we help you to assess your on-prem environment
and potentially place those resources under management
so that your entire environment,
whether on-prem or in the Cloud
can come under unified management with Azure Arc
that extends the Azure control plane
to your hybrid environment.
- So why don't we get straight into an example then
to make all of this real.
- Sure. So what I have here is an asp.net app,
and this runs on Windows Server, and it's got a SQL backend
that also runs on Windows Server.
It's an online retail app for an auto parts store.
Now what I'm going to show you is how you can
migrate the resources you want to to Azure,
and leave what you need to on premises.
We want to start by first moving the backend database
as a VM, then we'll modernize the front-end using containers
so that we can easily scale up and down
based on demand and not worry about
managing the underlying server infrastructure.
Finally, we'll make sure
that we bring everything under Arc management.
Now in advance, we've run an assessment with Azure Migrate
across this app and many others.
And if you want a detailed step-by-step guide
for doing that,
you can check out our show on aka.ms/MechanicsAzureMigrate.
Now I've filtered our assessment on Woodgrove,
which is the name of our app.
And you'll see here all of the related VMs.
If I click into view dependencies on this front-end VM,
this view is what we call the dependency map
in Azure Migrate.
And you can see that not only
do we have our two primary servers,
Woodgrove StoreApp1,
and this one's communicating over port 1433, our database,
but we also have a couple of dependent servers
that are communicating with them.
So I'll open up the details in port 443,
and you'll see six more resources
and another six communicating over port 80.
These are payment processing and ERP systems
that we're not ready to move yet to Azure and that's okay.
So that means when we migrate our front-end
and backend app servers to the Cloud,
they still need to be able to talk
to our resources on premises.
- Really the dependency map here is important
because it shows you all the connections
that you need to maintain
to be able to retain all the current functionality
then of your app.
- Yeah, that's right.
And being able to visualize those dependencies
makes it significantly less likely
that you're going to break things.
So let's go into Azure Migrate
and I'm going to click Replicate.
I'm going to choose my existing virtualization platform
in this case, VMware.
Select my appliance and hit Next.
And since I'm just migrating this one VM,
I'm going to specify my settings manually.
So I'll filter on Woodgrove Store
and you'll see our four servers.
Now we know our database has a lot of customization,
so we're going to move it up as a virtual machine
and we'll deal with our front-end later in the next step.
So here in target settings,
I need to enter standard options in Azure
as the targets settings, like location,
subscription, VNet, etc.
I'll choose the hybrid benefit
to save on licensing costs as well.
And once I'm finished, I'll hit Next.
Now I can choose my VM size to match my existing VM.
I'm just going to pick a standard DS4 v2 and hit Next.
And I'll keep the All selected in the Disk Type here.
Choose Premium for this one and hit Next.
Now I'm ready to replicate.
So let's go ahead and do that.
That'll save the contents of my VM
into my storage account.
And back on the Azure Migrate tab,
you'll see our replication's just started.
If I click into it, I can test from here,
but to save a step, I'll go straight into Migrate.
I'm going to select my server and hit Migrate.
And in just a moment,
it's now a running clone of my original VM.
And as you can see, it's running now in Azure.
So now we have the database backend
successfully running in Azure.
- Okay. So now you still need to make sure though
that you can reach your dependent services
like your payment processing
and the ERP systems we saw before.
- Yeah, exactly right.
And for that, I've set up a virtual network connection
to my on-prem environment.
And as you can see here in Azure Networking,
we've got a few options, for example,
basic connectivity over a VPN.
And this is going to ensure that all of our services
across Azure and on premises can talk to each other.
- Right. And of course,
you can also use Azure Express Route
as a more direct connection
depending on your performance needs.
So now you just need to bring over that asp.net front-end.
- Yeah. In fact, what we're going to containerize our app
in this case directly from our on-prem VM
to an Azure Kubernetes Service or AKS cluster.
And the nice thing here is
that we can do this without rewriting the app
and we'll retain its current functionality.
And we'll still be able to reach our backend in Azure
and our dependent services on-prem.
So I'm still in Azure Migrate, now under Explore More
in the Web apps to Container section
I'll click into App Containerization.
And you'll see this works with Java web apps
or asp.net apps.
And from there, I'll download the tool, with it running,
I need to specify the app type in our case, asp.net.
I'll walk through the pre-recs
and make sure everything we need is enabled and continue.
Now, I need to log in with my Azure credentials,
select my tenant and subscription and continue.
And now I can enter the IP address
or fully qualified domain name of my server.
I'll use the FQDN here and enter the username and password.
And once I validate connectivity,
I can continue and that will discover the apps running
on my server.
And you'll see here, it found our front-end app.
So I just need to enter the target container,
Woodstoreapp v1.
I'll select it.
And here I'll take a look at the parameters.
I'll select the default connection string for now,
but I'll need to change this over to our VM later
and then hit apply.
And now we can move on to the build,
and I just need to choose my Azure container registry
and select my container.
I can review and even make edits here if I needed to,
but I'm going to keep it as is and close it.
Next I'll hit build, and after a moment it succeeds.
So now I can move on to the deployment specifications.
And here I need to select my AKS cluster
called Contoso AKS, then continue.
Now in the deployment configuration,
I need to configure the app.
Here's where I can check the prefix string,
certificates, ports, replicas, load balancer type,
and I'll keep what's there.
And now I need to paste in our new connection string
for the VM now running our database in Azure,
and then I'll hit Apply.
And now we're ready to deploy
and I can edit the deployment spec if needed,
it's the YAML file.
I'll keep it as is and hit Deploy.
So I'll do that and once it's finished,
I'll click into the link here
and see the public IP and resources.
Now let's try this in the browser with our IP address,
I'll paste in the IP address there,
and there's our app.
And I'll make sure everything works and is looking good.
- Great. So now your app is actually working
in a hybrid state.
You got some components that are running in Azure
and a few still on-prem,
but if I wanted visibility maybe into management,
across everything in my app, how would I do that?
- Well that's where Azure Arc comes in.
Azure Arc is a recently launched, free Azure service
that can extend the Azure control plane
to parts of my IT estate
still running on-prem or even across other clouds.
So today Arc can manage service and Kubernetes clusters.
And now that we've gotten the initial migration complete
with Azure Migrate,
we can onboard our on-premises servers to the Arc service.
Azure Arc seamlessly integrates
into your Azure Migrate workflow,
and as part of the Azure Migrate server discovery
and evaluation process,
you can onboard your on-premises servers
and virtual machines to the Arc service.
The Azure Migrate appliance is already running on premises.
And if I log into it, I can scroll down
from the Azure Migrate appliance configuration manager,
when I get to the onboard to Azure Arc section,
to save time,
I'll show you all of the standard fields imported.
I've also created a service principle in Azure
to use for onboarding.
And as you can see, I've pasted in the secret.
Now I can start onboarding.
Arc and Azure Migrate
will then verify a few connectivity requirements.
And once complete, you'll see all of our on-prem servers
have been onboarded into Azure Arc.
- And by the way, any VM that's already running in Azure
is managed in the same way by default.
But things are a little bit different for our AKS cluster,
which needs to be enrolled into Azure Arc management.
So how would we then get our front-end Kubernetes cluster
to be under management?
And would it work the same way
if that was on-prem or in the Cloud?
- Yeah, that's right. We need to onboard them as well.
So in the Arc blade, we can see all of our
on-premises managed resources.
And if we had any on-premises Kubernetes clusters,
they would appear here.
The onboarding process is very similar
to the process for an on-premises server.
So I'll add a Kubernetes cluster with Azure Arc,
and that's going to show me a few prerequisites,
make sure they can access ports 443 and 9418,
and in onboarding I need to add the standard details
as well as a cluster name.
Then I can move on to adding tags,
which will help with things like filtering
or scoping policies later.
I'm going to add a tag for workload
with the new value of new web app for our front-end cluster.
Next, Azure is going to generate a script
that we can run using the CLI
to onboard our cluster into Azure Arc.
- So what does it look like then
to manage all those resources?
- Well, once our servers are onboarded,
they get the same management capabilities as VMs in Azure,
which means access to Azure security tools,
Azure policy update management, Azure monitor,
and some Azure VM extensions.
So we can use Azure Arc
to extend our Azure management practices on premises
and maintain consistency,
so that your resources don't drift from compliance,
which is a common challenge with hybrid environments.
Now normally I'd have to use an on-prem configuration tool.
But now I can use the same services and processes
that are used to manage my Azure VMs.
In this case, I want to make sure
that my service certificates are properly configured.
So I'll click into policies.
Azure policy together with Azure Arc provides a simple way
to define configuration requirements
and apply them across both Azure and on-premises resources.
Now I'll assign a policy.
There are several pre-made policies,
including one that verifies certificate expiration dates.
I'll search for certificate,
choose this one to audit Windows machines
that contains certificates expiring within a number of days.
I'll hit Select, add a description.
I'll review my policy, then create it.
And in a moment, you'll see the policy appears on our list
and there it is.
I can click into it and see the compliance state
and be able to show anything out of compliance,
whether it's in Azure, on-prem or in any other cloud.
- By the way, this is totally new.
We've always had the ability
to see our server's current state from Azure,
but now we can actually write back to those same
on-premises servers in an auditable and secure way.
So what are some of the other things you can do now?
- So Arc enabling our servers also gives us access
to Azure's cloud native monitoring tools.
Using Azure Arc and Azure VM extensions
I can set up Azure monitor on my managed servers
and stream that data into a single Azure monitor workspace
for visualization and analysis.
For example, this workspace is called traffic comparison.
It shows metrics and reports
for all my servers and containers
and not just those running in Azure.
Also using the same extension framework,
we can monitor our hybrid security posture
with Azure security center.
Once the agent is configured and installed by Arc,
we can see security alerts
and recommendations for our entire IT estate.
I can even filter using my resource type,
by VM's running outside of Azure, and managed by Azure.
And I have a complete view
and management controls across my estate,
no matter where the resource is running.
And that's really what Azure Arc is all about.
- Good stuff, Matt.
So if anyone's watching
and they want to get started with migrating and modernizing
and really managing everything from one place,
what do you recommend?
- Once you're ready to test out a migration,
you can get to Azure Migrate at aka.ms/azuremigrate
and to find out more about Azure Arc go to aka.ms/AzureArc.
And we've got a ton of learning content available
on Microsoft Learn.
- Thanks so much Matt,
for the comprehensive look at hybrid migration,
and of course, keep watching Microsoft Mechanics
for all the news and deep dives into the latest tech.
Be sure to subscribe if you haven't already yet.
And we'll see you soon.