Cloud Economics: Whose Responsibility Is It Anyway?

Public Cloud Services…the cure to all our problems, the ultimate solution that we’ve been waiting for? I guess that depends on your personal perspective and how your role relates to these services.

From an operational perspective, I believe that Public Cloud Services could well be an operational cure-all. Embracing powerful technology like Kubernetes and adopting DevOps processes coupled with SaaS best-of-breed services means that the life of a ‘techie’ nowadays is an easier task than it once was.

Public Cloud and SaaS services have made life much easier in many fundamental ways for businesses when you consider the ability to quickly deploy and configure large and complicated infrastructure projects, proof-of-concepts and on-premise migrations today. Gone is the critical need for datacentre employees skilled in the art of managing chunky and expensive large frames containing database servers, tape-drives, racks of blades or networking. You can do it all from the comfort of your local coffee-shop through a web-browser whilst sipping on a coffee.

However, from an organisational control perspective, I’d say that the complete opposite is true for today’s cloud economics.

Before the era of the Public Cloud behomoths, businesses ensured that their employees’ wildest flights of fancy were kept in check by developing sophisticated control mechanisms, strict purchasing and approval policies as well as rigorous change control. These control mechanisms ultimately ensured that any proposals for spend had to be approved by a responsible person with the experience and knowledge to control spend excesses.

Not anymore!

Is the Trojan Horse concept applicable in the era of Public Cloud?

Absolutely. While the gifts on offer for the techie community provide ease of access, speed of deployment, scalability on tap and a playground for the latest concepts ‘on-demand’ – from an organisational control perspective they come with a latent financial sting in the tail.

Devolving responsibility for decisions about architectural and operational choices in a Public Cloud environment, without the necessary fiscal verification or control of deployment, will come back to haunt you. Usually about one month after an associated decision to do something was taken by the technical person with (technical) control. Why one month? Because that’s often the billing cycle used by the cloud service provider. Once the resource has been consumed you cannot get a refund, the resource has been ‘used’ (maybe not in any meaningful way) and you are contractually committed to pay for it, end of discussion.

This is not scaremongering, it is a fact. Here are some examples:

  • A blob storage of 4 Tb replicated across region to test the speed of the process and resiliency of a failover approach. This was done 3 times to 3 separate regions then, when successful, the ops team forgot about the blob storage. 30 days later a bill for £36k came through the door, the estimate (and budget) had been £9k.
  • Virtual machines are created as part of a data centre migration which match the on-premise specs for the machines. Once deployed their utilisation levels are far below the specs. No-one ever revisits the sizing of these virtual machines, even though the Public Cloud provider publishes recommendations in your console. 30% wastage is not uncommon.
  • A service provider spins up a number of environments on a customer’s Public Cloud during a proof of concept exercise. After the POC is complete the customer receives a bill for £400k which the service provider refuses to pay, because “it’s the customer’s responsibility to control infrastructure costs”