Overheard at a local DevOps talk:
Are you guys doing DevOps? Because we are totally doing DevOps at MegaTelCo! We’ve just started up a 35-person DevOps team!
It took all my energy to keep myself from pulling a Picard facepalm right then and there. Unfortunately, this talk attendee’s excitement to hire employees with “DevOps” in their job title seems to be more than an aberration. A quick search of the internet turns up plenty of companies that are looking for “DevOps engineers” that will be asked to do some of the following tasks as part of their job:
- Automate all changes to production hardware
- Configure JIRA
- Administer MySQL databases
- Maintain large-scale Linux implementations
- Know everything there is to know about Puppet
- Write scripts in Ruby, Python, or Bash
- Throw together quick hacks
These items were all taken from real job postings, and have been slightly reworded to protect the guilty.
In some ways, I suppose it is good that the “DevOps” concept is gaining some traction. However, it seems to me that, as we have seen before with “Agile”, “DevOps” is in danger of achieving mainstream-buzzword status and is therefore in danger of losing all meaning. My sense is that most companies that are hiring “DevOps” people are not really interested in DevOps, they are interested in hiring sysadmins and sounding hip. Most of the skills and responsibilities you will find on a typical “DevOps” listing overlap almost entirely with a listing for an operations engineer or a systems/network admin. Notably absent from the typical “DevOps” job listing is the desire for a candidate that can create software that is simple to operate. It seems that instead of truly working to bring development and operations together to improve software quality, the industry is taking a shortcut by just rebranding sysadmin/operations as “DevOps”.
So, what really needs to be done to embrace DevOps?
Instead of creating a new DevOps team, blur the line between your existing development and operations teams. Developers and sysadmins should meet regularly to discuss operational concerns — including deployment, configuration, and software defects. Feedback and ideas should flow both ways between the groups. Project managers should view sysadmins as users of the software whose feature requests and use cases are just as important as those of the “real” users. Developers must be receptive to the needs and requirements of operations and should take pride in making the software easy for the operations team to work with. The two teams should remain somewhat separate, because they have separate strengths and responsibilities, but it is healthy for the teams to work as a single “uber team” with a shared goal — producing and operating software that meets and anticipates business needs while remaining reliable, simple, and consistent.
Instead of focusing on automation, focus on consistency and simplicity in your software. A common reason why people think that there is no “DevOps” in the Windows world is that the Windows ecosystem doesn’t have automation tools comparable those in the Linux world (I am primarily thinking about chef and puppet here). While tools can certainly be useful, I object to the premise that DevOps is fundamentally about automation. Your proprietary software simply should not require fancy scripts (whether they are in perl or puppet) to deploy and configure. Deploying an application should be a simple xcopy to the target machine (perhaps automated by the application itself in a “self deploy” mode). Configuration should be handled by your central configuration service, not by a complex dance of XML files. Rather than building Rube Goldberg machines to script your way around the inconsistencies and complexities of your proprietary software, work with development (and management) to eliminate those problems and reduce the software’s operational complexity.
Instead of treating “DevOps” as a buzzword, embrace it as a philosophy and spread it through your organization. Fundamentally, DevOps is not something you can achieve quickly by hiring people with “DevOps” in their titles or by bringing in some huge automation tool. Truly achieving DevOps Zen requires a substantial cultural shift. Developers need to focus on the needs of operations rather than myopically focusing on the end users. Sysadmins need to escalate production issues to development and deploy automation solutions that meet high standards of quality. Communication and culture are only the first step, however. You will also have to dedicate time and resources to change your software so that it becomes simpler and easier to operate. Apps will need to fetch configuration from a central service instead of local files. They will need to be xcopy deployable and be free of environmental dependencies. They should disseminate custom monitoring data in a structured way, and not rely on log file scraping scripts.
DevOps is not a checkbox you need to check off to look cool. It is a technology philosophy that requires communication, collaboration, and above all, a focus on producing a high quality software system that is a joy to develop, operate, and use.
