Red Hat’s David Lutterkort is on the money in this posting. The concept of a virtual appliance is seductive, but when the rubber hits the road, somebody has to keep it updated. That’s why we’re seeing the production-ready virtual appliances come from established appliance vendors who have the business and technical processes in place to do this.
Package management has come a long way in the past 10 years, and I expect that we’ll be seeing functionality to do unattended, automatic security updates built into our OSes and applications more and more over the next decade. This changes the role of the vendor or open source project into a service provider, but from my perspective, that’s a good thing. I’m looking forward to seeing how folks like David and Red Hat move the ball forward.
A decent system for handling appliances therefore needs to take the plight of the typical (which means grumpy) sysadmin into account, and needs to be geared towards almost arbitrary site-specific customizations, since sysadmins will still need to do a lot of the things they do to systems today to the appliances of tomorrow.
Instead of focusing on minimizing the footprint of general-purpose appliances, or marginally improving how the binaries making up the appliance are selected and built, we should be focused on delivering appliances that fit into a manageable ecosystem made up of virtual and nonvirtual systems. Which means that good appliance tools should be focused on producing appliances that can be managed well; at a minimum, let’s make sure that users have a reasonable way to upgrade the appliance and preserve their customizations at the same time. In other words: appliances are a new way to deliver software, but to run that software maintainably, we need to get down and dirty with old management problems like package management, config management, monitoring etc.