How much is cloud complexity costing you?

October 15, 2020

A blog post by David Linthicum, managing director, chief cloud strategy officer, Deloitte Consulting LLP.

It is well understood that movement toward multiple clouds (and the hybrid cloud) is even a logical evolution, and one that is likely to drive us into the future.  

What are the analysts saying? A 2016 Forrester study stated that, while organizations already use multiple clouds, they will do so even more in 2017 and beyond. CIOs are stepping up to orchestrate the various cloud ecosystems connecting employees, customers, partners, vendors, and (with the Internet of Things in mind) devices to serve rising customer expectations.

Of course, this is a macro pattern, and other research firms are taking notice. In its FutureScape: Worldwide Cloud 2018 Predictions, IDC predicts that by 2020, more than 90 percent of enterprises will use multiple cloud services and platforms.

So, what does leveraging multicloud mean to me? It means that we’re adding complexity, and if we’re adding complexity, we could be doing so at the cost of reliability. The purpose of this article is to explore that concept and determine if we actually have an issue that we need to deal with if we’re moving forward with cloud computing. 

So, do you have a complexity problem? And if so, how much is it hurting you? This is such an important question that Deloitte has created an automated tool to calculate the cost of cloud complexity, and thus the money you’ll save by removing it. You can give it a try here.

Driving to complexity

Putting surveys aside for the moment, there are a few key issues that I see in the market today:

1. Most enterprise adoption takes place around an existing business problem, with a clear business case. Enterprises do not adopt cloud computing because it’s trendy. They need to solve real problems right out of the gate, and if those problems require that we leverage complex architectures, so be it.
2. Most enterprise adoption involves existing application migration rather than new application development. Most enterprises that migrate applications try to do so as quickly as possible and do not focus on “refactoring” applications to make more efficient use of native cloud services. Thus, it’s a lift-and-shift world and will be for some time until we run out of applications that don’t force refactoring.
3. Most enterprise adoption occurs around existing technology partners. When enterprises talk to me about their cloud needs, they typically have a laundry list of companies they have already selected as part of their path to the cloud. It’s very difficult to get them to think outside those boxes.
4. Security and governance continue to be afterthoughts. This despite the fact that security is consistently listed as the No. 1 priority for enterprises as they move to the cloud. Most rely on technology rather than planning to meet their security needs. However, most security solutions are ineffective unless implemented with a great deal of planning.
5. Cost is not as much of a concern as we originally thought. While most enterprises will claim to move to cloud computing for cost efficiency reasons, the reality is that most are moving for shifts in budget. Leadership is getting tired of paying for data center upgrades and expansions each and every year and have set deadlines for IT to find other locations to support core IT systems.

The resulting solutions are clouds mixed with traditional systems, mixed with other outsourcing options (e.g., colos and managed services providers). However, the mother of all mixes is the rise of multicloud architectures, which means that we’re leveraging more than a single public cloud provider (and in many cases three or more). This means enterprise IT must also deal with the resulting rise in complexity.

Understanding that we have a problem

Consider the following oversimplification of the problem:

Note that, as you might expect, when complexity rises, reliability decreases at about the same rate. This is due to a number of different factors, including:  

1. The more links in the chain, the weaker the chain is. If we have a single system running, that is the most reliable if not set up with redundancy. As we add systems that are interdependent on each other, reliability goes down, considering that a single system failure can bring down the entire chain of systems. You can consider each link a single cloud provider.     
2. The more cloud services that are leveraged within a single cloud, the more likely there will be a failure. So, we’re leveraging many public clouds and many cloud services on those clouds. We’re not only running into reliability issues at the multi- or many-cloud level, but also within each cloud, in that the more services we leverage that are interdependent and not redundant, the more we’re doing so at the expense of reliability. 
3. The more cloud and cloud services we have to keep track of, the more likely humans are going to make a mistake. We have a tipping point when the number of clouds and cloud services becomes too much for our human brains to track. While we can leverage tools such as cloud management platforms (CMPs) or cloud services brokers (CSBs), there is still a point at which the complexity grows bigger than we can understand or track. When that happens, things are missed, and things go wrong.

The enterprise architect in me would suggest that the best solution for enterprises that are already hindered by architectural complexity without the presence of cloud computing is to get their respective “acts together” before they adopt cloud. However, the world does not work that way. In the real world, most enterprises would have to do a ton of work over many years to be perfectly ready to move easily to cloud-based platforms. 

The root issue is the ability to manage complexity, including the addition of applications (new and old) that will run on public cloud platforms. The trick is to think in terms of replacement, not additions. Applications that exist on traditional platforms (such as LAMP in the enterprise data center) should be moved in bulk to surrogates in the cloud. Then, after some acceptance testing, those platforms should be decommissioned with extreme prejudice.

Mistakes that existing enterprises make involve moving a few applications to the cloud, which creates the need to maintain applications that run on the hyperscalers while still staring at the same hardware in the data center. Nothing changes, other than that things get more complex. At issue are always those one or two applications that are not migrated. Any cost savings made through the use of public cloud–based resources is quickly gobbled up by the cost and complexity of maintaining one more platform. However, this new platform happens to be within a public cloud service.

Here are a few dos and don’ts for enterprises that balk at the use of cloud computing due to the complexity it may or will bring:

• Do enterprise architecture and overall IT planning. Yes, that means some advanced planning in terms of what applications and data will run where and why. Cloud-based platforms, at the end of the day, are nothing more than other systems that you must manage. Thus, the fewer you need to manage, the simpler the architecture, and the more likely you are to succeed longer-term. These are approaches and disciplines that are already well defined and well-known.
• Don’t push things to cloud just for the sake of pushing them to cloud. Applications should have clearly defined benefits when running on cloud-based platforms, the objective being to migrate and decommission existing platforms so architectural complexity is actually reduced or, at least, stays about the same.
• Do consider automation. While cloud management platforms and service governance tools clearly add value, most enterprises don’t consider them early enough in the process of moving to cloud computing. They should be systemic to the architecture and actually reduce complexity by abstracting those managed clouds away from the complexity using the “single-pane-of-glass” approach. 
• Don’t stop measuring. Keep metrics in mind as you move to the use of cloud computing, including the ability to determine and measure cost efficiencies and overall IT efficiencies. Be prepared to get some disappointing numbers at first, and adjust the process, technology, and architecture as needed. 

Finding the sweet spot

If the notion we’re putting forth in this article is that there is a trade-off between cloud reliability and complexity, in that they are inversely related, what are we to do about reality as we increase cloud complexity? Keep in mind that, for most enterprises, complex use of multicloud solutions is just a forgone conclusion.

There are a few things to consider: 

First, leverage redundancy when you can. Keep in mind that one of the core reasons that complex clouds that leverage multicloud decrease in reliability is the fact that there are more interdependent systems that can fail. Thus, if you back up most of them with some (active-active) redundancy, meaning running standbys that are ready to take over, the reliability will likely go way up—considering that interdependent system failure will be mitigated by redundancy.

Second, leverage automation when you can. This is a matter of abstracting yourself away from the complexity and automating around cloud and cloud services outages and other failures. We’re leveraging some type of tool that’s able to automate reactions to systems reliability issues, again mitigating the effects of reliability issues since they are self-corrected by tools like cloud orchestration, CSBs, and CMPs.

That said, there is no magical formula here, and dealing with increasing complexity is nothing new for those building systems. Cloud computing is just another layer of technology and a different consumption model.   

What is clear, however, is that we don’t yet understand the impact of the complexity that multicloud will bring; we’re just getting the initial implementations up and running. I suspect that we’ll learn from the many mistakes that are likely to be made in the next several years, including a few that cost millions in lost revenue.

However, if the alternative is that we don’t move enterprise IT forward, that could be much worse than doing nothing at all. That will kill your business much faster than complexity ever could.