Cloud Migration with VMC

Thinking back through my experiences with migrations to cloud highlighted just how difficult the whole process has become compared to the migrations I was part of early on in my IT career. 

Back then, the earliest phase of a migration was introducing server virtualisation into the datacentre, where the economies and return on investment from shifting from a 1:1 operating system/physical host was about as compelling as you could get. The business cases basically wrote themselves and the migrations, while not always easy, could follow a fairly standard approach. We could roll out our conversion tool of choice and P2V the workloads, and there weren’t too many variables in the mix.

Fast forward to the world of heterogeneous hypervisors and private clouds, and things got a little more interesting – moving workloads between Xen, vSphere and Hyper-V added another layer of complexity. But we still hadn’t moved into the SDDC model, and things looked mostly the same as all our workloads stayed in the datacentre and we were not interested in refactoring or rearchitecting our applications; we just wanted to lift and shift the whole OS and make minimal changes along the way. Application support teams shouldn’t see any difference.

So now in the age of public cloud migration why is the process more difficult, costly and sometimes prone to setback? Maybe because now with all the ways to modernise how our applications run, there is the option now to pull functions from the traditional operating system and have this run in a managed service – adding ‘transform’ to migration. We now open up a bunch of new challenges; how do I secure this new service that can be run on an internet accessible IP, how do I integrate with my monitoring view, do I get all the features I got when I ran my database on a server, and who is going to do all the testing?

Here at Cevo we’ve worked through many migrations to the cloud and our goal is always to provide a fit-for-purpose solution to support our customers business goals, whether that’s application modernisation or data centre exit. To support migrations at scale and at pace, we’ve partnered with VMware to incorporate the VMware Cloud on AWS solution into our migration toolkit for those workloads that are just too hard to migrate and transform at the same time.

So, how does VMC on AWS help with migrations?

If I think through the simple example of a typical application stack there might be multiple layers of complexity that take time to work through and could derail a migration program if there is not the appetite to spend the time and budget on transformation.

Let’s look at the following picture of what may be typical things lurking in your on-premises VMware vSphere environment 

1. Trusty load balancer – could be F5, NetScaler, or something else. These types of devices are incredibly powerful for managing the delivery of applications to your internal and external users – hopefully all you have on these are some simple HTTP load balancing rules and no complex content rewrite or content switching rules. If the latter you may be in for some time consuming application remediation
2. Web servers – usually nothing too controversial at the web layer, depending on whether you have certificates, authentication, content management and other factors organised
3. Middleware – do you have the source code, documentation and/or anyone who knows what’s on there? May or may not a problem
4. Database – sometimes where the fun begins; ODBC drivers, multiple SQL roles such as reporting, SSAS integration services? What about collation, stored procedures, not to mention the security model to support operations. This setup will be tricky to move and if you do, do you have a backup solution in place that meets RPO requirements and also archival of old backups if required?

All solvable problems of course, but what if you have 20 of these stacks and a deadline? 

What if your team is not yet set up to manage all the new cloud services at scale?

How do you get them into the box on the right? 

Where VMC can help is to take the pressure off by allowing you the luxury of not solving all the problems at once – get your apps into AWS and then in phase 2, phase 3, and phase 4 transform the application without the risk of a rushed re-architecture.

Let’s look at what this looks like if we attack the ‘low hanging fruit’ but leave the nasty challenges to a future when you have time and resources to tackle them properly.

1. Firstly, let’s get VMC enabled in your AWS environment and connect your network via Direct Connect or VPN. Hiding some of the detail here, but essentially with NSX-T you can now use the network underlay to provide vMotion or Clone via either layer-3 connectivity to your on-premises vSphere or layer-2 stretched VLAN to preserve IP addressing. So now anything on the left we can move to AWS with a right-click in the VMware console.
2. We can move the SQL databases across with minimal changes. In fact we can preserve service accounts, IPs, all the operating system configuration and deploy AlwaysOn Availability Groups across Availability Zones in AWS. Fully integrated into AWS VPC, we can plug and play with all the AWS services we require
3. Application servers can be Cloned/vMotioned across. These maybe easy to transform, but at the risk of delays for testing and other work we may decide to break this work up to remove complexity
4. Do the web servers run simple Tomcat or IIS with a bunch of dependencies? We may just deploy some EC2 to handle this, or vMotion the web servers across
5. If the load balancer is just running some basic rules we can replace with a native AWS Application Load Balancer, or if it’s doing a few more clever things we may just deploy a marketplace appliance into VMC and drop the on-prem configuration on – we can unpick this one later on!

Great, we’ve done the migration – but we just shifted a legacy pattern into the cloud, so now what do we do about it? Transformation is really the aim of the game when moving to the cloud, so let’s look at some of the options now that we’ve made it into AWS

1. Web servers can move across to ECS Fargate as a low-cost, low-overhead solution once we’ve had a bit of time to see how the application runs. There are significant savings to be made by transforming your simpler workloads to this pattern, and I’m seeing this with the organisations I work with where it’s not all-in on containers/serverless but more along the lines of identifying the easy wins and getting maximum value up-front
2. Our Java middleware can also move to Fargate or potentially some other serverless solution
3. Some or all of the database may end up on RDS, or in a hybrid solution, it all depends on the cost/benefit of the transformation and priorities

Summary

In summary, VMC can be an invaluable part of your migration toolkit if you have a number of legacy application stacks in your on-premises datacentre that you need to move, but you are challenged by timeframes, operational readiness or resourcing. VMC can be the stepping stone you need on large scale migration to get primary goals like datacentre exit, realised in realistic timeframes.

I hope this was a helpful introduction to the one of the use cases for VMC on AWS; drop us a line if this is something Cevo can help you with.