- Up next, I'm joined again by Matt McSpirit,
this time to walk through your options
for app modernization as you migrate to Azure.
From the updates for the containerization of your apps
to run in Azure Kubernetes Service
to running in the Azure App Service,
we'll also show you updates to the Azure Migrate tool
to help you discover and assess your .net apps at scale
before migrating them fully
to the managed Azure App Service.
So Matt, it's always good to have you on the show.
You know, we've covered a lot about migration topics
in past shows, and today we actually want to
go deeper on how you can take the opportunity
to modernize your apps as you migrate them to Azure.
- I'm glad we're going to go a bit deeper on this today.
We've touched on this topic in past shows
and there's a broad spectrum of what you can do.
The good news is that in many respects,
the sheer act of migrating to the cloud with Azure
will bring modernization benefits,
no matter which option you choose.
- Which then begs the million dollar question.
So which options do you choose and when?
- To which I would say, it depends.
Now, one way to approach the decision on which option to use
is to break down your app portfolio into a few buckets.
So firstly, there's essential apps,
where there's no active development going on,
but they're still in operation.
These may also be candidates for replacement
or even retirement down the line.
And this is where a lot of people may choose
lifting and shifting their app infrastructure into Azure
to take advantage of running the app on the latest silicon.
Conversely, there are the essential apps
that you're actively developing and need to be enhanced,
where additionally you may want to be able to run those apps
on multiple platforms.
So, here you can refactor these apps as containers
that run in our managed Azure Kubernetes Service, AKS.
This makes it easier to add new capabilities
as a new container.
And of course,
because each container can scale independently,
this has a lot of advantages for being able to
dynamically scale the parts of the app that you need.
So, you've got a lot of control.
- You know, that said though, this approach is best
if you have some experience already with Kubernetes.
- Yeah, it is.
You really need to be comfortable with the
managing and monitoring aspects
that come with container orchestration,
which brings us to our next bucket.
If you want us to take care of the management for you,
you can simply rehost your app in the Azure App Service,
which is great if you've got a monolithic app
that you want to bring over.
And this comes with a number of advantages,
things like built-in infrastructure maintenance,
security updates, and scaling,
as well as built in CICD integration.
And additionally, you can run key parts of the app
as custom containers in the app service, which is great
if you've got specific requirements like a port dependency
and you can do this without having to deal
with the additional complexity of running containers.
- Yeah and we've also done a lot of shows in the past
that cover all these different migration paths,
and you can check those out at aka.ms/mechanicsazuremigrate.
But can you walk us through then,
you know, some of the latest updates
for anyone who's choosing these options,
and use a specific example?
- Sure, of course, and we covered this before in
our last show, but there's been
a few updates to the experience.
So, we'll start by using the containerization tool
in Azure Migrate to help you refactor your app
and run it in the Azure Kubernetes Service
without needing to rewrite the app.
So, I'm in the Azure Migrate portal
and under Explore more in the Web apps to Container section,
I'll click into App Containerization.
And as you can see,
this works with ASP.NET apps running in AKS
and Java web apps running on Apache Tomcat.
So, I'll download the tool and with it running
I can go through the steps.
I need to specify the app type, in our case Java.
And next, the Target Azure service selection
is new to the experience
and it provides options for me to choose
the target destination for my container,
either Azure Kubernetes Service or the App Service.
In this case, I'll choose AKS.
And from here,
I walk through the prerequisites.
And you'll need to make sure SSH, secure shell, is enabled.
Then continue.
Now, I need to log into Azure.
I'm going to hit the Sign in.
It's going to give me a device code.
I need to copy that.
Then I'll sign in and paste in my code.
Select my tenant and subscription and continue.
Next, I need to enter the IP address
or fully qualified domain name of my server.
So, I'll use the IP here,
then enter the username and password.
And once I validate connectivity
I can continue and this will then discover
the apps running on my server.
And in fact, you can see it found our airsonic Java app.
So, I just need to select it
and enter the target container called airsonicv1.
And from here, I look at the parameters
and keep all the settings and check all the boxes
for username, password, and URL.
The advantage of this
is that I make in the connection string
a deploy time configuration that can be changed later
and I won't need to build a new image
for future changes to connection strings.
So next, I'll need to make a slight edit
to the app folder location, to map everything correctly.
I'll add a new folder and enter the path
and I'll also change the target storage
to a persistent volume.
The reason for that is it keeps my image streamlined
to improve performance and allows multiple replicas to read
from the same shared storage,
which is great for stateful applications.
Now, I'll save my changes
and I'm ready to move on to the build.
So here, I just need to choose my Azure container registry
and select my container.
You'll notice something new that we've added
is the ability to monitor your apps using App Insights
once they've been migrated to AKS,
which is incredibly useful for troubleshooting issues.
Now I'll hit Build and after a moment it succeeds.
And I can move on to the deployment specifications.
This is pretty straightforward.
So, here I'm just going to select
my AKS cluster called ContosoAppsAKSCluster, and continue.
And something else new, is that I can also use
the Azure Key Vault service to store
and manage application secrets, such as connection strings.
In this case, I'll choose my ContosoAppsKV resource.
And now, I also need to set my managed identity,
and I'll use this one I created earlier.
And finally, select the App Insights resource
and hit Continue.
From there I'll specify my storage account,
and the file share, and then deployment configuration.
I now need to configure the app.
So, here's where I can check the prefix string,
ports, replicas, load balancer type,
and I'll keep what's there for now
and enter my username, password, and the URL.
I'll keep the storage config as is, and hit Apply.
And great, we're ready deploy.
So, I'll do that and once it's finished,
I can click into the link here
and see the public IP and resources.
And just to test this out,
I'm going to go into kube control
and we're going to get service command.
And you'll see our airsonic containers running
along with the external IP and the port we just saw.
So now, let's try this in the browser.
I'll paste in the address, and there's our app.
So I'll log in just to make sure everything works
and it looks good.
- Quite a few updates then to the experience.
And you showed that one of the target destinations
to target is actually the Azure App Service
for your containers.
And this is where you'd want to put maybe custom containers
to run in the Azure App Service.
So, what does that path then look like?
- So yeah, this capability is brand new.
And as I mentioned, this is a good option
if you've got specific dependencies.
It's a similar process to what I just showed.
So, let me show you the experience again.
Firstly, you need to go through the same steps I just showed
with the app containerization,
but of course, this time in application type and target,
I'm going to choose the other option for App Service.
Again, most of the steps are similar
to what I just showed,
except in the deployment specification step
I'll select the App Service plan.
And I can even create a new instance of App Service,
right from here if I don't already have one.
Now, I'm going to stop there because the rest is the same
as the AKS target.
But, of course, this time our Java app ends up
running in the App Service instead.
- Since we're on the topic of Azure App Service,
we showed in detail how you can actually migrate
into Azure App Service on a previous episode.
And I know that we've also now made it easier to discover
and assess apps that might be ready
for App Service migration.
- Yeah, that's right, we have.
For bulk operations, we've extended the agentless approach
with the Azure Migration Tool to help you discover
and assess your .net apps at scale.
And this makes it easier to understand any dependencies
and to bring them over to the App Service.
It also compliments the App Service migration assistant
that we've shown before,
which is used to assess and migrate
your individual web apps.
So, let me show you how this works.
And in fact, many of you,
if you're familiar with VM discovery and assessment,
you'll notice it follows more or less the same steps.
But to save some time, I've already created a project.
And the steps through that, if you haven't done this before,
can be found at also known aka.ms/mechanicsmigration.
And as I mentioned,
it's the same steps that you use for server discovery.
So, you use an appliance VM to perform the discovery
and inventory of your servers and apps in vSphere,
Hyper-V, on-prem physical servers, or VMs in other clouds.
And here I'll generate a key
that I'll need to use in a moment.
And I use the appliance for VMware vSphere, in this case.
- Okay and just like with virtual machine migration,
you know, once that's running,
the appliance is itself a VM that you would log into
and remote into to configure
in order to inventory out all your servers.
- Yeah, that's right.
But in this case,
we're looking specifically for servers running IIS,
Internet Information Services, and collecting information
about migration readiness.
So now, I'm in the appliance itself
and here we're going to use the key
or just generate it and log into our Azure subscription
so that the appliance can log information up to Azure.
Next, this is where you need to provide
the vCenter credentials with sufficient permissions
to perform the discovery.
Now, I've already added my vCenter Server credentials
and a friendly name and saved it.
And the next step is a capability we've just recently added,
which is the ability to add multiple credentials
for your individual servers.
These could be domain or local account credentials.
And in fact,
here I've entered three sets of credentials
and the service will try each set to log into our servers
and map them to the correct server.
An important note here is that these credentials
are never sent to Microsoft
and don't leave your environment.
And so now with everything configured,
I can start the discovery.
- Okay. And by the way,
this might take a few minutes or a few hours to run,
really depending on your app inventory.
And you can also monitor the progress
while that's happening in Azure Migrate.
- Yeah. And to that point, and for the sake of time,
we sped up the process a little bit for the discovery.
And so, now it's complete.
And in fact, if I hop back into Azure Migrate,
I'll see that my appliances discovered 63 IIS servers
where our .net web apps are running.
I'll click into these servers for more detail
on each server, and in the web apps column
I can see the number of web apps on each server.
And here's one with 51 web apps.
And I'll click in to find out more.
And for each app, I can see the URLs and the binding ports,
as well as the application pools.
- So, now you've got a detailed inventory
of your servers and your web apps,
but how do you know then
if they're actually ready for migration?
- Well, for that I can create an assessment
using the information that was discovered.
So, now when you choose Assess,
you'll see a new option for Azure App Service.
And from here, I can configure the assessment.
I can edit the properties if I want,
like the target environment, pricing options, etc,
but I'll leave the defaults and go to the next step.
I'll imput an assessment name, then a group name,
and make sure the right appliance is shown here.
And I can multi-select or filter for the service
I want to assess or choose select all,
which I'll do in my case.
And this brings up a confirmation page
and I can click Create assessment.
That's going to take a moment.
And next, back on the dashboard, once I hit Refresh,
I should see the new App Service assessment
that I just created.
And there it is.
So, I'll open my assessment.
Then I'll open the Web App assessment,
and this brings up a dashboard view
with the count of servers and web apps.
In the center you can see how many apps are ready,
ready with conditions, not ready, or unknown.
And on the right, I can also see a recommendation
with the number of plans I'll need
if I migrate everything,
along with a monthly cost to run my apps in Azure.
And by clicking in, I can see details for each server,
including recommendations for the App Service plan
and th SKU level.
Now as you can see,
most of my servers are ready with conditions
and we give you detail about these conditions.
So, I'm going to click into the first one.
And in this case, it just needs to support incoming traffic
on ports 80 and 443 as required by Azure App Service.
This app is currently using port 85,
so it's an easy fix to specify the ports needed.
So from here,
I could easily start with the apps marked as ready
or prioritize the ones I want
and make any configuration changes based on
the conditions highlighted for each in the assessment.
Now, we're also working on integrating
the bulk migration process itself into these tools
so you can move your .net web apps at scale
into App Service.
- And one of the nice things is if the conditions
are like that minor port change that we just saw,
it should be pretty straightforward
to get everything to work.
So, equally as you showed earlier,
we can also opt to run parts of our app,
maybe in the Azure App Service's custom containers
to resolve specific compatibility or dependency issues.
- Yeah, that's right.
And going back to our theme of app modernization,
once you're in Azure, it doesn't stop there.
For example, you can easily apply intelligence to your apps,
whether that's with our pre-built AI models
in Azure Cognitive Services, or by integrating Azure Search,
there's a ton of opportunity to harness the brain
in the cloud to modernize the experience for your apps.
- In fact, we have two very recent shows on those topics
that you can check out as well.
So, thanks Matt.
As always, it was super informative.
But, where can people go to learn more?
- Well, firstly, try Azure Migrate
to migrate and modernize your apps, data, and info to Azure
at aka.ms/TryAzureMigrate.
Now, if you need expert help
to accelerate your cloud migration
and modernization journey,
make sure you enroll in the Azure migration
and modernization program,
and you can find out more at azure.com/AMMP.
- And of course,
keep checking back to Microsoft Mechanics
for the latest updates.
Subscribe to our channel if you haven't already
and as always, thanks so much for joining us today.