Over the past few years or so a term has arisen and gone from being spoken about in small circles to being widely used by those working in IT and exposed to the world of Agile. That term is ‘Devops’. I have been tracking its use and development for a while and have long been meaning to write something about it, but two things have stopped me – a lack of time, and latterly the sheer weight of information about it.
What is it?
The name is a portmanteau of “Development” and “IT Operations” and this stems from the fact that it arose out of an effort to reduce the friction felt between traditional siloed teams who would throw a finished product over a wall and expect an operations team to support it without any buy-in or involvement in the project. I’m not going to write a huge amount about it here, one reason being that searching Google for “What is devops? returns 14,000 results and there is now even a Wikipedia page on Devops. There are also varying answers to this question:
• Agile System Administration
• Agile Operations (where Operations refers to the ongoing support of an application)
• Developer and Operations collaboration
• Code as infrastructure
• Automation (e.g. using Puppet)
• People over Process over Tools
• Developers doing their own Systems Administration
• Using the cloud
• An elitist cult (!)
• Just another job title
• Test driven Systems Administration
Some of these are plain wrong, some of them only capture half the picture. So what do I think?
Clearly Devops has its origins in reducing friction between development teams and operations staff, but this is by no means the big picture. One of the key elements of Devops to me is removing silos and encouraging people from differing disciplines to work together, and not just dev and ops; QA should be involved and so should other disciplines, ideally all of them. This is not just in a team environment (although cross functional teams are a great idea) since traditional ops will be left managing the product long after the project team have moved on to pastures new; this should be a cross business attitude where people don’t say “That’s not my department, someone else can worry about it” but instead understand and work with the different business areas.
Devops is more than this though. Devops is closely associated with the Agile Software movement and it follows then that it has some common aims. I found Devops whilst looking into Agile System Administration. I had seen the benefits that agile brought to software development and wanted in on the action. My taskboard was created as a reaction to this and since creating it I read up on Kanban, discovering that in fact I had almost implemented a simple form of Kanban. This, by the way, is the best and most long lived task management system I have ever used, individual or group based. You would not believe how many times I had tried to solve the problem before and found the management overhead too high. Looks like K.I.S.S. wins again. Another notion borrowed from agile is that of automation and the use of tools such as Puppet, Chef and Cfengine are common amongst those who subscribe to Devops. I do not believe these to be a defining characteristic, but rather facets of trying to approach Systems Administration from a more professional viewpoint rather than the traditional and tired stereotype of a few grumpy forgotten blokes trapped in the basement and mired in cynicism and grumpiness.
Who is doing it?
Lots of people, though it does feel as if most of the people who are doing it are single product houses (e.g. Etsy, Flickr) who to a large degree are free to pick and choose how they run their systems without the complexities of third party boundaries such as clients and externally hosted systems.
What does it mean for Technophobia?
Devops has a lot in common with the way Technophobia has always operated, but we still have further to go before we can truly describe ourselves as fully embracing Devops. I have always been a fan of IT and Developers working together closely and it is something I feel we do well. We don’t always get it right, but usually if there is a problem rather than throw blame back and forth we work together to resolve a problem. With recent projects we have also started embedding members of IT in project teams to varying degrees of success.
Agile is something that we have embraced and although we have recently begun to use Puppet I feel there is more we can do to automate server management and gain further benefits. Systems Administration has always been about automating simple tasks so you spend less time repeating them, but Devops does this on a far wider scale with common toolsets rather than custom scripts which get abandoned. I’m not necessarily advocating diving straight in to doing everything with Puppet, but it does warrant further investigation into the possibilities and how we can save time.
Where can I find out more?
• www.jedi.be/
• theagileadmin.com/
• dev2ops.org/
• www.agileweboperations.com/
• agilesysadmin.net/
• www.devopsdays.org/
