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.<p>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.<p>CM tools (current and their predecessors like cfengine) as they tend to be implemented strike me as a way of avoiding administering the whole <i>system</i>, by focusing on a single component (servers) and reducing them to a lowest common denominator.<p>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.<p>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.<p>These are all traditional sysadmin areas, with <i>plenty</i> 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.<p>By way of example, something I wrote on LinkedIn, in response to why I'm not a fan of puppet:<p><pre><code> 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"
</code></pre>
[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.<p>[2] Which can be like an encapsulated OS itself