Best Practices for Multicloud (that Cloud Providers Prefer You Not Know) | eWEEK

Multicloud is one of those topics that most cloud providers would rather not discuss. Why? Well, you’re admitting that their cloud is not the only destination for your applications and data. Also, and most important, they will be forced to work and play well with other cloud providers and do so as a stated policy.

Sadly, if you’re moving down a multicloud path, which most enterprises are these days, you’re mostly on your own in terms of how you put together an optimized multicloud architecture. It’s no real surprise that a lot of people are making a lot of mistakes right now, and this is leading to multicloud failures that cost enterprises millions of dollars.

The Flexera 2021 State of the Cloud report released states that 92% of enterprises have a multicloud strategy. This ranges from those who have begun their journey to those who are just entering the planning stages. So you’re not alone in your struggle: Managing complexity across different cloud providers is the core battle that enterprises are now facing.

Managing complexity across different cloud providers is the core battle that enterprises are now facing.

Why We Multicloud

For those of you who would consider leveraging a single cloud deployment to overcome the challenges of multicloud, you are effectively losing the core business benefits of leveraging a multicloud deployment. These benefits include:

The ability to select best-of-breed technology

AWS may have the best data analysis system for your inventory management system. However, Google may have a better AI platform for your needs, and Microsoft may have a SaaS system that you want to utilize.

We all want to find an optimized solution that leverages the best technology to fit the specific needs of the business. A multicloud deployment typically offers the lowest cost and most business-optimized solution—at least, conceptually. 

Also see: AWS vs. Azure vs. Google Cloud

Opportunities for operational cost efficacy

All public clouds have different pricing options. Either the price is higher or lower, or more likely, the way they bill for services may favor some use cases but not others.

Take data ingress and egress, for example. Cloud providers are all over the place on what they charge to simply bring data into your cloud-based data stores or transmit the data out of the cloud. The way they bill could be for data sent and received, the bandwidth used, or the time expended.

This means your configuration will have advantages with some clouds, but not with others. Given that this could be a bill that moves to well over $500k per year and is likely to increase as the business grows, these are major considerations. Therefore, it is important to consult with your cloud provider for specific policies and pricing.

Pricing analysis then moves on to storage pricing and policies, such as leveraging reserved instances to save some money. Other areas of pricing you should consider include how compute is charged and special services such as artificial intelligence and analytical systems. All are different, and all should be considered along with the business requirements. Then, consider again which cloud is the most economical to meet a specific business need.

Removing single vendor dependency

Many point to multicloud as being a way to avoid vendor lock-in. While using a single vendor can certainly have its advantages, if you write your applications to leverage whatever native cloud API is provided by only one of your cloud providers, you’re pretty much locked in. Multicloud does little to solve this problem other than allowing you to get locked into more than a single vendor, but the limitations are much the same, if not worse.

if you write your applications to leverage whatever native cloud API is provided by only one of your cloud providers, you’re pretty much locked in.

On the other hand, there is a notion that having the ability to leverage more than one vendor provides a bit of operational and business leverage. For example, the ability to have a pre-established relationship with more than one public cloud provider allows you to make better choices around the use of core cloud services, such as storage and compute. You even have options available if one of the vendors does not provide good terms or good service.

The same can be said around operational issues. For example, let’s say your primary cloud storage provider is not living up to SLAs (service-level agreements). With a multicloud deployment, you can easily move to another place, which can reduce both risk and cost.

Also see: Private Clouds Remain Central in a Multicloud World

Emerging Multicloud Best Practices

While multicloud deployments are relatively new, enterprises are already beginning to gather some best practices regarding multicloud solutions. These are best practices that most cloud providers would rather you not know about or leverage.

It’s not in cloud vendors’ best interests to spend billions of dollars to push enterprises to other vendors’ clouds. Their dollars get spent attracting enterprises to their cloud and no other. Thus, this is becoming a path to cloud where enterprises are largely on their own.

So, when it comes to cloud computing, these emerging best practices are about acting and thinking more independently than you have in the past.

And more important, you must understand that cloud is not a “one size fits all” type of technology deployment. A cloud deployment needs to be a decision that considers all aspects of your business and uses best practices to find the most optimized multicloud solution. You must weigh cost efficiencies and complexities and the cloud platform’s ability to meet the needs of your existing and future business.

Here are some of the best practices that most often drive multicloud success:

1. Consider the resulting complexity of your multicloud deployment

There are a number of technologies deployed across a multicloud deployment, and all need to be understood regarding function, correct integration, and long-term operations and support.

With cloud services such as storage, compute, AI, serverless deployment and more, it can be difficult to figure out how to configure and leverage these services optimally for your business. 

With a single cloud deployment, you limit the number of technologies you can leverage, but most of them are purpose-built to work well together. With a multicloud, multiply the number of clouds you leverage by a multiplier of the different technologies available. For example, a single cloud might have 5 different native storage solutions (e.g., block, object, file, etc.), but you could have as many as 30 when you leverage three public clouds as part of your multicloud.

a single cloud might have 5 different native storage solutions (e.g., block, object, file, etc.), but you could have as many as 30 when you leverage three public clouds as part of your multicloud.

Let’s say you leverage 10 of the 30 possible storage solutions, for use with different applications and data stores. Don’t forget that you’ll need to hire and train for the additional technologies, as well as operate them using CloudOps staffers who understand how each works, as well as expertise for more specialized ops tooling. You can count on spending as much as twice or three times the budget for operations than when deploying on a single cloud provider.

Most enterprises won’t spend that kind of money to deal with multicloud complexity, which means complexity must be mediated during the design phase of your multicloud. You have to plan ahead for operations.

You can also mediate much of the complexity by using advanced operational tools, such as AIOps, where you can leverage abstraction and automation as ways to deal with complex operations with fewer humans. While this can lead to a reduced cost compared to traditional methods of handling complexity, operational tools like AIOps typically operate best as a built-in feature and will cost much more if integrated later. 

Also see: The Future of CloudOps: Big Challenges and Possible Solutions

2. Consider multicloud cost governance

Just as too much architectural complexity leads to cost overages, not having a solid grip on the consumption of cloud services across a multicloud deployment will lead to cloud bills that are higher than any benefits multicloud can provide.

Cost governance has other names, such as FinOps, which basically leverages cost monitoring technology to monitor what cloud services are being consumed by what or who as well as how much they cost over time. The trouble is that many who deploy multicloud often rely on the cloud native cost monitoring tools from each provider. While these are fine when you leverage a single cloud solution, they are overly complex to deal with if you leverage two or more clouds – and often lead to costly mistakes.

The trouble is that many who deploy multicloud often rely on the cloud native cost monitoring tools from each provider.

The new generations of cloud governance tools should have the ability to monitor the ongoing usage of cloud resources as well as set limits on usage, provide charge-back and show-backs to budget per organization. They should provide deep data analytics to determine how the spending will likely change over time. This includes what-if analysis to consider the cost of leveraging different cloud services, including more complex usage billing, such as ingress and egress charges, and leveraging discounted services that are purchased ahead of need.

3. Consider what’s between the clouds rather than what’s in them

What’s important about multicloud is not what runs within each cloud, at least conceptually; it’s about what runs between them. This includes all common services that should span the entirety of the multicloud, including security, governance, operations, etc. This includes all services that should be the same between clouds and that will operate as “cloud agnostic” or “cross-cloud” functioning technology.

This can be a bit confusing because these technologies may operate within a specific cloud provider as a third-party application. However, they are purpose-built to deal with all the clouds within your multicloud deployment as if they were functionally operating between them on an independent platform.

These third-party technologies that can span clouds may include cross-cloud security managers that leverage a common identity directory, cost governance as covered above, and operational tools such as AIOps that span all clouds. And any other services that are common to all clouds and should run above all clouds rather than as a specific tool native to a single cloud.

Also see: AIOps Trends

Learning Multicloud by Trial and Error

Core to the best practices presented here is the ability for enterprises to create their own path to multicloud. Yes, it would be nice if there were a single solution pattern that fit all enterprises when it comes to the use of multicloud deployments. In the real world, each architecture needs to be purpose-built for the enterprise that leverages it.

The good news? Some common best practices are beginning to appear. It’s important that you learn as much as you can from the trials and errors of those who came before you, and then, come up with your own specific solutions. Those who follow the best practices mentioned in this article are more likely to find multicloud success.

Leave a Reply

Your email address will not be published.