In the internet era of computing, it seems there are two types of computer systems: those that are being consistently updated and those that will eventually be infected with some type of malware. From Windows to Mac OS X to various flavors of Linux, the ecosystem around each widely deployed modern operating system has a prominent method for patching and updating the operating system and its applications.
As the industry moves into cloud computing, the security equation does not change. Robust means of system updates are still required. However, the architecture of cloud-based ecosystems are often quite different. Take the examples of how two Citrix products might be deployed to a cloud:
1) With the release of XenApp 6, Citrix has introduced the worker group concept. Each farm server assigned to a worker group shares a common base image of applications. The worker group silo can then be managed and scaled as a unit. In a cloud-based deployment, using worker groups permits use of a single “golden image” per worker group that can be updated outside the production environment and then rotated into production instances at convenient times.
2) A core advantage of XenDesktop 4 is support for single instance management. The entire product is designed to update the same “golden image” per operating system and application, and then build up-to-date desktops when clients request access.
Thus, in a certain sense, the management architecture of the cloud will often be the inverse of the traditional model. The old notion of a maintenance window for a production system does not directly apply. In the cloud, the “golden image” systems that need updating are ideally offline images in storage, while the system instances that are active and in use are not typically updated directly.
Multiple technologies have to be brought together to realize an ability to efficiently update offline systems. One of the required elements is an ability to describe offline system contents to an external “maintenance agent”. If needed, the agent can then apply the required updates for operating system and applications. The maintenance agent may cause the virtual systems to be booted to acquire changes, or the disk images could be modified directly as files on a disk. Those are innovations for the system maintenance vendors to undertake.
The role of the OVF standard should be to define the content descriptors so the maintenance agent can determine what needs to be updated based on available changes. I believe OVF to be the right place for this innovation because it is gaining in popularity as the standard format for virtual systems on disk.
The 1.0 standard contains an extensible XML-based descriptor. The extensibility of the descriptor is important to allow innovation to continue among vendors of cloud products. However, if each cloud vendor has to extend the descriptor independently to cover system image contents, we will have lost a key opportunity to leverage cloud computing to improve image maintenance processes.
So, a clear challenge for the future of OVF should be to extend the standard to describe the operating system, applications, and patch levels for each system contained in a package. In my view, only with a standard method of describing content can we bridge the gap to general solutions for cloud-based image maintenance.