Upcoming: High Performance Events

For those aching to meet your West Coast Grid host face-to-face in the near future, I'll be at a couple of public events in November.

For the nth year in a row, I'll be at SuperComputing. This year's glorious location is the Biggest Little City in the World, which is fine with me (assuming they can feed all 9,000 attendees simultaneously, a feat which was beyond the ken of Seattle in '05). I don't mind mixing a little blackjack in with my HPC.

If you want to find the Digipede entourage in Reno, head for the AMD booth. We'll be demonstrating software running on some very cool new hardware. The manufacturer hasn't made an official announcement, so I can't name names or give details, but these guys are making some screaming hardware: the deskside, personal xsupercomputer is a reality. It's a great fit for a partnership: how can a developer keep 40 cores running on 5 motherboards busy? We've got the perfect SDK for you: turn that box into a .NET powerhouse.

Anyway, see you in Reno.

And for those of you across the pond, wait a couple weeks and you'll get your chance, too.

The National e-Science Centre (note the spelling of "Centre," this is the UK we're talking about) has invited us to participate in High Throughput Computing Week at the e-Science Institute in Edinburg.

I am very excited about this. Europe is years ahead of the US in terms of large grids, and David Wallom from Oxford is one of the top people in the UK in this regard. I'm happy we're going to be able to do a half-day hands-on lab, but I'm even happier at the opportunity to spend 4 days with some great grid thinkers.

And it certainly won't hurt that we'll be in the land for which my favorite beverage was named. David assures me we'll be within stumbling distance of a pub...

Technorati tags: grid computing, digipede, hpc, supercomputing

Why West Coast Grid? PowerShell and LINQ are two great reasons

My very first post explained why I call this blog "West Coast Grid:" simply put, we think there's an advantage to specializing on one platform (in our case, the Microsoft platform, which happens to be developed here on the West Coast).

There are many advantages to working on one platform (deep integration with .NET, integration with the development environment, easy integration with Office and other tools, etc.).

Two cutting-edge examples of why stack integration is so useful have sprung up in just the last couple of days.

First, Digipede CTO Robert Anderson posted a PowerShell SnapIn for the Digipede Framework. I'm really excited about the SnapIn for a couple of reasons.

• First of all, it allows for command-line management of the Digipede Network (of course, PowerShell's .NET interface would allow this anyway, but Robert's cmdlets make it easier and more script-friendly).
• Secondly, we decided to open-source this SnapIn. That means that this is, in effect, an in-depth code sample for the Digipede Framework Management namespace. Most of our code samples have focused on the different distributed application patterns, so this is quite valuable. And, by releasing the source, we hope that our users may feel inspired to offer their own improvements!

You can download the binaries and the source here.

The other great example came from outside our organization.

Matt Davey, the Lab49 WPF guru who has been doing a bunch of writing about the use of cutting-edge Microsoft technologies in finance, posted a very simple "GridLINQ" this morning, using Digipede and LINQ together. It's very simple, but very powerful. And, according to him, it took him about an hour to put together!

One side note: In a recent post (where, by the way, he said that "probably have the best customer support in the world"), Matt mentioned that he had some trouble using Digipede and Vista together. While we do support Vista for the Digipede Agent and the Digipede Framework SDK, we haven't yet released a version of the Digipede Server that runs on Vista (which is where he ran into some installation problems). Not to worry, we'll be releasing a version of the server that supports Vista (and Server 2008) in the near future!

Technorati tags: linq, digipede, powershell

Another dead technology: the horseless carriage

I love finding new blogs about grid computing, and I did just that over the weekend. Guy Tel-Zur's Blog is "Mainly dedicated to IT, Parallel Processing and Grid Computing."

But I have to take issue with the first post I found: The End of Grid Computing? Guy says that "something is not going well with 'Grid Computing.'"

His evidence? Google Trends. He notes that the term "grid computing" is not as commonly searched-for as it once was, and concludes that something is not going right. I think there's a far simpler explanation, however: I think people aren't using the term "grid computing" as much as they used to.

To test my hypothesis, I looked at the Google Trends for "Information Superhighway." Not surprisingly, it turned up no results. Now, in 1996, this was almost a standard synonym for "internet." As far as I can tell, the internet is alive and well despite the lack of searching on "information super highway."

Simply put, the term "grid computing" is going out of fashion (and for good reason). As far back as 2005, I posted on the fact that the term meant so many different things to so many different people, it was effectively useless. To some people, "grid computing" means harnessing individual machines for SETI. To some Oracle, it's a clustered database. To others, it's two clusters. To others, it's a cluster with heterogeneous hardware.

Guy notes that since 2003, the term virtualization has increased its Google Trends momentum--he failed to note that companies like Platform Computing and DataSynapse no longer use "grid computing" in their marketing materials, preferring the trendier "application virtualization."

So, no, grid computing is not dead. But "grid computing" may be on its way out.

Technorati tags: grid computing, application virtualization

So does "utility computing" mean we'll each buy generators?

While Rob and I have both blogged about the differences between compute utilities and electric utilities (Rob here and I in one of my most popular posts here), the computing world in general continues to use the electric utility analogy when talking about utility computing.

Way back in March of last year I took Nick Carr to task (well, that may be overstating it a bit--he's a hell of a writer and technologist--let's just say I "attempted" to take him to task) for concluding that utility computing would lead to the death of the server market. "Nonsense," I said: "did the advent of electric utilities spell the death of the generator market?"

So it was with great amusement that I read Nick's latest post ("Caterpillar: Web 2.0 giant"): He says one of the big winners in the Web 2.0 boom is none other that Caterpillar. Caterpillar? Yep, Caterpillar. In addition to the equipment that makes our highways, they make the generators that power the information super highway (well, at least the generators used to supplement or backup existing power sources). Caterpillar's large generator sales are up 41%, and there is a year-long wait for a 2MW model.

In other words, the generator market is booming. It hasn't been killed by the electric utility industry. I maintain the same thing is true of computing: utility computing sure as hell won't kill the server market.

There's one other aspect to this: these generators are so important and selling so well, even though they are primarily used as backups. These datacenters buy power as cheaply as possible (think hydro electric). This incredible demand for generators exists because power is so very important; its ubiquity and utility have made it critically important. Datacenters need these expensive generators just in case their main power sources go down.

The same may be said of the server market. As more and more companies become dependent on utility computing, they will require more servers, not fewer. As John Clingan said:

Value drives adoption. Adoption drives volume. Volume drives down price. Lower price results in broader applicability. Broader applicability results in more servers.

In other words: the more important servers get, the more will be sold.

So why is all of this important? Well, again, the metaphor is dead.

But if electric utilities haven't killed the generator market, why would compute utilities kill the server market?

Technorati tags: utility computing

RDB is a good idea, but should you write your own?

Dr. Dobb's, always worth reading, has a couple of interesting articles this month.

Matt Davey of Lab49 has a good read on WPF and Complex Event Processing (but where are the illustrations?). He blogs here.

However, even more exciting for me, there's an article on grid computing (regular readers will recall that Robert Anderson and I wrote an article on scaling an SOA on a grid for them last year).

In this month's article (entitled "Grid-Enabling Resource-Intensive Applications"), Timothy Hoehn and Bob Zeidman of Zeidman Consulting compare several different strategies and methods for grid-enabling an application. For the most part, I love the conclusions they draw:

Among the architectures they examined, Distributed Objects provided the most scalable, flexible solution. They preferred it over Client/Server ("Overhead of managing socket connections can be tedious. If server fails, clients are useless."), Peer to Peer ("Harder to manage froma central location"), and Clustering ("Needs homogeneous hardware. High Administrative overhead for processes and network.")

They also examine "communication strategies," and again I like the way they think: they prefer Remote Method Invocation to Sockets or Remote Procedure Calls.

Next, they examine the "Push" and "Pull" distribution models, and they conclude that Pull offers some obvious advantages.

Finally, they discuss three different "frameworks:" .NET, JNI, and EJB. However, they're unable to actually do a comparison here. Tight timelines (and a lack of C# expertise) kept them from working in .NET; they preferred EJB to JNI.

Timothy and Bob then implemented their solution, getting good speedup on large jobs (they don't offer actual numbers, but I certainly believe them).

So, the things I like: they validated many of the decisions we made in our own product, which has a pull model that distributes objects and invokes methods on them. That's every cool.

But the one thing that I didn't like about their methods: they wrote all of the grid infrastructure themselves!

I understand that they weren't trying to do a "vendor bake off," and I really do appreciate the research they did.

But by essentially recommending that people write their own grid is a bit like saying "We've done some research into databases; if you need one, we recommend you write a Relational database." In other words, the conclusion is perfectly valid right up until the "write it yourself" part. There are many vendors out there who have written very good tools here--it would be silly to write your own database. You'd spend far more in development time than you would on a far superior software product.

The same is true in distributed computing. You could write your own...but with the selection of high quality vendors out there, why would you?

And Tim and Bob, if you happen to come across this post, I really did like the article. I think you reached all the right conclusions. I'd love the chance to see what it would take to grid-enable CodeMatch using my favorite grid computing toolset!

Photo Credit: Emily Roesly

Technorati tags: grid computing

Another voice on low-latency computing

I haven't blogged about the Univa-UD merger (mostly because it confuses me a bit, but that may be because I haven't talked firsthand to any of the players). But I liked a piece that I read that was written by Rich Wellner of the new Univa UD. I found it here on Grid Today, but it was originally published over on Grid Gurus.

Rich takes on the fallacy that utilization rate is the most important measure of a grid's (or cluster's) effectiveness. He cites a theme he hears "over and over again: 'How can grid computing help us meet our goal of 80 percent utilization?'"

As Rich points out, having a grid running at 80% does nothing to help your business directly. Quoting again..."How does 80 percent create a new chip? How does 80 percent get financial results or insurance calculations done more quickly?"

The questions are rhetorical, because the answer is obvious: it doesn't. The goal of a grid is not to use your hardware more (or more efficiently): it is to get your answers faster. Create that chip faster. Get those results more quickly.

Sometimes, the best way to answer questions is to take them to logical extremes. What's the best way to increase your utilization? Why, it's obvious: reduce the number of machines. Make the cluster smaller, and its utilization will go up. Only have 75% utilization on your 200 node cluster? Throw away half of the machines--sure, your wait times during peaks will more than double, but your utilization may hit 100%! Will your users be happy now?

In truth, I've never had a customer ask a question like that. A much more common question: how can I reduce the time it will take to run my end-of-trading day jobs?

That fits exactly what Rich sees:

For most businesses, it's queue time and latency that matters more than utilization rates. Latency is the time that your most expensive resources -- your scientists, designers, engineers, economists and other researchers -- are waiting for results from the system.

That's what real-world users are concerned with. "If I add 100 nodes to my grid, how will that affect wait times during the day? How will it affect processing times on my most important jobs?"

As an aside, here's something I've noticed in potential customers. Sometimes, I'll have someone call up and say "We've got all of these CPUs that sit around all night doing nothing, can you guys help us use them?" Of course, the answer is "Yes," but there's not a great likelihood of a sale there. They have hardware they could use more efficiently, but they don't have a need.

Sometimes, someone calls up and says "I'm running analysis jobs that take 27 hours on a single machine and I need them to run in under an hour--can you guys help?" Again, the answer is yes--but now there's a very good likelihood of a sale, because there is an actual need.

Photo credit: Jane M. Sawyer

Technorati tags: grid computing, hpc