Funny thing about the hype-cycle surrounding cloud, it just doesn’t seem to be slowing down. Indeed, some are clinging to it like it was their long lost child – it in this case being the hype cycle, not the concept of cloud.

But seriously, lets consider exactly what is in a “cloud” anyway. Because a small percentage of enterprises are even considering it, and a huge percentage of chatter is dedicated to it, and I’m willing to do my part to stop the hype and start the help.

The “Cloud” is someone else’s data center running your app. Yeah, it really is that simple. Software As A Service evolved.

The hype-sters will no doubt howl about this with the following (and maybe more) chants - “reliability!” – because Salesforce.com didn’t have that already? “redundancy!” – because “redundant data center” didn’t mean anything? “Agility!” because you can’t spin up another VM in your own data center?

Lori was telling me today that an associate from our writing days asked her if F5 does anything special for the cloud. The answer to that would be “why?” Anything useful for the cloud is useful for redundant data centers, virtualized data centers, or both. Everything I can think of – even something as cool as iSessions or iRules – that we might do for the cloud isn’t “special for the cloud”, it’s useful in and of itself and one of the applications would be the cloud. Indeed, routing via iRules has been around since long before I was an F5er, so cloud really is just a new application of an existing technology.

So if you’re interested and want to delve past the hype, “the cloud” means moving all or part of your application to someone else’s data center and letting them worry about uptime, etc. While many will wrap a ton of verbiage around claiming there’s more to it, from an enterprise IT perspective there still isn’t. If your web farm got over-burdened you would bring up another instance and put it behind your load balancer or ADC (that would be a BIG-IP of course), which is what a cloud provider would do. The difference being that you’d pay your staff to do this work, and in the cloud you pay them to do it. Staff being a sunk cost, this might not be your best option. So make certain you know what you’re about when moving work to the cloud.

As I’ve said before, there are cases where the cloud makes a whole lot of sense, and cases where it makes zero sense. Your job as IT is to get past the screaming fits of those who have bet their future on the concept consuming the world and figure out which situations really do make sense for you. For a starter project, I’d run with a self-contained app that sees a large variance in usage – spikes and valleys – to see the real benefits of the cloud in action. Stand-alone is just a simple precaution, because network connections do go down, and an app that must have access to your data center in order to run has a totally different set of failure parameters that aren’t shared in a stand-alone app. Keep it simple in the first run.

The real beneficiaries of cloud will be those without a huge IT infrastructure already in place. Sure it’s a monthly expense, but so is hiring a staff and putting in all the gear, if you’re starting out, the cloud has to look appealing. I just want to see things move along far enough that there are some “moving clouds” success stories out there, because services in a hyped market have a tendency to want to lock you in somehow, and it’s tough to know how bad that will be until we have some serious movement under our belts. Simply put, service contracts are not forever, and “agility”, one of the many supposed benefits of the cloud, had best apply to your ability to move between vendors to best suit your needs, or the industry will suffer.

So take the hype with a grain of salt, understand your needs, understand what you’re getting into, and do what’s best for your organization. Beware those counseling radical change, after all, you have a business to support, and any radical change can severely impact your ability to do so.

Until next time,

Don.