Complex cloud architecture is finally causing budgetary pain

Multicloud complexity is moving from a theoretical cloud architecture problem to a financial one, and businesses are suddenly searching for solutions.

6 indirect expenses cost money fine penalty pepi stojanovski unsplash
Pepi Stojanovski (CC0)

According to a report published by Anodot, 49% of survey respondents find it difficult to get cloud costs under control. Furthermore, 54% believe their primary source of cloud waste is a lack of visibility and observability into basic cloud usage. Nothing new here.

What did catch my eye is that 49% said that managing complex multicloud environments was a core challenge to managing cloud costs. One in two enterprises is finally understanding that cloud architectural complexity is a core part of cloud cost utilization and needs to be dealt with.

I’ve certainly been waving the flag of “multicloud complexity is an issue” for many years here. The latency in enterprise IT responding to this challenge is likely because the pain had not yet been felt. I’ve noticed throughout the years that it’s one thing to sound an alarm and another for enterprise IT to finally heed the warning. Now it’s hitting business in the budget, which is something that will quickly get you fired.

Perhaps “complexity” is the wrong way to describe the problem. Complexity is an outcome of heterogeneity, which is an outcome of needing to leverage best-of-breed cloud services from whatever cloud provider is offering them. This is a natural progression of the expansion of cloud computing. Most enterprises are simply increasing the number of services that must be maintained and thus raising the costs and risk of cloud operations or cloudops.

The problem already exists for most businesses. I’m not sure any enterprises have taken action to deal with multicloud complexity other than read a few articles and ask a few more questions. Most enterprises see the expansion of multicloud services as something they can only deal with using tactical, reactionary approaches. They leverage whatever security, operations, data management, data integration, and governance platforms the specific providers offer, understanding that this can be fixed later, thus kicking the can down the road.

What’s occurring now is that many enterprises are in a cloud complexity hole and they keep digging, thinking there is no other choice. The business, investors, and the marketplace have demanded a shift to “the cloud,” accelerated by a global pandemic and increasing reliance on virtual, cloud-based resources. Speed has been prioritized over planning. Enterprises have ended up with a cloud architecture and multicloud deployment that “works” but does so with 50% to 100% less cost efficiency, depending on how bad things are with your solution domains.

The fear is that things with just stop working (à la Y2K), outages and breaches will become more frequent, and there will be no more money to toss at the problem. I suspect a few failed businesses will be traced back to a lack of architectural planning, IT cost overruns, and PR-killing events, such as data breaches, that take the business to a quick acquisition or even bankruptcy. We’ll know that complexity killed those businesses. 

Fixing this is no mystery: Look at your “as is” state, understand the deficiency, and create a plan to resolve the holistic problem, which requires winning many tiny battles. The battles will be to consolidate many of the native services to cross-cloud services that serve the entirety of the multicloud and even traditional legacy platforms instead of serving a single cloud provider’s platform.

Expand this concept to security, operations, governance, data integration, and many other services, and you’ll start to understand the emerging concept of the “supercloud” or “metacloud,” which is just a layer of cross-cloud services that should reduce complexity and its costs, which is what we’re talking about here.

Pain can teach us what to avoid. I guess we’ve put our hand on the stove.

Copyright © 2022 IDG Communications, Inc.

How to choose a low-code development platform