Now for something completely different ... startup IDS is pitching floating data centers. Some good discussion on the topic here and here.


Now for something completely different ... startup IDS is pitching floating data centers. Some good discussion on the topic here and here.

One of my favorite parts of the role that Nicholas Carr is playing as an observer of modern computing culture, and a fomenter of useful change, is not so much what he has to say - and I think he says a lot of very insightful, very useful things - but what he triggers other people to say, think, and perhaps do.
![]()
At the very least, Carr certainly makes the conversation in our industry far more interesting.
Ok, well the broken stuff for today (so far) includes Digg and Yahoo Small Business.
As I have commented before, I am a big fan of Google's basic approach to scalable computing. There is much to like - Captain Enormous scale on commodity gear, rapid deployment of applications, and so on.
Yet it is by no means perfect.
In particular, there is a chronic level of failure in (at least) some of the flagship services that should not be acceptable in any modern day offering, least of all something which is a standard part of many people's workflows.
Just ran across a very good post by Robin Harris from the misty dawn of time (last summer) stemming from the Google Scalability conference. Why should we care how Google scales? Like Robin points out,
They roll out new applications for millions of users with surprising speed, especially compared to corporate IT. They build data centers with hundreds of thousands of servers - and millions of disk drives - and run it all on free software.
Costly corporate kit, like RAID arrays and 15k FC drives, aren’t used. Yet they do more work in an hour than most companies do in a year.
I wonder if there's a "rolling brownout" in google applications today?
Earlier in the morning google reader (generally a really decent app to have around) was hanging, going into eternal "loading" screens (see below).

Since all of my blog / news feeds go through google reader (for now), I decided to switch gears and go research something. Except that google search was down as well.
The fact that SaaS vendors can offer innovative, cool new services that are easy to start using and easy to operate is a given ... nobody would argue with that.
But can an enterprise trust these offerings yet?
As Larry Dignan notes in a post about Coupa's e-procurement offering, which is going to market on top of Amazon's EC2 and S3, enterprise expectations are typically "five 9s" ... that is, uptime of 99.999%.
What are Coupa's chances of achieving five-nines as they stand now?
In a good move for the industry Amazon finally (in the past two weeks or so) put an SLA into place for S3, the storage half of their cloud computing offering.
Yes there are caveats, and yes the services levels are not enterprise-grade, but ... at least they have something. And that's a start.
The announcement post is here, if you want the details, with a good summary post from Larry Dignan here.
Mr. Benioff:
I guess this must actually still be 1892, or some other year when it was OK for enterprise applications to just summarily shut down for awhile.
But of course, this is the Web-2.0-SaaS-is-King era, in which rock star architects and eloquent marketing folks convince all comers that all customers can trust SaaS providers, that anyone can bet their companies on these elegant, brand-spankin' new apps because the golden age of "trust-us-we'll-run-them-for-you" enterprise applications is finally upon us.
Except that it isn't. Not yet anyway ...
Is "One Nine" Enough?
It is really hard to go more than a week or two without hearing news of yet another invincible, web 2.0-service-built-to-scale-and-be-reliable, not scaling or being reliable.
On the one hand it's easy to dismiss these failures as someone else's problem, but the plain reality is that these systems have been built and deployed by folks who really thought that they had the scale and reliability problems covered ... except that they didn't.
Oops.