What would you like your appliance to do ?
Appliances of the ‘software’ or ‘virtual’ variety are popular, and everybody has to have a few. And that’s your problem right there: once you have not just a few, but many appliances, how do you keep track of them, how do you keep them running, and how do you keep them updated ?
Imagine you had to manage 100 of those little DSL routers — one of the favorite analogies in the appliance world — routers like the one that’s connecting you to the pipes of the Interweb right now: you’d be guaranteed that at least one of them will fail on a regular basis, and when you replace it, you need to reconfigure it in exactly the way its predecessor was configured. Which means you’ll be spending lots of time clicking through HTML UI’s and copying lots of binary ‘backup’ blobs around. You’d barely be able to tell what your network looks like, much less what it //should// look like. Of course, nobody in their right mind runs a large network of $50 DSL routers.
That is exactly the state of the art in the virtual appliance world: you get a binary blob and a pat on the back, and keep your fingers crossed that your PostgreSQL appliance just works; otherwise you need to upgrade your appliance, and depending on who made your appliance that means that you have to throw your whole binary image away, including your customizations. The customizations for a database appliance can range from creating a new database schema to changing root’s authorized_keys file to installing an agent for your site-wide backup scheme. Not something you’d be keen on losing.
Most people pushing appliances, like VMWare and Virtual Appliances, don’t seem to pay any attention to these issues; others, like rPath tell you that you have to get used to a completely new way of building systems (because they are called appliances now) while still not helping the poor sysadmin who wants to have his favorite colors for ls on all his machines. Or, more seriously, have his own configuration for sshd on every machine, have automounting set up on all servers etc.
For all their newness, appliances bring up many of the questions and problems that system administrators have been struggling with for a long time. If the pictures I have seen showing how essentially every network service will soon run in its own appliance will ever come true, those problems will become even more pressing: the number of machines system administrators have to deal with will go forth and multiply, in great numbers. And hoping that all these appliances will manage themselves is just whistling in the dark.
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.
Watzmann.Blog by David Lutterkort is licensed under
a Creative Commons Attribution-Share Alike 3.0
United States License.
Generated with Jekyll