In this Q&A with GRIDtoday
, IBM's program director for Grid computing strategy and technology, Matt Haynos, previews his upcoming presentation at LinuxWorld's "Enterprise Grid Solution Showcase"
and discusses the synergies among Grid computing, virtualization and SOA. At IBM, he says, "Grid IS virtualization."
Can you give me a preview of what you'll be discussing at LinuxWorld? About what can attendees expect to learn?MATT HAYNOS:
I'll be outlining the relationship and synergies between virtualization, Grid and service-oriented architectures. There's been a lot of visibility and momentum around each of these and what I hope to do is to describe, in a very simple manner, how Grid and virtualization as infrastructure capabilities can complement and accelerate companies SOA plans. Grid/virtualization and SOA are very synergistic thoughts and what I want to articulate is why infrastructures based on virtualization and grids are strong foundations for SOAs.Gt:
Can you give brief definitions of Grid, virtualization and SOA?HAYNOS:
I'm not sure I'm game for defining "Grid", but here goes! At IBM, we try to keep it pretty simple: Grid IS virtualization. In particular, extending the virtualization thought to two important areas: workload and information virtualization. There are multiple layers to virtualization, starting from the microprocessor and including server, storage and network virtualization. Grid is a logical extension of virtualization to encompass both workload and information across a distributed infrastructure.
At a high level, workload virtualization is about separating services and applications from the underlying infrastructure; abstracting the concept of workload execution so that, from the standpoint of end-users or submitters, the overall Grid system appears as a single set of capabilities.
Information virtualization is a similar concept, but for data. If you start moving application and service execution around dynamically or start distributing it more widely, you really need the information (data) that the application requires in the proper format and with "near-local" performance to achieve the kind of improvements in "time to results" or resource optimization that is the goal. If you don't have that information readily accessible, you can expend a lot of energy scheduling and managing the execution and still get no advantage because the application is "bottlenecked" waiting for access to the data it needs.
Finally, SOA is an architectural style that supports service orientation, which is a way of integrating your business as linked services and the outcomes they bring. A service is simply a repeatable business task. For example, checking a customer's credit, or opening a new account.Gt:
How can these technologies be utilized in the same infrastructure?HAYNOS:
Companies are adopting and utilizing SOA as a way to align and architect their application architecture to support business processes. The challenge today is to quickly assemble resources to respond to new business opportunities and endeavors. The companies that can do this -- and are nimble and fleet-of-foot -- realize incredible competitive advantage. Innovation in terms of process is just as important, or maybe even more important, as technology innovation. Witness what we are seeing with "mash up" applications. The software development and deployment lifecycle is days and weeks now, not months -- all facilitated by the "services" notion.
Recently, BusinessWeek's cover story asked "Is Your Business Fast Enough?" and stated "speed to market is now the ultimate competitive weapon." IBM's Global Innovation Outlook 2.0 declared that "we're witnessing the rise of a new breed of very small and highly specialized businesses that are not only competing globally, but in some cases seriously disrupting existing business models and paradigms" and it noted a company -- Apex Digital -- that actually generated $1 billion in revenues in 2002 with fewer than 100 employees.
So, it starts with business processes, tasks and endeavors, and the SOA approach is an architectural approach around this concept. It's really a business thought and how people, processes and information can be integrated in a seamless and coordinated way. So architecture, the relationship between services and composite applications, and how these facilitate business processes and new business opportunities -- both within an enterprise and across the extended network -- are vital.
Now, the question to ask is do I have an underlying infrastructure to support this agility? Once I've decomposed my processes into services and tasks accordingly, what kind of IT infrastructure do I need? How do I manage it? And that's where virtualization and Grid come in. Services are dynamic. They move around, they can be fleeting and they need to be started and stopped on demand. Putting all of this logic and capability into Grid middleware and letting it place and move services for execution makes all the sense in the world. When new resources come online, the Grid middleware recognizes them and can deploy new services and composite applications to them. If SOA is about separating applications from services, Grid is about separating services and applications from the underlying infrastructure. It's one of the reasons why containers and execution environments are so important, as are technologies like virtual machines. We've seen incredible adoption of WebSphere Extended Deployment in support of SOAs.Gt:
Would it be accurate to describe virtualization and SOA as stepping stones to a Grid architecture? Why or why not?HAYNOS:
I don't necessarily see it that way. In some sense, Grid and virtualization are distinct thoughts from SOA. SOA is more of a business and application thought: how you decompose processes into constituent services and tasks. Grid and virtualization are infrastructure thoughts, how your resources and your infrastructure management supports the dynamic nature of SOAs and how you match resources -- either execution engines or information -- to services and composite applications.
There's been a lot of talk about convergence of Grid and SOA. I think this might be the wrong way of looking at it. Certainly, a lot of Grid middleware is built in a service-oriented way and style, and you can argue that Grid is SOA, but the more powerful notion is how infrastructures based on principles of virtualization and Grid support what organizations are trying to do with SOA. They are really very complementary, and the smart firms are realizing that virtualization and Grid, as infrastructure capabilities, are the perfect foundation for SOA.Gt:
How has being associated with virtualization, SOA and other related technologies helped Grid computing move beyond its image of being strictly about compute power?HAYNOS:
I think that it has helped tremendously. Having worked in the "Grid" space for over three years, I've seen Grid move from a niche associated with high-performance computing to more of an enterprise thought. Organizations realize that this abstraction -- or virtualization -- of workload and information across the "enterprise" is a very powerful concept and one that aligns perfectly with SOA.
We always believed that, as time proceeded, Grid would cease to exist as a four letter word, and that it was just the natural way to do distributed computing. The progression and adoption of SOAs and the associated standards, which cannot be understated, have moved Grid beyond its early image of strictly being about compute power to being a much more broad infrastructure thought in support of the SOA principles of integrating people, processes and information.