Sysadmin Field Notes

February 9, 2006

One of my favorite analogies in building systems is "Moving Parts." Things that are simple have few Moving Parts, complicated things have more. The more moving parts, the more likely something is to fail.

But I don't think the notion for me is tied only to some absolute measure of complexity. The Weblogic proxy plug-in for example, is certainly complicated. However, it doesn't have a lot of configuration, a lot of dependencies, or maintain a lot of state. And so even though the code may be complicated, the component itself is very reliable (I've attributed very few problems to this plug-in beyond initial configuration).

Moving parts are stuff that -do- things. It's the data in motion, and how the parts of the data flow are connected. I think this idea needs more fleshing out.

If you need a data file from somewhere, then having the data pulled from a DB to a file system via a cron job, then having another cron job ftp it to the remote system, then some process on the remote system that runs every 15 minutes notices the file, imports it into a local DB, then another process generates an XML file and pushes it to a server where it's remotely loaded by the box that needs the feed...that's a lot of moving parts.

Moving parts means more things likely to fail.

In code, moving parts are hard to test. They require specific environments, and criteria. Maybe you can mock up some of the interfaces, maybe others you can't. So that tends even more to make them less reliable, because they aren't nearly as fun to test as clean, isolated components.

Think about moving parts as you design; state, timings, external dependencies...those can all be moving parts. The more you can minimize those, the more reliable things will be.