Contain yourself!

We tend to talk a lot about the cost benefits of consolidating workloads to virtual images – and those benefits are significant. Another significant benefit, albeit not as hyped, is the concept of the application being “contained” in the virtual image. “Contained” is a loaded term, but what I mean here is that operations can be performed on the virtual image such as moving, copying, deleting, recovering – and all things that affect the state of the application. This can be handy for portability, but also as a way of controlling the application configuration for compliance and security purposes. The concept is fairly well known with VMware’s capabilities supplied around their Control Center and VMotion. The VMware tools implement the container concept from purely a system perspective, so the actions performed on the container are done based on  information such as CPU and i/o as opposed to based on the application state. Dan Chu from VMware has some good discussion on VMware Appliances which is prettty similar to the container concept I'm describing. Without application state information, decisions regarding resources and configuration are being made based on shadows on the wall rather than the actual state of the application or service being provided. This will be key in making container actions more widespread in production (as opposed to dev and test) environments.

Another aspect of containers applies to the end-user. An early example is Citrix providing, effectively, multi-user access to Microsoft Windows environments. A new example is with Softricity (just acquired by Microsoft) providing application streaming. In both cases it’s the idea of providing end-user functionality (either OS or App) from a central location (a container) that can undergo all the container actions described above. A nice aspect to these types of containers is having near absolute control of the environment and application configuration provided to an end-user. So along with that comes security to the enterprise in knowing that the environment and applications being used by their end-users exactly meets specifications. Another use case for user environment containers is providing a guest environment – give a guest/visitor access to limited applications such as web access within a “contained” environment. Then, when the guest is finished, the environment can be disposed without impact to the enterprise.

In both container cases, the environment is really looked at as a file. Both VMware and Microsoft have their proprietary virtual file formats, but, in the end, it’s just a file. This means the containers themselves, while undergoing the above operations, should also be considered candidates for Change and Configuration Management processes. Such an approach might greatly enhance the way that applications and user environments are managed thru every ITIL process. I do think there’s room for standardization of the virtual file formats – which would make containers portable across virtual environments. I doubt this will happen anytime soon, but it may be an inevitable development if virtual environments follow the same path as processors and operating systems.

I’ll end on a personal use case. My son helped setup a media center where we stream photos, video, and music from a central server in our house. We therefore needed a media server that would feed the streamed content. Well, we decided to load Windows Media Center into a virtual machine under VMPlayer. We did this because WMC needs a machine to run on and by being on my son’s laptop so we could test and tweak in the same location as the media center. Once we got it working, we copied the .VMX file to the primary server environment, and, it ran without a hitch! This way we could verify the functionality without creating any risk to the main server environment. An interesting side note, we subsequently had the hard drive crash on the primary server and recovered the media server by copying it from the backup hard drive.