As VP of Technical Strategy and Innovation at IBM, Irving Wladawsky-Berger has been an important supporter of both the Globus community and the Grid computing community at large over the last 10 years. Ian Foster recently had the opportunity to catch up with Wladawsky-Berger and get his thoughts on the progress of Grid, and some other emerging technologies that IBM is actively contributing to.

Foster: IBM works very closely with both the Linux and Grid communities - but the Linux and Grid communities at large are not exactly joined at the hip. Do you think there is an opportunity for the two communities to work more closely together moving forward?

Wladawsky-Berger: Yes, I do think so. One of the questions that we always think about is while Grid protocols can run on any operating system, are there special Grid capabilities that you could build in at the operating system level? The OS community that you would expect to be most receptive to exploring that level of integration would be the Linux community. Because of the open source nature of Linux, members of the community can more easily develop the code, test it out, and then submit it to the Linux maintainers for possible inclusion in future releases.

So yes, there is a natural affinity to see how Linux can best support Grid protocols and Grid capabilities. But I haven't seen as much effort in this area as I wish there were, and I think it's an area that could be very fruitful.

Foster: In application development, we're seeing a lot of momentum around the LAMP application infrastructure - and specifically the "P" languages (Perl, Python, PHP). How does IBM see the trend playing out in the Grid industry? And do you see any merit in open source Grid technologies such as the Globus Toolkit being integrated into the LAMP stack?

Wladawsky-Berger: Ideally, software -- whether it's middleware applications or business software - will become Grid-enabled by integrating Grid protocols. And the application components of the LAMP stack are naturals to integrate.

As participants at the recent Open Source Business Conference discussed, open source development stacks are most popular in simple environments. Specifically, developers are typically using LAMP and even LEAP (Lightweight & Efficient Application Protocols) in areas where Java is too complicated.

That doesn't mean Java is no longer important, but it means that if you have something really simple, Java may be overkill. And what we see more and more is the emergence of 'good enough' situational applications, where people just need to quickly build them and deploy them. New technologies such as AJAX and web application hybrids called mash-ups have introduced new capabilities to let developers do just that.

Now, if you were building an application for the Federal Reserve Bank or for a major hospital management area, you would never do that. That's where more sophisticated languages like Java and C, C++, and where more sophisticated stacks are needed. But there is a huge number of areas where all that sophistication is overkill, and if you have simpler stacks, you can get around a lot of cost and complexity.

Foster: How might the Grid community take advantage of the trend?

Wladawsky-Berger: One possible direction for the Grid community is to develop a subset of Grid protocols that would be particularly simple and suitable for integrating with the P languages. That version might not have all the bells and whistles of the entire Globus Toolkit, but would do enough to let them start linking to a Grid. The full array of Globus components might be overkill for the kinds of simple applications that people develop with LAMP and LEAP.

But I think what has happened so far is, from the application perspective, these open source stacks in the enterprise are primarily focused on single systems. I don't think they have focused on distributed systems, because it's a much more complicated problem. But as LAMP, LEAP and so on start focusing on making sure that they can work across networks - and, in particular, work by linking to distributed versions of themselves across the network - the natural framework to use would be the Grid protocols. So it would be ideal to integrate the relevant components of the Globus Toolkit into distributed versions of LEAP, and LAMP and the related protocols, languages and applications.

Foster: Most large-scale Grids today are running on Linux. Would you attribute that to any specific technical capabilities of the OS? Are there any particular reasons beyond just the economic factors with Linux, or the open nature of the OS?

Wladawsky-Berger: I honestly think the main reason why most Grids are running on Linux is that Grids are being used primarily in universities and research labs, and in technical and supercomputing applications in industry. That's where Grids have made the greatest impact at this stage, and also precisely the areas where Linux is so immensely popular. But it's important to remember that one of the things that makes Grids so appealing is that it is an open, aggregating technology, running on different platforms and providing resource connectivity. Windows can support Grids just as well as Linux, just as well as AIX or Solaris and everything else ... so I think that as Grids become more widely used in the commercial world, where Windows is more popular, we will see more Grid implementations on Windows and other operating systems.

Foster: You wrote your chapter a couple years ago for the Grid 2 book, and you pointed to two development stages for a new technology. The first one was just building it and making it work, and the second one is the application of the technology. Where are we with Grid today?

Wladawsky-Berger: We are still in the building phase. If I compared Grid computing to the early days of the Internet and the Worldwide Web, I would say we are still pre-'95. Lots of people know about Grids, there are already quite a number of successful commercial pilots of Grids, and everybody in the research and supercomputing community is involved with Grids already. But the problems being tackled by Grid computing, the whole general area of distributed systems based on open standards over the Internet, is an incredibly complicated set of technical problems. So it's not surprising that it's taken time to develop the needed architectures and the needed software for Grids to be acceptable for general production use. There's lots of work being done, lots of good progress, but we are still in the development phase, in my opinion.

Foster: What area would you isolate as the most critical to the evolution of Grid computing in the near future?

Wladawsky-Berger: I think the key progress we need is in the software -- making sure that Grid middleware gets more and more sophisticated but at the same time that it provides the necessary constructs to allow it to become better integrated into enterprise software from vendors and enterprise software already in wide use. At IBM, my expectation is that Grid capabilities will eventually be integrated into all of our enterprise middleware, and integrated into all layers in our system software -- which we call our virtualization engine -- enabling virtualization across distributed systems. That's already started to happen, but it's in the early stages. My expectation is that will happen with other vendors, and obviously that will also be a focus of the open source community.

Anybody who is building distributed systems software, whether it's middleware or application or business software, whose job is to run on distributed systems in a totally virtualized way with shared resources, should use Grid protocols. That is the most natural thing for everybody to do, and I would hope that will happen more frequently. Essentially, the Grid protocols and Grid middleware become integrated into the enterprise middleware for use by the applications in much the same way TCP/IP is integrated into similar systems. You don't think about TCP/IP anymore. You just assume it's there. And I would expect the same will happen with Grid over time.

close window