I have been knocking around the computer industry for a while now, and I've noticed some changes in my contemporaries and myself... For one thing, the buttons around the stomach of those old shirts that have eluded capture by my wife are looking a bit more strained than they did in the shirts' heyday.
Another thing: I can't run down the road to the shops without spending five minutes glowing a vivid purple hue. I'm sure that kind of thing used to be much easier. I suppose that the increasing demands on my time - having a young family, more responsibility at work, etc., mean that all that time I used to spend playing badminton and going to the gym is being consumed by other activities, and what spare time I do get is generally used up exercising my right arm by lifting 568 g of brown liquid to my lips...
The other thing that I have noticed is that the same thing has happened to many computer systems I have known over the years. Those once-lithe applications so keenly tuned and lovingly slotted into production are getting a little tired too. Gone are the hours of tuning and tweaking that kept them at their svelte best; now, tired operations folk gaze blankly at a wall of CPU meters creeping ever upward, occasionally brushing off a cobweb or two to ring a bell when the utilization hits 90 percent for the umpteenth time.
The applications have gone the same way as the folk who created them. They too are doing different workloads than they did in the early days of their lives - as workloads have increased, extra machines have been thrown at the applications in an attempt to keep them useful. Eventually one will be unable to consume any more machine resources due to some architectural constraint or another, at which point the unfortunate application will be taken out back and put out of its misery, and a new project will be spawned to create a new one, more fit for the purpose at hand. Maybe that's what they mean when they say that J2EE is a mature server-side platform...
It is lucky that application servers, with their clustering technology, make it easier to deploy new capacity than it was in the 2-tier client/server days, when the only option was to try to find an even bigger hunk of tin and hope that the application could make use of all of it. Application servers have thereby augmented this more traditional "scale up" option for adding more power to the middle tier with the "scale out" alternative - just rack up another Linux blade, and Bob's your uncle. The flavor-of-the-month solution to this is to scale out with blades, since the acquisition cost of a really big server machine is generally rather high. However, the lifetime cost of blades is also very high - they consume a lot of power - which in turn means they require a lot of cooling, and require a lot of management. "Will you just apply that security patch to the OS please?" is the tip of a pretty unpleasant iceberg if there are a few tens of machines to "just" upgrade.
Rather than continue to bark up this tree, which is feeling more and more wrong, it is worth taking a step back and considering what it is that drives the need for this incredible quantity of machines. The answer turns out to be - at least partially - the need to overprovision to provide headroom for demand spikes. That order-processing system that manages the sales of Christmas wrapping paper idles along utilizing 5 percent of a UNIX server for most of the year, just so it has 75 percent in its back pocket for the Christmas rush. And so it goes on, across the whole application estate, since each application generally has its own dedicated hardware on which to execute. It would be too difficult a configuration management job to have all of the applications on one machine - imagine if one of them needed an OS upgrade that the rest weren't compatible with. Therefore in an effort to make configuration management manageable, lots of CPU headroom is wasted, complete with the associated wasted power and cooling.
It is this issue that the Azul appliance is designed to address. The appliance is designed to run Virtual Machine-based applications on behalf of existing UNIX servers. An application that used to leave the UNIX CPU 15 percent idle under load will leave the same CPU 75 percent idle under the same load, when it is mounting the appliance's compute capacity. Suddenly, there is much more headroom on the UNIX box - maybe you can take the 10 you have already and replace them with just three to handle the same load and still provide for redundancy for failover. The appliances providing this compute capacity are deployed in a pool themselves, which means that they are redundant and highly available too. It also means that extra capacity can be brought online administratively, without making any changes at all to the UNIX application environments; the next time a Java application launches, any additional capacity added will be available to service its needs.
Finally, because the UNIX tier still exists to provide the Configuration Management control that it is very good for, the appliances can be shared among multiple applications, so one pool of appliances can be used for the Christmas wrapping paper application, the Easter Bunny application, and the Halloween gifts application. At any one time, the peaks and troughs will balance out, so the compute pool can be kept much more utilized than any one of the UNIX boxes ever could have been. In one fell swoop, the Network Attached Processing approach provided by the appliance pool has allowed consolidation of applications, and provided the flexibility to provide additional capacity on demand whilst preserving the existing configuration management systems.
This is clearly a recipe for teaching some of the "old dog," middle-aged applications some new tricks, and thereby preserving the investment made in them for some years to come.
However for the hopeless cases, the appliance approach brings other benefits: new applications can be written to take advantage of a 96GB heap. Without fear of stop-the-world garbage collection pauses stretching into infinity, they can use easy-to-maintain, coarse-grained lock structures - since the appliance provides optimistic Java lock concurrency - and they can be written to take advantage of large numbers of active threads, because even the smallest appliance provides 96 CPU cores, each of which can run a thread in parallel.
All in all, the Network Attached Processing solution provides a powerful way to combat mid-tier bloat, while reducing management costs and providing new opportunities for innovative Java architectures. After all, since the advent of Storage Area Networks, when was the last time you worried how much spare disk capacity there was in your machine? Why shouldn't compute become commoditized in the same way?