today's SOA developers .... tomorrow's Grid developers

Three years ago, Grid computing and SOA were both commonly regarded as "nascent, emerging enterprise technologies."

But while enterprise Grid uptake is still at its infancy, service-oriented architecture interest has blown up in the commercial sector. Go to InfoWorld's SOA Executive Forum, and you will hear very mainstream enterprise end users talking about real world deployment issues and experiences. Go to GridWorld, and in the enterprise track, you'll hear from a smattering of early adopters -- and then a lot of vendors describing what the future will look like.

Why has SOA jumped out ahead of Grid in enterprise traction?

There are a range of factors that have supported the explosion of commercial interest in SOAs. Web services standards have matured tremendously over the last five years. Developers have a wide range of options to choose from in programming languages -- not just Java, but .Net, Ruby on Rails, the "P" languages (Perl, Python and PHP). But I think the most compelling reason why SOA has outpaced Grid in enterprise growth is that you can actually take relatively mainstream enterprise applications and write to a service with a simple API. That just hasn't happened yet in Grid.

But one really encouraging fact is that the common web services skills and knowledge that SOA is ushering into the enterprise are extremely similar to the skills required to write Grid services. Last year's release of Globus Toolkit v 4.0 signified the Grid community's full embrace of the WSRF. If you poke around today's technical tutorials on building Grids -- such as the recent IBM developerWorks series on "Building a Grid using Web services standards" -- you'll note that SOA and Grid architecture development practices have truly converged.

So if you're keeping an eye towards the future, and you want to be in a good position for your company to take advantage of Grid when the technology has fully matured -- just keep plugging away on SOA, and you'll be fine.