Sunday, August 14, 2005

Why Grids Make Sense

The term "grid" means a lot of different things to a lot of different people, so first off let's define "grid" within the context of this post: a cluster of commodity machines in the same geographic location running a single transaction-oriented application.

The traditional way to run transaction-oriented applications is with a three tier architecture, where web servers running on a cluster of 1 or 2 processor commodity machines mitigate connections to application servers running on a small cluster of 4, 8, or 16 processor machines. This is a great architecture and made a lot of sense when software was written to scale vertically and IT organizations wanted to run small clusters of UNIX machines.

Traditional Three Tier Architecture

The web tier serves static content and load balances connections to the application server tier, which serves dynamic content and connects to backends.

As part of the trend towards commodity machines, people are starting to run 1 or 2 processor commodity machines in the application tier as well as the web tier.

Modern Three Tier Architecture

When you step back and look at this evolving architecture, it begs the question:

Why have a cluster of commodity machines mitigate connections to... another cluster of commodity machines?

Consider the following architecture, where the web and application tiers are collapsed:

Grid Architecture

Since static content is now served directly from the Linux kernel, there is no performance impact of serving the static and dynamic content from the same machines. By including a reverse proxy, which most people are running now, a DMZ can be maintained in place of the web server tier's DMZ.

This architecture where we move from a triple decker club sandwich to a pancake architecture where the web and application tiers are merged together is the exact architecture deployed at every large scale web site, ranging from Amazon to E*TRADE to Google to Yahoo.

In order to deploy this kind of grid architecture in an enterprise environment, the nodes need to be able to call each other to share sessions or data. More on this evolved load balancing in a subsequent post.

Friday, August 12, 2005

Here Come the Java Guys

We threw a small party last night to celebrate the ActiveGrid 1.0 release, which was a fun time. We really pushed it to the limit getting this release out, and I was worried that it was going to be a trophy wife release (definition: looks good but does not work), but the 1.0 is actually very stable and applications like our pilot at Pfizer are running well. Kudos to the OpenCrowd guys for getting the Pfizer app done in record time.

The party was one of those unfortunately few and far between times when you get the former CTO/architects of WebLogic, Kiva, and NetDynamics together. This of course led to some good natured ribbing about how scripting languages suck and that I had better see the light about Java. It was pointed out that even the SpikeSource and SourceLabs guys now have Java stacks!

I shared the questions I ask the audience nowadays whenever I give talks, like the last couple of weeks at OSCON and LinuxWorld:

Q: Does anyone remember back in 1996 and 1997 why everyone started running Java on the server? What was the big compelling thing about Java that Sun had up on its home page?

A: WORA (Write Once Run Anywhere)!

Q: What operating system and processor type are the vast majority of new applications deployed on today?

A: Linux/x86!

Q: So do we still need a big abstraction layer above the operating system?

A: Hmmm...

When I was at Sun there was a guy who had this great way to evaluate technology. He said, if it was invented today, would it win? So today's requirements for an application platform are: "Linux/x86 application platform that processes HTML and XML text efficiently and handles unstructured data well." If J2EE came out today would it win this market?

In other news, I was blown away by a demo of Zimbra (formerly Liquid Systems). This is the nicest AJAX application I have seen yet. Yes, yes, the backend is in Java... :)