Thinking Out Cloud

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.