- 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.
