To read previous entries on this cloud series, check out the following articles:
If you’re thinking about a move to the cloud, consider how it changes your risks. One new sort of risk that clouds expose IT shops to is in the risk of unanticipated costs. To see what I mean, think about how you plan for IT costs now versus how you’d do it in the cloud.
In a pre-cloud world, I’m simplifying a bit, but your costs mainly arise from of labor, hardware, software, and internet connectivity. Labor’s fairly predictable, as most IT shops have some known number of staffers, each of whom are paid some amount that doesn’t change much (unfortunately) and receive some set of benefits. Hardware— servers, routers, switches, desktop systems, their attendant electrical and cooling needs—are also fairly predictable. Many companies lease their hardware and so can foresee their hardware costs with a high degree of accuracy. The biggest source of uncertainty comes from the size of the user base: if the company’s main line of business takes an unexpected upturn or downturn, then it’ll probably require more or fewer employees, and therefore more or less hardware. Software costs are a similar story, a set of costs usually closely related to the size of the user base. (And I hear you, users of open-source software—I know, adding users doesn’t cost anything in terms of licenses but, again, my point was that software costs are a fairly predictable number in the pre-cloud world, well, and zero is a perfectly predictable value, right?) Similarly, most of us pay a fixed cost per month for our internet connectivity, and so it too is a very predictable component. In sum, there’s probably not much in the way of cost surprises on the IT side of things for business owners, pre-cloud.
Consider now, in contrast, life in the cloud. All of a sudden, most of your costs are variable. For example, the Amazon Web Services folks now offer a page letting you estimate your costs, were you to run a virtual system on their EC2 (Elastic Compute Cloud) cloud service. Visit http://calculator.s3.amazonaws.com/calc5.html—just look at the six examples on the page, it’s much easier than trying to figure out what an “elastic IP” is—and you’ll see that your costs would come from two places. First, there's a fixed cost per month for reserving some amount of CPU capacity, and second, there's per-gigabyte charges for moving data in and around Amazon’s cloud. Looking at the examples, it appears that the lion’s share of what EC2-ing would cost you comes from the variable part, and that seems to be the case for the other cloud services that I’ve looked into. (Remember that EC2 is an example of the simplest sort of cloud service, a Hardware as a Service or Infrastructure as a Service type, similar to Microsoft’s Hyper-V cloud offering. If you’re wondering how cost components might shake out on a Platform as a Service cloud such as Azure, Google “Microsoft Windows Azure Platform TCO Calculator.” I played around with a few options and found that the Azure calculator came up with prices similar to EC2’s for similar uses. The ratio of fixed-to-variable components was a little higher in the Azure estimate than in Amazon’s case, but again the fixed costs were the minority. Meanwhile, I’m still shaking my head over why anyone would think I’d want to move my website to the cloud and pay $12,000 a year for the privilege.)
Now, let me be clear, I’m not saying that moving from a world where you know what your costs will be to a world where you’re guessing and hoping is necessarily a bad thing. After all, suppose your current, predictable annual IT costs were a million dollars a year, and suppose moving that operation to someone’s cloud would cost you somewhere between $125,000 and $375,000. The cloud option would offer a fair amount of variability and that would drive the bean counters crazy, but no matter how the bills run, you’d still be hundreds of thousands of dollars ahead of the game by going to the cloud, assuming no other cloud objections mattered.
It does, however, mean something else, and if you’ve read the past few pieces that I’ve done about the cloud, you won’t be surprised to hear it: don’t even consider the cloud until you know your current needs. Telling a cloud vendor how much CPU juice you need isn’t that hard, as you know what you have in your current servers. Knowing how many gigabytes of storage your application will need should, similarly, be pretty simple by looking at what it’s currently using on your servers. But what about bandwidth needs? Well, again, some of you will have those numbers close to hand, and in many cases probably with some snazzy analysis tools. But if you don’t currently have any bandwidth numbers, you can turn to Performance Monitor. On a web server, you’ll see Perfmon counters for “Web service” and not only will it give you bytes of throughput, it’ll break down those throughput numbers by each website on your IIS server. If your application isn’t a website, then look to Perfmon anyway—there may be a useful counter or object offering throughput numbers.
The cloud may be the right place for your applications, or it may not be, but you can’t even consider the question until you’ve first considered the fact that your cost structure and risks change considerably when moving from in-house IT to cloud-based IT, and then gathered some solid data on your current bandwidth usage upon which to build your estimates.
