Ok, Chuck Hollis posted a great article on Cloud but I had to get my two-one-hundredths in. Enough so that I’ve temporarily decided to come out of retirement.
The problem with “Cloud” is that most people don’t realize that while you might be gaining in areas of cost, possibly (but not likely) performance, and scalability, IMHO what you’re giving up is far worse.
Putting your application in “The Cloud” is the ultimate abdication of an IT Manager’s responsibility. It’s saying “If it breaks, I have someone else to blame.”
Cloud computing has been around for years. They just called it “Managed Services” or “Hosted Services” or any of a number of other marketing catch-words before.
Myself I’ve told people that if you “…can’t point to the system that is hosting your application, it’s technically in the cloud.” A simple two-node VMWare cluster, technology that’s been around for years, is suddenly a “Private Cloud”
I’ve often said that Marketing is nothing but Sales without the ethics involved. My wife (The marketing person) and I argue on this point regularly.
Cloud is ambiguity wrapped in uncertainty. It’s a hope without proof that what you need will be there when you need it.
This is obviously an oversimplification but nonetheless it’s accurate.
Now don’t get me wrong – “Cloud” computing is perfect for small businesses who don’t want to host an IT staff or dedicate 250 square feet to a computer room. It’s good for medium businesses that are trying to control licensing costs or who expect random expansions/contractions of their user base. Heck, even *I* provide similar services to a few local businesses simply because I’ve already got the disks spinning (and it helps pay the electric bill)
But if you have data-retention compliance requirements or any of a dozen other regulatory hurdles, or if you just plain want to *KNOW* where your data is, you’re often better off keeping the application in house.
*ESPECIALLY* if you already have a datacenter you’re using for other purposes.
As a consultant for a company that is experimenting with moving it’s corporate email system to Google. I’ve been asked a number of times what the backup policies are, what the retention policies are, what RTO and RPO are in the event of a failure.
The only answer I can (and will) give is “Well Google says it’s this, Google says it’s that.”
When they ask me what *I* think I simply tell them I not only don’t know, but that I can’t know. It’s unknowable. Since I don’t have control over the application as such I absolutely refuse to speculate as to the actions and abilities of others whom I don’t know and are not in my direct control. I hope the managed services company has someone competent in their employ, but as most of them hire based on labor cost over skill-set (I’ve interviewed for the positions, I’ve seen the depth-charge offers they throw out) I won’t count on it.
Because the truth is, you don’t know. Sure you know what the marketing says, what the sales rep told you, what the tech-support person tells you when you call in. But if your hands aren’t the ones shuttling the tapes from the library to the vault, you don’t actually *KNOW*, you suspect.
Finally, “Cloud” services are fine until there is a failure. The problem with a failure, as last year’s EC2 failure illustrated, is that when there *IS* an enterprise failure, whether it be due to the lack of planning, infrastructure, or just a plain, old-fashioned act of god, you’re not in control.
You have to wait on the guys at Amazon to fix the problem. And if you’re one of a thousand customers affected by an outage, odds are pretty strong your application isn’t the first one that’s being worked on. And no amount of yelling or screaming is going to change that…
Personally, I would always prefer to be in a position to make a single phone call and get someone out of bed whose sole job it is to get *MY* Exchange server back online, or handle a failover, etc. If I measure downtime in thousands of dollars per minute, I want to *KNOW* that my sites/applications are being worked on first. The only way to know that is to sign the paycheck of the guy who is actually hands-on. (Or in my case to *BE* the guy who is actually hands-on.)
Again, Just my .02 cents.