What a VM can tell you about migrating a Datacenter

Migrating an entire datacenter from on-premises into the cloud is huge proposition. Don’t let anyone fool you by telling you that it’s easy.

At almost every instance the topic of migration of datacenter to Azure comes up in a conversation, the first things that get thrown into the din are the 5Rs(Re-host, Re-factor, Re-platform, Re-Engineer and Retain). Yes people, I give it to you these are important buckets to categorize your workloads into, but there is so much prior design thought and engineering work that has to be put in before you start spending significant time classifying workloads amongst these 5RS. Many organizations perform this work under the Cloud Enablement program, but often underestimate how vast this program can become.It is helpful to comprehend the situation by using a mental model. In this case let a single humble Virtual Machine be that mental model.

Virtual Machine – Mental Model

Domain / Identity:

A virtual machine in a organization is typically domain joined. If there is an application running on that VM, typically that application authenticates users from the organization. There are two separate domains to consider here, a domain join Domain (in which the virtual machine sits) and an identity domain (in which the users sit). There are few decisions that have to be made.

  1. How would you design your AD domains in Azure. How different would that be from your on-premises?
  2. Did you setup your Azure AD properly. Are you syncing users / groups from your on-premises into Azure AD?
  3. Are you considering separate user account to access the Azure Control Plane? If yes, how will you provision these accounts, any automation factored in?
  4. Have you tested for latency? How much more AD server capacity do you need?
  5. Azure AD uses modern authentication methodologies driven by federation. How will your legacy applications deal with this when they move to the cloud?
  6. If you are using third party technologies on-premises for federation, how will that interplay with Azure AD? Have you implemented the necessary changes for the interplay to work.
Operating System
  1. Have you thought about Operating System availability on Azure. If you are using Windows Server 2008 or below then those operating systems are not supported on the Azure platform. Have you sensitized your application teams to test out their software on newer operating systems given the impending move to azure.
  2. In similar vein, have you thought about any custom software licenses that require the machine to stay on-premises. If however, the VM could move to the cloud how would it communicate with the license server?
  3.  Have you thought about what would happen to a running application if Microsoft decides to patch the underlying VM. This requires you to use availability groups. But usage of availability groups assumes that your application can be load balanced. If your application is very aware of the machine on which it is running, then availability groups does not work for you. This requires some fundamental application re-design.
  4. Have you taken a look at your existing Windows Server / SQL Server licenses. If you already own these licenses, this can massively reduce your Azure Windows VM Costs. How much cost savings can you expect? How would you ensure that you are benefiting from these savings?
  5. Similarly for SQL Server on a VM, you can only use gallery supported versions. For instance SQL Server 2012 on Windows 2008R2 is not supported. Have you accounted for cases such as this?
Configuration Management
  1. Have you given a thought to your configuration managers such as SCCM, Puppet, Chef etc. How are you currently hardening your OS installations on-premises. How would that translate to Azure?
  2. Typically the number of datacenters that organizations manage are small when compared to the number of Azure regions they might decide to use. Have you provisioned for your configuration manager master nodes to handle the capacity?
  3. Have you updated your scripts / configurations or what have you to handle the Virtual Machines that shall be spun up in the cloud? Have you tested every bit of this? How resilient to failure is this thing?
  4. Do you have enough optics into successes / failures. Do you know what to do when this thing fails and how you plan to correct.
  5. Have you thought of the support and operations personnel that have to be staffed to address these failures?
Hardware:
  1. Of course every VM has a processor, some amount of memory and disk space. The configurations that you have in your on-premises environments may not be a match with what you have in Azure. Have you understood the differences and performed a planning exercise.
  2. Have you standardized on any sizes? How are you planning to enforce the use of these sizes?
  3. For general decision making, have you standardized on any T-Shirt sizes? What does a small, medium, large VM mean in your organization?
  4. SSDs cost more than HDDs. Where would you use an SSD in your organization?
  5. Have you mandated and enforced policies to ensure that only managed disks are used.
  6. Do you have any dependency on D drive. On Azure the D drive is ephemeral only. Have you planned for mitigation of risks that arise from this?
  7. Azure today only supports BIOS boot format. Are you using UEFI on-premises? If yes, have you written the necessary automation to convert?
Network Attached Storage / Network File Storage:
  1. Some applications depend on a NAS/NFS attached to the VM. When you decide to move your workloads to the cloud, the data in the NAS/NFS has to move too. More so, it has to move in a manner that provides for the same access patterns to the applications as it exists on-premises. Have you given a thought this problem?
  2. Its very unlikely that you can do it all at once. You have to have a way of syncing up to the cloud, running your Azure and on-premises storage simultaneously for while before you cut the cord on your on-premises storage.
  3. Have you considered shipping your data in a secure fashion using Azure Import/Export service?
  4. How would you backup and protect your NAS / NFS data in Azure?
  5. There are Azure native offerings and compelling third party offerings as well. Please make an informed choice here.
Backups:
  1. How are you going to backup your Virtual Machine disks in the cloud. Have you put in place a design for this. Have you tested this for scale and size.
  2.  Have you put in place automation for backups to happen periodically. Have you accounted for the size of the backups? Have you decided how long you need backups in the Azure?
DNS:
  1. Where will your DNS infrastructure live for virtual machines that will be migrated to Azure?
  2.  Have you put in place the automation necessary for automation to make forward and reverse DNS entries. How resilient is your DNS infrastructure.
  3. What are the DNS resolution latencies? Are these numbers acceptable?
Networking:
  1. Have you established secure connectivity from your on-premises into Azure? Have you enabled express route? Have you planned for the network capacity that you might utilize?
  2. Have you established firewall rules that gates traffic between your on-premises datacenters and Azure? Remember there a few important decisions to make here. Do you want traffic to flow bi-directionally? There are always exceptions to the rule? Do you know what some of those are?
  3. Have you planned for the IP Address space that you would need in Azure. How will this space be divided up and amongst what Networks?
  4. Have you established thresholds beyond which you would create new entities. Have you established procedures to monitor these thresholds and current utilization levels?
  5. What are your baseline Network Security Group rules? Where will these NSGs be assigned? Did you take into account any need for User Defined Rules and Network Virtual Appliances?
  6. Have you planned for North-South, East-West Isolation, Micro-segmentation so as to enable zero-trust network security architecture?
Monitoring:
  1. Have you turned on Azure Security Center, Azure Monitor? How do you plan to remediate the violations? Who has the authority to remediate?
  2. Have you planned for using OMS? Have you configured OMS, written queries to visualize and report on the important infrastructural data?
  3. Have you set up important alerts and SLAs to respond to those alerts?
  4. Are you actively monitoring utilization of Azure subscriptions vs limits imposed by Microsoft?
  5. What are all the third party security solutions that you have invested in. Are those solutions configured to monitor your environment? Are you seeing reports from those solutions? More importantly are you acting on any of them?
Governance Aspects:
  1. Do you know how you would organize your subscriptions and resource groups in Azure?
  2. What is your RBAC strategy?
  3. Have you considered implementing ARM policies for your organization. What does your Management Group hierarchy look like?
  4. Most often the need for HA/DR or planning for network segment allocation, subscription allocation for is overlooked. Do you have a plan for this place?
  5. Have you established a Cloud governance council with key stakeholders in your organization to set and drive Cloud adoption.
Costs:
  1. Have you tagged your Azure resources with a cost code. Does your organization utilize a chargeback / showback model. Have you put in place the necessary automation that can accomplish this?
  2. Do you know how much you will consume in Azure? How much your consumption is likely to grow?
  3. Have you considered negotiating preferable rates with Microsoft?
  4. Have you signed up for pre-commit of Azure to bring down your rates?
  5. Have you turned on Azure Advisor and have you put in place SLAs to implement the recommendations?

 

If you have given a good serious thought to all the above and have made progress in implementing at least some of these that you deem critical then you are ready to debate the 5RS. Now if you do take up actual migration work, then chances are that you are going to be successful.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.