Devops

This weekend I attended the devopsdays. The conference topic was “agility in system administration”, and breaking down the wall between development and operation. I like the idea and I think this is the way forward. This is also import for me from a research perspective, because an important aspect is the use of system configuration tools. By using this tools operations also becomes development using the API provided by the tool.

Although the conference was nice and I especially liked Teyo from reductive labs talk, I was a bit disappointed. Most of the attendees where part of small companies or startups. As Teyo said in his talk, this is where a lot of these new ideas are formed and they trickle up to enterprises. The second part of the conference, after the presentations, was an openspace meeting. It was there that I got a bit disappointed. Most discussions were at a low level and did not touch the real problems that the devops concept faces.

Instead of talking about the next generation patch tools, how to migrate partially puppet manged debian boxes, how evil mailing lists are or the “next yet another” cloud management tool. These are all really interesting discussions if I was wearing my sysadmin hat, but they do not have much to do with devops (and I was wearing my researcher hat).

Devops is much easier to do when you talk about a small team, where the developer is setting next to the sysadmin. This is, like Teyo said, much the case in small companies or startups. According to me the discussions should have been about:

  1. How do you move from the current model in enterprises to the devops model?
  2. How do you make devops compatible with stuff like ITIL or COBIT? This is important for enterprises, you can not ignore this.
  3. What about security? Are you going to give everyone access to the API? How do you control access? ACHEL is a step in the right direction according to me.
  4. How far do you want to go? Will everyone be dev and ops? Or is there still some specialization? Because even in development, nobody does everything.

I know this is the whole point of open space, everyone can propose a session. I tried one about the security aspect, without talking about ACHEL. But nobody was interested. I also did not want to push this, because forcing would have been contra productive. Maybe a last question: How do you bring these kinds of questions on as a sysadmin, without looking like a researcher in his ivory tower? I have no idea …

3 thoughts on “Devops”

  1. Hi Bart,

    I just ran into your blog entry about devops. Pity we didn’t meet during devops’09 but I guess there will be plenty of other opportunities.

    Interesting blog post that yields many reactions from my part.

    First of all, openspace is mainly what we bring to it :) I too thought that it was sometimes too technical but at the same time I think it is because there are still some tools missing to lower the cost of bringing agility to ops [1].

    As far as I know, all the companies having bridged the gap and doing “agile ops” have developed in-house tools to do it.

    This in my opinion also answers your first question: there is no easy path at the moment to bring this into a company. It is mainly trial and error and before devops, there was very little communication between those involved in that pioneer work.

    Hopefully this will change and new tools will lower the entry price tag by allowing re-usability, ensuring reproduceability of experience across workplaces/companies.

    As for ITIL and Cobit. Well… I’ve been trying to think in the past at how agile and ITIL could work together, but I must say that I probably failed [2]. There are some similarities between some of the general ideas expresses in ITIL (for instance the scm used for puppet can be seen as a form of CMDB), but there are also IMHO fondamental differences, the first being that ITIL/COBIT are all about processes while agile prefers on interactions and people [3].

    Lets just say that it’s probably best to set examples of Agile/bridged-devops practices in non-ITIL/Cobit companies and _prove_ that it works.

    Because it is all about proof, right? If you can show a lot of examples from different environments that implements a method that just work, then ITIL should try to integrate it since I believe this will probably be enough to be considered a “best practice” [4]?

    This leads to your question about access control. I have only quickly parsed your document on ACHEL and it brings me the following question: why do we want to implement this? For instance, why do we want a manager to sign a technical change (i-e is he the right person to take that decision)? This for me goes against the agile principles where you try to empower people because this is where they will try to do their best and it avoids the blame/”umbrella” culture (people being counter-productive by spending a lot of time/energy to protect themselves).

    I believe a process like this may be the wrong solution to the wrong problem. I guess that what I want is to limit risk and bring as much value as possible.

    In my opinion, a combinaison of agile values such as common ownership, peer review and of tools such as continuous testing and configuration management are preferable, especially if you have a scm that tracks what/when/who (not to blame someone about something, but to track what happened and fix it asap [5]).

    On your last question, I personally believes that at least for a transition period, there might be 4 differents profiles: “classic devs”, “classic ops”, dev-that-care-about-ops and something else that I can’t quite completely describe yet even after the session we had at devops’09 [6].

    I hope that everyone may become that something-else-I-can’t-quite-name-yet-because-I-don’t-know-how-to, but it might not be the case. What is sure is that there is a change of paradigm in the air and I’m happy about it because in 10+ years of experience in Ops I wasn’t so impressed by the statut-quo.

    Cheers,
    Gildas

    [1] this was the purpose of the “missing tool” session and was something that was discussed in the non technical “what are our values/what name could we choose for our emerging movement”: we need a basic set of tools before this can happen,
    [2] I should post some stuff about it on my blog though
    [3] http://agilemanifesto.org/
    [4] as a matter of fact, I’ve never seen any proof or reference in ITIL/COBIT. “Best practices” seems to be the new religion: you have to believe in its positive effect to be able to see it.
    [5] see http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr esp. slides 32, 72 & 73
    [6] this too should be a post on my blog….

Leave a Reply

Your email address will not be published. Required fields are marked *