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.


The Future of Grid Computing: A look into my crystal ball

Grid computing is here to stay and I believe we are preparing for a tipping point. The tipping point HAS NOT happened yet, but its coming. When it happens there will be an explosion of new applications and the rewriting of old ones. I believe this because we (computer users) have been demanding, getting, and using increased processor speed and more responsive operating system architectures. The acceptance of grid computing will result in a new programming paradigm with developers creating grid-based products and using Grid Oriented Architecture (GOA) to develop them.

Part 1
Grid Oriented Architecture starts with the high-level look at the product in question. Architects identify what parts of the application can run in parallel and what parts can’t. They then look at the parallel work and decided which work is best run in a thread and which work is best run on a grid. Work that can run on a thread is work that has limited scaling requirements (remember that for optimal use of threads, there should be one processor per thread), and a very short execution time. The other parallel work with be executed on the grid.

Historically grid solutions have distributed executables and scripts but with the new style of grid computing, grid solutions are able to distribute actual instantiated objects, i.e. the power of grid computing INSIDE your application. .NET and XML serialization make this possible on networked Windows machines and Digipede is the first company to provide this capability. Object distribution on a grid is a key enabler for grid computing acceptance among the development community because this technology allows the developer to approach grid problems in a manner similar to how they already approach threading problems, uses familiar object oriented techniques, and reduces the complexity of initializing the work and retrieving results.

Because Digipede is the only grid solution that distributes objects, I’m going to discuss Digipede object distribution. Here are some of the advantages to distributed objects:

- Distributed objects are created by simply instantiating an object from a class—developers can use familiar object oriented methodologies.

- Object initialization happens in the main code body. When initializing distributed executables a developer is limited to the type of data that can be easily sent on the command-line, in an input file, or via a database. For the average development problem this creates unnecessary complexity. With distributed objects the developer sets the initialization properties in the object and the data elements can be any data type. From a programming perspective this is also nice because it provides encapsulation. Input files and databases can still be used, but being able to use OOP methodologies allows the developers to finish their work faster because they are able to use methodologies they already know.

- Object results are returned to the main code body inside the distributed object. With distributed executables a developer can return an integer on the command-line, a result file, or update a database. With distributed objects the developer sets the results properties of the object on the compute node and the results are serialized back to the main application. Again the data elements can be of any type.

- The distributed objects are returned to the main application when execution on the compute node finishes. The main application is notified of the returned object via an event. This serializes the parallelized work, which eliminates much of the complexity associated with threading.

Distributing objects on the compute grid makes it very easy to add grid computing to any application. It is this ease of use which will propel grid computing to general acceptance.

Digipede has provided other functionality geared toward making it easy on everyone and that is that the Digipede Network will automatically move dependent files. The Digipede Network can automatically figure out what some of the files are and there are APIs available for the rest. Many cluster and grid solutions require that the user preinstall the executables on the compute nodes. (With the Digipede Network you will only have to preinstall software that requires an installation program.) This allows newly added compute nodes to quickly and seamlessly contribute to the grid. Eventually all grid computing solutions will provide this functionality simply because it makes it easier for the user, the developer, and the IT folks.

The order of the day is ease of use. That will gain grid computing full acceptance as a viable development tool. Don’t make people invest precious time figuring out your grid infrastructure; instead give them the power of the grid in a manner they are already familiar with.

Part 2
More companies will grid-enable their applications using standard grid platforms. We’ve already seen one partner do this, 4th Story. 4th Story’s application has a checkbox that enables the user to add the power of grid computing to the computations that 4th Story is running. Customers have been excited about having this functionality available within the 4th Story product and they have also been excited about the fact that they can use that same grid for their own applications. That grid is the Digipede Network and we will see more companies deciding that they need a grid solution and it really makes sense financially to use someone else’s.

Part 3
With the move toward mobile computing solutions, the ubiquitousness of the Internet, SOA, and the power of grid computing, we are also going to see more powerful mobile applications. With a thin client or even just a browser, running on the mobile device and the core applications running on SOA on a grid, developers will unlock the opportunities inherent in powerful mobile devices. Where in the past there was the client/server software approach we will see the same thing start to happen on hardware, with the device acting as the client and the SOA/grid acting as the server. A fun area for this will be mobile gaming but I also think there will be applications in the areas of chemical sensors and monitoring, CAD and construction, medical, and security.

Grid computing is on the rise and with the ease of use of the Digipede Network it’s only a matter of time until other grid providers drink the Kool-Aid and start making their solutions more accessible. With the Digipede Network Windows application builders will have a leg up.

Technorati tags: , ,



At June 25, 2006 9:06 PM, Anonymous Anonymous said...

Distributing objects? It's been long since CORBA is able to do it. Grid computing has to do with resources (at the conceptual level) instead of objects (at the implementation level).

At June 25, 2006 9:59 PM, Blogger Kim Greenlee said...

For grid computing to go mainstream it has to be easy to use. Objects at the implementation level, .NET objects in particular, make that easy. Yes, we've been able to distribute objects for a very long time. But having to update the IPersist interfaces every time a variable is added to a class creates a maintenance problem. (DCOM)

CORBA and DCOM are also designed for a client/server model, not a grid computing model.

So, I'm sorry you don't get it. Try using the Digipede Network and maybe you will.

At June 27, 2006 8:19 PM, Anonymous Anonymous said...

This comment has been removed by a blog administrator.


Post a Comment

Links to this post:

Create a Link

<< Home