How To Make The Cloud Really Work

For some applications, the cloud is not all that it’s cracked up to be.

So says Rick Clark, global head of cloud advisory at digital technology and transformation services company UST. When applied thoughtfully, migrating applications can transform a business. But “in many enterprises, technologists made decisions that were based on technical innovation instead of business drivers,” says Clark. Soaring costs with the lack of promised agility has left many scratching their heads.

Clark spoke with Chief Executive to share his best practices for leaders looking to reimagine their tech strategy: “Not everything belongs in the cloud.”

We are seeing enterprises expressing regret about their cloud migrations. Are you seeing this with your customers and what concerns are driving this?

Yes, we are. In fact, this has become the most common discussion topic related to the cloud over the last two years. We are hearing over and over that the cloud has not delivered on its promises.

Cloud migrations ended up being much more complex than anticipated and often took much longer and cost more than initially budgeted. In addition, once the migration was completed, the costs were often significantly higher than anticipated.

In some cases, we have seen a company’s entire yearly cloud budget drained in a month. A further complication is the fact that many enterprises can’t see the expected business benefits. To many enterprises, the cloud is a black box that hides the true financial cost, while failing to deliver the agility they expected.

Why hasn’t cloud delivered on its promises?

I think there are a few reasons.

The cloud was often marketed as a cost-saving exercise when most of the cost savings were already taken out through server consolidation when data centers moved to virtualization. There are types of workloads that are much more expensive in the cloud. It is up to the business to decide if cloud provides enough value to justify those costs.

In the race to close data centers, many enterprises, faced with overruns and slipping deadlines opted to “lift and shift” workloads that were not appropriate for the cloud, sometimes with the encouragement of the cloud providers. This is often the most expensive way to migrate an application and should only be done in certain situations.

The CapEx process was slower and more bureaucratic than the OpEx process at most enterprises, which made many think of the cloud as a panacea that would increase business agility and shorten time to market, causing them to push workloads to the cloud, regardless of appropriateness. While this may have been a boon initially, finance departments soon wised up.

The move to the cloud was often a technology-driven exercise. In many enterprises, technologists made decisions that were based on technical innovation instead of business drivers, often without even including the business in the discussion. They were told, “Just sit back and enjoy the cost savings and business agility,” which never materialized.

We lost checks and balances. There is a movement concurrent with cloud computing which believes that everything should be in the hands of the software developer. Many of the guardrails that were provided by the enterprise architecture and infrastructure teams have been removed in the name of developer flexibility. This movement often conflated developer flexibility with developer productivity.

Developers were free to spin up cloud resources, configure their own virtual machines, and even decide which cloud provider to use, on a per application basis. We did not, however, make the necessary change in compensation to ensure developers cared about cost or provide extra training with the new responsibilities. This created a perfect storm where cloud’s financial decisions were in the hands of developers who were not trained or compensated for them.

There was a kind of tech blindness. Cloud computing was new and had exciting potential, but the hype cycle was monumental. We believed that the cloud could fix every technological problem for every application. We saw many enterprises closing data centers and moving everything to cloud.

Don’t get me wrong, the cloud is a significant technological advance with enormous potential, when applied thoughtfully, to transform a business. But it doesn’t solve all problems and not everything belongs in the cloud. When cloud migration was driven by business goals and the business was part of the decision, the results were much better.

If enterprises failed migrating to the cloud, how can they avoid making matters worse with repatriation?

They need to approach the problem thoughtfully. If an enterprise engages in the knee jerk reaction of pulling everything back to on-premise or mandating a 30 percent reduction in cloud spend without including the business in the discussion or looking to see where they are getting value, then they are likely to put themselves in a worse position.

Look before you leap. Develop a cloud FinOps practice with the intent to open the black box and reveal where business value exists. Work with the business to develop cloud unit costs in language that business understands. The decision to repatriate a workload is a business decision, not a technical one. The job of the technologist is to provide business with the data they need to make good decisions.

What are the motivations for repatriating certain workloads back to private datacenters and what criteria should they be applying to ensure they are not losing business value?

Cost, technical business requirements and proximity to other resources such as data are some of the motivations.

Cost is a criteria that most focus on, but it is not the only, or even the most important one. It is important to consider each application and understand the business requirements. Those business requirements will then drive the technical requirements such as: resiliency, scalability, bandwidth and security. If you have developed a good FinOps practice, the business should then have all the information they need to evaluate whether an application should stay in the cloud or be repatriated to an on-prem data center. 

One thing that we see many enterprises miss when making cloud repatriation decisions is capability loss. For many enterprises the journey to cloud has been a long one, stretching out more than a decade. It is important to think about the operations and engineering capabilities required to move and run an increased number of workloads in your enterprise data center. Do you still have enough properly trained operations staff? Are your current enterprise management tools up to the task? Are there additional license or operating costs that will eat up any savings?

Is there anything else a CTO or CIO should consider to successfully repatriate cloud workloads?

If you don’t have a good strategy, based on business requirements, that understands the technical complexities coupled with a healthy FinOps practice, you are likely to increase costs, lower reliability and damage the business.