The Hidden Costs of Cloud Computing

What are the benefits of moving various IT workloads to the cloud?

By “cloud” I don’t necessarily only mean Public Cloud (Amazon AWS, Google, Microsoft Azure or O365). I do mean adopting cloud principles to deliver your technology resources. This could mean private on-premise, virtual or trusted private, community or public cloud architecture.

I also consider the whole compute stack in this definition: Infrastructure, Platform and Software-as-a-Service.

So what are the benefits of moving your assets to a cloud-based environment?

When asked this question, countless vendors, HP included, propose:

  • Lowered costs
  • Reduced time to deploy or reduced time to market
  • Greater agility
  • In certain cases, increased security
  • Vendor contestability (which in turn leads to lower costs)

My experience in talking to many CIO’s across a number of industries, however, highlights a couple of assumptions that we make when discussing cloud. These include:

  1. The myth of the greenfield enterprise
  2. The myth of cloud readiness
  3. The myth of infinite availability

Let’s discuss each of these in turn briefly:

1. The Greenfield Enterprise

This is an easy assumption to make, because of the way cost models are constructed. Generally the vendor (even the internal vendor if adopting private cloud) determines the cost of compute from a run perspective.

Of course this is considerably less expensive, depending on the workload, because it is considered as an OpEx construction. With no heavy dependence on capital, or depreciation to consider, the hourly charge for the service comes out favourably.

The assumption is that workload A, on premise, costs $x to run, and in the cloud $y. And that’s fine.

Except that workload A has to get to the cloud!

This model works perfectly if you’re a start-up, with no legacy applications, growing (but minimal) data, and a few core or contextual applications.

But I haven’t come across an enterprise like that. Most of the multi-national, or large corporations I’ve consulted have multiple, complex, interdependent systems. These often have multiple disparate authentication schemes with terabytes, if not petabytes of data.

So there is a two-fold transformation cost:

  1. The cost to actually shift the systems and data across
  2. The cost to remediate the applications, data, users and systems to a place where they’re ready to be shifted.

When you’re considering cloud computing, calculate and add the cost of systems transformation to the cloud operational cost.

2. Ready for the Cloud

Another implicit assumption is that adopting cloud computing is so simple, that anyone can just take out their American Express card and subscribe. The danger of this assumption is that this is by and large, true. At least this assumption is applicable at an individual or even departmental level.

But of course most large companies have spent millions of dollars on enterprise-wide architectures. Many of the standards and principles employed are from a different paradigm. Just think about client/server computing vs. service oriented architecture; or perhaps perimeter security vs. defence-in-depth.

Even the business processes—not to mention end user skills—are aligned closely with the application architecture. Invoicing is done this way, by these people, in this order, on these systems. Bring on a new finance person, and you have to teach them the invoicing system.

Every business process then, needs to be evaluated in light of the cloud. While it may be less expensive to rent systems than purchase them, you do need to consider which systems and workloads translate easily to a service catalogue.

When considering cloud computing, take an honest look at the readiness of your business to consume computing as a service

3. Infinite Availability

Recently both Amazon Web Services and Microsoft Azure had relatively significant outages. Yes these are public cloud services, but the outages identified interesting impacts on business. It seems this helps us identify another implicit assumption—that putting systems in the cloud inherently removes the need for contingency architecture.

As it turns out, the old saying: “There’s no patch for stupidity,” still holds true.

Depending on the workload, you still need to architect resiliency into systems, even in the cloud. It probably doesn’t matter if your development or testing server fails for 8 hours, but it does if it’s your CRM system at month end.

Despite being depicted as a cloud, there are still very real physical computers running applications. Hardware and software fails, for any number of reasons.

Of course the higher the SLA, the more expensive the architecture is.

Conclusion

Of course, I am a firm believer in cloud computing. I also agree that we will increasingly see organisations adopt cloud computing over the next 5 years. Those that don’t will rapidly find that the diseconomies of scale will outweigh the economies of scale, and they will fail. This will occur in much the same way that we saw companies fail at the advent of automated manufacturing.

Nevertheless, at the outset of your adoption of cloud computing in your IT strategy, understand the implicit assumptions of the vendors—and champions of cloud wherever they are—and consider the hidden costs.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Roger has been trying to get out of Information Technology since programming COBOL on mainframes in the late '80's. But no matter in which c...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.