IBM Guest Blog: Tips on lift and shift of VMWare workloads to the cloud
Cloud First?
What do you do when you have been given a “cloud first” mandate, but you know that it will take months or years of effort to re-platform your applications for cloud – and in the meantime you are faced with an aging infrastructure and technical debt?
This is an issue for many parts of the NHS today, leaving many organisations in limbo. It can be a challenge to secure funding to do essential maintenance and upgrades in your on-prem environments, whilst not having the budgets, manpower or skills to rewrite your applications for cloud; or to research and test software-as-a-service alternatives.
“Lifting and Shifting” VMWare workloads to the cloud is an option that many are considering, and it can provide an economical alternative to application modernisation. Below is a guide to the key considerations for a successful project.
1. Rationalise
The first step to any cloud migration is to ensure you’re not migrating workloads and data that are no longer needed. It is worth going through every VM to assess what it is, who owns it, and whether it is still needed. If you suspect that the VM has an over-allocation of resources, then check that by resizing in the source environment where you can rollback any change if performance is impacted.
2. Design the target architecture
In most cases, workloads for different environments (dev, test, prod etc) and projects can run on the same VMWare cluster, using virtualised networking (NSX) to provide logical separation between your different workloads. In fact, it is preferable to have this blend of workloads to optimise resources.
However, there are some situations where separate clusters are needed. For example, if you have Oracle workloads, you will want to place those on a separate cluster of minimal size to limit license costs. Or sometimes customers require a separate management cluster for separation of duties, and again a minimal size and number of hosts is needed for this to reduce costs.
Complex network requirements will likely need to use VMWare’s NSX to provide a network overlay mechanism. This will enable you to do “bring your own IP” as well as define your network segments according to your specific needs. However, more simple network requirements may not need to use NSX and on some clouds it is possible to deploy vSphere hosts only without NSX.
3. Size the target environment
Look at the total amount of virtual cores (vCPU), memory and storage that is required in each cluster and compare this to the host sizes available on each of the cloud providers. Most cloud providers only have one or two bare metal sizes to choose from, and the number of hosts you need will be determined by your CPU, memory or storage constraint. Other providers offer a much more flexible approach where you can configure the bare metal to have enough CPU, memory and storage to fit your specific requirement – thus minimising the amount of “wasted” resources deployed. The ability to customise the hardware means that generally a smaller footprint is needed, saving you money on both infrastructure and license costs, as well as reducing your CO2 emissions.
4. Evaluate storage options
Whilst VSAN is mandated for VMware on most clouds, some providers offer the alternative option of using cloud storage instead of VSAN. This allows for smaller clusters (minimum of 4 is recommended for VSAN clusters) as well as breaking the dependency between storage volumes and number of hosts in the cluster. Using cloud storage is more flexible as you can grow storage quantities without having to add more hosts to the cluster – adding CPU, memory and all the associated additional license costs that you may not need. It is available in a range of performance tiers, allowing you to save money by only provisioning high performance tiers for workloads that really need it; and you benefit from the provider-managed redundancy to ensure a highly available solution.
5. Who can see your encryption keys?
Cloud providers routinely offer encryption of data in transit and at rest in their cloud environments. “Bring your own key” is a standard practice now – but only one cloud offers “Keep your own key” encryption using a FIPS 140-2 Level 4 certified hardware security model to provide technical assurance that even the cloud provider cannot access your encryption keys.
Please reach out to us if you’d like any help with sizing and pricing IBM Cloud for VMWare solutions.
Louise Baynton – Senior Public Cloud Technical Specialist: [email protected]
Chris Achiampong – Advisory Cloud Platform Specialist: [email protected]
