John Reynolds's Blog

Clustering's new alternative

The current approach for scaling J2EE applications is to cluster application servers. Some really good work has been done and clustering has improved to the point where it's a basic commodity. Even “free” products such as JBoss and JOnAS offer complete solutions that include clustered caches to keep servers in sync. The process of setting up and deploying applications across J2EE clusters isn't standardized across vendors, but we really don't mind mastering the details.

Azul's “JVM appliance” is a totally different approach at dealing with JVM scalability: . Azul replaces the JVM on a server with a proxy that redirects processing to a specialized grid of “JVM tuned” processors. As the processing and memory needs of the system increase, you add processors and memory to the “JVM appliance”. The application is completely ignorant that the “JVM appliance” exists, so presumably the application's design can ignore many scalability issues.

Azul's “appliance” approach to JVM scalability is intriguing, but what leaps out at me is the realization that we may be in for another big shift in how we write and deploy applications. With Azul's approach and technologies on the horizon such as Sun's Multi-Tasking Virtual Machine, 10 Gigabit Ethernet, Computational Grids, et cetera, it seems pretty likely (to me) that our notions of how to scale an application are going to have to change dramatically.

Take this prediction with a huge grain of salt:

In the future we will design applications as if they were executing on a machine with unlimited CPU power and unlimited memory... Tools will figure out how to map those designs onto the reality of the available network resources.

Hardware constraints and network latency are never going away, but they are guaranteed to change. Automating the task of porting an application from a single “virtual machine” to a network of servers (or a grid of processing units) is not fantasy... science fiction maybe, but no laws of physics are violated. It is going to happen some day.

Building on David Rupp's blog entry on teamwork between humans and computers, I envision an environment where “the computer” comes up with options, and humans use insight and experience to make the right choice. Picture the dialog that you have today with your peers when mapping business requirements on to your company's IT infrastructure... Can't you envision an expert system taking part in that conversation?

Comments

• Clustering is currently extremely easy to do with Java. At the cajo project for example, we just pass objects to any available Virtual Machine via a method called setProxy(). This returns a reference to the remote object, which can then be used identically as if it were local.

  This allows large existing applications to scale on an object-by-object basis, with no modification to the underlying application itself. You could easily scale the application until every object was running on a separate machine.

  Rather than shelling out big $$$ for these so-called "JVM appliances"; it is far wiser to buy a bunch of commodity white boxes, and make use of free software.

  Posted by: cajo on April 15, 2005 at 07:19 AM

• Cajo sounds cool.Imagine the possibilities when those commodity white boxes have 10 Gig Ethernet on the motherboard.

  
  For the sake of civilized argument: The "JVM appliance" approach may have a slight edge over multiple servers in terms of setup and long-term maintenance. It all boils down to the process necessary to add (or remove) a server to (or from) an existing cluster.

  Update: Here's some pricing info on Azul's solution:"192 processing engines costs $199,000"

  --John

  Posted by: johnreynolds on April 15, 2005 at 08:48 AM

• Thanks! :-)

  Mobos currently come standard with 1Gig Ethernet, even on sub $100 models.

  A VM running under cajo can multicast its availability over UDP. The application can easily listen for these announcements, and then use the host. It is quite easy to structure an application so it can tolerate someone turning the cluster machines on and off, at random.

  Posted by: cajo on April 15, 2005 at 09:41 AM

• Now if we can just convince vendors to abandon per-cpu-licensing ;-)

  My company currently uses WebLogic, and BEA currently has a per-cpu licensing model (as does Oracle). If I go with conventional clustering, I get to shell out licensing fees every time I add a new server.

  I wonder how a "JVM appliance" fits into this model. Azul's has up to 394 processors... but WLS isn't technically even installed on the Azul box, it's installed on the "real" server.

  As if the rucus over "multi-core" processors wasn't a big enough licensing headache ;-)

  Check out this article on
  Grid licensing headaches.

  Posted by: johnreynolds on April 15, 2005 at 10:54 AM

• Hi John, have you looked at Tangosol Coherence?

  Peace.

  Posted by: cpurdy on July 08, 2005 at 11:32 AM

This work is licensed under a Creative Commons License.