Robert X. Cringely looks at IBM’s latest mainframe with a bit of a jaundiced eye:
I’m perfectly happy for IBM to introduce a great new mainframe computer. It’s just that the 85 percent faster, 85 percent smaller and a little bit cheaper z10 is coming three years after the z9, and Moore’s Law says sister machines that far apart ought to be 200 percent faster, not 85 percent — a fact that IBM managed to ignore while touting the new machine’s unsubstantiated equivalence to 1,500 Intel single-processor servers.Where were the hard questions? Did anyone do the math? The tricked-out z10 that’s the supposed equivalent of 1,500 beige boxes costs close to $20 million, which works out to $13,333 per beige box — hardly a cost savings. Even taking into account the data center space savings, power savings, and possibly (far from guaranteed) savings on administration, the z10 really isn’t much of a deal unless you use it for one thing and one thing only — replacing a z9.
Heres where things get interesting — Azul Means (Big) Blue:
Azul makes custom multi-core server appliances. You can buy a 14u Azul box with up to 768 processor cores and 768 gigabytes of memory. The processors are of Azul’s own design, at least for now.But what’s a server appliance? In the case of Azul, the appliance is a kind of Java co-processor that sits on the network providing compute assistance to many different Java applications running on many different machines.
Java has always been a great language for writing big apps that can be virtualized across a bunch of processors or machines. But while Java was flexible and elegant, it wasn’t always very fast, the biggest problem being processor delays caused by Java’s automatic garbage collection routines. Azul handles garbage collection in hardware rather than in software, making it a continuous process that keeps garbage heap sizes down and performance up.
Language geeks used to sit around arguing about the comparative performance of Java with, say, C or C++ and some (maybe I should actually write “Sun”) would claim that Java was just as fast as C++. And it was, for everything except getting work done because of intermittent garbage collection delays. Well now Azul — not just with its custom hardware but also with its unique multi-core Java Virtual Machine — has made those arguments moot: Java finally IS as fast as C++.
But for that matter there is no reason to believe that Azul’s architecture has to be limited to Java, either, and can’t be extended to C++, too.
To me what’s exciting here is Azul’s redefinition of big iron. That z10 box from IBM, for example, can look to the network like 1,500 little servers running a variety of operating systems. That’s useful to a point, but not especially flexible. Azul’s appliance doesn’t replace servers in this sense of substituting one virtualized instance for what might previously have been a discrete hardware device. Instead, Azul ASSISTS existing servers with their Java processing needs with the result that fewer total servers are required.
Servers aren’t replaced, they are made unnecessary at a typical ratio of 10-to-one, according to Azul. So what might have required 100 blade servers can be done FASTER (Azul claims 5-50X) with 10 blade servers and an Azul appliance. Now that Azul box is not cheap, costing close to $1,000 per CPU core, but that’s comparable to blade server prices and vastly cheaper than mainframe power that isn’t nearly as flexible.
And flexibility is what this is all about, because Azul’s assistance is provided both transparently and transiently. Java apps don’t have to be rewritten to accept assistance from the Azul appliance. If it is visible on the network, the appliance can assist ANY Java app, with that assistance coming in proportion to the amount of help required based on the number of cores available.
Now imagine how this would work in a data center. Unlike a traditional mainframe that would take over from some number of servers, the Azul box would assist EVERY server in the room as needed, so that you might need a big Azul box for every thousand or so servers, with that total number of servers dramatically diminished because of the dynamically shared overhead.
This is simply more efficient computing — something we don’t often see.