This post has been republished via RSS; it originally appeared at: ITOps Talk Blog articles.
Over the last few years, I have spoken to customers who are either looking to expand their datacenter into Azure or move their workloads into Azure instead of hosting them on prem. Often the workloads they are looking to host in Azure are virtual machines (VMs) or Infrastructure as a Service (IaaS) VMs.
Lifting and Shifting workloads into Azure is often the best way forward for some workloads, however there are some things that you need to think about before going down that road and make sure it really is the best fit for your organization and workload.
Legacy Operating Systems
Operating System Icon - Icons made by www.flaticon.com
Most organizations will have a legacy operating system (OS) running somewhere in their datacenter. I’ve seen plenty in my time. And often the application or workload that is running on top of that legacy OS runs fine, without any issue. The IT department and organization have taken the decision to run the risk of that legacy OS because the application or workload that runs on it is no longer available and they haven’t found a suitable solution.
Unfortunately not all operating systems are supported in Azure, most operating systems will run on an Azure Virtual Machine, I’ve successfully deployed several VMs with legacy operating systems running on them for test and development purposes but there is no guarantee the VM would run in a stable state and if something went wrong official support from Microsoft would be limited. So, it’s something to consider and weigh up carefully if you want to run that legacy VM within Azure.
You can reference the list of endorsed Linux distributions that run on Azure can be found here.
Backup Strategy
Backup - Icons made by www.flaticon.com
Every organization has a backup strategy in place, if not for all workloads in their datacenters, then for most workloads. When you migrate a virtual machine to Azure you still need to ensure that workload is protected by a backup strategy (if appropriate). And this is where some thought needs to be put in.
Within Azure there is a native backup product, Azure Backup, that can protect cloud and on-premises virtual machines. Is introducing that within your setup the best way forward? Could you use your existing backup product to protect your Azure virtual machines? Could you use a combination of your existing backup product with Azure Backup? What is going to be best to protect your workloads and be manageable going forward for your staff?
Protecting your workload is important but you don’t want to add addition load to your management.
Patch Management
Patch Management - Icons made by www.flaticon.com
Ensuring your virtual machines are patched is an important task to ensure that any vulnerabilities are secured. On-premises utilizing a Windows Server Update Services (WSUS) server or Microsoft Endpoint Configuration Manager (MECM), formerly System Center Configuration Manager (SCCM) to deliver those patches in a uniformed and scheduled way.
Much like your backup strategy, figuring out the best way of continuing to patch your virtual machines in Azure is something that you need to think about. Within Azure there is a native solution, called Azure Update Management which is part of the Azure Automation suite.
Again, like Azure Backup, Azure Update Management can deal with both on-premise and Azure based virtual machines. And it can be integrated with WSUS or MECM or utilize it independently.
Call to Action
If you have migrated your virtual machines to Azure and have any other pointers to share please let us know in the comments below.