Appistry upgraded from 'snake oil' to BEHOLD

While I often dabble in application development and have crafted some pretty neat applications, I don't by any stretch of the imagination consider myself to be a software engineer.  Particularly since my software development training (one way in one way out structured programming in COBOL, C, etc.) predates object-oriented programming.  But I do think of myself as having a fairly good snake oil detector when it comes to app dev related innovations.  Some things are just too good to be true.  Short of seeing a demonstration of Appistry's griddish clusteresque fabric technology that not only makes applications run faster every time a new system (node) is added (griddish), but also gets more reliable with each additional node (cluster-esque), I was impressed.  But the first time I was briefed on the technology (when I wrote that it might be snake oil), I was still in that mode of I've got to see it before I'll believe it.

At Gartner Symposium last week, as I roamed the aisles of the exposition part of the event (ITxpo), I came across Appistry's booth and this time, they had something to show me; a fabric in operation. 

I consider Appistry to be one of the most significant disruptive technologies I have seen in years.  What makes the company's technology really something to behold is how it takes the idea of using commodity hardware to deliver supercomputer like power to a completely different level that no technology I have ever seen before does.  Supercomputers based on commodity hardware is a concept that grids, and to some extent clusters, have promised us for years.  But, to the extent that grids are good at taking compute intensive tasks (for example a Monte Carlo simulation or examining data gathered in the search for extra terrestrial life), dividing it up into smaller chunks of work, and parceling those chunks out to other systems, grids are not incredibly well suited to real time transactional systems.  At least not yet (standard grid technology promises to eventually get us there). 

Some types of computer clusters -- for example Oracle clusters that take the share-everything approach -- offer a degree of fault tolerance and performance that's tough to find in other solutions.  If a node drops out, everything keeps running as though nothing happened (OK, maybe there's a slight performance hit).  And, clusters are really good at handling real-time transactions.  But, Oracle's clusters are, well, for people running Oracle technology.  They lack that general purposeness that you theoretically get with grids.  The same goes for other clusters.  Oh, and have you ever taken a closer look at the configuration of a cluster node?  It may have Intel under the hood, but these machines are not exactly commodity hardware.  They usually involve server specific technology which, relative to real supercomputers or mainframes may qualify as commodity hardware.  But verus something like a Pentium desktop, the type of system that can be a node in a cluster isn't what most people think of when they think "commodity system."

So, what's Appistry?  It's general purpose.  Your applications can be written in Java, C/C++, or a .NET language like VB or C#.  So, it can apply to any type of application, transactional or not.  It's like a cluster.  The more nodes you add, the faster it gets.  And the more nodes you add, the more fault tolerant it gets.  It's commodity.  Whereas you need to buy exotic server things like multiprocessor XEONs with special error correcting technology and high speed interconnects for clustering, with Appistry, you don't need any of that.  All that fancy schmancy stuff is done in software.   Laughingly, the executives at Appistry talk about how one telecommunications customer -- you know, the kind that crunch a gazillion transactions every hour --  tried Appistry out with a bunch of desktops they bought at Wal-Mart.  But they weren't laughing because it was a joke.  They were laughing because it worked.  Maybe laughing to the bank.  You see, with Appistry, when when a node breaks, you don't need to fix it.  It's cheaper to just throw it away and replace it.  Now that's commodity. 

What will make you even more giddy is that when one node fails, the fabric recognizes that it failed and gives whatever task it was working on, perhaps a transaction, to another node in the fabric.   In real time.  To make this work, you do have to modify your application.  But the code you must add -- code that's usually added just before an atomic piece of work begins and just after it ends (to keep track of that atomic unit's state of completion) is minimal.  Child's play for most developers.   At Gartner Symposium, they showed me the code and then they  said "Unplug a node.  Any node."  I did.  And another.  At first, the client system that was monitoring all of the transactions waiting for completion showed that something was terribly wrong.  Transactions were failing.  But then, almost as quickly as they appeared to fail, they recovered, and then, they completed.  Sure, it took longer.  Add more systems to fabric, and it takes shorter.  By the way, when adding more systems to the fabric, with PXE -- the pre-execution boot environment provisioning technology that most systems have -- the new node just assimilates into the fabric.  You literally just plug the bare metal in, hook it to the network, and smile.  

I asked where a fabric tops out.  20 systems? 30? 50? 100?  More like a 1000 I was told.  "You've got to be kidding" I said.   But they weren't laughing.