There is a lot of talk about “multi-cloud,” but trying to achieve that level of cloud diversity might be challenging for many organizations. If you are starting out in the cloud, instead of building cloud-specific expertise across multiple cloud providers, try to “float” across multiple clouds as much as possible. Here is how.
First off, “What is Multi-cloud?”
There are two variations of the definition. It is somewhat like “love.” Everyone knows what it is, though the definition from one person to the next might not be exactly the same.
Multi-Cloud: (choose one)
(1) An organization uses a combination of on-prem, private cloud, and a public cloud (singular) to access, build, and operate essential applications.
(2) An organization uses a combination of on-prem, private cloud, and public clouds (plural) to access, build, and operate essential applications.
Strategy vs. Tactics:
Your strategy is to move some, most, or all of your existing on-prem applications to the cloud, but what tactics will you use to get there? Depending on your tactics, you’ll have different costs, complexity, and risk values. Your goal might be to become totally “cloud-native,” but there are many ways to get there. That is where the “float” comes in.
One strategy might be to go from existing on-prem and, in one step, refactor to all cloud-native services on one or more clouds. This is a legitimate path, but success will depend on how much expertise you can bring to the project. If this isn’t your first cloud migration, then chances are you’ll have no problem. If this is your first big move to the cloud, then you’ll need cloud-specific skills. Either developed and curated internally or from partners or Professional Services from the cloud vendor. This path will have costs and risks since you’ll fundamentally change the application architecture and require everyone on your team to “do things” differently than they have historically done.
The other alternative is to “float.” To float means not fundamentally changing your application architecture but instead performing a “lift and shift” as much as possible. If you can float, you can take an intermediate step to pure cloud-native services. Floating will give you a different risk profile, allow you to use your existing IT skillsets, and might require a smaller initial financial commitment in terms of outside expertise.
Let’s look a two “float” technologies.
VMware
All the major cloud vendors support some form of VMware. This is usually done as a built-in offering within the cloud vendor. If you go from on-prem VMware directly to native cloud service VMs that do not use VMware, you’ll have to make big changes. All the individual VMs running inside of VMware will have to be re-implemented as native cloud VMs running on a non-VMware hypervisor. The provisioning, management, and maintenance of all those VMs will significantly differ when implemented as native service VMs.
The advantage of running VMware in the cloud is that the basic mechanics of how it works will be the same as on-prem. Even if you are running across multiple public cloud vendors, the overall way of doing things will be familiar to your existing IT team members. There will be some new things to learn, but the VMware vocabulary and basic operational procedures will be the same. That is a huge advantage when considering your “path to the cloud.”
On top of familiarity, your cloud-based VMware installation will be “physically closer” in proximity to other native cloud services. With lower latency, you create a path where you can, over time, incrementally transform existing legacy applications into native cloud services. Or you can just run VMware “as-is” in the cloud. You have maximum flexibility.
IBM Power
This example will be more unfamiliar to many. Thousands of companies worldwide use IBM mid-range servers running AIX or IBMi (AS/400). A vast majority currently run on-prem hardware. All the major cloud vendors now support Power hardware within their clouds. That means the IBM virtual machine called an “LPAR” can run on dedicated Power hardware inside or closely linked to the cloud vendor’s regional data centers.
So the question becomes, “Do you refactor those IBM Power applications into cloud-native services as a single big and potentially complicated project, or do you float?”
To “float” means that you don’t initially refactor. Instead, you lift and shift, re-use your existing skill sets, get out of the on-prem data center, then set yourself up for your next move. That next move might be to incrementally refactor those traditional applications to be cloud-native, or you can just let them run “as is.” Once again, floating gives you maximum flexibility.
Just like the VMware example, if your IBM Power applications have a low latency connection to the rest of the cloud provider’s services, you’ve created a great “path to the cloud” for those traditional applications that might have been running in the data center for years or decades.
By floating, you take an intermediate step to becoming fully cloud native. That intermediate step has lower risks and potentially lower costs. It allows you to incrementally improve or refactor traditional applications over time instead of doing a “big bang” conversion.
Summary:
VMware and IBM Power are typically considered “on-prem” technologies that only exist in the data center. But that is no longer true. By floating those existing legacy applications to the cloud, you create a buffer of safety that still provides a “path to the cloud” but doesn’t force a risky all-or-nothing big-bang conversion to native cloud services. Your dependency on large amounts of cloud-specific expertise is initially reduced and creates multiple options for the future.
If you are moving to the cloud, you might as well float there.