Just because the terminology "cloud computing" is in vogue and has become the hottest topic to hit IT in a long time doesn't necessarily give every vendor the creative license to say, "we're cloud computing, too!" Or does it?

David Berlind, Chief Content Officer, UBM TechWeb

December 18, 2008

6 Min Read

Just because the terminology "cloud computing" is in vogue and has become the hottest topic to hit IT in a long time doesn't necessarily give every vendor the creative license to say, "we're cloud computing, too!" Or does it?

I've known the folks at Appistry for a very long time. Back when I first met them, the name of the company was Tsunami Research and they referred to their technology as "hive computing." To be honest, I love the technology. For companies with on-premises applications that need to scale, Appistry takes a grid-like approach that not only lets you simply toss more machines at the problem, the machines don't have to be exotically configured servers. They could, for example, be ordinary desktops. Back in 2005, I blogged "Why buy Xeons when Wal-Mart Pentiums will do?"

One of the cool ideas behind hive computing was that machines could be taken out of "the hive" just as easily as they could be added. Sort of like a beehive. If a bee dies, his work is absorbed by the rest of the hive. The same goes for Appistry. If a machine in a hive dies, the rest of the hive (and the applications running on it) keep chugging along, barely noticing the that one of the systems has gone down. Even the work that that system was doing is taken over by another system. Though it's not a very green idea, one of the advantages of this approach is that, to the extent you loaded your hive with cheap PCs, you could toss crashed PC's out. That's because the cost of figuring out how to resurrect a dirt-cheap PC exceeds the cost of replacing it.

In Appistry's parlance, however, the whole "hive" technology eventually gave way to a new acronym: EAF or Enterprise Application Fabric. EAF sounds sort of catching in a "we need something marketable to enterprise IT people" sort of way. Then, in 2007, along came the phrase "cloud computing" and, would you believe it? Now, Appistry is a cloud computing solution provider. It sort of leaves you wondering who the guardian of the phrase "cloud computing" is (yes, I know, it was almost Dell) and where the hell are the terminology police when you need them? At least to double-check and make sure a crime isn't being committed.

So, how is it that Appistry, after all these years as something else, now sees itself as a cloud computing solution provider. Well, one answer, theoretically, is that much the same way you could once toss a Wal-Mart Pentium into Appistry's hive-cum-fabric-come-cloud, now, you can use machine instances or VM instances running on Amazon's Elastic Compute Cloud (EC2).

Earlier this year, I caught up with Appistry co-founder Bob Lozano (he's on Twitter) at MIT's Emerging Technologies conference. It was moments after CNET News.com editor-in-chief Dan Farber led an all-conference panel on cloud computing and it couldn't have been a more fitting time to hear about Lozano's views. I captured the entire interview with my digital recorder so you can stream (using the podcast player on this blog post) or download the audio.

But here is some of what I heard:

Clouds have been very good to us. The panel today was about the public cloud...

.... the semantic load for people isn't the most important thing. The most important thing for a lot of folks -- it's about scale. And they think to [themselves] "I can be flexible. I can be scalable and I don't have to worry about the upper bounds." As we talk to a lot of enterprise customers and the customers of ours in the intelligence community and things like that, what attracts them about the Google story and the Amazon story is the fact that these folks just seem to be able to grow stuff and that's very attractive.

We cloud-enable applications. We basically take lots of computers or virtual machine instances or whatever you want them to be and make them look like one thing so that your application can very easily live in a world that is composed of lots of smaller things. If you're a virtualization person, the way to think about it is that we aggregate stuff together. Traditional virtualization divides up a bigger resource for lots of separate applications. We take care of the problem of an application that has to live on a whole bunch of stuff, but act like one thing and we make that happen transparently.

... what we are saying is let's take an application and let it get as big as it needs to get. When you are able to aggregate things together -- and this is key -- and that happens without the developer who doesn't have to do anything, then you can pick the things underneath it to be optimal from an infrastructure point of view. Maybe you might want to run [those applications] on commodity stuff. Why? Because it's cheaper. Because may use more efficient and less power for computing purposes.

[Appistry] is saying the same exact thing, which is why we like the cloud language and the cloud meme that's developed is that the applications can truly be decoupled from what's underneath them. The problem comes in if you have a small application -- then this part really doesn't matter -- but if your application gets any kind of a scale to it, then it really does matter if you can aggregate things together.

What we end up doing is we teach the computers underneath [the applications] how to act like one [computer]. So, for example, if you're using Amazon, and [Appistry] can run on [Amazon's EC2], you have instances you can pick from. You can pick a small, a large, and a jumbo, and so on. What if what you need is 100 jumbos? What are you going to do to the application? The traditional choice has been to write a bunch of complicated code at the application level to tie them together. We make it so you don't have to do that.

One of the more interesting pieces of the new Appistry story has to do with its support of Amazon's EC2. I asked Lozano if any benchmarks had been run to determine if going the EC2 route even made sense. Lozano told me that there were no benchmarks but that at some point, Appistry would have announcements around EC2.

Another issue I talked with Lozano about had to do with potential lock-in given that Appistry's solution is somewhat proprietary. Lock-in is one of the big fears of IT people who, as they look at the cloud, also are looking for ways to unravel all the lock-in points in their on-premises portfolios. In my questioning, I brought up Google App Engine's usage of Python (a relatively standard language) as a step in the right direction. Citing App Engine's usage of BigTable, he clearly thought I picked a bad example.

There's a community edition of Appistry that people can download for free and that allows you to run on up to 10 cores before ringing Appistry's cash register. After that, the list price is around $1,875 per core, but Bob will deal with you once you get into the higher core counts. Tell him I sent you.

About the Author(s)

David Berlind

Chief Content Officer, UBM TechWeb

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights