Sysadmin Models

by Luke A. Kanies

My post on the fact that I don't think system administration is evolving seems to have ticked some people off on the lopsa-discuss list.



Sure, I was a bit flippant in my post, but I think many of the critics are falling into the common trap of thinking that tools vary in functionality but not in fundamentals. Paul Graham does a great job discussing this in his article about beating the averages; it is about languages but it's just as valid here. Just like languages, tool power varies considerably.



I don't just mean tool functionality, that is, the specific features of the tool; I mean the overall power. I think of this variance in power as deriving from difference in models: Tools with low-level models are not very powerful.



For instance, take one of the big differences between cfengine and Puppet; cfengine focuses mostly on managing textfiles, while Puppet manages semantically more powerful constructs like users, services, and packages. Thus, Puppet has higher-level models than cfengine, and if you accept my premise that model power derives from how high-level it is, that generally makes Puppet a more powerful tool than cfengine.



Note that that doesn't make it more functional -- it could be less stable, there could be lots of interesting things it can't do, whatever.



This is one of the things I think are really lacking in the sysadmin world: High-level models. Do you think in terms of /etc/passwd, or users? If you think about /etc/passwd, then LDAP is fundamentally unrelated, but if you think in terms of users, then they're functionally equivalent.



It's not just about how powerful the modeling of the tool is, though, it's about the power of the models it creates.



Take dependencies and relationships between resources. Are there any sysadmin tools that effectively model these relationships? Of those tools, do any of them make the information exportable to other tools, so you're encouraged to spend a lot of time developing these comprehensive models? No, not really. Sure, some of the monitoring apps allow you specify basic dependency information, but they're extremely limited, and you can never export them so they're useful elsewhere.



What really sets Puppet apart from Cfengine isn't that it models higher-level resources instead of files, it's that it allows you to model the relationships between those resources. Puppet's lowest layer is responsible for the resource modeling (e.g., what it means to be a User on Solaris vs. OS X), but its language handles the high-level relationships between those resources, including how they're grouped (e.g., they're all part of the class of resources that makes apache work) and how they relate (e.g., apache should restart if its configuration file changes, and changes to the file should happen before the service is checked).



This is why better tools are so important: The models our tools use set an upper limit of the size of the problems we can comfortably work with. Unless we develop a whole slew of new tools with more powerful models, we'll be forever stuck thinking about bits on disk.



That means it's not just about configuration management, it's about everything on your network. If my configuration management system can't model the network, then I can't set up IP addresses or firewall ports; if it can't model the backup system, then I can't provide guarantees of data availability or perform automated restores; if it can't model change, then I have to do all migrations manually.



These models are critical, and they're all in our heads instead of in our tools. This fact is a severe limitation on our field's ability to move forward.


2 Comments

Christian Pearce
2007-02-17 18:48:59
I couldn't agree with you more about the need for models. I have been taking time off from sysadmin work recently. I started to do a bit of MVC work with a PHP rails equivalent framework. But decided I need to to use ruby. And with very little trouble at all was able to switch languages entirely. I am not certain if that is what you are hoping to archive by modeling sysadmin work, but it might be nice to be able to model your sysadmin configs at a lower level, and move to a different tool with greater ease. This might provide future incentive for admins to actually take the time to model there configs in a lower level tool, if they think there is benefit of a better tool down the road. Especially if the current tool helps them out a bit now.


There has always been a ton of talk about community this and wiki that for config management. But I think the modeling is going to be the biggest benefit. How do you suggest we approach that? Let's start with user management.


Sidebar: Here is a project that I think attempting to do some modeling. http://config4gnu.sourceforge.net/ It focused more on modeling the different config types from a end user perspective but I think it was a step in the right direction.

Luke Kanies
2007-02-19 09:58:32
I plan on going more in-depth on some of the models in later posts, but I think the resource models, like those for users, are less interesting, since they're usually pretty easy. Easy enough, in fact, that Puppet attacks these first.