All Posts in Cloud

|In: Cloud|Last Updated:

We’ve seen this movie before.

It’s a new cast, and they changed the title, but the plot is the same: What was supposed to be easier and cost less turns out to be harder and costs more.

Not only that, but it has the exact same plot twist.

The old cast and crew was client/server computing. The new cast and crew is The Cloud. As InfoWorld’s always-worth-reading David Linthicum reports, “It’s harder, and it takes longer than many thought” (“This just in: Cloud computing is hard and takes a long time,” InfoWorld, 5/10/2012).

The plot twist?

Back in the early days of client/server computing (when the distinction between client/server and distributed processing baffled even many self-described experts, who lumped the two together) the discovery that so-called client/server systems often cost more to develop than their mainframe equivalents was quite a shock.

As I pointed out at the time (“Client/server confusion,” InfoWorld, 2/24/1997) the shock was misplaced because the analysis was badly flawed: Mainframe systems were developed by programmers already experienced in the development language and environment (COBOL/CICS) on already-deployed, stable platforms (IBM MVS mainframe computers).

The programmers who wrote the shockingly costly client/server systems had to learn a whole new language (C++ was a popular choice at the time). They also had to evaluate, select, purchase, install, and configure server and desktop hardware and operating systems, plus the network technology that connected them.

Oh, and they had to learn how to design graphical user interfaces, too — a change that wasn’t just technical, but cultural as well.

Fast forward to the present and the surprise finding that The Cloud costs more and takes longer.

Recognize the shared plot twist?

So far as I can tell, most IT shops trying to deploy in The Cloud have to assemble their cloud computing environments themselves. Then they find that developing for The Cloud isn’t just like developing for local hosting.

Some of the basics are obvious, like, you can’t buy your storage from Amazon while developing your application on Microsoft Azure. Unless, that is, performance doesn’t matter. (If this point isn’t obvious, it’s because inside your own data center, network latency is rarely an issue. When your storage and processing might be thousands of miles apart, the speed of light imposes limitations that matter a lot when you’re processing millions of records.)

Others issues are more subtle, like, if your cloud vendor contractually commits to a specified service level, that doesn’t mean you’ll actually get that service level … it means you either will get it, or get a credit to your account if you don’t.

Or, that not all cloud vendors put you in control of version changes … and in fact, some of the sloppier ones have been known to change their APIs without even notifying their customers that they’re doing so.

It isn’t that all of the differences cloud computing introduces are bad. Some you should be building into your own data center right now, whether or not you’re planning to build a fog (KJR’s term for a private cloud, fog being a cloud you’re in the middle of). As an example, modern information security architectures focus far less on protecting the perimeter, hardening assets instead. As one major benefit of cloud computing is access from wherever a user can connect to the Internet, cloud security is asset-based rather than perimeter-based, because there is no perimeter. (For an extreme view of this, check out Roger Grimes’ provocative “Why you don’t need a firewall,” InfoWorld, 5/15/2012).

Make your security asset-based too, and the challenge of providing access to mobile employees and teleworkers becomes a whole lot more straightforward.

There are two take-home messages from all of this, one for cloud-computing customers, the other for providers.

For providers: What are you thinking? Especially Platform as a Service (PaaS) providers should be delivering turn-key integrated development environments. Sign the contract and start writing code. That this late in the game, Google’s entry (App Engine) is a preview release is extraordinary.

For customers: Just because right now, on average, cloud computing costs more and takes longer, that doesn’t mean it’s the nature of the beast. It means doing something a new way almost always costs more and takes longer than doing it in a way that’s familiar … at first.

Will cloud computing eventually be quicker and cheaper than traditional in-house-data-center-based computing?

I’ll give that a definite maybe, and an even more definite sometimes.

Comments

|In: Cloud|Last Updated:

Why go to the Cloud?

Don’t answer. It’s not a good question. The question to ask is whether you should go to the Cloud. And maybe where.

It might seem like a distinction without a difference. But it isn’t. Ask why and you assume the conclusion. It’s a dangerous habit, because once you do that, you gather information as ammunition, not to help you make a complicated decision.

I’ve been doing some pro bono work with a local non-profit — 25 wonderful, dedicated people, who work for far less than they could make anywhere else and run their information technology so long that if it were a car it would be an original VW Beetle, held together with duct tape and Bondo.

Their server is out of gas.

They have three different applications that have to keep track of contacts, with no integration except brute force, and no way to afford anything better. Beyond that, they’re pretty basic. MS Office. Outlook and hosted Exchange with bundled administration and support. InDesign. QuickBooks.

And a high-end networked copier/printer/scanner.

A perfect candidate to move to the Cloud.

Or so I thought until I scratched beneath the surface. It didn’t take much scratching, starting with two basics — identity management and printer queue management.

25 employees are enough to need Active Directory (or eDirectory, or LDAP, if they wanted to move to the Linux world). Right now these live inside the firewall no matter what else a company does with its architecture.

25 employees hitting a printer also means a server-mediated print queue.

Conclusion: They might not need a very big server, but they do need a server.

But surely they could do everything else in the Cloud, couldn’t they?

Sure they could, except that with a staff of 25, they just don’t need very much processing power. Storage, yes. Which, once they own a server, is cheap … dirt cheap. 2 terabytes of mirrored storage — enough to last them five years — would cost about four hundred bucks.

No, that doesn’t buy them the real-time collaboration they could get with hosted SharePoint or Google Apps. On the other hand, the most inexpensive hosted SharePoint they could get would cost them $10 per gigabyte per month.

As they’re a non-profit, they’d probably quality for Google’s free program for non-profits. Free, that is, other than what they’d have to spend to integrate it with Active Directory, recreate their current folder structure, migrate their data, and then pay for a higher-speed Internet pipe than what they currently need, because now every file retrieval is going to the Cloud and back. Estimated incremental cost: $600 per year — more than what they’d spend for 2 TB of on-site storage, once and done.

Which yes, they do need to back up. Add two backup drives, simple backup software (with encryption), and an employee willing to transport the backup drives back-and-forth and that’s taken care of for just about nothing, too.

Not fancy; more than good enough.

What to make of this?

They’re in the Cloud with hosted Exchange. The bottom line benefit doesn’t come from hardware and software savings, but from not having to employ a sysadmin to run and administer the sucker. Score one for the Cloud. Could they switch to gmail and Google Calendar? Sure, but then they’d have a migration to manage, after which they’d have to take on their own email administration and bring staff support in-house as well.

One of their three contact management applications is also in the cloud … a bulk emailing service. Same story.

So for an organization that should be an ideal target for Cloud computing, the Cloud turns out to be a case-by-case choice, not a strategic solution.

The more I look at the Cloud, the more concerned I am that its economic model is based on a seriously flawed assumption: That paying “by the drink” is more attractive than paying a lump sum and getting it over with.

No question about it — if you’re in a business where processing loads are unpredictable, varying from a low baseline level to very large short-term peaks, then the Cloud’s ability to provision resources dynamically is just the beverage you need.

I suspect, though, that most businesses will find, for most of the situations they face, what oenophiles have known forever: That when they pay by the drink, a glass of wine at a restaurant costs a whole lot more than paying by the bottle to enjoy a glass of the same fine wine at home.

That’s true even if they only drink half the bottle.

Comments