Some thoughts for the holidays… Best Regards!  Cloudadmins team.
by Julian Dunn, 2012

Last night, at a meeting of NYLUG, the New York City Linux Users’ Group, I watched Sean O’Meara whip through a presentation about Chef, the system configuration management (CM) tool. I was impressed. The last time(s) I tried to play with automation tools like cfengine and Puppet I got very frustrated at their complexity. The folks at Opscode have definitely succeeded at bringing simplicity (as much as can be had) to the CM space.
But what struck me after hearing Sean had nothing to do with Chef. Instead, I came to the conclusion that pure systems administration is eventually going to die out as a profession. The developer is now king (or queen), and that’s not a bad thing.
Let’s step back for a minute and talk about CM tools in general. Traditional CM tools — to the extent that they existed before cfengine et. al. – know nothing about the underlying semantics of what you ask them to do. At CBC, we had a set of elaborate shell and Perl scripts that were written in-house, collectively known as ASC, Application Server Control, to do so-called configuration management of the origin infrastructure. ASC’s sole job was to revision control configurations, perform deploy and rollback operations, and perhaps do some auditing. But it was prescriptive, not descriptive. Most of the time I spent monkeying with ASC was debugging how it was doing things.
Enter Chef (or Puppet, LCFG, cfengine, BCFG2; pick your poison). These are all configuration management tools that allow you to describe your infrastructure  in a fourth-generation language (4GL) way. You describe the features that certain hosts should have, and the tools, using canned recipes, makes it happen. (“Make me a MySQL server,” for instance.) Another advantage of these tools is that they (can) keep track of the state of your infrastructure, and you can query that database to make decisions about new deployments. “How many MySQL servers do I have?” for example. Or even “Which node is the MySQL master?” and then kicking off another job on a new MySQL slave to automatically start replicating from the right server.
Had it not been for the development of IaaS — infrastructure as a service — everything that I’ve told you would not be particularly noteworthy. But IaaS, or “cloud computing”, now allows anyone to provision new (virtual) servers inexpensively. No more waiting around for the system administrator to order a couple servers from Dell, wait a few weeks for them to arrive, rack them up, configure them, etc. Developers, armed with a tool like Chef and its huge cookbook of canned recipes for making many standard infrastructure components, can fire up everything they need to support their application themselves. Therein lies the demise of system administration as a standalone profession and the rise of “devops”.
I admit that when I first heard the concept of “devops”, I snickered. “Give developers the keys to the infrastructure and they’ll surely break it beyond repair and expect the sysadmins to fix it,” I thought. But it’s finally dawned on me that “devops” isn’t just some buzzword concept that someone has thought up to make sysadmins’ lives hell. It’s the natural evolution of both professions. By bringing development and system administration closer together, it does two things. First, it makes developers operationally accountable for their code, because they are the ones that get paged in the middle of the night, not some “operations team” upon whom they can offload that responsibility. And secondly, it makes those on the systems side of the house better at their jobs, because they can use newly-acquired programming skills to manage infrastructure resources in a more natural way.
So will IaaS and sophisticated configuration management tools kill the system administrator? I believe so — but that’s not a bad thing. System administrators have got to stop thinking of servers/disk/memory/whatever as “their resources” that “they manage”. Cloud computing has shown us that all of that stuff is just a service, dedicated to nothing more than serving up an application, which is what really matters. If sysadmins want to remain relevant, they’ll get on board and start learning a bit more about programming.
Source: http://www.juliandunn.net/2012/01/13/chef-devops-and-the-death-of-system-administration/