Thinking Out Cloud

Grid-Enabling Resource-Intensive Applications

Timothy Hoehn and Bob Zeidman from Zeidman Consulting published on Dr. Dobbs a really interesting analysis of what's the optimal way to distribute an application across multiple machines.

They examined several methods and reached the conclusion that the optimal approach is distributed objects and the master-worker paradigm.

Sounds familiar? :-)

Grid Meets the Middle Office

Found this City#Grid Special Report via Matt Davey's blog. Lots of interesting real-world cases on how banks are using grids of all sorts. Not surprisingly, I especially liked the piece on page 12 in which Andy Doddington from Bank of America describes how they used GigaSpaces to scale and simplify a middle office applications for P&L analytics.

One the interesting things Andy raises is a very common thing on Wall Street, which is the extensive use of Microsoft Excel among middle and front office users (traders, quants, etc.) in investment banks. Whatever you think of it, Excel is the de facto standard front-end for many-many apps in the securities industry.

While it is a flexible tool, and one that many users are familiar and comfortable with, it also creates many difficulties from an enterprise point-of-view around management, maintenance, disjointed data silos, etc.

In this particular case the solution was to use the GigaSpaces in-memory data grid and replace the client (Excel) with a rich client. That works. But one of the things we are working on with Microsoft is how to have the best of both worlds: the low-latency and central synchronized data grid with the familiar Excel.

I can't spill the beans just yet, but we'll be announcing and demoing what we've been up to together with Microsoft at the SIFMA show (formerly known as the SIA show) in June in New York.

Come see us there!

A Good Start

It's been a while since I posted but there is some really interesting discussions and blogs lately on JavaSpaces and specifically GigaSpaces. Most notably this thread on TheServerSide.com, which is a response to this article by Joseph Ottinger on "Using JavaSpaces." The nice thing for us is that Joseph recommends the GigaSpaces Community Edition (free!) as the JavaSpaces implementation for his walkthrough.

As a matter of fact, looking at our Google Analytics page view numbers and product download numbers January 2007 is the all-time highest month ever for GigaSpaces. We had 58% more visits in Jan 2007, than the average monthly visits in 2006. Cool.

Some other interesting posts include this one from Lorenzo Puccetti and the ensuing discussion in the comments. This topic keeps coming up every few months, and I also discussed it here. In any case, GigaSpaces continues being the example that JavaSpaces is extremely successful, useful and commercially viable.

The activity we generated in January is not just due to these threads. We've also had some great announcements: our remarkable 2006 results, partnership with Platform Computing, a project for a federal government agency, our new .Net features, award for our documentation, partnership with Torry Harris, and last but not least our Series C investment round with new investor FTVentures, and our existing investors Intel, BRM and Formula. So as you can see we started 2007 working full steam on all fronts. 

We also received some nice press coverage in Redmond Developer News and other publications. And I had the opportunity to present with Intel and Deutsche Bank at this webinar.

All in all, a pretty good start for the year.

Response to the Java Posse

The Java Posse podcast guys were kind enough to mention us again, specifically our 5.2 release. One of the comments they make, though, is that we seem almost afraid to mention that GigaSpaces is a Jini/JavaSpaces implementation, as we don't mention it in the press release and it is not featured on our web site. They say it's a shame for Jini/JavaSpaces fans everywhere.

Well, first, I take that as a compliment. So thanks, Java Posse.

Second, let's make it clear: we are damn proud of being a Jini/JavaSpaces implementation, and associated with the technology and the community around it.

The reason that we do not emphasize it in our marketing material is straightforward. We get more bang for the buck by talking about our features, benefits and customer results than we do by talking about the underlying technology, which sometimes ignites silly religious wars.

Another reason is that, frankly, our product goes well beyond Jini-JavaSpaces (as Patrick Logan notes), so we don't want to sell ourselves short. We definitely take advantage of the underlying Jini-JavaSpaces capabilities, but not necessarily as a programming model. That's why we prefer talking about Space-Based Architecture.

Our biggest contribution to the Jini/JavaSpaces community is creating a robust, enterprise-grade, commercially successful product.

In the meantime, and despite Sun having originally mis-marketed J/JS ("Your toaster will talk to your microwave oven and together they'll order a pizza"), the technology is clearly growing in popularity.

Speaking of mis-marketing J/JS: Fuzzy rightfully complains and Dan Creswell sets the record straight.

The Tyranny of Tiers

Ted Neward wrote an excellent piece in his new MSDN column about "layering." Essentially, Ted is making the same argument that is one of our key tenets at GigaSpaces -- separation of concerns in the architecture should be logical, not physical, as is the case with most tier-based systems. The physical separation creates huge latencies and is a scalability bottleneck. This idea of "virtualized Tiers" is the basis of our Space-Based Architecture and what lies behind our slogan: Write Once Scale Anywhere.

A while back, Nati Shalom wrote an excellent white paper about this entitled Space-Based Architecture and the End of Tier-Based Computing (registration required). By the way, it was one of the all-time most downloaded white papers on the TheServerSide. And Nati has been presenting this idea in various conferences.

We have been talking about "virtualized tiers." Ted gives it a name, which I think clearly establishes the difference between a "virtual tier" -- a "layer" in Ted's terminology, and a physical tier. I think I'll adopt Ted's version from now on.

From Nati's paper:

Tier-based computing has hit a wall when it comes to supporting performance-intensive applications. Whether the challenge is to grow these applications beyond a few hundred concurrent users or a few dozen parallel processes, issues like complexity, scalability, load-balancing, and synchronicity get in the way. The solution is not to improve the tier-based approach but to move beyond it — to a service-oriented architecture built on shared spaces within a grid computing framework.

The power of spaces comes from not having to separate various parts of an application into discrete physical runtimes — and then wiring those together in complex, hard-to-scale, and performance-consuming tangles of middleware. A space doesn’t care if an application has been “tiered.” Whether it has or not, the same program code will instantiate multiple times on the same machine or on multiple machines automatically — and even dynamically - in response to runtime parameters like CPU utilization.
Instances communicate through the space, just as if they were talking to middleware. In fact, they can use the same middleware APIs they always have — except now the middleware’s role has become virtualized, meaning that all physical message and data exchanges are handled transparently by the space.

And here’s the best part: Spaces make migrating today’s tier-based applications to tomorrow’s service oriented and grid architectures an evolutionary migration — with immediate performance boosting benefits.

Jini - Killer Apps aren't developed; they emerge

With the shift in Jini/JavaSpaces legal status from Sun to Apache, there has been some re-thinking in the community about the technology. Fans and users of the technology have long realized its power and benefit, and are somewhat perplexed: how is it that the rest of the world isn't catching on?

As part of this re-examination, a recent survey on Java.net asked "What would best help Jini gain traction?" The results made me wonder. More than half of the 490 voters answered that Jini needs a "killer app" (either for developers or end users). This result is not surprising. It echoes the "Beyond the Choir" presentation given by Daniel Steinberg at the 10th Jini Community Meeting (reproduced here).

I question the wisdom of the crowd on this one. Not so much because it isn't true that a killer app would help Jini, but because it is not a helpful call to action. Killer apps are not what makes a technology widely accepted. Killer problems do. Killer apps emerge.

To understand this better, some familiarity with Richard Gabriel's brilliant work would help. In particular, his seminal presentation Models of Software Acceptance: How Winners Win (PDF). It is very worthwhile going through Dr. Gabriel's presentation in its entirety. The main point I want to extract, however, is the myth that if a technology has been around for a long time, and has not achieved wide acceptance, it never will.

As Gabriel shows, most successful technologies, including software, actually take between 10 to 25 years from first instant in the lab to wide commercial acceptance. He gives a wide range of examples: from the VCR (developed 1954, widely accepted c. 1985), spreadsheets (first developed 1965, wide acceptance c. 1986), the web, and various programming languages.

The basic assertion Gabriel makes is that while a technology may have been around for a while, massive acceptance only occurs when there is significant environmental change that suddenly makes those technologies relevant (he gives 3-4 other scenarios, but this is the one he focuses on). Once this change happens, and if the technology is positioned to seize the opportunity, everything else will fall into place: products rapidly improve, they become cheaper, and with multiple applications -- including killer applications.

When a product is first launched, its quality is often low, its price high and its applications limited. The personal computer fell into this category, until software firms developed spreadsheets and word processors.

Gabriel then revises the Crossing the Chasm model. Geoffrey Moore's assertion is that innovative products that successfully cross the chasm between early adopters to mainstream use do so by finding a niche market they can dominate and expand. In Gabriel's version:

This [chasm] really represents a change in the environment that renders the technology useful/desirable/hot/necessary. It turns a vitamin pill into a pain killer, a nice-to-have into a must-have.

Now back to Jini/JavaSpaces.

The bad news: there is really nothing to do in terms of "developing a killer app". If the environment changes so that the need is strong, killer apps will emerge.

the good news: The environmental change required to turn Jini/JS from a vitamin to a pain killer is happening now -- and in a huge way.

Jini was originally designed with the motivation to overcome The Eight Fallacies of Distributed Computing. And distributed computing has never been more in demand and "more distributed" than it is now, because of (among other things):

• The trend to move to low-end commodity hardware
• Virtualization and grid computing
• Service-oriented architecture
• Multi-core platforms
• The overall need for scalable systems due to exponential data and transaction increases

There are also enabling factors that come from changes in the environment, particularly the abundance and low-cost of memory and fast networking.

Looking at the world with this in mind, killer apps for Jini/JavaSpaces are everywhere: Wall Street, defense, online retail and gaming, analytics, RFID. Heck, even the original, somewhat derided, proposed killer app for Jini -- device connectivity -- is highly relevant today.

It's everywhere. I know. My company sells more of these "killer apps" every quarter.

So what should Jini/JavaSpaces fans do now? Finish the job. Make it easy to understand and learn, easy to use, interoperable, commercially supported.

At GigaSpaces we've been doing a lot of this: interoperability with .Net, C++, Spring, Mule and other environments. We're working hard on online documentation, and ease of use, and every other aspect of making Jini/JavaSpaces into an enterprise grade product.

Others have been doing good things as well: Paremus with their efforts on OGSi and SCA, Dan Cresswell with the Blitz Project, the Sun Jini team, Van Simmons with the ComputeCycles project,  Calum Shaw-Mackay with Glyph and many others.

(By the way, there's an interesting presentation from the folks at Paremus at the 10th JCM on the topic Why Jini must Adapt to Survive.)

We are seeing the momentum for Jini/JavaSpaces out there -- backed by dollars. It's an idea whose time has come.