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.
What is 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 skill sets, and might require a smaller initial financial commitment in terms of outside expertise.
Let’s look at how a multi-cloud “float” strategy works for IBM Power workloads.
Migration path for IBM Power workloads
Thousands of companies worldwide use IBM midrange servers running AIX or IBM i (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.
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.
IBM Power has been typically considered “on-prem” technology that only exists in the data center. But that is no longer true. By floating these existing legacy IBM Power 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 or multi-cloud, you might as well float there.
Learn how to migrate your IBM Power workloads to the cloud with Skytap on Azure.
