In our multi-cloud world, workload placement is one of the most crucial IT decisions organizations make. With the plethora of mature and proven cloud options out there, the business case to migrate most legacy, on-premises applications to the cloud is undeniable. But, which cloud do you choose? Desired redundancy, application recoverability, networking, storage, and support are just a few of the factors that must be considered to get workload placement right.
Optimize Legacy Application Performance with a Multi-Cloud Strategy
To simplify the process, many IT organizations quickly narrow their cloud search to the largest cloud providers: Amazon Web Services, Microsoft Azure, and Google Cloud Platform. This “nobody ever got fired for buying the market leader” approach seems like sensible risk management. Yet, prematurely narrowing the field before considering other cloud options can discount or ignore the fundamental differences between traditional corporate computing environments and the environments the hyperscalers provide. These differences can impact migration, application performance, uptime, supportability, and long-term costs. As underscored by the widespread adoption of multi-cloud strategies, it’s rarely ideal for an organization to adopt a single cloud platform for its entire application portfolio.
“Cloud” Doesn’t Only Mean Hyperscale
Many organizations we work with HAVE NOT included VMware-based Enterprise Cloud (Enterprise Cloud) as a possible destination for their virtual machine-based workloads. Enterprise Cloud may be overlooked because of all the media attention the hyperscalers receive. It may be overlooked by Systems Administrators eager to learn hyperscale. Developers often don’t consider it because they want to take advantage of platform-specific capabilities like AWS Lambda (to build functions-as-a-service) or Azure Data Lake. Whatever the reasons are, the point remains that VM-based workloads will typically perform better and more efficiently in a familiar Enterprise Cloud environment. Why is this? Let’s look at specifics.
Redundancy
- Enterprise Cloud provides a traditional, stable platform for applications that you can expect to be always online.
- Hyperscalers expect individual virtual machines (VMs) to be disposable and applications need to be designed to deal with loss of one or several VMs.
Networking
- Enterprise Cloud supports both traditional network-based filtering as well as host-based firewalling so you can port your existing firewall rules into the cloud without having to reengineer your security solution on Day 1, yet you can still leverage micro-segmentation and tag-based security where it makes sense.
- Hyperscalers expect you to migrate fully to their security model, and if that model is not well understood, problems like unsecured S3 storage buckets and misconfigured load balancers tend to happen.
Disaster Recovery Capability
- Enterprise Cloud has several native disaster recovery (DR) options that operate at the VM level, and provide extremely low recovery time objectives (RTO) and recovery point objectives (RPO) without data egress charges.
- Hyperscalers expect DR to happen at the application level, with the VMs themselves being disposable. This is absolutely the right approach for apps with large, dedicated teams managing them, but totally impractical for traditional IT departments to manage. VM-based replication exists but is poorly supported and RTO/RPO is quite long in most cases with many caveats.
- Enterprise Cloud lets you manage as few as one DR process for everything; hyperscalers expect you to create a custom solution for every app.
Storage usage provisioning
- Drives in Enterprise Cloud are provisioned on storage capacity and performance tier, allowing customers to right-size their storage usage.
- Drives in the hyperscalers are packaged as provisioned IOPS based on their size, requiring very large drives if performance is needed, even if the actual amount of data being stored is very small. Extreme cases include financial services clients spending in the millions per month for over-provisioned storage costs due to performance requirements.
Console access
- Hyperscalers don’t support direct connection to a VM console; initial bootstrapping must be scripted and get to a point of remote desktop protocol (RDP) or secure socket Shell (SSH) being available.
- Enterprise Cloud provides full console access, just like VMware vSphere.
Sizing
- Clients have full control over sizing in Enterprise Cloud.
- Hyperscalers require you to pick from a menu of size options that may or may not line up with actual requirements.
Deploy and support workflows
- Supporting workloads hosted in Enterprise Cloud environments uses the same techniques and methods to deploy, manage, and troubleshoot VMs that your team is currently using to manage on-premises VMware environments.
- Hyperscalers expect you to adopt their ways of doing things; re-using existing methodologies can be time-consuming and potentially expensive.
Technical design and ongoing support
- Enterprise Cloud providers provide expert help with engineering a best-fit solution, while hyperscalers provide only documentation links and sometimes third parties to help
- Enterprise Cloud providers (like Expedient) offer standard, 24x7x365 human-based support with published services levels backed by a team of engineers, while hyperscalers only provide email support with low service levels and optional high-premium 24x7x365 support to improve SLAs.
After reviewing this comparison, hopefully Enterprise Cloud will make it onto your short list when you’re considering cloud options for VM-based workloads. If you’re interested in learning how an Enterprise Cloud platform can simplify cloud migration, I encourage you to attend the webcast, “The Cloud for All Your Critical Applications” webcast, hosted by Expedient and Chi Corporation on June 17. Get more information and register here.
Originally published on the Expedient blog, by Doug Theis, on January 27, 2020.
