Does the cloud even exist?

individual clouds
Credit: Nicholas A. Tonelli

'The cloud' is actually a collection of hundreds of individual clouds, all of which operate independently from one another.

RELATED TOPICS

As an IT leader, how often have you heard “move it to the cloud” in response to mounting pressures to reduce operational costs and increase delivery speed?  

Having grown up in an operational IT role, I'm willing to bet you’ve heard that said hundreds of times by now. Here’s my recommendation: The next time you’re asked this question, respond with something cheeky like, “Which one?” After a few moments of uncomfortable silence, break the tension with a more constructive discussion on the merits of using “a cloud” in lieu of “the cloud.”

Here’s why:

“The cloud” is increasingly used as a panacea for nearly all ills associated with legacy computing (as well as legacy IT outsourcing): too expensive, too slow, too complicated. The problem with this approach is that it fails to take into account the nuances inherent in a massive and complex ecosystem with very little standardization. Depending on the cloud that buyers choose, the services they’ll receive are a combination of outsourcing and insourcing, with some traditional software procurement mixed in. Either way, it will likely look very different from traditional on-premises IT or traditional ITO.

Today, each cloud is, for the most part, unique. This uniqueness has fostered an explosion of innovation within the cloud ecosystem. Each cloud provider operates in its self-interest, maximizing shareholder value by creating features and capabilities that are unique to its proprietary cloud.

One could argue that this uniqueness is beginning to dissipate a bit, because there is a good deal of current discussion about the future of interoperability between cloud infrastructure services. Most leading thinkers in this space believe we’re headed to a place where workloads will be able to move between clouds with little to no transformation. Others are attacking this problem from an application point of view. Docker, an open-source initiative that creates “containers” for applications, hopes to solve this problem by creating application portability across environments. Docker is creating a lot of buzz, and some very big organizations have some very smart people focused on this new project. 

However, we aren’t seeing similar interest in portability between clouds as buyers move further up the cloud “stack,” into software as a service (SaaS) — which just so happens to be a much bigger market than infrastructure as a service. Differentiation in SaaS is the name of the game, and Tier 1 SaaS providers are aggressively charging a premium for high-end features such as embedded analytics and mobile-enabled workflow. 

From a sourcing perspective, it’s important to note that this uniqueness inherent to each cloud is not only isolated to the features and APIs the provider exposes to its users. It also creeps into everything the company does: how it runs day-to-day operations, the service levels it exposes to customers, the contracts it asks customers to sign, the way it negotiates and the way it prices its services. 

This battle for differentiation creates significant challenges for ITO buyers who want to include cloud in their delivery model. Many buyers today approach cloud providers (as well as traditional providers that have developed or acquired next-generation cloud services) with the same thinking they have used with outsourcing providers for the last decade or so: Providers have limited to no differentiation so, therefore, the one that can lower my cost with the least disruption, provide the most client endorsements and the most amenable team for me to work with will win the work.

This approach discounts the uniqueness inherent in each cloud and fails to take into account several important distinctions between outsourcing providers and a cloud delivery model:

  1. The individual cloud a buyer selects in no way guarantees a reduction in cost. With many leading SaaS providers, a major upgrade may need to be avoided in order to ensure a positive business case. For public cloud IaaS, cost savings depend heavily on designing an appropriate infrastructure configuration for the application and the usage profile of this configuration. The potential for savings is unique to each provider and how the buyer chooses to use the platform.
  2. Most leading outsourcing providers have generally agreed on a set of commercial standards to ensure each party is protected from the inevitable ups and downs inherent in day-to-day operations. No such model exists for cloud providers. Infrastructure buyers are on their own to ensure they are not overpaying for compute and storage resources, and SaaS buyers will likely commit to a baseline of users that cannot be reduced during the term of the agreement. The protection you receive as a buyer is highly dependent on the specific cloud you choose, and how you choose to deploy it.  
  3. And, finally, day-to-day management of an outsourcing service, typically managed by large sourcing teams, is being disrupted by massive levels of automation inherent in many clouds. Increasingly, cloud platforms are using APIs to communicate with each other and with users. The robustness and maturity of these APIs varies wildly from cloud provider to cloud provider. Again, each cloud is unique, therefore, they way that buyers interact with each cloud provider will be unique as well.

Cheeky responses aside, using “a cloud” in lieu of “the cloud” can help crystallize the discussion when evaluating cloud as a potential delivery model. This approach helps to underscore the uniqueness and opportunity inherent in each cloud, but also reinforces the fact that selecting a specific cloud requires considerable due diligence, especially for mission-critical workloads.

This article is published as part of the IDG Contributor Network. Want to Join?

RELATED TOPICS
Crash Course: Advanced beginner's guide to R
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies