DevOps Engineering: Who does your automation?

Linky - http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing...

Call it what you will, 'DevOps' is just what you'd expect a good sysadmin to do in a sufficiently large org. That there is on going friction between developers and sysadmin ("it works on my box" is a valid excuse?) is perhaps a larger sign of the culture and people involved.

Sounds like regular Operations work to me. I don't understand why it needs to be differentiated.

Sometimes I wonder if DevOps isn't really just those who would truly prefer to be developers but don't mind sysadmin work and, for whatever reason, started out doing the latter.

I, too, cringe a little when I hear the term, perhaps because I've always viewed myself as a "pure" sysadmin. That is, this is the kind of work which continues to bring me joy after 2 decades. Application development, on the other hand, despite an ability to code, does not.

CM tools (current and their predecessors like cfengine) as they tend to be implemented strike me as a way of avoiding administering the whole system, by focusing on a single component (servers) and reducing them to a lowest common denominator.

It also fits the pattern of trying to solve problems entirely in a custom software solution, a trait I associate with developers, not sysadmins. This is the source of my inference of DevOps' true leanings.

The reality is that the system consists of considerably more than fungible servers[1]. There's the underlying hardware, the peripheral hardware like disks, database software[2], network hardware and configuration, and service providers.

These are all traditional sysadmin areas, with plenty of room for professional growth and overall benefit. So much so, that I have difficulty imagining why any SA (not a developer in SA's clothing) would wish to do more dev at the expense of increaaed mastery of the infrastructure.

By way of example, something I wrote on LinkedIn, in response to why I'm not a fan of puppet:

  I'm uncomfortable with any system that attempts to maintain state in place
  on a running system, as well as possibly override the native packaging ethos. 
  That the client takes its own local file inventory on a fresh system, rather 
  than trusting the one the package manager has, is wasteful at best. What's 
  worse, to me, is that it creates yet another system to administer. I haven't yet 
  found anything similarly suitable for the Ubuntu/Debian world, but I very 
  much liked Cobbler a couple years ago, as it was primarily a wrapper for 
  what could otherwise be standard, standalone services (kickstart, package 
  repo). Even without such a wrapper, yum/rpm or apt/dpkg can do nearly all 
  the work"

[1] Virtualization and "cloud" notwithstanding, as anyone who's experienced an outage with a hosting provider or an i/o perofrmance issue with a cloud server can attest.

[2] Which can be like an encapsulated OS itself

Yea I think like some the term DevOps makes me cringe as well since people use it as a job title when it should be more thought of like agile development, just another term to describe a process of working.

I use chef because I needed a way to consistently deploy software in exactly the same way every time to multiple servers. A repeatable deployment process that scales. Why did I pick chef over puppet or cfengine? Because I also wanted to learn ruby and the entire thing is in ruby, win. Plus we have a ruby on rails team in the office, if ever I needed a hand, they were there or if they wanted to write recipes to deploy software thats not an issue either.

DevOps is just a new buzz word. My title is System Administrator. I have a depth of knowledge in the infrastructure of all our technologies and how they are interconnected. I know how to deploy, maintain, scale and do it all over again. My knowledge in programming in second to that but is necessary to automate repetitive processes. DevOps I guess is being classed as a way to bring the IT team together, making sys admins and developers aware of each others "agendas" when it comes to running apps on servers. I as a sys admin have to understand what each of our applications does throughout its life cycle, from the browser right down to the database. Because if something goes wrong, I'll be the first to figure out where that happened and relay this back to the developer. By understanding core functionality of the code I can make it clear to the developer, "look you are executing a query on the database thats scanning millions of rows because its not using an index, its occurring in this controller in your code". We are seeing this term DevOps be classified now as more and more startups are emerging, because its essentially alot easier to execute in a startup environment where everyone is talking to each other to roll things out, everyone is trying to solve problems together. In large companies you'll see a massive separation and segregation along with processes to keep people in their place and slow results.

I hope that all makes sense. DevOps as a process is not new, the classification of it as this term is.

40 years ago IBM called these guys "systems programmers". That this is a new concept to some people is symptomatic of a wider problem in the industry: everything needs to be shiny and new so every 10 years we reinvent the wheel with new jargon.

There is a bit of the same movement in CCP Games where I work, it's not called DevOps here, but there are groups forming in both the EVE Online software team and the Core technology group with an engineering focus on QA, which in practice translates pretty well to the DevOps style of thinking about the needs for this type of development and quality work. Here's one of the advertised positions for example:

http://www.ccpgames.com/en/jobs/job-details.aspx?jobid=101