What Sysadmins Can Learn From Developers

by Luke A. Kanies

LinuxPlanet published an interview with Ibrahim Haddad this past summer on a topic near and dear to my heart.

Developers have done a great job in the last couple of decades of evolving their practice, so that development looks very different now than it did a couple of years ago. There's a lot of competition for tools and methodologies, lots of publishing on these differences, and plenty of opportunity for new ideas to gain mindshare. This competition is really important to evolution: Unless there is opportunity and reward for better ideas and products, these better ideas don't develop very quickly.

Sysadmins, on the other hand, have very little competition, in either ideas or products, and in the few areas where there is competition there generally isn't much to differentiate the competitors.

Ibrahim's interview mostly focuses on process, which is, I think, where a lot of the evolution has happened in development recently. The wizz-bang Agile stuff is all about changes in process, and has almost no impact on tools, other than having a preference for tools that enable the process. It doesn't hurt that there are lots of consultancies set up specifically to sell Agile development methodologies.

I'd love to see the same kind of process competition in the sysadmin world, and I wish I knew how to kick-start it, but my only real area of expertise is tools, so I'm kind of forced to stick to trying to that.

I will say that I'm very happy that Puppet has modern competition in BCFG2, because it forces us to keep making our products better. I know that reporting in Puppet needs to improve, because BCFG2 has set the standard there, and I like to think that there are parts of Puppet that Narayan sees and knows he has to match in order to compete effectively.

10 Comments

Simon Hibbs
2007-03-08 02:30:56
I terms of processes, how much do you know about ITIL (the IT Infrastructure Library)? It's originally a European initiative to document best practices in IT services management and provision and has a close relationship with ISO20000 and PRINCE2.


I get the impression though that you're talking about best practices at a lower level than this, and your work on Puppet is certainly in the low level/tools category but as you say management processes and tools are very different spheres. Do you think ITIL is relevant to this discussion?

Luke Kanies
2007-03-08 07:08:13
I know some about ITIL, but every time I spend any time looking into it I get overwhelmed by how huge and cumbersome the standard is. From what I can tell, if you're planning on spending $5m on your management system and devoting 50 people to it, maybe it makes sense, but it seems too much standard and not enough implementation from my experience.


The whole discussion around a "configuration management database", or "cmdb", is a perfect example. They've essentially pushed all of the complexity into the cmdb without defining it, and there are still literally no implementations of a cmdb, even though all of the consultants and companies are talking about it like it has meaning.


I like to think of Puppet being to ITIL as LDAP is to X.500: Just as functional but 1/100th as complicated. Of course, this isn't really true, because Puppet is just one tool and there are plenty more to create, while directory access is an enherently encapsulated process.

Simon Hibbs
2007-03-08 07:34:57
Fair points. ITIL talks about the CMDB as though it's an atomic entity or product, but in practice it's likely to consist of a variety of databases and monitoring tools. What's important is meeting the objectives, rather than the implementation, and that's where tools like puppet come in.


I like the X.500 analogy, the same could be said of the relationship between SGML and either XML or HTML, but that doesn't mean the SGML or X.500 are bad things. Without them their successors wouldn't exist, at least in the highly effective forms that they do.


If ITIL provides a conceptual framework that, through practical experience and iterative refinement can lead to more effective, practical guidelines and processes then it's all good in the end.


Maybe you should add a note on the puppet page on how it can help achieve ITIL compliance ;)

Luke Kanies
2007-03-08 07:37:40
Heh, well, that would require that I spend some time on the ITIL standard and actually understand how Puppet can help it. Every time I read about it, though, I just get the hives -- it seems to represent very "enterprise" ways of looking at the world, and in my experience that translates to "very expensive and so complicated you can't tell it's worthless". It would take quite a bit to convince me to spend any time on ITIL, or trying to integrate with one of the big tools like Tivoli.
Clive Porter-Brown
2007-05-07 09:43:48
There are some interesting comments on ITIL, but one point that is missed is that ITIL is a framework that helps you to incorporating best practise into your daily work routine, regardless of the size of the operation. To get a fair comparison, I recommend that you look at the ITIL foundation course (as I did) and you will probably find that you are already applying many of the ITIL principles in your daily activities, but you do not necessarily follow a particular model.


What is missing is the identification and linking of the various disciplines in your working routine (e.g. Management of Incidents, Problems, Change, Release, Capacity, Continuity, Security, etc). In ITIL, these processes are managed by function, not actual positions, so you can use this to empower a small support team to have specific responsibilities and make them more involved in the day to day workings of IT support.


I agree that one of the problems with ITIL is that it is presented as a complete solution which can make it daunting when initially met, but break ITIL up into its component parts and you can build a robust operational environment. Plan a migration to these principles and you will get the backing of the business and the net result will be that you start finding more time to work on more interesting developments, rather than getting bogged down in fire fighting.


As for the comments about the CMDB, this is a tool that helps to track components and becomes a common reference point for the process areas. The CMDB can be as simple as a spreadsheet or as complex as a system management solution. The objective behind ITIL is to make the IT operation predictable and repeatable and by improving the operational practises, you can improve the service given to your customers. The nice thing about it being a framework is that you choose how to apply it.



Luke Kanies
2007-05-08 09:18:05
I'm hesitant to rely on a standard that's so complicated you have to take a foundation course to understand how it can be useful. Are there any documents out there that cover it simply and in a way that's immediately useful?


It's certainly possible that ITIL could help one avoid fire-fighting, but I've very successfully avoided fire-fighting through good practice in general, without the need for ITIL. I agree that standardizing that good practice is a good idea, but why does the standard need to be so complicated?


As to saying that the CMDB is "a tool", well, it's a tool in theory, but in practice, it doesn't actually exist, from what I can see, it's just the rat-hole down which the standard developers stick all of the complexity. Any standard that allows the CMDB to be a spreadsheet isn't much of a standard, in my book.

Andrew Hodgson
2007-05-22 12:53:00
Luke, I recommend you check out the Visible Ops book (http://www.itpi.org/home/visibleops.php). It distills the ITIL framework into a set of workable stages, and seems to embody the spirit of ITIL without losing site of the everyday sysadmin worldview (i.e. it's not sickeningly "Enterprise"). For my money it just makes sense, nothing too crazy and certainly nothing you have to spend much money on. Sounds like you have your practice together anyway, but can you rely on your team to perform to your standard? Maybe a framework can come in handy.


(Disclaimer: I am not affiliated to itpi.org or anyone else to do with ITIL! I work for a software dev company and am very interested in the subject of getting better process into sysadmining...)

Luke Kanies
2007-05-24 08:33:58
I'll look into that book; thanks for the reference.
mechanic
2007-06-04 17:51:28
Question about puppet and how it differs from some of the GUI oriented tools:
hyperic claims to do both management and monitoring and offers a CLI to do things from the shell. what is your take on that?
Luke Kanies
2007-06-05 09:03:13
I haven't used Hyperic, but it's a monitoring tool with some ability to make changes to systems (I'm assuming this was mostly developed initially to respond to monitoring events). I don't know what kind of management Hyperic can do, so I can't really compare.


GUIs clearly have a role, especially in information display, but you have more options than GUI and CLI. In particular, Puppet doesn't really have a CLI interface so much as a programming language interface, so it's hard to compare it to a CLI. It has some limited GUI for information display, and we're working on enhancing what we have (providing a web interface for configuration inspection etc.).