Avoid Being Plowed by the Cloud

Are you going to lose your job to the cloud? Well, any of us might, but you can reduce that possibility by preparing to meet cloud providers’ claims for possible, promised benefits with solid, undeniable facts about the service that you deliver right now. Put simply, decision-makers in your organization will decide whether to replace you with a cloud vendor by doing a trivial bit of math: can the cloud vendor provide your organization with the services that you do, for less money at the same or better service level?

Of course, in truth there is nothing trivial about the calculation, or at least about half—your half—of the calculation. The cloud vendors have plenty of snazzy spreadsheets and web-based calculators showing how much they can provide in the way of reliable services and how cheaply they can do it, even if some of those figures might be best characterized as “numerological proctology.” Your best chance of avoiding becoming a “nebular statistic” lies in having some well-documented numbers close to hand. The first bunch of those numbers concerns service—what does your IT department do for your organization right now, in a pre-cloud regime?

Crunch the Numbers

How many messages, and how many megabytes of messages, does the average user send and receive? How many pages of documents get printed? How many terabytes of user data sit on file servers, how frequently is it backed up, and when someone needs a lost file recovered, how long must that person wait? What sort of database and SharePoint infrastructure does IT support? How often are you called upon to create a new share, a mailbox, a SQL table, an Active Directory account, or to set up a server for a department?

While you’re doing that, be sure to take a stab at measuring response times and client-server throughput in your current network. When you access your intranet’s secure HR site or grab your email, you probably do it over a connection that runs more than a few hundred feet, and at speeds of at least a hundred megabits per second. You’ve probably never even thought to try to measure the sum total in bytes of that traffic, but you’ll want that information now, as every cloud vendor that I’ve looked at charges by the gigabyte for client-server traffic.

Why is this so important? Well, consider this: once you’ve moved your servers to the cloud, you don’t move your people to the cloud. Thus, all of those bits that used to travel between the workstations on the eighth floor and the servers in the basement did so at very low marginal cost—you already own the routers, NICs, etc.—and at near-gigabit speeds that would be ruinously expensive to try to duplicate over the Internet. In effect, when you move to the cloud you still have to keep running a high-throughput IP infrastructure inside your building (as before), but now you’ll need to acquire considerably high-speed Internet connectivity, or accept much slower response times (read: reduced worker productivity). Oh, and don’t forget that now you’re paying for part of the cost of the cloud vendor’s infrastructure.

Focus on Network Uptime

You’ll also need to take a close look at your current network’s reliability. I know, it’s a sensitive subject—we do the best that we can with the limited budgets provided—but uptime is going to be one of the big weapons in the arsenal of the cloud sales folks. The fact is that cloud vendors have to be able to quote superlative uptime numbers because the whole image of offsite computing services inevitably leads prospective buyers to think about service quality from phone, Internet, cable, and electric utilities. So how’s your uptime? If you have a change control process in place—and if you don’t, get one immediately—then you probably have a rich vein of mineable data.

If you don’t have a change control system in place, then all’s not lost. Windows has (since NT 4.0 service pack something-or-other) generated event log entries noting when the system started, when it was stopped, and so on. There’s a bunch of event IDs in every Windows box’s event log chronicling when the system stopped and started and a bit of scripting could pull out enough times and dates to get you started on reliability numbers. Heck, you can even avoid a lot of the scripting and event log spelunking by pulling down Microsoft’s free command-line tool “uptime.exe.” 

Simply seeing some solid numbers attesting to the sheer volume of can’t-live-without-it work that your department does may slow down the cloud chatter for a while, but in the end it’s the money that matters—we’ll talk about that next month.