Saturday, December 23, 2006


Closing Thoughts on the 451 Group Conferences and Grid Computing

Two weeks ago, I attended the Enterprise Computing Strategy put on by the folks at the The 451 Group and wanted to share my closing thoughts...

There was lots of discussion around Sun Grid and many folks concluded that there was lots of marketing but it was not yet a market. Some of the characteristics that prevent it from becoming a market are:While the folks at the conference didn't go too deeply in terms of what was wrong with security and grid computing, my take was that several deficiencies exist including, but not limited to:In terms of grids having to deal with a variety of languages and chipsets is equally problematic. So, if I have a C++ grid application compiled to the Intel chipset, migrating it to the Sparc architecture could either be really easy or really difficult. Minimally, toolsets should exist to make this form of migration easier.

Likewise, it does beg the quesiton of whether enterprises should continue to write applications in C++ and whether migrating all development to Java is better in the long run. It still does beg the question of enterprises who embrace scripting-oriented languages such as Ruby on Rails and how Sun sees these folks participating.

I also learned that the University of Tokyo has a 512 Core Processor which seems ripe to displace all the incumbent vendors who think that 16 core is meaningful. This project seems ripe to even displace startups such as Azul Systems who are at 24 cores. Hopefully, industry analysts will pay attention to the Grape chipset and its potential.

One of the conversations that I wished would have occured but didn't was the simple fact that the Mhz race is for the most part over. Nowadays, everyone is driving towards multi-core architectures which can be utilized by first understanding how to write multithreaded applications and secondarily, how to make tasks run in parallel.

The J2EE & .NET community have been telling us for so long that enterprise developers never needed to worry about the complexity of writing multithreaded applications and that the application server will handle everything. In hindsight, this feels like a trap as no J2EE vendor and their application server have the right architecture to scale across hundreds of cores.

Maybe this is an opportunity for industry analysts to stop talking about the need but to commission someone to tell enterprises how to write applications that scale in this regard. For analyst firms that provide coverage on grids, they can sometimes be impressed by the numbers of CPUs we can throw at a given problem-space but still are ignoring the fundamental question of how efficiently are we using them.

The biggest unanswered problem that attendees mentioned was licensing. Acquiring a software license on a grid is part of overhead. Minimally, this problem space has at least two components. First, licenses have locational barriers (can only be used in the US, a named site, etc) and second that there is no such thing as a license markup language in which a computer could interpret all of the characteristics of a license to make a decision at runtime. I would love to see the folks over at the OMG champion the creation of a license markup language. Maybe I will ping Richard Mark Soley, Peter Herzum or Phil Gilbert to see what it would take to get something started.

The more interesting thing that closed source vendors should pay attention to is if your enterprise customers are asking about grid computing and you aren't changing your licensing models to meet them, then they have one and only one choice and that is to go open source and displace you. Hopefully, folks from Oracle, BEA and IBM will step up and figure this out before your customers do...

Links to this post:

Create a Link

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?