He Ain't Superman

Back in the early days of java and the time of the dotcom bust, George Reese was a minor pundit/author (O'Reilly division) in the database part of the world.  You can look up his stuff at O'Reilly or Amazon.  Not much heard from since then.  He would occasionally show up on the O'Reilly site.  And he has again.

Here's his take on the Amazon fiasco.  What's so intriguing about this missive is the Up is Down meme involved here.  The Cloud meme has been promoted as a less: expensive, time, resource, attention answer to the Data Processing Problem, particularly for web sites.  Reese spends his few thousand words telling us that the SLA is *our* responsibility, not Amazon's.  Ditto for infrastructure design.  Ditto for physical design.  Ditto for just about everything.  Well, you're not allowed RDBMS, but you didn't want that anyway, did you?

He spends all that ink telling us that we have to work around the fragility of Cloud provision, in order to utilize Cloud.  And we can't do databases, because, well, Cloud just isn't quite up to that.  Where, exactly, is the win for clients who care about their data?  He admits that such services won't provision such that there is sufficient excess capacity to support the loss of significant resources.  Kind of like what might happen if you ran your own datacenter, only worse. 

What's most annoying about his missive is that he makes, nearly explicitly, the assertion that the storage method, Cloud, determines the nature of the datastore.  Not only can you not have SSDs as primary store for a BCNF databases, you can't even have *any* sort of RDBMS if you use Cloud.  Last time I checked, that's the tail wagging the dog.  But knuckleheads who admire the Emperor's New Clothes typically ignore such conflicts.

Oh, and you really should go read the piece.  The commenters have a field day with his silliness.  Yum.

[UPDATE]
In my haste to get this in words, I neglected to explicitly state the objection to Cloud I (and others) hold:  the value proposition for Cloud is that it enables organizations (even just the IT group on its own) to out source an unwanted responsibility at lower cost; don't do it yourself and save money.  Reese's treatise, and the failure, deny the existence of that proposition.  This, while I gather he doesn't get it, is kind of a Big Deal.

Was A Cloudy Day

As regular readers know, I've not been a fanboy of anything Cloud.  My reasons are less to do with security, reliability, and other mundane considerations; rather that Cloud represents lowest common denominator (race to the bottom) disk storage.  As a means for storing family vacation photos, well, OK.  I'd prefer to keep those on my own storage, but each to his own.  But Cloud for serious storage, I've never been a fan.  My Yellow Brick Road is paved with SSD running BCNF databases.  Unless, and until, Cloud provisioners recognize that it ain't "about just bytes", I'll pass.  Some times, if it's too good to be true, it ain't true.

Then Amazon jumped the shark.

Here's another take on the situation.  This is from an experienced Cloud provider, of a sort.  As he says, the Fortune X0 have been trying to provide a central storage solution for rather a long time, with little obvious superiority.  It's worth noting that the IBM Service Bureau service goes back to, at least, the early 1960's.  Cloud is neither new nor a walk in the park.  I guess Amazon and its clients now know that.

The Service Bureau (and similar) were able to provide some semblance of service over leased lines.  The notion that TCP/IP, with HTTP tossed in, over normal phone lines is sufficient is, well, immature.  What was that you said?  The Emperor has one fine set of threads.  Yes, yes he does.

Not A Cloud Was in the Sky

On more than one occasion, I've made the point that "cloud computing" is really very old hat.  Or, old wine in new bottles.  I came across this interview with IBM honch Steve Mills.

Here is a clip:

Mills: I think that's the number one reason why this is appealing to CIOs. The interesting part about "cloud speak" is that many people want to isolate their discussion of cloud to only certain classes of companies. And my view is that's too narrow. Service bureaus emerged in the 1960s. I mean, ADP is one of the industry's biggest and most successful cloud companies.

Knorr: And earliest, right?

Mills: Yeah. If I'm in the accounting department and I use ADP, ADP is my cloud company.


The "service bureau" is actually older than ADP, and was an IBM invention.  See this search result.

Your Diagnosis, Herr Freud?

Just a short note about the new Intel 510/320.  In a nutshell, Intel claims the Marvell powered, sequential biased, 510 is the Prosumer part while the Intel powered, random biased, cap protected 320 is the Consumer part.

This makes no sense at all.  The early reviews, both systematic and informal, say that the 320 is a righteous part.  I'm going to order the 160 gig in a few weeks (or so), depending on whether there're reports of funny business.  Amazon shows two part suffixes: B5 and K5; the AnandTech review is a K5 part, so that'll be the one.  Now I can, finally, get around to running some data (leave the other stuff to the side for a week...) through HDD, G2, and G3 (as the 320 is being called).  Fingers dirty.  Yum.

What's Your Preferred Position?

Regular readers know that I've been talking up the synergy between iPad type tablets and the normalized relational database.  And that such synergy must recognize the nature of input on a tablet.  Little bits of pickable data.  Hors d'oevres, so to speak; not a four course meal.

A few minutes ago Anand posted a quiz.  I guess the question has reached the mainstream pundit class, although it's not quite the right question.  The right question is:  what kinds of data can a keyboard-less device support, and therefore what kinds of applications are best suited to such devices? 

Mr. Natural Answers Your Questions

A posting on the PostgreSQL/Performance group (having to do with the Intel 320 announcement, which I'll save for a different posting after the dust settles a bit) got me to looking again for published tests of SSD vs. HDD and databases.  As you can see, Dennis Forbes is listed in the links block.  I don't recall whether I've mentioned this post of his before; may haps I have.

But, in some sense related to the Intel 510/320 situation, he makes the salient point (my point since I discovered SSDs years ago) thusly:

Of course NoSQL yields the same massive seek gain of SSDs, but that's where you encounter the competing optimizations: By massively exploding data to optimize seek patterns, SSD solutions become that much more expensive. Digg mentioned that they turned their friend data, which I would estimate to be about 30GB of data (or a single X25-E 64GB with room to spare per "shard") with the denormalizing they did, into 1.5TB, which in the same case blows up to 24 X25-Es per shard.


Of course, his insight is rare, even among those I've read who've been positive about RDBMS/SSD synergy.  It's always been obvious:  normalized datastores are orders of magnitude smaller than their flatfile antecedents.  This smaller footprint comes with all the integrity benefits that Dr. Codd (and Chris Date, et al since) defined.  There are a whole lot of ostriches out in the wild, insisting that massive datastores are needed by their code.  What does it all mean Mr. Natural?  Don't mean shit.

Shape Shifting

One thing that I really like about O'Reilly books is the Rep-Kover binding; the original better than the current, however.  I find that most computer texts are near interchangeable with respect to content.  It's nearly always marginal, so what matters is ease of use.  For that, Rep-Kover is better than current "hardcover" bindings.  What I tend to dislike about O'Reilly is their (his?) incessant need to create "new" memes in the computing world.  Web 2.0 is, I think, the first; certainly the most infamous so far.

The last few months have seen the aborning of another: Data Science.  This one is even worse, in that it seeks to dumb down a perfectly legitimate pair of professions; statistician and operations researcher.  Long ago, I got involved in ISO-9000 certification, which was another early attempt to dumb down those professions (these days it's Six Sigma, which I had the pleasure to mentor at CSC).  It irritated me then, too.  It's of a piece with DIY neurosurgery, although not as directly deadly.

Yesterday's Forbes on-line version published a story about this newfangled profession, in the context of EMC.  Regular readers may remember that STEC, gorilla of the Enterprise SSD jungle, first touted, then crashed, on its relationship to EMC.  The article whispers that STEC, or whoever is currently supplying, is and will do well.

What's most bothersome about this meme is, as many others have remarked, both math stats and ORs do inferential stats, and inferential stats is based on the math of sampling and inference.  The fact is, one needn't have much training to calculate the parameters of populations.  Fact is, math stats and ORs don't even refer to these numbers as statistics, because they aren't.  It is exactly the same as baseball stats; they aren't stats, just numbers.  But, of course, the meme-sters once again wish to wrap themselves in the blanky of higher math. 

On the other hand, stats as a profession and work product is more interesting than computers.  Even databases, by golly.  May be I'll try to parlay both; the article says that such folks (humble self qualifies) are in demand.