DevOps Engineering: Who does your automation?

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"

[2] Which can be like an encapsulated OS itself

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.

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

Now I know that "DevOps" means "those who forget history are doomed to repeat it". Whenever you come across something in IT you think is new, take the time to find out if mainframe shops were doing it in the 1970s... Back then sysadmins wrote assembly language to automate systems tasks and it was just an everyday part of the job!