- Up next, we'll look at Azure as a platform
for running your Linux virtual machine
and open source database workloads,
from your options for how you can lift and shift
existing VMs and databases to Azure,
and also modernize them using cloud-native approaches.
So, today I'm joined by Matt McSpirit
from the Azure engineering team,
and also no stranger to Microsoft Mechanics.
Welcome back.
- Hi, thanks for letting me back on.
- And thanks for joining us today.
So, we wanted to do a show based on Azure support
for open source platforms across operating systems,
with different Linux distros and also their publishers
and open source databases.
You might be surprised that more than 50%
of the workloads running in Azure
are actually running on Linux VMs.
- Yeah, that's right.
And we've been working with Red Hat,
SUSE, Canonical, Flat Car, Elastic and HashiCorp,
and open source databases like MySQL,
Postgres, Cassandra, MariaDB, and more for years.
And it's actually more than 60% of our marketplace solutions
that run on Linux,
and we support open source native PaaS services too.
Then beyond the workload level,
we also contribute back to the upstream Linux
and Kubernetes communities that many of the modern
and cloud native architectures rely on.
- Okay. So let's unpack this a bit more
starting with your options then that we have
for running infrastructure in VMs.
So, if you're a Linux shop maybe running multiple platforms,
what's the best way to think about
running Linux VMs in Azure?
- Well, nearly every business or organization out there
is running on multiple platforms.
So there isn't really a concept of a pure Linux shop
or a Microsoft shop these days.
And both platforms have a lot of pros and cons,
and we've done a ton of work for performance,
reliability, manageability, and security
to make Azure the best home
for running any open source workload.
Now, starting at the foundational level; as I mentioned,
we're working with the leading Linux distros
to optimize the kernels for Azure,
including tuning the kernel for a Hypervisor,
providing updates and patches and performance enhancements
for running open source databases.
And we also work closely with Red Hat for managed services
like Azure Red Hat OpenShift,
and SUSE with SAP enhancements.
So we want to make sure when you bring
your workloads to Azure,
there's benefit in every step of the way,
from onboarding to operation, and you gain more security
than you may have had on premises,
in your private cloud or in another cloud.
And whether you're starting green field
or bringing what you've already got running through Azure,
we've got you covered.
- Okay, so spinning up a couple of VMs,
I think from Azure is pretty straightforward.
But, what if you got dozens or hundreds of VMs
that constitute your apps,
how would I bring those into Azure?
- Well, Azure Migrate is, as we know,
your one-stop shop in Azure
for bringing in virtual machines, databases,
complete applications, even entire VMware sites into Azure.
And of course, you can rebuild or rehydrate everything
using automation for the apps you install in
VMs running in Azure.
And those will work the same as you'd expect.
But unless you've fully automated that process,
you'll likely save a ton of time using Azure Migrate.
- Great. So, let's make this real though.
Can you show us how you'd move an open source app then
from an on-prem system into Azure?
- Sure. Now, first I'll start by showing you
our app called Airsonic.
It's an open source Java app that you can find on GitHub
and it's used to host podcasts, as you can see here.
Now, it's running in an on-prem VMware environment
and consists of a frontend VM
running on Apache Tomcat on Ubuntu,
and a backend VM with MySQL also running on Ubuntu.
And I want to migrate and modernize the app.
So here's what I'm going to do.
We want to start by lifting and shifting
the frontend VM into Azure.
Now, as I mentioned, the backend database
is running in MySQL on a Linux VM.
And instead of lifting and shifting that,
I'm going to migrate the data directly from in the VM,
into Azure MySQL, a PaaS service,
so that I don't have to worry about managing that VM
once the data's in Azure.
And finally, we'll take the frontend VM from the first step
and containerize it so that it runs as a container
in the Azure Kubernetes Service.
And this step is all about modernization
and being able to take advantage
of cloud native, scalable compute.
And of course, that last step of containerizing the app,
well, you can do that from anywhere.
It doesn't need to be currently residing in Azure.
I just wanted to start by showing you a lift and shift
VM-to-VM migration,
because it's probably where most people will start.
So, I'm in Azure Migrate,
I've already performed a VM discovery
on my on-premises, VMware environment.
And you can see we've got
hundreds of Linux virtual machines here.
- Right. And by the way,
if you want to see how that process works
for Azure Migrate, we've got a complete step-by-step guide.
So check out our recent show
on Azure virtual machine migration using Azure Migrate.
Now the process is the same by the way,
for both Linux as well as Windows.
- Absolutely.
So in my case, since I've already run the discovery,
I just need to search for the VMs I want to migrate.
So in this case, I'm going to search for Woodgrove,
and you'll see that these two VMs that make up our app
both are running Ubuntu with two cores and four gigs of RAM.
And if I click into software inventory,
for this one you'll see everything running in each machine.
I can also see dependencies,
which is all the TCP/IP traffic connecting to our VM.
This way I can ensure I migrate everything I need to.
Now looking at Port 3306, you'll see my SQL server.
And if I switch tabs to my assessment
and click into assess Azure VM,
then edit our assessment properties,
you'll see all of the options for basic properties,
VM size and pricing.
Now I'm going to close that and next,
I'll create an assessment using those two VMs.
I'll give it a name, AirsonicPAYG, pay as you go.
Now I'll create a group with my two VMs
and I'll call it Airsonic.
Then I'll search for Woodgrove again,
select my two VMs and finally hit create assessment.
Now, if I click into the assessment,
you'll see the details for Azure readiness,
with cost details for storage and compute.
And when I click into Azure readiness,
I can also see the recommended VM size,
in my case both the standard F1.
If I click into cost details,
you'll see the cost estimates broken down
by compute and storage.
Now I can tweak all of these values,
but everything looks good to me and we can start migrating.
- So now that you have the assessment complete,
how do you go about doing the actual migration?
- Well, with Azure Migrate, you could move both these VMs
and the tools even scale to thousands of VMs
if you've got a load of apps.
But in my case,
I'm only replicating the one VM for the front end.
So, I'm still in Azure Migrate
and below the assessment tools are the migration tools.
So I'm going to click into replicate.
I'm going to choose my virtualization platform,
in this case VMware, select my appliance and hit next.
And here I could import my assessment to migrate.
But since I just want to migrate the one VM,
I'll specify the settings manually.
I'm going to search again for Woodgrove
and choose the Airsonic frontend VM and hit next.
And here I need to enter standard options in Azure
as the target settings, like location,
subscription, VNet, etc.
Now to save time everything's filled in,
and so I'm going to hit next.
Now I can choose my VM size
and I'll just pick a standard D2a_v4 and hit next.
I'll keep all selected in the disks tab, and hit next.
And now I'm ready to replicate.
So let's go ahead and do that.
That'll save the contents of the VM into my storage account.
And back on the Azure Migrate tab,
you'll see our replication has started.
If I click into it I can test from here, but to
save a step, I'm just going to go straight into Migrate.
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.
Here, I could just continue using the on-premise database
if I needed to keep it on-prem,
but I'd just need to make sure this VM could reach it,
and then just redirect the app's DNS settings
to this new IP.
- Okay. So in this case, your app is still running,
but now you've got the front end as a VM in Azure,
but the database is left running as VM
in your on-prem environment.
So, how would I move the database then into Azure?
- Well, we've got tools that can help with that as well.
So, instead of replicating and migrating as a VM,
I'm going to convert it to the PaaS service.
That way in the future,
I don't need to worry about managing that underlying VM.
So let's do that.
We'll use the Azure Database Migration Service
to migrate our databases contents to Azure MySQL.
Now DMS works for both MySQL and Postgres.
The first thing I needed to do in this case
was create a MySQL instance in Azure,
which I have done in advance.
Now in the MySQL workbench,
I set up a tab for my source VMs database on-prem
and one for my target in Azure.
Knowing the source, I can see all of my tables,
but in the target you'll see there aren't any tables.
Now using the CLI
I'll run a MySQL dump against my source database.
Enter the source database password.
And with this command,
I can see it's already created a dump,
and this is a pretty small database.
Now I just need to import the dump I just created
into our target database in Azure
with this command containing the address.
I'll enter the target's database password,
and this is just copying a schema and a table structure
over to the target instance, but not the data yet.
And once my dump has moved into the target,
I can go back to the my SQL workbench,
and in the target database tab
I'll refresh and I can now see all of my tables are there.
But they're still empty, so let's fill them.
So next I'll head over to the
database migration service in Azure.
I've already created a DMS instance in advance,
but now I'll create a migration project.
I'll give it a name, Airsonic test migration.
I'll choose the target server type
and you'll see additional options here,
including Postgres and Mongo, but we're using MySQL.
And now I'll hit create and run activity.
It's going to ask me for source details, server name or IP.
I'll enter the IP.
I'm going to keep Port 3306 into my username, root,
and my password, and then I'll move to the target settings.
So I'm going to paste in the server name, its address,
my username, Airsonic admin and password.
And now I can choose the databases I want to migrate.
I only need to move the Airsonic one.
So next, I'll configure the migration settings
and you'll see DMS found our 36 tables.
I'll take a look at everything
and keep all the tables selected and move on to the summary.
And now I just need to give the activity a name,
Airsonic migration 1, and hit start migration.
Now I can monitor everything here,
but since our database is only a little bigger
than two MB, if I hit refresh, you'll see it's complete.
Now, if I click into it,
you'll see my tables are all complete as well.
So now, it's up and running in our Azure instance.
And if you have a large database, we've got super fast,
parallelized, Azure DMS migration for MySQL,
where we've been able to burst up to 188 GiB per hour,
which is great to minimize the servicing window.
And if you need to, you can even migrate deltas
between the first and final migration.
Now, finally,
we would normally update the connection strings
so our app knows about the new location of our database.
But we're going to wait,
because I want to modernize the front end
to run in containers,
and that's going to take just a few minutes.
But this will also open up better scalability,
and I won't need to maintain the Ubuntu VM.
- So how do you repackage or convert then your front end VM
and everything inside of it so it can run as a container
in Azure without having to rewrite the app?
- So for that, I can use another tool from Azure Migrate
called app containerization to containerize the front end VM
without needing to rewrite the application.
So under explore more in the Web apps to Container section,
I'll click into app containerization.
And you'll see this works with ASP.NET apps
running in AKS and Java web apps running on Apache Tomcat.
Now from there, I'll download the tool and with it running,
I'll need to specify the app type, in our case, Java.
I'm going to walk through the pre-recs
and make sure SSH is enabled, then continue.
And 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.
And I'll use the IP here
and enter the username and password.
Now, once I validate connectivity, I can continue
and that will discover the apps running on my server,
and you'll see it found our Airsonic app.
So I just need to select it
and enter the target container, Airsonic V1.
And here, I'll take a look at the parameters.
I'll keep all of these settings and check all the boxes
for username, password, and URL and click apply.
Now I need to make a slight edit to the app folder location
to map everything correctly.
So I'll add a new folder and enter the path.
Then I'll change the target storage to a persistent volume
and save my changes.
And now we can move on to the build.
Now I just need to choose my Azure container registry
and select my container.
I'll hit build.
And after a moment, it succeeds.
So now I can move on to deployment specifications,
where I just need to select my AKS cluster called
Contoso-AKS, and then continue.
Now I'll specify my file share with subscription,
storage account, and the file share.
Now to save time, I've configured these in advance.
Now in the deployment configuration,
I 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,
and enter my username, password, and the URL.
I'll keep the storage config as it is, and I'll hit apply.
And now we're ready to deploy.
So I'll do that, and once it's finished,
I can click into the link here
and see the public IP and the resources.
And just to test this out, I'm going to go into kube control
and run a get service command,
and you'll see our Airsonic containers
running along with the external IP
and port that we just saw.
So now let's try this in the browser.
I'm going to paste in the address and there's our app,
and I'll make sure everything works and it's looking good.
So now we've migrated our app into Azure
and even modernized it to use MySQL PaaS
and cloud native containers.
So it's going to be way more scalable and easier to manage.
- Okay. So now that your app is running in Azure,
what are some of the other things that you can do?
- Well, there's a lot.
But to look at just a few highlights, firstly,
there are a ton of options
to take advantage of for high availability.
So those start with VM options for availability sets
and availability zones for redundancy,
all the way to disaster recovery solutions
to ensure your services are as resilient
as you need them to be.
Now moving OpenStack into the management layer,
we've also integrated Linux and open source databases.
So, all the scaling and elasticity in Azure works for Linux,
such as virtual machines scale sets,
diagnostics monitoring and software update management
are all built in.
You can use the Azure portal
to manage all of the Linux-based services.
And you can take advantage of proactive security
with Azure Defender and the Azure Security Center
to keep your infrastructure and your data protected.
Plus, there are AI and ML capabilities
that can be applied to your Linux stack,
enhancing your application and workloads
with cognitive services or machine learning services.
And if your organization uses managed Linux services,
we've worked closely with Red Hat and SUSE to offer unique,
integrated support experiences where you can raise tickets
and our support team will work with Red Hat
or SUSE support teams to triage cases together.
And in fact,
Azure is the only cloud service doing that today.
- Right. And these are just a few examples of how Microsoft
is working with the open source community.
So Matt, if anyone is watching
and they want to get started, what do you recommend?
- To find just about everything related to Linux
running on Azure, check out azure.com/linux.
And once you're ready to test out a migration,
you can get to Azure migrate at aka.ms/azuremigrate.
And to find the tools to migrate your data stores,
check out aka.ms/datamigration.
We've also got a ton of learning content available
on Microsoft Learn.
- Thanks Matt, for the comprehensive overview
and look at what Microsoft's doing
with the open source community
and also how you'd bring your open source apps into Azure.
Of course, keep watching Microsoft Mechanics
for the news and deep dives in the latest tech.
And be sure to subscribe if you haven't already,
and thanks so much for watching.
(air whooshing) (logo chiming)
(upbeat music)