A Day in the Life

A day in my life. Thoughts on leadership, management, startups, technology, software, concurrent development, etc... Basically the stuff I think about from 10am to 6pm.


Digipede and Sun Grid

An article just went up on CRN by Mario Morejon called "Review: Gridlock Alert for Sun Grid?" in which Mr. Morejon finds the Digipede Network easier to use than Sun Grid.

Mr. Morejon's findings validate our programming model. The Digipede Framework SDK supports .NET 1.1/2.0 and COM, which means that you, the developer can add the power of grid computing right into your applications using the model and language you are already comfortable with. You don't have to figure out a new way of doing things; you just have to learn a new API.

One other advantage is that the code you are distributing on the Digipede Network is packaged up as an object. Create a class object, set it up, and send it out. The object is returned to the main application and provides an easy and safe mechanism for returning results. If you read the recent article "The Race Is On to Debug Dual-Core Deadlocks" (registration required) you would know that the new dual-core machines are revealing a number of applications with multi-threading problems.

Developing multi-threaded applications is a challenge mostly in that it requires every developer on the project to have a complete and clear picture of the threaded code and that code’s dependencies. While I was the lead on the Agent Server project at OnDisplay I had to help other engineers understand multi-threaded issues. It was a lot tougher than I would have thought and with some of the folks they never did get it. I think mainly the problem is that few engineers really understand what is going on when their application is running. They don’t really understand thread switching, priority, memory, stack, registers, etc...and as a result they don’t really know how to look at the problem.

Because the Digipede Network is delivering objects around the network for computation, the developer is unable to access any memory in the main application. The executing code is encapsulated and all the dependencies must be sent along with it. When the results are returned to the main application they don’t come in all at once but serially via messages. Thereby, serializing parallelized computations. This provides the power of threading with significantly reduced risk. I'm not suggesting that grid objects replace threads, but I am suggesting that they provide a safe alternative.

One other benefit from the developer's perspective is the idea the Sun has been promoting and that is the ability to easily scale your applications to thousands of machines. If you build grid computing into your applications all you have to do to improve scalability is add more machines to the grid infrastructure. You don't need to change the code. Yep, I really said, "You don't need to change the code."

IT Manager
In the article Mr. Morejon mentions a script and a Digipede job wizard. What he's talking about is distributing existing executables on the grid. Early on Digipede identified that one problem with many grid computing solutions was that they required a lot of script writing, command-line interfaces, and batch processes. (The user basically has to know how to write programs.) Digipede does provide a command-line application that can distribute your executables and scripts but we also built the Digipede Workbench. The Digipede Workbench (the job wizard) is an easy to use Windows application that let’s a non-engineering person easily define and create a job, which can then be started from the Digipede Workbench or saved and started externally using the command-line application.

If you read much on grid computing you’ll read time and time again that grid computing is hard. Grid computing has been hard because most of the people and companies building the grid infrastructures are trying to be everything to everyone. The Digipede Network is built on .NET, designed specifically for the Window platforms, and targeted as an enterprise solution. We have simplified the problem space. In addition, we are an experienced Windows product development team so we built the product we wanted to use, with all the necessary bells and whistles. We also don't believe that using a product should require a team of consultants. We can provide consulting services, but one of our core beliefs is that companies should focus on their core business - not on their grid infrastructure and tools.


At May 08, 2006 8:32 AM, Blogger Dan Ciruli said...

One comment, Kim - I believe that for this article, CRN didn't use the Framework at all. I think they were just distributing command-line executables (using the Digipede Workbench). Still, I can't disagree with a word you said!

At May 08, 2006 4:27 PM, Blogger Kim Greenlee said...

Yep, that's true. And Mr. Scanner, I mentioned that in the IT Manager section!


Post a Comment

Links to this post:

Create a Link

<< Home