Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Are you considering a multi-cloud strategy for your organization? Getting this sequence of foundational steps right can make a huge difference, both economically and performance-wise. FinOps or a cloud resource optimization solution like Archera, for example, is often brought into the picture after a company has already embarked on a multi-cloud approach and is knee-deep in long-term commitments. These solutions can help organizations avoid—or get further entangled in—problematic costs and contracts. We recommend a three-step approach for organizations that are going multi-cloud. The sequence of steps is:
Cloud zoning policy: Determine which applications, teams and projects go where—and 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, but we strongly encourage putting 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.
Step One: Cloud Zoning
First, is 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 into 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.
This also involves identifying your special focus areas. For example, 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 possibility that different teams need to use different best-in-class tools that may be specific to a provider; for example, an AI team that needs GCP TPUs.
Step Two: 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? 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, in the long term, we see it is cost-advantageous for companies to 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.
Step Three: 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 three 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 mitigate the risk of the commitments you’ll make. One way to do this is via commitment buy-back guarantees or by 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 three 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.
Going Multi-Cloud: Real Perspective
In real-life multi-cloud computing where services are billed by the second, it is almost impossible to achieve 100% 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 three providers to understand the optimal 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 cannot make them less costly.
Your challenge with 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.
