The Myth of M & A and Multi-Cloud

So, you read a white paper on Kubernetes, and now you want to apply a multi-cloud strategy to your IT infrastructure? As my industry friend Amy Lewis loves to say, “Bless your heart.” Multi-cloud isn’t as simple as taking an abstraction such as Kubernetes or VMware vSphere and deploying it across multiple clouds. In my 100-days and 100-blogs, I’ll address that scenario head-on.  I wanted to examine the most common use case for multi-cloud I’ve seen on social media – Mergers and Acquisitions (M & A).

Before we get started, let me preference my advice. There are noticeable instances where you must create multi-cloud applications. Also, some applications lend themselves to multi-cloud solutions, and there are some areas of multi-cloud operations that are reasonably mature. These include networking and storage. However, generally speaking, most enterprises shouldn’t look at multi-cloud applications or even multi-cloud support as the defacto offering from centralized IT.

M & A as a Driver for Multi-cloud

First, every organization has multiple cloud providers. My little org is approaching a $1M run-rate, and we have paid money to most of the major cloud providers. So, at some level, there’s a need to have a multi-cloud support strategy. I’m a champion of centralizing data and leveraging consistent network abstractions. These efforts make compliance and audit less painful and lay the groundwork for true multi-cloud.

Aslo See: The impact of business disruption on IT: The divestiture

My organization uses 4-clouds; what happens if another company acquires us? If the shop that purchases the CTO Advisor is primarily an AWS-shop, what’s the strategy for placing all of our existing services and applications on the AWS cloud? That’s the fundamental question my peers ask me on Twitter. Keith, if your bias is to use a primary cloud, how does a business that acquires dozens or hundreds of companies perform that many migrations. By nature, you must support multi-cloud.

The Overhead of Multi-Cloud

What does it mean for centralized IT to support a Public Cloud? As of this writing, AWS has 175-services. Nine of the 175-services are database services. What does it mean for your organization to support all 9 of these databases? I’m not suggesting what level of support you should or should not offer. I’m asking you to define the charter of your support for the public cloud provider. When you tell a business unit that you will support their application, does that mean you’ll provide an SRE that will support the application that uses shared services via Kafka across AWS, Azure, and GCP?

Will the next team that builds an application using RabbitMQ also receive the same level of support? I’d guess that your organization places guardrails around the application architectures you support.

Art: pic.twitter.com/oXTo8fVz4U

— Luke Norris (@COentrepreneur) September 20, 2020

It isn’t easy to sustain a centralized set of cloud services within AWS. Conversely, it’s nearly impossible to support a mix of applications with vastly different designs across multiple clouds. M & A rich organizations find themselves inheriting vastly different architectures spread across various cloud providers.

People and Process

So, what’s the solution to this challenge? Multi-cloud is an overly generic term. However, I take it to mean customers want to use multiple clouds under a single technical and support framework. There’s isn’t a technical solution to this problem, not today.

Companies that are heavily involved in M & A should treat Public Cloud integration as they treat the integration of similar disjointed business operations. What happens when a finance company purchases an adjacent business, let’s say an advisory service? While there are synergies, the finance company can’t simply replace all of the advisory company’s back-office functions. There’s an impedance mismatch. However, the advisory company inherits all of the regulatory controls of the finance company.

In the real world, the finance company has a group that audits the acquired company’s controls and operations. Out of that audit comes recommendations to meet the finance company’s compliance standards. IT isn’t different. IT leaders with massive M & A workloads must no longer approach companies’ integration as we did a decade ago. We won’t move complex applications to a single preferred cloud. We also can’t support an unlimited number of clouds and services.

IT leaders must put in-place guardrails in the form of security and compliance standards that acquired companies adopt. I understand this means that some headcount synergies will not occur. That’s simply the reality I’ve witnessed for companies doing successful M & A in the era of the public cloud.