How to Multi-Cloud: 3 Key Considerations from a Cloud Computing Expert

This is part of Solutions Review’s Premium Content Series, a collection of contributed columns written by industry experts in maturing software categories. In this submission, Archera CEO and cloud computing expert offers his best advice for “how to multi-cloud” through several key considerations.

SR Premium ContentAre you considering a multi-cloud for your organization? If so, sequencing is critical. Getting the sequence of foundational steps right can make a great difference, both economically and performance-wise, between an organization avoiding – or getting entangled in – problematic costs and contracts.

A one-two-three sequence for organizations that are going multi-cloud is critical. The three phases are:

  • Cloud-Zoning Policy: Determine which applications, teams, and projects go where – which cloud they will reside in.
  • Architecture: Draw up the blueprint for your multi-cloud infrastructure. This specifies how applications run within a cloud and/or across clouds, particularly focusing on which applications need to be portable between clouds and cannot use vendor-specific services like AWS Lambda.
  • Pay for It: Typically this is called the “Contracts and Commitments” phase. In this phase, it is best to put off decisions on contracts until you have created an overall plan, started to roll out, and forecast usage so you understand the overall financial requirements for each platform.

Cloud Zoning

First, Cloud-zoning. Your cloud zoning choices will have a major impact on commitments and costs. You need to map out what applications and processes will run on each provider. That entails deciding what can be locked on a single cloud, what needs to be portable between clouds, and what applications need to be fully multi-cloud.

Cloud zoning policy would cover, for example, whether you keep analytics and web serving on separate cloud providers.

Your special focus areas; if you want to ensure constant uptime even in the rare instances that AWS goes down, you might concentrate to extremes on load balancing among multiple clouds.

If global availability is absolutely paramount to your business, you would set cloud zoning policies to support that imperative.

Do not overlook the possible need for different teams to use different best-in-class tools that may be specific to a provider, for example, an AI team that needs GCP TPUs.

Next, Architect Your Multi-Cloud

The high-level design, and knowing what goes where are the crucial foundations for multi-cloud implementations. Forecasting is an art that comes into play here because you will need to forecast how your utilization of different services will grow.

Hopefully, you will know how it’ll grow. Where do data science and AI go, where is production application serving, where is data warehousing, and how will they grow relative to each other?

The architecture phase is where you determine projects that need to be cloud-agnostic, and which don’t need to be portable and therefore can lean on proprietary CSP managed services.

In general, it is cost-advantageous over the longer term when companies take a flexible and containerized approach that can work with any Infrastructure as a Service Provider, or build with common standards if using managed services, such as using EKS for Orchestration. This ensures not only portability between vendors common compute hosting solutions, but also portability within individual vendors managed service ecosystems, allowing customers to find an optimal fit for the application needs. For example a containerized application can run on EC2, Lambda, ECS and a number of other options within AWS alone.

Forecasting comes into play for specific parameters, including invocations of lambdas, the data storage your computing will need, the number of compute nodes and database utilization.

Financial: Contracts and Billing

Forecasting continues to be important, as you move into the selection of services and preparing for contracts. You need a clear understanding of your flexibility needs as the infrastructure you are consuming changes over time  – both today and up to 3 years out. Then comes the process of matching costs to each forecast, to build your cloud consumption budget,

By studying your forecasts, and the amount of uncertainty associated with each of them, you can begin to optimize commitment plans to zero in on the best blend of contracts to cover the expected future usage.

Throughout this challenging phase, look for ways to de-risk the commitments you’ll make. One way to de-risk is via commitment buy-back guarantees such as those Archera offers, or taking advantage of more natively flexible commitment options from AWS, such as compute savings plans, which can be consumed by any AWS compute usage in any region, in exchange for much lower savings rates.

You can avoid confusion and lost time with careful budgeting and accounting. Make sure that commitment costs and savings are attributed specifically to the right applications, not spread like peanut butter across everything, which is often the default (unfortunately)

Finally, when planning migrations of applications between vendors, Interpret carefully between the Big 3 and other providers. The performance semantics of a virtual machine at vendor X usually means something different than a VM at cloud provider Y, even if they appear to have the same specs.

Final Thoughts

In real life multi-cloud computing, with services being billed by the second, it is almost impossible to achieve 100 percent optimization of costs, commitments, and performance. With manual approaches, very few organizations can expect to come close. Some companies do a very good job with attribution and tagging but do not accurately compare the hundreds or thousands of options between the Big 3 to understand the optimal go-forward strategy.

It can be extremely challenging, and it’s useful to understand the perspective of Amazon, Microsoft, and Google. They respond first and primarily to the technical needs of their customers and often put off servicing their other wants (contracts, cost, transparency).  For example, they make  VMs spin up faster, but not less costly.

Your challenge in going multi-cloud is much greater because you confront complexity by design, which makes optimization grounded in simplifying processes and automating as much as possible indispensable. Optimizing your multi-cloud smorgasbord requires involvement on your part, as well as external, neutral partners that exist to help the hundreds of thousands of organizations that consume cloud services.

Aran Khanna
Follow