Multi-Cloud Strategies – Do they work?

  • Article

We are often asked about our thoughts on multi-cloud, cloud-neutral, and cloud brokerage strategies. Or we work with customers whose strategy is already established multi-cloud.  From a Modern Service Management (MSM) point of view, which starts with Agile/DevOps, our principles apply to any cloud as they do in Microsoft Azure. We would seek to enable “cloud born/native” services in AWS or Google, as we would in Azure, in lieu of approaching them generically or from the lowest common denominator functionality such as just Infrastructure as a Service (Iaas) or non-cloud native tools.

Beyond cloud vendors themselves such as Microsoft, Amazon and Google, there is an entire industry of firms desiring to get into the cloud game by creating solutions to problems customers haven’t even experienced yet. This leads to the question: “Why do organizations feel the need to leverage multiple cloud providers simultaneously for similar or dissimilar purposes?”

Some arguments include;

  • all cloud vendors are alike
  • that perhaps it feels good to “share the wealth”
  • there are capabilities in one that are not found in the others
  • the fear of the dreaded “vendor lock-in”
  • organizations believe that like oil futures, they can platform applications based on price advantages or pitting cloud providers against one another,
  • workloads can easily be moved back and forth between cloud providers.

The problem is that most (not all) of these arguments actually begin to eat themselves once you get past non-differentiated, commodity services such as IaaS and containers. It is those differentiated services and capabilities such as Platform as a Service (Paas), Functions as a Service (Faas) or Software as a Service (Saas), that a specific cloud may offer that provides the most value and benefit.

There is also a cost and potential value impact with a multi-cloud strategy. The following costs have been discussed over time from a number of internal community threads, presentations and discussions on multi-cloud and cloud brokerage;

  • A cost in management ~ you have to manage and learn to manage two platforms as opposed to one
  • A cost in upskilling/cost in investing in multi-cloud tools
  • An opportunity cost if multi-cloud tools prevent you from leveraging high value services in a given cloud
  • Bandwidth costs and lost time moving mass amounts of data to/from each cloud provider
  • Upskilling costs to take advantage of multiple clouds deeply (i.e. using their specific PaaS services and ecosystems) then there is obviously an even higher upskilling cost.
  • If instead, you take a lowest common denominator approach then you also have an opportunity cost as you are unable to leverage the higher value services that each cloud offers. The opportunity costs of going lowest common denominator on 2+ clouds quickly outweighs perceived advantages and constrains modernization.

Additional reasons for going multi-cloud break down when you dig into them;

  • There is no simple migrate capability, especially for Paas and Saas, between clouds, so once workloads have landed then they tend to stay put, and the cost of re-factorization can be high
  • For most workloads the pain, risk and cost of moving between clouds far outweighs the ongoing marginal cost benefits once the workload has been migrated.
  • Attempting to play vendors off against each other for advantaged pricing usually doesn’t yield anticipated saving because of current state IT procurement processes. This only works if you are an enormous cloud consumer like Netflix as pricing is fixed based on features, and most companies have insufficient leverage.
  • The concern for “Vendor lock-in” should be compared to the either direct or indirect cost of lock-in from an outsourcer or SI (a lock in of sorts). In many cases, it may cost less to refactor applications over time to run natively in the cloud compared to transitioning large portions of outsourcing contracts to support applications back on-premises or into IaaS. This starts to unveil the real cost of “technical debt”

Multi-cloud approaches may prove to be short lived with customers focusing on Iaas and Containers only. As many organizations discover, the true value of cloud comes from modernizing IT and re-factoring applications to take advantage of value-added services that a cloud provides. We believe over time, organizations will most likely embrace and choose a primary cloud provider and stick with them to leverage the services and ecosystem fully. Especially as applications are modernized or re-factored to take full advantage of that cloud’s PaaS, Faas and SaaS capabilities.

Some will settle on a couple of clouds as they are big enough to invest the time and people to go deep on both, and that makes sense if the clouds offer differentiated value beneficial to the workload, but only if you go in deeply with both and take advantage of the PaaS services that each offers. It is well advised that if an organization chooses to have a multi-cloud strategy, workload placement criteria be managed by the company’s IT enterprise/solution/platform architecture team to take advantage of the capabilities in each cloud, not to attempt to place or manage workloads randomly.

Do 3rd Party Multi-Cloud Management solutions help?

Purchasing solutions to problems you may not even have yet, borders on insanity. Often customers will “lock-in” to a boutique solution capability that claims multi-cloud, only to find out that it;

  • limits or doesn’t support the modern workloads that customers are looking to achieve, or
  • It is focused on traditional data center extension into the cloud

Our recommendation leveraging Azure (or any cloud) is to provision using automation that supports true CI/CD pipelines and infrastructure as code, even at just the platform level (if all you use is Common-Off-The-Shelf software, or COTS). This approach makes a big difference over manual efforts. Multi-cloud solutions often only target infrastructure provisioning and don’t address or support PaaS or SaaS services. Therefore, the requirements and justification for them tends to fade as you go deeper into a clouds service offerings.

Ask yourself; “What problems do these tools solve that aren’t solved already in each cloud?” If through a given approach to cloud we free up 60% of an application developer, system integrator or architect’s time, what is the value of additional tool sets when the cloud native solutions from Microsoft or other cloud providers work better for their cloud? Any solutions that reduce speed or limit scale should obviously be avoided. Azure, and other cloud services, move and change quickly – and 3rd party solutions have to keep up to manage the integrations and front-end security, etc.

Our recommendations

  • If you have started multi-cloud ask yourself what your platforming algorithms are? How do you make decisions and do these make business sense? Consider the cost of complexity, the cost of not using value added Paas and Serverless services, the value of modernization vs the cost of managing Iaas VMs in multiple clouds. You might find that the agility, speed and scale of these services far outweighs the value in your goals of just moving VMs to the cloud.
  • If you haven’t started to go mult-cloud but are planning it, recognize there will be additional costs and there are no magic cloud management tools that do everything across all clouds. Cloud services are too numerous and change too fast for these solutions to keep up with and they only usually focus on infrastructure only vs driving Paas services.
  • Wait until you have deployed cloud-based solutions taking a modern approach to cloud, before purchasing these tools. If you take a traditional data center extension approach to cloud, yes, there may be lots of reasons for these solutions.
    • A modern approach is based on automated cloud native controls, automation in testing, and release and infrastructure as code. See if the problems you believe these tools claim to solve are really that great of problems and perform a business analysis at that point.
    • The problems may be addressed natively and in some cases at no charge, by the cloud provider directly.
  • Most importantly, make sure you fully understand the cloud platform(s) you are on and the capabilities it(they) provides. If you are looking at 3rd party cloud management or consolidation tools, make sure they are addressing the capabilities you are seeking to leverage. For example, if your goal is to go Serverless with Azure Logic Apps, Functions, and CosmosDB, ask yourself what value does an additional tool on top of those do? What value does it bring? Remembering that an unintended consequence of these tools may include a friction in release velocity, or how often you can update or limit access to the services of the cloud provider.