(bright music)
- [Narrator] Linux has grown to be
the most popular operating system on Azure
with more than 60% of customer cores in Azure running Linux.
And there are strong reasons behind it.
Linux runs great on Azure.
Microsoft is a major contributor
to many open-source projects
such as the Linux Kernel, Kubernetes, and PostgreSQL.
Microsoft now offers
its own Linux distribution with Azure Linux,
which is a container host for Azure Kubernetes services
that is optimized for Azure.
Many AI workloads on Azure run in Linux,
including OpenAI and ChatGPT.
You can choose any Linux distro you prefer
as Microsoft supports all major Linux distributions
and has deep collaboration with Red Hat, SUSE, Canonical,
and the broader Linux community.
As we look at moving workloads to the cloud,
there are three major categories of tasks
that need to be accomplished
regardless of which tooling you choose to employ
and whether you perform a lift and shift
or modernize as you migrate.
First, you need to discover the systems
and workloads you have in your environment.
Second, you must assess whether these systems
are in a state where there can be migrated
and whether it makes financial sense.
It may be more beneficial to retire aging systems
or move to PaaS or SaaS solutions.
Third, you need to perform the actual migration,
whether it's moving a VM to the cloud,
migrating data from a database VM
to a database-as-a-service solution,
or moving a Java application onto an Azure service
like Spring Cloud or JBoss.
Let's look at why you might want
to use Azure Migrate for these activities.
Azure Migrate covers the migration process end-to-end
in a consistent manner.
It has been most successfully used
to migrate tens of thousands of Linux VMs.
You get savings estimates
and cost for optimal configurations
that meet your performance needs,
thus, your deployments in Azure are cost optimized.
Azure Migrate also provides capabilities
to migrate workloads such as ASP.NET apps, Java Tomcat,
and Spring Boot apps to Azure PaaS services
such as Azure App Services, Azure Spring Apps, and AKS.
And best of all, it is free.
Let's see how you can use Azure Migrate
through your entire migration journey
and migrate RHEL machines
running Java Tomcat Workload to Azure.
We already have an Azure Migrate project
that is connected to an on-prem VMware environment.
With this setup, you can see a variety of servers discovered
based on RHEL, Ubuntu, and other operating systems.
You can also see server information such as:
OS version, storage, disks, et cetera.
You can also view the software inventory
and web apps running on this RHEL VM.
In the discovery, we discover the Spring Boot apps
are running in the customer discovered servers
and list them at a server level.
Here, it shows that these are
the two Spring Boot apps running in this machine,
along with more details
that we capture for an individual app,
and we can now also assess these apps
for Azure Target like Azure Spring Apps.
In the assessments, we show the app readiness
to move to the Azure target,
along with its estimated monthly cost to run.
We can also show why the apps
are not ready or ready with conditions
so that customers can leverage that information
to mitigate the challenges.
Once you've discovered the inventory,
you can generate a business case
that can help you identify the benefits you can get
by migrating to Azure.
To do this, you click Build business case,
provide the name,
target location where the details will be stored in Azure,
discovery sources, which is appliance in our case.
Now, you can optimize your migrate settings
to minimize cost or move to PaaS.
Let's optimize the cost.
You can select the discount you would've gotten
out of the Azure Enterprise Agreement and click generate.
It might take a few minutes
so I have a business case ready for you.
In this business case,
you can view the estimated total cost of ownership
of running the workloads and servers in Azure
and the comparison of it based on the on-premises costs.
You can also look at the detailed breakdown
of the Azure IaaS and PaaS costs
and review the cost assumptions taken
for your on-prem servers and licensing.
You can also export the reports
that can be shared with your business decision makers
to get closure on your migration decision.
Note, that the Linux license costs are assumed zero here
and the compute and storage costs
are incorporated for the business case calculations.
Next, to help you with your migration plans,
you can perform Azure Migrate assessments
that help you provide the readiness, cost benefit,
and target path for the migration
for each of your inventory items.
To create an assessment, you click on Assess.
Now you can migrate to multiple targets using Azure Migrate
such as Azure SQL, Web Apps, and AVS.
I'll go forward with the Azure VM
and provide the name and the source of discovery.
By default, the assessment performed is performance-based
analyzing the PERF for the past few weeks
with prevalent VM sizing and pricing settings.
I can override assessment settings
to change these settings as necessary.
I'll continue with the defaults.
Next, let me select the on-prem servers
that I want to assess.
I can view the OS and other details
to help in the grouping and then click Create.
It should take a few minutes,
so let me go to an existing assessment
and show you what it looks like.
Here, you can see we have a detailed report
of the Azure readiness, cost estimate,
and recommended configurations
for these servers for migrating to Azure.
This information can help customers identify quick wins,
close on the migration approach,
and plan for their migration journey.
Once the migration plan is closed,
you can use Azure Migrate to leverage the plan
and perform migrations as well.
I'll now show you how easy it is
to migrate your applications
and databases running on Linux servers
to Azure using server migration.
To start, you need to initiate the replication process
that copies your on-prem data to Azure.
In this, we'll set our targets as Azure VM,
the type of virtualized platform, VMware, vSphere,
and the appliance that was set up for discovery.
Now we can import the assessment plan
or select the server manually that I plan to migrate.
I'll select my RHEL VM.
Now I can choose my target settings.
I'll choose my subscription, region,
resource group where my VMs will reside post-migration,
then, my VNet and subnet
so that my VMs can communicate once they're migrated.
I can choose to right-size the compute and storage settings
to ensure that we get the best out of Azure.
I'll keep the defaults compute and storage details.
Next, I can choose to tag the replicated resources.
And in the review and start replication tab,
I can kick off the replication process.
Azure Migrate supports up to 500 VM replications
at the same time.
Now, the initial replication takes some time
depending on the data.
To speed up the demo,
I have some VMs already replicated and ready for migration.
Next, you can perform test migration
to deploy the VM in an isolated test environment.
This enables you to perform all the end-to-end testing,
user acceptance testing, et cetera,
to ensure that the migrated application
is working as expected
and you can migrate to Azure with confidence.
Once you're satisfied with the migration,
you can clean up the migration
and perform the final migration.
Similar to test migration,
you can perform the final migration.
In this step, you can additionally choose
to shut down the on-prem VM
to ensure zero data loss as you migrate to Azure.
Once you migrate,
the workflow starts and completes your migration
and your migration completes.
So in this session, we saw how you can use Azure Migrate
through your migration journey
to help you decide, plan, and perform migration.
We saw how it was to migrate your RHEL VM to Azure.
The customer journey, however, does not end here.
Once you're in Azure,
you can continue to optimize your infrastructure.
You can leverage Azure hybrid benefits
to reuse your on-prem licenses
and save huge costs when in Azure.
You can also utilize all the services
and capabilities Azure provides.
Thank you. (bright music)