News Review:
Network Attached Processing - the next big thing for Java ?Will NAP have the same all-pervading presence that NAS gained?
It's not often that a new piece of technology comes along where people are tempted to say "why didn't they think of that before?" Yet I think I have found just such a technology. And if I am right, you will be hearing a lot more about it in 2006.
The concept is called Network Attached Processing, and the company in question is Azul Sytems.
When Java was first invented, it was decided that software code would not be compiled "natively" to any particular hardware or operating system. Instead, the compiled code (sometimes called "byte code") is designed to run in an environment called a "Java Virtual Machine" (or JVM).
The JVM represents an imaginary machine architecture. In order to run Java applications on, say, Linux or Windows, it is necessary have a Java Runtime environment that maps the JVM to the specific target operating system & architecture. Once the Java Runtime environment has been written, then all Java programs would be able to run on that target. This architectural approach lies at the heart of the "write once, run anywhere" mantra for Java.
Obviously, if the underlying OS and architecture is relatively similar to the JVM, then the Java Runtime will be relatively easy to write, and should be very efficient. Ideally, then, an executing JVM should be located on an Operating System and Architecture that is architecturally similar to the JVM. On the other hand, there is a requirement to be able to run Java applications on Industry-standard Operating systems (e.g. to run Websphere or Weblogic or JBOSS on Solaris Linux).
Azul Systems have provided a solution to this challenge. - Network Attached Processing, in the form of an Azul Compute Appliance.
The Azul solution consists of a customised JVM or "VM Proxy". This VM Proxy receives incoming byte code for execution and forwards it directly along a network path to the Azul Compute Appliance, with executes it. On the Compute Appliance, the byte code is received by a "VM Engine", which then performs the Java compute operation, before returning control to the calling server's VM Proxy.
One obvious advantage of this architecture is that the "client" Operating System still appears to be performing the same functionality as before, running the business Application. However, the actual CPU processing is being off-loaded to the Azul machine. Neat, or what?
So what's the Azul Compute Appliance? In a nutshell, it is a 24-way (or up to 384-way!) multi-processing server which is specifically designed to run JVM environments very very efficiently. For example, it handles multi-threading very well (not surprising, if you could have 384 CPUs!), oodles of "heap" memory, highly efficient memory garbage collection etc. etc.
So how about the best of both worlds ? Keep your existing application on your old server, hook in a Gigabit Ethernet card, and hang the Azul System off the other end. Better still, have multiple Servers being Compute Served by a single Azul machine. Sounds a bit like a Compute equivalent of NAS ? Yep - you've got it!
Once the concept is grasped, all sorts of opportunities arise. Firstly, we are used to purchasing servers to host J2EE environments, based on their computing power. Instead, the host server becomes just a "mount point", a suitable O/S architecture for running the I/O and communications activity. The real processing is done in the "compute farm". What happens if you need additional CPU for this growing application ? No action required - just ensure that the compute farm is powerful enough !
The use of a "Compute Farm" suddenly changes the whole dynamics of Servers in the datacentre. Each Java server could just be a tiny blade (or a Virtualised server), providing it has the O/S and I/O capability for the application. Datacentre management of Servers would be massively simplified with NAP, just as it has been in the storage arena with NAS
Azul Systems web site is at http://www.azulsystems.com. I hear that they have plans to support .NET runtime as well in the near future. Definitely one to watch in 2006.
Reviewed by Dennis Adams in December 2005
