Managing the multi-cloud: It's complicated
The cloud: What is it and how does it work?
One of the more annoying aspects of the tech industry is the proliferation of buzzwords and marketing-speak. Take "cloud" for example. Somehow, we managed to re-label the practice of filling up giant, power-sucking, heat-spewing, soulless warehouses of computing power into something nice and floaty like "cloud."
And now we also have "multi-cloud." In the fevered world of IT marketing, what exactly is "multi-cloud"? Who cares about it? Who uses it?
Featured
The best way to understand multi-cloud is to picture a scenario like this: Recently, Northern Widgets decided to adopt a cloud-first strategy. If an IT function can be put into the cloud vs. installed on-premises, the cloud is the preferred choice.
When Northern Widgets added a new customer experience sentiment analysis big data infrastructure, they decided that this new buzzword soup would be installed on a virtual rack in AWS. They spun up a network of virtual machines, used other aspects of Amazon's on-demand infrastructure, and deployed their solution.
So far, so good. Then Amazon had an outage. It wasn't a big one, but it was a wake-up call to the Northern management team. Every time their customers experienced an outage, Northern was penalized. Outages, therefore, are bad.
After about four months of meetings and conference calls, Northern decided to clone their AWS infrastructure to Azure.
And so it came to pass that Northern Widgets now had infrastructure-as-a-service (IaaS) buildouts running on AWS and Azure. They also had on-premises infrastructure. On top of all that, they also used a variety of SaaS systems, ranging from SalesForce to Gmail to Slack and Dropbox.
While there's a lot to discuss about SaaS, let's limit today's article to just the IaaS challenges Northern Widgets is facing with coordinating AWS and Azure.
That's because it's never that simple, is it? Sure, you can set up virtual Linux boxes in both environments, build out storage, build out microservices and all that. But no matter how close you try to get, the architectures are going to be different, the SLAs are going to be different, the identity management systems are going to be different, and so are the management consoles.
Northern IT managers found themselves constantly jumping between management consoles for their legacy on-premises stuff, plus for their various AWS and Azure installations. One department went rogue and, instead of building fail-over to Azure, decided to build fail-over to Bluemix.
By the time the CIO found out about that, too much data and infrastructure had been built out into Bluemix to pull it off, so now the company had AWS, Azure, and Bluemix to coordinate.
This is multi-cloud. It's not pretty. But its reason for existence is certainly understandable. No smart company wants to put all of its eggs in one basket, even if that basket is run by highly-reliable companies like Amazon, Microsoft, or IBM.
There are a variety of reasons for this caution. One reason is failover and disaster recovery. All complex systems experience failure, and in the case where infrastructure fails for one reason or another, having a backup virtual datacenter can be critical. This is particularly important a world where cyberattacks are now the norm.
Another reason is the whole vendor-relationship part of the puzzle. What happens if your cloud vendor suddenly changes strategy or management and either starts to consider you as a competitor or sets its terms of service, pricing, or other conditions to something unsustainable? If you're a going concern with an active user base, the months it would take to migrate can be too long. Again, you're essentially looking at a failover situation, but here it's based on business terms, not technical problems.
You see where I'm going with this. Other reasons to go this way include possible government or jurisdictional issues, the potential of a change in a vendor's technology stack breaking your systems, the desire to have the ability to handle surges across vendors, the need to build and practice design abstraction so you have a layer that's not dependent on a vendor's underlying platform, and more.
A variation on the multi-cloud concept is hybrid IT. Essentially, hybrid IT is a mix of infrastructure located on-premises and infrastructure located in the cloud. Hybrid IT, therefore, can incorporate multi-cloud. This, of course, increases management complexity by yet one more level.
More great project ideas
Northern Widgets, our example scenario, is running a hybrid IT operation. They have some legacy on-premises systems, and cloud infrastructures in AWS, Azure, and Bluemix. All of these systems need to be managed through a mixture of monitoring, policies, automation, and federation.
Every multi-cloud or hybrid IT configuration is going to be different. When you're higher in the stack, things aren't so varied. Your experience and my experience of Gmail (separate from a few add-ons) will be essentially the same. That's because, at the public application level, we're all using the same tools.
But at the private infrastructure level, where each company builds up its own IaaS stack to meet its own unique needs, the stack configuration is going to be different for each organization.
I'm not going to dive into the various tool stacks in this article. Instead, my message here is simple: just moving to the cloud isn't going to solve your problems. In fact, when you move to the cloud, you add entire new layers of complexity to your management operations.
Keep in mind the need to automate and manage across clouds, and plan and budget, not only for the resources provided by the various public cloud providers you choose, but also for all the software and licenses you'll need to manage it all.
You can follow my day-to-day project updates on social media. Be sure to follow me on Twitter at @DavidGewirtz, on Facebook at Facebook.com/DavidGewirtz, on Instagram at Instagram.com/DavidGewirtz, and on YouTube at YouTube.com/DavidGewirtzTV.