tech/DesignToBeManaged written at 02:08:19; Add Comment
Design systems to be managed
Here is something that I've come to believe strongly: if you're building a system today (whether it's just a single program or much larger), you should be designing it for what I'll call 'manageability'. By this I mean the ability of your system to integrate with other systems and to be managed by them.
Once upon a time, the state of the art in systems operation was such that systems (programs, packages, environments, etc) were basically standalone and self-contained entities. A lot of the time no one really worried about system management issues, and it was good enough that your system actually existed and worked. If you worried about these issues at all, generally you built things directly into your particular system. Thankfully, the state of the art has moved on since then. Although it's by no means universal (yet), a 'best practices' environment today will certainly have its own monitoring system, its own configuration management and automated deployment system, and so on.
This means that if you're designing a system to go into a modern environment, you should be designing it so that it can easily integrate with these systems. You should absolutely be thinking about how your system can be deployed and managed with cfengine or puppet or chef, how it can be monitored with Nagios, Catci, or Munin, and so on. Since there are a lot of these systems (not just the ones I've listed here), you shouldn't be planning to do this by writing specific plugins for your favorite tools. Instead, you should have useful public interfaces for dealing with your system.
(The minimum interface you should aim for is something to report configuration information, state information, and performance metrics.)
I don't really care what form these interfaces take, although I feel that programs with documented, machine-parseable output are usually better than libraries with an API. The important thing is that you have such interfaces, that you document them, and as much as possible that you keep them stable; whether or not you produce XML, JSON, or something else is a minor issue after that. The important thing is to think about the issue and to solve the problem of making your system transparent, not opaque.
(The problem with libraries is that they only do half of the job; you still need to write or modify other code to call the libraries.)
Please note that if you have programs that output this information but you have not made their ouput easily machine parsed or documented it, you have not actually solved the problem. As I noted in my recent ZFS grump, this is the difference between a tool and a frontend; a tool produces things that are easy for other programs to use.
* * *
Atom feeds are available; see the bottom of most pages.