2018: The year you migrate to the cloud?

2018-01-23T23:52:54+00:00 January 24th, 2018|Azure, blog, Cloud, Disaster Recovery|

Welcome to 2018, where the rush to the cloud shows no sign of slowing down.  New Azure features are being released so quickly that the Azure marketplace seems to show new services every day.  I sometimes see new features arrive between button clicks!  It is probably safe to say that we are in the “majority adopters” phase of the traditional technology adoption curve for the cloud.

The big question for you is whether this is the year to migrate your data center assets to the cloud.

Lift and Shift vs. Application Modernization

The first thing you need to consider is whether you want to “lift and shift” your infrastructure or start an application modernization project to move your digital assets to the cloud.

Lift and Shift Methodology — This method consists of cloning your server infrastructure to the cloud and transferring the data to the new servers.  The new servers are cloned as virtual machines (VMs) operating as they did in your on-premises infrastructure.  The plan detailed below is going to focus on this methodology.

Application Modernization Methodology — This method requires you to refactor your applications for the cloud.  There are significant cost savings available long term using this method; however, the conversion cost will be much higher than a straight “lift and shift” to the cloud.

The “Lift and Shift” Plan

Azure provides several tools including Azure Migrate (public preview) and Azure Site Recovery (ASR) to execute the migration to the cloud, but you need to understand what you are trying to accomplish.  The following is a typical plan for one of these projects:

  • Assessment – Use tools to collect data in manual or automatic ways to perform a documented analysis.  Data that should be collected and analyzed include the server function, operating system, cores (or CPUs), memory, disk sizes, and network performance.
  • Selection and Planning – Once the assessment is complete, you can then select the servers or workloads that are good candidates for migration.  You should also identify any server issues such as unsupported operating systems, large disk sizes, or incompatible disk technologies.  For example, disk sizes over 4TB cannot be cloned using ASR as of this writing.  Items like available network bandwidth, maintenance windows, and business objectives need to be considered before publishing your plan.
  • Environment Preparation – With any on-premises migration to the cloud, network constraints may need to be implemented (such as QoS and firewall changes for future replication). The target also needs to be created in Azure consisting of the new network, storage, and virtual private networks.  If you are using ASR, an on-premises process server needs rollout.  In this stage, I also recommend implementing a monitoring solution where you can watch the process server health and network bandwidth.
  • Replication – This is probably the longest and most tedious part of this entire project.  At this stage, the data is replicated using the selected migration tool.  Like any backup or disaster recovery solution, the longest part of synchronization is the initial data replication.  You do not merely want to replicate all the servers at once because you could significantly affect your available network bandwidth and that could make you unpopular.  When your end users come to find you with their torches and pitchforks, that’s very bad.  I have seen in the migrations that I have managed that doing more than 2-3 initial replications at a time is the limit.  Once a server has completed the initial replication, then you can add others because the completed servers need incremental changes over time.
  • Cutover – You are almost there!  Now comes the maintenance windows where you can migrate to Azure and then disable the original server.  Depending on your project and business needs, you can either do it all at once, or break up the list based on workloads and other factors.  Doing the migrations in multiple, distinct sets reduces stress.

Here at Coretek we do many of these projects every year.  We can definitely help you with your migration to the Azure cloud!  Just give us a call.

Disaster Recovery: Asking the wrong question?

2017-07-27T00:00:58+00:00 May 11th, 2017|Azure, blog, Cloud, Disaster Recovery|

image

In my role as an Azure specialist I get asked a lot of questions about Disaster Recovery. IMHO they almost always ask the wrong question.

Usually it goes something like “I need Disaster Recovery protection for my data center. I have N VMs to protect. I have heard that I can use Azure Site Recovery either to facilitate Disaster Recovery to my backup data center, or even use Azure as my backup data center.” That is true. Smile

In a previous lifetime I used to work on a Disaster Recovery  testing team for a major New York based international bank. We learned early on two major principles:

1. It is all about workloads since different application workloads have different Disaster Recovery  requirements. Every workload has unique Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Not all workloads are created equal.   For instance email is a critical workload in the typical enterprise. An outage of more than a few hours would affect business continuity significantly.  Other application workloads (such Foreign Exchange Trading, Order Processing, Expense Reporting, etc.) would have more or less stringent RTO and RPO requirements.

2. So it is really is all about Business Continuity. Disaster Recovery is a business case. It is clear that providing perfect Disaster Recovery for all application workloads would be extremely expensive; and in many cases not cost effective. In effect there is an exponential cost curve. So it is all about risk management and cost/benefit.

So where does that leave us?

1. Evaluate your Disaster recovery requirements on a workload by workload basis.

2. Plan how to implement it considering the objective of Business Continuity, RTO and RPO.

3. Use Azure Site Recovery to make it happen. Smile

This article originally posted 4/1/2016 at Bill’s other blog, Cloudy in Nashville.