Grid vs SOA

Grid and SOA are going to be on something of a collision course if enterprises embrace both simultaneously. At first glance, that seems like a counter-intuitive statement. Aren't grid and SOA both aiming to do the same kind of thing? Well, yes ... and no. SOA aims to create a unified loosely coupled software architecture in which resources can be plugged in and out at will. Grid aims to do much the same in hardware, except that being hardware, most commercial implementations tend to prefer tight coupling wherever possible, because that allows them to squeeze higher performance out of the environment.

So although all the major systems vendors are avidly promoting their grid strategies, all of them are proprietary stovepipes. This would be alright if standards existed that allowed them to interoperate, but, as revealed in the latest Loosely Coupled feature article, Grid lock-in on route to SOA, they don't. Interoperability standards for grid infrastructure are still pretty much at base one, as can be seen from this week's submission of the still-rudimentary DCML specification to OASIS, mainly because its supporters are desperate to enlist more helpers to work on extending it.

Yet there's a perception out in the market — which the systems vendors are eager to encourage — that SOA and grid go hand-in-hand. Enterprises who implement SOA will encounter bigger peaks and troughs in application demand, most of them difficult to predict, and so (goes the argument) they'll need to run SOA on top of a grid infrastructure to ensure that they've got enough horsepower available on demand to soak up all that application load.

Indeed, one of the more mature interoperability standards in grid-land is Web Services Resource Framework (WSRF) and its companion WS-Notification (also in the news this week after the signing of a truce between its backers and the proponents of WS-Eventing, which wasn't really a rival spec but does have some areas of overlap). The purpose of WSRF is to make grid resources available within an SOA, thus providing a means of accessing the necessary oomph as required.

The vision being sold to enterprises, then, is of a homogenized IT infrastructure providing computing resources on demand to power the on-demand applcation infrastructure of SOA. Armed with this vision, systems vendors are fully geared up to sell a new generation of grid-capable hardware and systems software that — of course — forces their customers to accept vendor lock-in in order to realize the economies of tightly-coupled scale and efficiency that they claim will come from adopting the grid approach.

What they won't tell you is that adopting an SOA can help you realize much greater efficiencies in resource utilization without having to buy any new equipment at all. SOA doesn't need grid — it virtualizes all resources within the IT infrastructure anyway, irrespective of whether they're hardware or software resources. It's just a matter of how granular you want to make your service definitions.

Grid has its place in an SOA, to power those resources that will benefit from a highly integrated distributed computing infrastructure. But to position grid as the ideal platform for SOA is asking too much of grid and too little of SOA. Grid technology today — as offered by commercial systems vendors — is still too monolithic and platform-centric to offer the kind of flexibility that prompts enterprises to sign up to SOA. Grid solutions are well worth investigating to improve the efficiency of existing data centers, but any vendor who suggests consolidating from multiple platforms into their proprietary grid solution to power an SOA is probably more interested in lining their own pockets than advancing their customer's SOA implementation.

posted by Phil Wainewright 3:20 PM (GMT) | comments | link