James Staten| Zdnet
We all know the conventional wisdom about cloud computing: it’s cheap, fast and easy. But is it really that much cheaper? Or is it simply optics that make it appear cheaper? Optics can absolutely change your perception of the cost of something. Just think about your morning jolt of coffee. $3.50 for a no-foam, half-caf, sugar-free vanilla latte doesn’t seem that expensive.
It’s a small daily expense when viewed by the drink. It appears even cheaper if you pay for it with a loyalty card where you don’t even have to fork over the dough and the vanilla shot is free. But what if you bought coffee like IT buys technology? You would pay for it on an annual basis. That $3.50 latte would now be about $900/year. For coffee? How many of you would go for that deal? That’s optics and it plays right into the marketing hands of the public cloud services your business is consuming today.
But optics aside, is that $99/month per user SaaS application just another $20,000 per year enterprise application? Is that $0.25 per hour virtual machine just another $85 per year hosted VM? No, it’s not the same. Because the pricing models are not just optics but an indication of the buying pattern that is possible. If you buy it the same way you do traditional IT, then yes, the math says, there’s little difference here. The key to cloud economics is to not buy the cloud service the same way you do traditional IT. The key to taking advantage is to not statically and rotely consume the cloud. Instead, consume only what you need when you need it – and be diligent about turning off when you aren’t.
That said, however, there are cost gotchas for which you need to be watchful. Otherwise you will face the “hidden costs” of the cloud. So what are these gotchas and how to you avoid them? You have to look at this question in two groups: SaaS and cloud platforms.
SaaS services nearly always carry a perpetual, per-user license (you pay monthly on an annual or multi-year term). The hidden costs here fall into 3 areas:
- Customization – the more you can use the SaaS solution as it was designed the lower your costs. Customizations can quickly lead to development and maintenance costs you didn’t anticipate. this is the most widely made error by enterprises. It is more cost effective to teach your employees to use the SaaS as it is designed than to try to bend it to your processes. This isn’t always possible but should be used as a rule of thumb.
- Integration – you will inevitably integrate SaaS services with in-house applications, data stores and other SaaS services. These integrations must be built, managed and maintained. Best practice is to define a clear integration architecture via as few means as possible.
- Sprawl – A SaaS app you bought initially for just 15 employees, sounds like a great investment and low-cost solution until you open up the app to 1500 employees. Suddenly $99 per user could be more than an in-house solution. Be diligent about who you grant access to any SaaS app.
- Not turning things off – It’s easy to see how pay per use makes your startup costs low and elastic scaling as traffic rises easy. But it is just as easy to not pay attention to application use/load patterns when they go the other way. This is where you can save tremendous money, by turning off resources that are no longer needed.
- Storage grows, it never shrinks – and on a pay-per-use service you are constantly reminded of this. which means you need to actively manage your storage consumption by moving data to lower cost services when they are no longer in constant use, leveraging caching as much as possible and deleting files or copies of files if you don’t need them.
- Not activating cloud economics – Not every application is a fit with a pay-per-use platform. The best fit are those that take advantage of the pricing model through either elastic scale or transiency. Elastic scale means the app increases or decreases its resource consumption based on use. Best fit are apps that do this as granularly as possible. Transient apps are those that are not active all the time and can be parked or completely shut off when not in use. Batch work, high performance computing, seasonal or cyclical applications are all good examples. An app that just sits there 24/7 consuming the same resources is usually a bad fit and should be moved either back into your data center or to traditional hosting.