Moving existing workloads to Azure


From https://www.pexels.com/

Applications born in the cloud can take full advantage of the cloud and the agility it brings.

But there are a lot of existing solutions out there that weren’t born in the cloud.

In this article I want to sketch a very high level approach on how to proceed about taking an existing on premise solution and move it to Azure.

Let’s first talk about pure Lift & Shift.  Lift & Shift refers to the approach of taking on premise workloads and deploying them as-is in Azure.

Despite its popularity, it receives a fair bit of bad press because performing a lift and shift doesn’t give you most of the advantage of the cloud, mainly the agility.

I agree with the assessment since a lift and shift basically brings you to the cloud with a pre-cloud paradigm.  That being said, I wouldn’t discard that approach wholesale.

For many organizations, it is one of the many paths to get to the cloud.  Do you move to the cloud and then modernize or modernize in order to move to the cloud?  It’s really up to you and each organization have different constraints.

It often makes sense especially for dev & test workloads.  Dev + Test usually:

  • Do not run 24 / 7
  • Do not have High Availability requirements
  • Do not have sensitive data ; unless you bring back your production data, without trimming the sensitive data, for your dev to fiddle with, in which case sensitive data probably isn’t a concern to you

The first point means potential huge economy.  Azure tends to be cheaper than on premise solutions but if you only run it part time, it definitely is cheaper.

The last two points make Dev + Test workloads easier to move, i.e. there are less friction along the way.

Where I would be cautious is to make sure you do not need to do a lot of costly transformations in order to purely do a lift and shift ; if that’s the case I would consider modernizing first, otherwise there won’t be budget in the bucket for the modernization later.

Address blockers

red-building-industry-bricks[1]Will it run on Azure?  Most x86 stuff that run on a VM will run in Azure, but not all.  Typically this boils down to unsupported network protocols and shared disks.  Azure supports most IP protocols, except Generic Routing Encapsulation (GRE), IP in IP & multicast ; User Datagram Protocol is supported but not with multicast.  Shared disks are not supported in Azure:  every disk belong to one-and-only-one-VM.  Shared drive can be mounted via Azure File Storage, but for application requiring a disk accessible by multiple VMs, that isn’t supported.  This often is the case with Quorum disk-based HA solutions, e.g. Oracle RAC.

If you hit one of those walls, the question you have to ask yourself is are there any mitigation?  This will vary greatly depending on your solution and the blockers you face.

Does it provide suitable High Availability (HA) feature support?  A lot of on premise solution relies on hardware for high availability, while cloud-based solutions rely on software, typically by having a cluster of identical workload fronted by a load balancer.  In Azure, this is less of a blocker as it use to be, thanks to the new single VM SLA, which isn’t a full fledged HA solution but at least provide a SLA.

Will it be supported in Azure?  You can run it, now will you get support if you have problems?  This goes for both Microsoft support and other vendors support.  Some vendors won’t support you in the cloud, although the list of such vendors is shrinking everyday.  A good example of support is Windows Server 2003 in Azure:  it isn’t supported out-of-the-box, although it will work.  You do need a Custom Support Agreement (CSA) with Microsoft since Windows Server 2003 is no longer a supported product.

If not, does it matter and / or will ISV work with you?  If you aren’t supported, it isn’t always the end of the road.  It might not matter for dev-test workloads.  Also, most ISVs are typically willing to work with you to make it possible.

Does it have a license that allow running in Azure?  Don’t forget the licenses!  Some vendors will have some funky licensing schemes for solution running in the cloud.  One question I get all the time is about Oracle, so here is the answer:  yes Oracle can be licensed under Azure and no you don’t have to pay for all the cores of the physical server you’re running on ; read about it here.

Address limitations

fence-1809742_640[1]

Time Window to transition should drive your strategy.  This might sound obvious but often people do not know where to start, so start with your destination:  when do you want to be done?

Authentication mechanism (Internal vs External).  Do you need to bring your Domain Controllers over or can you use Azure AD?  Do you have another authentication mechanism that isn’t easy to migrate?

VM Requirements:  cores, RAM, Disk, IOPS, bandwidth.  Basically, do a sizing assessment and make sure you won’t face limitations in Azure.  The number of VM skus has grown significantly in the last year but I still see on premise workloads with “odd configuration” which are hard to migrate to Azure economically.  For instance, a VM with 64 Gb of RAM and only one core will need to be migrated to a VM with many cores and the price might not be compelling.  Disks are limited to 1Tb in Azure (as of this writing, December 2016), but you can stripe many disks to create an OS volume.  That being said, different VM skus have different number of disk limits.

Latency requirements (e.g. web-data tier).  Basically, no, if you put your front end in East US and the back-end in South India, latency won’t be great.  But in general if you have a low latency requirement, make sure you can attain it with the right solution in Azure.

Solution SLA.  Azure offers great SLAs but if you have a very aggressive SLAs, in the 4-5 nines, you’ll need to push the envelope in Azure which will affect the cost.

Recovery Time Objective (RTO) & Recovery Point Objective (RPO).  Again, this will influence your solution which will influence the cost.

Backup strategy / DR.  Similar to the previous point:  make sure you architect your solution accordingly.

Compliance standards.  Different services have different compliances.  See this for details.

Basically, for most of those points, the idea is to consider the point and architect the solution to address it.  This will alter the cost.  For instance, if you put 2 instances instead  of 1, you’re gona pay for twice the compute.

Make it great

london-140785_640[1]

We have our solution.  We worked through the blockers & limitations, now let’s take it to the next level.

Storage:  check out Microsoft Azure Storage Performance and Scalability Checklist.

Scalability:  consult the best practices on scalability.

Availability:  make sure you’ve been through the availability checklist & the high availability checklist.

Express Route:  define your connectivity strategy & consider Express Route prerequisites

Guidance:  in general, consult the Patterns & Practices guidance.

Get it going

As with every initiative involving change, the temptation is to do a heavy analysis before migrating a single app.  People want to get the networking right, the backup strategy, the DR, etc.  .  This is how they do it on premise when creating a data center so this is how they want to do it in Azure.

For many reasons, this approach isn’t optimal in Azure:

  • The constraints aren’t the same in Azure
  • People often have little knowledge of Azure or the cloud in general and therefore spin their wheels for quite a while looking for issues while being blind to the issues that will cause them problem (usual unknown-unknowns problem)
  • The main advantage of the cloud is agility:  long up-front analysis in order to attain agility is the straightest line between the two points

This is why I always give the same advise:  start now, start small, start on something low-risk.  If you migrate 30 solutions and realize that you bust a limit of Virtual Network and have to rebuild it one week-end, that’s expensive.  But if you migrate a solution, experiment, realize that the way you laid out the Network won’t scale to 30, you tear it down and rebuild it:  this will be much cheaper.

imageI’m not advocating to migrate all your environments freestyle in a cowboy manner, quite the opposite:  experiment with something real and low-risk and build from there.  You will learn from the experiment and move forward instead of experimenting in vacuum.  As you migrate more and more workloads, you’ll gain experience and expertise.  You’ll probably start with dev-test and in time you’ll feel confident to move to production workloads.

Look at your application park and try to take a few solutions with little dependencies, so you can move them without carrying your entire park with it.

The diagram I’ve put here might look a bit simplistic.  To get there you’ll probably have to do a few transformations.  For instance, you might want to consider replicating your domain controllers to replica in Azure to break that dependency.  There might be a system everything depend on in a light way ; could your sample solutions access it through a VPN connection?

Summary

imageI tried to summarize the general guidelines we give to customers when considering migration.

This is no one X steps plan, but a bunch of considerations to remove risk from the endeavor.

Cloud brings agility and agility should be your end goal.  The recipe for agility is simple:  small bites, quick turn around, feedback, repeat.  This should be your guideline.

Advertisements

One thought on “Moving existing workloads to Azure

  1. Pingback: Azure Weekly: Dec 19, 2016 – Build Azure

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s