GridGain presentation, 3/21/2011

I'd like to go over the GridGain presentation from last Monday night,
to offer some perspective on some of the points, and point out some
things that can be useful for future presentations.

First off, note that I work for a company in a similar space as
GridGain; I don't think I can legitimately pretend to be unbiased.
That said, I have a long (long) public history of observing companies
and products in *many* spaces. I'll try to keep my employer's biases
and personal biases out as much as I can, and point them out where I
cannot or where it's relevant. (It might be relevant because, as
someone with experience in distributed computing, there might be
employer-related insight that actually contributes value.)

Now, on to presentation-oriented matters. I have run a few major
conferences; some of these observations are based on that experience.
These are tips that every conference would give you.

1) It's almost always wise to use Eclipse in any presentation, because
it's the de facto standard for Java editing, for better or for worse.
(It's "for worse." Eclipse is horrible. C'est la vie.) Even people
like me who prefer IDEA (and would gnaw off our hands before using
Eclipse personally) know Eclipse well enough to use it for
demonstrations, and the UI shifts that IDEA incurs aren't worth losing
your audience.

2) Use the language your audience knows. When four or five people know
Scala in the audience, by golly, USE JAVA. As it is, the Scala tooling
support for *every* IDE is still lacking, so you end up fighting the
tools, plus you have to explain and justify Scala at every step, and
plus Scala's terseness works against you in the demonstration. (We saw
every one of these weaknesses in the demonstration last night. Dmitriy
even pointed out that the tooling support wasn't all there.) The
concepts Scala has have analogs in Java; he should have used them, in
my opinion. I think he encouraged people to try out Scala and
GridGain, which was good - but I don't think he actually demonstrated
*why* outside of his obvious passion for them both.

3) Fonts... fonts, fonts, fonts. Use a low screen resolution for
demonstrations. People don't want to squint. Lower amounts of content,
with more getting through, is a lot more valuable than your comfort
zone with your screen real estate. When you have to apologize that
your IDE doesn't scale fonts up past a certain point... time to change
your screen resolution. And your IDE. (See point one...)

4) Networks, networks, networks. I wondered if I should bring in a
wireless router just so we could establish a controlled local network,
to enable everyone to run in the local grid. He promised us steak and
gave us fizzle. I was really looking forward to this part of the
demonstration, because it's a lot of fun to run stuff locally - and
it's very, very effective for distributed computing demonstrations to
show local participation. It's also got its own perils, but if you're
going to promise it, it should happen.

5) Versions, versions, versions. He ran 3.1.0; the most up-to-date
download available on the GridGain site was 3.0.5e (which I was
running) and while that wasn't the reason the cluster couldn't
autodiscover, it's just one more variable that isn't needed. It also
comes across as a bit elitist; "I am running a version you can't,
muuuaaahahahahaha." If there's no absolute justification for running
an inaccessible version, then don't use the version people can't find.
Or...

6) Storage, storage, storage! I built a USB drive (there) with my
GridGain installation; if the cluster had autodiscovered properly, I
would have offered it to anyone who wanted it, just so they wouldn't
have had to download GridGain from the site itself. If you're showing
off a product for which a license isn't necessary, or in which the
attendees are invited to participate, then you need to provide the
product for them. CDs are acceptable; USB drives are even better. In
fact, if you're going to run a version that people can't download
themselves, you could always provide it to attendees...

Now, on to the content itself:

GridGain is actually pretty nice. It uses a traditional cluster
approach, and has some very nice features - job stealing is one, for
example, which other products can emulate, but GridGain has a very
workable approach to job stealing. ("Job stealing" refers to what
happens when a node takes too long to process a message, due to
starvation for whatever reason on that node; another node can
appropriate the message and process it instead.)

However, what he was showing was not unique to GridGain. Plus, his
terminology was slightly flawed.

He described GridGain in terms of three features: as a compute grid
(meaning "map/reduce"), as a data grid (meaning "distributed cache"),
and as a deployment platform ("zero deployment," a term they use
heavily in their marketing.)

A compute grid is more than map/reduce. A compute grid is distribution
of requests. Map/Reduce is a form of grid computing, in which a
request is broadcast to multiple receivers (the "map" phase), and then
those receivers send back partial responses, which the broadcast
source then collects into a cohesive set of results (the "reduction"
phase.) Limiting distributed computing to map/reduce is like saying
all vehicles have three and only three wheels. (What about boats?)

A data grid is more than a cache. Ideally, a data grid is reliable
(which means it can be used as a system of record.) Most data grid
products on the market (including my employer's) provide the
capability for a data grid to serve as a system of record, which means
that the database becomes a backup and a source for reporting
information - not where the data "lives." A cache can be measured in
terms of how appropriate it is for this purpose. Features to look for:
query capability, write behind, synchronization and replication,
transaction capabilities. Most people don't think of a distributed
cache as being a system of record (nor should they); a data grid,
however, should be usable as a system of record.

To be fair, with the event model GridGain provides, you can in fact
bolt on "system of record" capabilities, as long as you follow a few
rules: you can use the enterprise version of GridGain (which provides
query capability), or you can limit the search to specific (and known)
keys (i.e., as if you were using a pure key/value store, which was how
Dmitriy described the cache last night); you can also use the eventing
system to write changes written into the data grid to a database or
other backing store. Neither of these are difficult, but it's worth
keeping in mind.

(The marketing monkey in me says that if you have to bolt something on
to gain a feature, it's not actually a feature. But hey.)

The zero deployment thing actually annoyed me a lot. GridGain, as a
company, is very verbose and aggressive in how they say none of their
competitors support "zero deployment." However, what they described
was as simple as a master/worker pattern using an interface as the
distribution point; there's no classloader magic, nothing really
special under the hood at all. (I can show you articles from 2007, for
example, that *I* wrote demonstrating the same "zero deployment"
facility with both Terracotta DSO and GigaSpaces.) I felt that this
feature was misleading.

His initial demonstrations - in which a node broadcast its ID to the
other nodes in the network - would have been just as appropriate for a
*standard* messaging system - any JMS provider, for example, would
have worked (albeit slightly more verbosely), by sending out a message
on a topic being listened to.

To his credit, he was demonstrating connectivity and broadcast
mechanisms, but he defined it as a compute grid, which wasn't
leveraged at all. Plus, while the API was *far* nicer than JMS would
have been (by leaps and bounds), it ... was in Scala. Akka
(http://akka.io/) has the same semantic capabilities, except in pure
Java, which would have been a better choice for use in the
presentation (as stated above). I suppose it goes without saying that
my employer's product *also* has similar capabilities, although it
also is able to hide the fact that it's remote from the client code.
(The salespeople said I had to put that in.)

Look: distributed computing is really *all* about messaging. Even a
distributed data store is about messaging; an entity is a message that
is consumed or read on request (as opposed to being pushed to
listeners) and has no expiration. Method calls are messages that are
pushed to waiting listeners. Everything else is window dressing and
enablement, even if some of those things can be critical (in
particular, failover and transaction management, as well as security).

Seen with this in mind, the demonstrations last night made a lot more
sense, including the event handling (which, BTW, was... kinda scary in
terms of how selective it wasn't.)

Now, I'm not saying GridGain is a bad product - not by any means. In
many ways, it's very innovative; their use of Scala in the internals
is actually very wise, and I respect and admire their advocacy of
Scala in the industry. However, it's important that you - as attendees
- see distributed computing as being more than what was shown to you
Monday night. The time constraints would have made an actual
demonstration very difficult in any circumstance, but the choices made
added to the lack of content communicated.

Some references:

* http://www.theserverside.com/news/1363891/Using-Terracotta-DSO
* http://replay.waybackmachine.org/20070202031207/http://www.theserverside.com/tt/articles/article.tss%3Fl%3DUsingJavaSpaces
(Sorry, TSS' developers are really smart and naturally lost a lot of
information when they removed features from TSS last year.)

-- 
Joseph B. Ottinger
http://enigmastation.com