You Are Not Even Wrong About the Cloud - Part 4
By RickG on Apr 18, 2014
This series of blogs has been exploring several aspects of Cloud computing which have the difficult property of orthogonality – a characteristic where two aspects of Cloud computing which would seem to work together actually follow separate and sometimes divergent paths. The tangible result of this orthogonality is difficulty coming up with an accurate assessment for a Cloud computing offering, since these multiple areas are not easily resolved into a simple value proposition. The last area in this brief list revolves around cost.
There is a widespread belief that Cloud computing means that IT will cost less. Through the magic of Cloud, the IT budget will shrink while still delivering everything your organization wants and needs. Some people justify this belief with the idea that buying in bulk gives Cloud vendors a cost advantage which they can pass on to their customers. You know – give it away and make it up in volume.
But, unfortunately, the reality is a bit different. Although Cloud vendors probably do get a better discount than individual customers, they still have to make margin themselves, which usually exceeds their lower cost advantage in one stroke.
Cloud vendors can reduce costs, though, by making it easier for them to scale the number of different distinct customer environments they can support with a smaller number of IT staff. There is no real magic in this – Cloud vendors use automation as one of the key ways to achieve this benefit.
Automation, in turn, comes with its own set of requirements, the main one being the necessity to operate automated processes in a predictable environment. This predictability means that the flexibility typically available in your own managed IT environment has to be curtailed to accommodate the automation requirements. As an example, an environment can have only one party controlling root access – either the Cloud vendor or the customer. Dual control could lead to chaos, and rapidly.
There’s nothing magical about using standardization to allow automation – most big shops do it already. And in those cases where automation can’t be used in house, because of specific requirements (technical or political), the standardization required will probably not be any more acceptable just because it happens in the Cloud. In other words, if you cannot accomplish this in-house, it probably will not pass muster for you in the Cloud.
There are other ways that Cloud vendors can lower their costs, such as implementing some form of multi-tenancy, but this architectural change has fairly dramatic implications – so much so that you will have to make even more accommodations to the new architecture than you would have to make for the standardization in a Cloud environment.
So if you are looking to save money because the costs are lower in the Cloud, you may be disappointed. Couple this with the unavoidable truth that using the Cloud is like renting instead of buying. The only question about a cost comparison between renting and buying is how long it will take for renting to cost more.
The renting concept does present one way that you can save costs in the Cloud. If you have an IT scenario where you really only need an environment for a fairly short period of time, the Cloud may be a great way to go. But take a hard look at how long you are likely to need an IT system, and you may find that your aspirations undercut the cost-saving aspect of the Cloud.
But there is one clear way that you can achieve a cost benefit, as well as a much larger operational benefit, with Cloud computing. I was the product marketing manager for Real Application Clusters (RAC) when it was first introduced. One of the great advantages of RAC was the ability to easily scale by adding more nodes. You did not have to overbuy hardware and software at the start of a project since scaling was not disruptive.
With a monolithic database, pre-RAC, you would estimate the size of the server you would need in a couple of years. If you overbought, you would waste money by buying too much (too soon). If you underestimated, you would end up having to upgrade your server at a time when the need for the database was expanding, which was even worse.
When I would present this option, I would ask the audience if they estimated eventual server size at the start of a project, and virtually everyone agreed that they did. I then asked the audience how often these estimates were right. The overwhelmingly answer? “Never”.
With RAC, you never again had to be wrong with your sizing estimates, since you could scale as needed. You could change that “Never” to “Always”, since you would not even have to make an estimate.
The same is true with Cloud computing; in fact, probably more true, since you can scale more resources easily. This benefit means that you save money, since you rarely pay for what you don’t use, which adds up to lower costs. You aren’t paying less, you are buying less.
And you should not underestimate the impact that comes from never being wrong. The ease of scaling in the Cloud may be a bit more difficult to calculate, in terms of cost, but easy to understand and appreciate in your daily operations. It’s not easy to account for this in an ROI calculation, but this type of flexibility makes everything run more smoothly with your IT environment – eliminating one aspect of your planning and operations from your decision matrix has a far reaching impact.
This last example is one of the furthest reaches of orthogonality – a benefit that is strategic, in the sense of making your IT operations easier to run, but not necessarily tactical, in the sense of saving money for the same result.
The last three blog posts have illustrated some common misunderstandings about Cloud computing, based on the orthogonal nature of costs and benefits. In the final blog post, I will outline some best practices for moving to the Cloud that will make your journey as practical as possible.