In the early 1990s, some of the industry’s most prominent figures (including the CEOs of Oracle and Silicon Graphics) were adamant that the then-nascent technology of massively parallel processing (MPP) would be the architecture of the future, offering limitless, modular scalability and power at a fraction of today’s costs. But even though MPP machines were built, they failed to attract any real interest out of scientific and academic circles for one overriding reason: Any application targeted at MPP had to be extensively rewritten to address the architecture’s multiple nodes.
The same issue is staring today’s grid computing initiatives in the face. However, in this case,according to informed observers, much of the complexity is hidden in middleware; connection can supposedly happen seamlessly in the application layer, invisible to the end user.
So as one early grid user – an electronics company – reports, its use of a distributed grid file system with a virtualised data structure means the front end remains exactly as it was and its chip engineers are able to run simulations of their designs and access files in just the same way as they always have.
Unfortunately, moving applications to a grid computing platform is not always that simple. Much will depend on what the organisation is trying to achieve – and for more complex business applications, grid or utility computing is likely to deliver the benefits without substantial reworking.
At one level, the strategy of offloading compute-intensive tasks for increased performance or migrating mainframe applications to shared server resources is proving popular. But today, this is limited to academic research projects and resource-intensive applications in areas such as financial risk analysis. Such standalone applications do not need to be ‘grid-aware’ as the application server is perfectly capable of running them over a grid.
As Rob Hailstone, an analyst at IDC specialising in service-oriented architecture (SOA) and application platforms, says: “The app server should protect the applications from needing to be aware of the grid. This should apply to any virtual platform, so there is no reason why a Java Virtual Machine (JVM) should not protect its apps in a similar way."
But in the case of more complex business processes, where multiple applications are running mutually dependent functions – such as a stock replenishment system that cannot carry out a transaction until an order management system has completed its processing – swapping in grid resources is not going to be easy. "With coding and a bit of luck, you can pull out specific parts of the application to carry out specific functions. But commercial applications are not written to operate in a grid environment, custom applications even less so," observes Frank Gillett, an analyst at Forrester Research.
To get these applications running on a grid, the application layer needs to be broken down into business services, which can themselves be virtualised into a service-oriented architecture (SOA). Effectively, what is happening on the IT side must be mirrored on the business side, which also has implications for the whole business/IT divide (see box). Andrew Cleverly, director of applications and technology marketing at Oracle, points out that some hard decisions need to be made first.
"For this type of enterprise grid architecture to be successful, you have to look at consolidating systems. People still have too many silos of data and applications spread around the organisation."
Once it does begin to happen, though, application functionality can be offered as web services which can be orchestrated into business process flows or composite applications, with each service being load-managed off the grid.
"The goal is to have capacity as a commodity, dynamically sourced in a service-oriented architecture, so the business can define, deploy and manage web services," says Mark Barrenechea, senior vice president of product development at systems management software vendor Computer Associates.
A key thing for enterprise users is to avoid the all-too real risk of vendor lock-in. With the existence of so many different implementations of the grid and utility concepts, organisations might well end up with a grid manager from, say, Oracle on the database side that cannot work with an application server file system from, for example, IBM.
Oracle, despite being the first vendor to offer a grid-enabled database in the form of its 10g product, with a whole host of grid control functions such as automated storage management sitting behind it, admits interoperability is still an issue.
Standards such as the Open Grid Services Architecture (OGSA) and Web Services Resource Framework (WSRF) will need to mature before there is any hope of that being addressed.
IDC's Hailstone believes the real benefits will only come in the medium to long term. "SOA is likely to have greatest return on investment for subsequent projects due to the reuse of work already done in early projects to expose legacy applications. This makes it more of a strategic issue, whereas most expenditure right now is tactical."