As one of the original pioneers of Grid computing and the open source Globus Toolkit, Carl Kesselman (Chief Scientist at Univa, and Ph.D. Information Sciences Institute Fellow at USC) naturally has some opinions about the future of Grid computing. In a recent interview with GCJ, Kesselman discusses future directions for the Globus Toolkit and enterprise Grid.

GCJ: Tell us about some of the near-term focus areas for GT4.0.

Kesselman: We're continuing, obviously, along the path of improved performance, feature and functionality improvement of the existing pieces, increasing the robustness, the reliability, increasing overall the performance, updating to newer versions of standards, filling in the various pieces that maybe we didn't have a chance to do quite everything we wanted to have done in time for 4.0 release.

For example, I just saw one of the things that has been checked into the repository is this connection reuse with HTTP/S connections to services, which is going to have a dramatic performance improvement for a variety of clients. This will allow the reuse of HTTP connections throughout interactions with a server. It's kind of the normal things that web servers have gone through with the ability to do connection caching and reuse existing connections, rather than have to renegotiate everything again. That's going to have a fairly dramatic increase of performance of a number of our applications and clients.

We're also seeing the introduction of new services and new functionality, based on a lot of the work that's gone into some of the large-scale science data management applications. One example is the work that we've done on the LIGO (Laser Interferometer Gravitational Wave Observatory) effort. They're using RLS technology to manage somewhere in the neighborhood of 30 to 40 million files distributed across ten or more computing sites. Based on our experiences with LIGO, we've developed a new completely GT4-compatible service called the Data Replication Service (DRS) that does automatic replication of those data sets.

GCJ: How would that interface with GridFTP?

Kesselman: DRS actually uses GridFTP indirectly through RFT, the Reliable File Transfer, RFT service. So it combines RFT and RLS to allow you to specify a set of files the user might happen to want on the site, then finds out where they are and replicates them. This is all done reliably and scalable and robustly.

GCJ: It's sometimes tough for the non-Globus insider to make sense of which of the sub-efforts have the most momentum at a given time.

Kesselman: That's because the evolution is a bit amoeba-like.

But what we'll see happen in the 4.0.1 timeframe and beyond will be continued enhancements in terms of performance, robustness, and basic functionality of all the existing GT4 services. We're seeing extending the use of those services with more and more different and complex types of deployment scenarios and application scenarios. And then we're seeing the development of fundamentally new services building on top of the capabilities that we've developed, addressing primary needs that we see of our user communities.

GCJ: Why is enterprise having a hard time getting comfortable with the idea of Grid computing?

Kesselman: Enterprises are used to laying down a piece of hardware, manually building a software stack on it, and manually deploying a server on it -- and then that becomes the foundation on top of which they build applications. As I think everyone seems to be agreeing, that ground is rapidly shifting with the creation and the enhanced acceptance of blade servers with virtualization technology. As a result, we're seeing an increased interest for how one does provisioning for reasons of accommodating peak demands, dynamic deployment of VO specific services and isolation. The idea that servers are these things that we kind of build and they live in our machine room and they change very slowly, it's just an idea that's not going to result in competitive behavior in the future.

GCJ: In its current form, do you consider the Globus Toolkit to be easily downloadable and readily understood by an enterprise IT person with just a common set of skills?

Kesselman: Increasingly that's becoming the case. All the feedback we've gotten so far from the enterprise developer community on their ability to download and install the Globus Toolkit has been quite positive. There are still areas to be cleaned up, but for the most part, people are being very successful in their ability to download and install and make basic things run. With Univa supporting Globus, those things will be made even easier and simpler, in terms of installation and maintenance and support.

GCJ: With the TeraGrid announcement, there has been a fair amount of compare / contrast discussions about e-Science Grids versus enterprise Grids, what's your take?

Kesselman: I think that the basic problems that the Globus Toolkit solves in e-Science are just as germane and just as important to the enterprise guys. Did the e-Science folks understand what the actual detailed requirements of the enterprise computing environment would be when they set out to build the Globus Toolkit? No. But the basic engineering underneath it -- whether you're doing science or whether you're doing business -- 90% percent of the problems that you need to address are common. I have yet to see a compelling case where one would say, well, the enterprise requirements for IT infrastructure are so radically different than the requirements for IT infrastructure for doing these large scientific experiments that there's no basis or reuse or commonality or interoperability.

The one thing that I do hear frequently is that enterprises don't want lock-in specific vendors and non-interoperable solutions. They don't want, necessarily, proprietary solutions, or they're certainly hesitant in many ways to introduce proprietary solutions if there are alternatives available. I think that's one of the reasons why we've seen the growth of the open source UNIX platforms, and one of the key strengths of the Globus Toolkit -- is that it does provide a vehicle for interoperability and for avoiding lock-in to any particular vendor, lock-in into one setup of protocol, vendor-specific protocols. We see increasingly that the source code is out there. You can use it for free. You can use the Univa version. You can buy support from somebody else if you want. That turns out to be, I think, a compelling argument.

And planning - avoiding the lock-in, having the open interfaces, having the open interoperable software on top of that just gives you the flexibility that you need and the robustness that you need to be able to accommodate the change that's inevitable in the way that you're going to be building out and managing your IT infrastructure.

GCJ: Will there someday be a Grid, like there is the Internet?

Kesselman: That's the way we've always thought about it.

GCJ: The Globus Toolkit's strongest affinity still seems to be with e-Science and academic developers. When will Globus figure out how to get more penetration with enterprise developers?

Kesselman: I'm not sure I would say that we haven't figured it out. It's a work in progress, and I think even on the vendor and certainly on the customers side there's a lot of thinking still to be done. To date there has been historically less penetration with the enterprise developer community simply due to our priorities in e-Science Grid projects.

But we are making a more concerted effort today to recruit and support the enterprise developers working on the Globus Toolkit. The formation of the Globus Consortium is one example. The creation of Univa is another.

So I think it's a normal evolutionary growth process, and I think there will be new things that we'll have to do and issues we'll have to take into consideration as we broaden the base of applications and take into more the concerns that commercial users are going to have. But I see these as all being part of the normal process of growth that we're going to be going through. And it will be exciting.

close window