You may have a private IaaS solution that is exactly like your old managed services solution, from the same provider that you’ve been using for years and years. If so then your cost is probably not wildly different from what it was before, though you’re seeing some savings from moving to standardized infrastructure. Now you pay by the hour for a bundle of hardware and labor instead of up-front for hardware plus monthly fees for labor. That’s different, but it’s not so different that your financial people can’t cope with it, compare it and even have some hope of planning for it. But your development teams are, let’s admit it, a little disappointed, right? They may complain about the solution not being “true” cloud and not delivering all cloud benefits, and you may be worried that they have a point.
Well, they do have a point (and if you think AWS accounts aren’t springing up in the business units independent of IT you’re probably kidding yourself), but as usual with anything good in the IT world, the issue is way more complicated than it first appears. If you’ve embraced the idea of the virtual private cloud running on shared infrastructure with privacy enforced through software logic and encryption, able to scale up and down automatically within mere minutes, then no one can say you aren’t using “true” cloud. But you’ve also learned by now that you can’t just go look at the on-line pricing calculator on the provider’s web site and know what the service is going to cost.
Proper financial planning for IaaS is a challenge for a number of reasons, not the least of which is the plethora of available options. As of this writing, if I want a Linux server from Amazon, I have 29 different combinations of instance type and size that I can choose from, and the price difference between the most expensive and the cheapest is hundreds of times. And that changes if I want Red Hat or Suse, and it’s extra for EBS (storage) optimization, but you can reduce the price if you reserve the instance for one or three years. And the entire pricing table changes if you’re, say, on the east or west coast of the U.S. Now, more choice is good, of course. Different applications have different needs. But consider that different instance types can perform very differently depending on the characteristics of your application. Amazon can tell you that M1 and M3 are usually good for SAP back-end processing, or that M2 is usually good for SharePoint, but these are guidelines only. Your mileage may vary, and when it comes to your in-house developed applications, you’re on your own.
The bottom line is that unless you do some modeling and experimentation up front:
- You don’t know how well your IaaS solution will perform on the provider’s machines, and
- You absolutely don’t know what it will cost, not even within a pretty large ballpark.
The lesson here is that cloud, while it does work to commoditize infrastructure, in no way relieves you of the need to do careful architectural design and financial planning, and the process for constructing the business case is, if anything, more complex than ever, since more price points are available than under your traditional, customized managed services contract. Once you get a public cloud project up and running, just knowing what the invoice will be every month (particularly when each instance can be reserved for different amounts of time), can require a highly polished crystal ball. No one can just look on-line and assume that a $20 per month instance can replace a server they currently have running.
In part 2 we’ll look at even more cloud pricing concerns, such as what to look at besides just the bottom line on the monthly bill.
