Hire People on DevOps and Other Bad Ideas

Original author: Stuart Lange
  • Transfer
Once I witnessed a conversation between two friends and heard:
“Have you already implemented DevOps? It's just that in MegaTeleKo everything is in full swing! We recently recruited a DevOps team of 35 people! ”

So why is hiring a DevOps team a bad idea?


At that moment, I resisted the captain Picard-style feispalm. Unfortunately, hiring employees for a position containing the word DevOps and the joy of the participant in this conversation about this is not an accidental delusion. According to a quick review of sources on the Internet, many companies are looking for DevOps engineers who, among others, will be engaged in:
  • automation of changes in infrastructure
  • JIRA setup
  • MySQL administration
  • support for large-scale Linux projects
  • managing everything related to puppet
  • writing scripts in ruby, python or bash
  • operational propping up with “crutches” here and there

The list is made up of pieces of real jobs, slightly modified so as not to hint at someone specific.

In general, I am positive about the fact that the concept of DevOps is becoming popular. However, as it was with Agile, DevOps is in danger of getting the status of another fashionable term, and subsequently losing all meaning. It seems to me that most of the companies looking for DevOps just want to hire a system administrator, but at the same time look modern. The lion's share of the requirements in a standard DevOps job is fully covered by the competencies of a support engineer or system administrator. At the same time, it is especially funny that in these requirements the item “ability to create simple and working solutions” is often missing. It seems that instead of working in the direction of interaction between development and support to improve quality, the IT industry is trying to "cut" by simply giving the admin a new title - DevOps.

So what is really needed to develop DevOps?


Instead of creating a new DevOps team, try removing the wall between the development and support departments. Developers and system administrators should meet on a regular basis in order to speak out all the working moments, including installing, configuring software and its problems. Feedback and discussion of ideas should work both ways. Project managers should consider system administrators as the same software users, and therefore, consider their work scenarios and take into account the wishes, as they do for external users. Developers should be sympathetic to the requirements of support and responsibly approach their implementation. Of course, the two teams must remain independent, because each has its own specifics, strengths and competencies,

Instead of ubiquitous infrastructure scripting, software should be made holistic and logical. It is believed that the term DevOps does not exist on Windows due to the lack of efficient automation tools in this ecosystem as in the Linux world (here I am hinting at chef and puppet). It's hard to disagree, such tools are extremely useful, but I don't support the view that automation is the cornerstone of DevOps. In fact, your software should not rely on non-trivial scripts for installation and configuration (it doesn't matter perl, puppet). The implementation should be simple, ideally, like a regular xcopy on the target machine (it would be nice if the software installs itself on the first start). Settings should be obtained from the configuration service, and not arrange carnivals of XML files. Instead of designing another Goldberg machineIn order to script all the features and difficulties of setting up your software, finally interact with the development (and management) to get rid of such problems and unnecessary complexity.

Do not think of DevOps as another buzzword, better accept this philosophy and spread it. In reality, DevOps cannot be arranged by simply hiring specialists with this word in a resume or implementing monstrous automation software. DevOps takes Zen to a cultural leap. Developers who are fixated on end users should look at support and its needs. Admins, instead of silent grunts, should report inconvenience to the product and contribute to improving the work process. Thus, establishing relationships within the company is the first and important step. Next, you will have to devote time and resources to improving the product to a “simple and convenient” state. Configuration through a central service, implementation by simple copying, lack of external dependencies,

DevOps should not be taken for show. This philosophy involves communication and interaction, and most importantly, the desire to create high-quality software that is developed, maintained and used with pleasure.

Also popular now: