This all also gets me thinking about what container abstraction is the best for grid applications… I think it is a very complicated subject. My off the cuff conclusion is that if we had perfect infrastructure available to deploy each kind, grids would probably be able put it all to use to best satisfy different scenarios and constraints (constraints that are coming from both client and resource provider). That’s getting way ahead of things though. A lot of this software, and the tools to manage it, are still maturing. And for the timebeing, production grids are just warming up to the idea of one virtualization platform (Xen), not five at once 🙂

In the long run, an important factor is the onus placed on the remote user when preparing its environment for deployment across a grid. With VMs or any kind of “contained” guest, you’ve always got to lock in your “capsule” to a certain environment in order for the container to accept it, be it:

• raw instruction set (unmodified guests)
• virtual instruction set (Xen)
• userspace API (VServer)
• software API (grid container/servlet)

For grid applications, it is yet to be seen how important locking in to instruction sets is, but Xen is still a great option (acceptable performance, very portable and very isolated). The choice can affect a lot of things: ease of maintenance, security policies, resource availability, performance, etc.

What is apparent is the advantages of having a consistent compiler chain, libc, and other libraries. It can mean the difference between being able to use a site’s resources or not (see slide 18) and even if the dependencies at a site seem to line up with requirements, it could take a large effort to actually verify the environment. Xen based VMs provide a path out of this mess.

As for requirements for needing to customize below the Linux userspace API (or needing some other OS entirely), I’ve always thought it would be cool to see more code developed for kernelspace (in the vein of the tux webserver). Pervasively available virtualization platforms may make this a real option for grid applications or infrastructure. Then again, some memory protection is a good thing :-).

Ultimately, the workspace abstraction is geared to handle many different implementations, e.g. physical workspaces (node re-imaging) and different kinds of VMMs. After all, they are all just containers with different enforcement and isolation capabilities. In the long run, it is going to be very interesting to seriously evaluate the different approaches (under both pathological and real grid application workloads) vs. the current Xen backend.