Is multi-cloud architecture a good idea?

One of the technology trends emerging today can be found in various analytic firms, consultants, and the like recommending that their clients invest in multi-cloud infrastructure and distribute workloads between AWS and Azure rather than using either of them exclusively. Although this was not the first time that multi-cloud was brought to my attention, I hadn’t given it much thought before a Gartner analyst began suggesting that route for the government’s new JEDI project. But I have since developed reservations against multi-cloud as it does not pass the smell test, at least with respect to the cloud solutions presently available in their present state which I will outline here.

For starters, it’s important to point out that Azure is a distant second to AWS, both from the perspective of its financial performance in the market along with the performance and quality their clients can find within it. The financial performance and long-term viability carry significant weight when you’re determining which cloud infrastructure to adopt. This matters simply because it can take years to breakeven after a cloud migration as migrations can be complex and consequently expensive while having to migrate to a new service from a defunct one is even worse.

By the numbers and although Azure has roughly 13 million tenants, it is still not profitable to date nor has Microsoft post its financials since its inception around a decade ago. Meanwhile, AWS has roughly 1 million tenants and is wildly profitable. Amazon also has no problem reporting AWS financials as opposed to Microsoft who lists Azure under their Intelligent Cloud and averages its losses with its more profitable solutions. With regard to their financial performance and long-term viability, it’s generous to even list Azure on the same field, let alone put it at second place to AWS.

Further and while they’re similar in licensing costs and entry burden, another major setback of Azure is the ownership costs found after purchase associated with it due to the disparity in quality. Compared to AWS, Azure comes with much more downtime, is much more complex, and has significantly more attack vectors than AWS, consequently requiring much more staffing to keep a tight ship due to all of this. All of which seems minor to some at first, but it’s important to remember that productivity lost from downtime is the #1 IT expense for any company. #2 is the staffing required to manage and support technology while #3 is the initial cost of the solution which is odd given how much priority is given to the entry burden of solutions these days.

With all of this in mind, the notion of multi-cloud architecture between AWS and Azure seems quite ludicrous. Since competitive trade is a form of war and that efficiency is their plane of battle, it wouldn’t make sense to distribute half of your technological needs on a hyper-efficient platform while artificially limiting the other half of your infrastructure by distributing it on a much less efficient platform, limit productivity and increasing downtime and staffing costs as a consequence.

For comparison, this is as irrational as a country comprising their air forces with an equal distribution of P-51 Mustangs and A10 Thunderbolts or any company outfitting their office with 50/50 distribution of MacBooks and Surfaces. While multi-cloud may hold water under circumstances where competing platforms were at all comparable, the deltas between their relative complexities and efficiencies of AWS and Azure are too significant to dignify and companies would not achieve the efficiency within multi-cloud that they could achieve on AWS alone.

Even worse, it is well-known in engineering and architecture that simplicity wins. The simplest solutions are the most profitable along with being the easiest to fix, upgrade, support, warranty, and scale. Although they tend to cost more upfront, they also tend to generate less downtime and require the least amount of staffing among their competitors and cost less in the long run when looking at the whole. But when you go multi-cloud, your complexity doubles at an optimistic minimum, as do your costs from staffing and downtime, and this is especially the case when going multi-cloud with AWS and Azure. Taking such a hit to complexity isn’t justifiable unless there is a significant financial reward which I have yet to see from Azure.

In summary and while upfront costs are similar, Azure is nowhere near the financial performance of AWS nor can it come near to offering the operational efficiencies that companies can achieve with AWS. Distributing your cloud resources across multiple cloud hosts also only makes sense if said hosts are remotely comparable which Azure is not to AWS; there’s are levels to this cloud thing. Doing so would artificially limit your efficiency across half of your infrastructure while increasing its overall complexity and the costs associated with its upkeep. Ironically and based on most objective measures, the only time that a company should ever be in a state of AWS and Azure coexistence is when you’re migrating all of your workloads over to AWS with the intention of relying on it exclusively. The same goes for Google, IBM, Oracle, and the like for now.

Although there may be extreme outliers, multi-cloud infrastructure only seems viable if you will never be around to actually implement it, support it, or operate within such an environment ripe for chaos. It’s important to remember that chaos is a ladder for consultants and that many operate with a conflict of interest, are paid to play by their vendors, and often engineer little else than their own necessity. All of which may explain why they love the idea of multi-cloud so much in the first place.

However, if it is your goal to pay a heavy idiot tax for your infrastructure then by all means ignore the fundamentals of IT finance and engineering philosophy in favor of magic quadrants fueled by proprietary algorithms from the likes from Gartner, then go multi-cloud. Maybe go with G-Suite and Office 365 simultaneously for reasons unknown and throw even more money into the enterprise bonfire while you’re at it.




Engineer, Farmer, and Hellion

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Building an efficient dashboard for IOT

What is Velocity?

Installing, Configuring and Day 0 Operations on Rancher Server — Series III

Lining up Audio & Visual to Build Cutscenes in Unity : Part 6

Deploying Rails 6 application on Ubuntu using Capistrano, Puma and Nginx

How to Import Yahoo Emails to AOL Email Client?

Understanding Pythonic PyTorch

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mitchel Lewis

Mitchel Lewis

Engineer, Farmer, and Hellion

More from Medium

What is Infrastructure as Code (IaC)? And why you should do this

AWS Lambdas Retry Behaviors

Integrating Sentry in Prefect Flows

The Architect, The Starter, and The Closer