{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"There are no DevOps engineers. So who does exist, and what should we do about it?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"There<\/p>\n

<\/p>\n

Recently, such job postings have flooded the internet. Despite the attractive salaries, it's hard not to feel uneasy about the nonsense written inside. Initially, it\u2019s suggested that 'DevOps' and 'engineer' can somehow be glued together into one word, followed by a random list of requirements, some of which are clearly copied from sysadmin job postings.<\/p>\n

<\/p>\n

In this post, I want to discuss how we got to this point, what DevOps actually means, and what we should do about it now.<\/p>\n

<\/p>\n

Such job openings can be criticized in many ways, but the fact remains: there are a lot of them, and this is how the market is structured at the moment. We held a DevOps conference and openly stated: 'DevOops<\/a><\/noindex> \u2014 is not for DevOps engineers.' Many will find it strange and ridiculous: why would people organizing a purely commercial event go against the market? We\u2019ll explain everything now.<\/p>\n

<\/a><\/noindex><\/p>\n

About culture and processes<\/h2>\n

<\/p>\n

Let\u2019s start with the fact that DevOps is not an engineering discipline. It all began because the historically established division of roles does not work for product quality. When programmers only code and refuse to hear about testing, the software gets plagued with bugs. When admins don\u2019t care how and why the software is written, support becomes a nightmare. <\/p>\n

<\/p>\n

For example, the description of the difference between sysadmin and SRE approaches to service management is where the famous Google SRE Book begins.<\/a><\/noindex>Interesting research has been conducted within the DORA survey<\/a><\/noindex> \u2014 it shows that the best developers somehow manage to deploy new changes to production faster than once an hour. They also test manually no more than 10% of the time (as seen in the last year's DORA report<\/a><\/noindex>). How do they achieve this? 'Excel or die' \u2013 says one of the report\u2019s headlines. For a detailed discussion of this statistics in terms of testing, you can refer to Baruch Sadogursky's keynote 'We have DevOps. Let\u2019s fire all the testers'<\/a><\/noindex> at another one of our conferences, Heisenbug.<\/p>\n

<\/p>\n

'When there is no agreement among comrades,
\nTheir business will not go well,
\nIt will yield not a deed, only suffering.
\nOnce upon a time, the Swan, the Crab, and the Pike...'<\/p><\/blockquote>\n

What do you think, how many web developers truly understand the conditions under which their applications operate in production? How many of them will approach the admins to figure out what happens when the database crashes? And who among them will go to the testers and ask to learn how to write tests properly? And then there are the security specialists, product managers, and a bunch of other people.<\/p>\n

<\/p>\n

The general idea of DevOps is to establish communication between roles and departments. This is primarily achieved not by some cleverly configured software, but through communication practices. DevOps is about culture, practice, methodology, and processes. There is no engineering specialty that directly addresses these questions.<\/p>\n

<\/p>\n

Vicious circle<\/h2>\n

<\/p>\n

So where did the discipline of \u2018DevOps engineering\u2019 come from? We have a theory! The ideas behind DevOps are so good that they became victims of their own success. This topic has attracted a lot of shady recruiters and people traders who have their own atmosphere.<\/p>\n

<\/p>\n

Imagine this: yesterday you were flipping shawarma in Khimki, and today you\u2019re a senior recruiter. There\u2019s a whole process of searching and selecting candidates, and it\u2019s not simple, you need to understand it. Let\u2019s say the department head says: find a specialist in X. We add the word \u2018engineer\u2019 to X, and it\u2019s done. Need Linux? Well, that\u2019s definitely a Linux engineer; want DevOps? Then it\u2019s a DevOps engineer. A job vacancy consists not just of a title but also requires some text inside. The easiest way is to jot down a set of keywords from Google, whatever your imagination allows. DevOps consists of two words\u2014'Dev' and 'Ops', so we need to mash keywords related to developers and administrators all into one pile. This is how job postings emerge that require mastery of 42 programming languages and 20 years of simultaneous experience with Kubernetes and Swarm. A working scheme.<\/p>\n

<\/p>\n

Thus, a meaningless and ruthless image of some super-hero \u2018DevOps\u2019 has taken root in people's minds, someone who will set up everyone\u2019s deployment on Jenkins, and happiness will ensue. Oh, if only it were that simple. 'And this way, we can also hunt sysadmins,' thinks the HR person, 'it\u2019s a trendy word; the keywords are the same, they should bite.'<\/p>\n

<\/p>\n

Demand creates supply, and a crazy number of system administrators rushed to these ridiculous job offers, realizing they could do the same things as before but earn significantly more by calling themselves 'DevOps'. Just as you set up servers via SSH one at a time, you will continue to do so, but now it\u2019s supposedly a DevOps practice. This is a complex phenomenon, partially related to the undervaluation of traditional admins and the hype around DevOps, but in general \u2014 what has happened is what has happened.<\/p>\n

<\/p>\n

So, we have demand and supply. A closed loop that feeds itself. This is what we are fighting against (including creating the DevOops conference).<\/p>\n

<\/p>\n

Certainly, besides sysadmins who have rebranded themselves as 'DevOps', there are other participants \u2014 such as professional SREs or Infrastructure-as-Code developers.<\/p>\n

<\/p>\n

What People Actually Do in DevOps<\/h2>\n

<\/p>\n

So, you want to advance in learning and applying DevOps practices. But how do you do this, which direction to look? Obviously, blindly following popular keywords isn\u2019t the way.<\/p>\n

<\/p>\n

If there is work, someone has to do it. We\u2019ve already figured out that it\u2019s not the 'DevOps engineers', so who is it? It seems more accurate to formulate this not in terms of job titles, but in terms of specific areas of work.<\/p>\n

<\/p>\n

Firstly, you can engage with the very heart of DevOps \u2014 processes and culture. Culture is not a quick or easy matter, and although this is traditionally the responsibility of managers, everyone is involved in it in one way or another, from programmers to admins. A couple of months ago, Tim Lister said in an interview<\/a><\/noindex>:<\/p>\n

<\/p>\n

\u2018Culture is shaped by the core values of the organization. People usually don\u2019t notice it, but we, having worked in consulting for many years, have come to recognize it. You enter a company and within just a few minutes you start to feel what\u2019s happening. We call it the 'scent'. Sometimes this scent is really good. Sometimes it makes you feel nauseous. (\u2026) You cannot change the culture until the values and beliefs that underlie the specific actions are recognized. Behavior is easy to observe, while searching for beliefs is difficult. DevOps is a great example of how everything becomes more and more complicated.'<\/p><\/blockquote>\n

There is certainly a technical aspect to the question. If your new code arrives for testing in a month, but the release doesn\u2019t happen until a year later, and it's physically impossible to speed up the process, you may never reach good practices. Good practices are supported by good tools. For instance, by keeping the idea of Infrastructure-as-Code in mind, you can use anything from AWS CloudFormation and Terraform to Chef-Ansible-Puppet. You need to know and be able to use all of this, and that already falls under engineering discipline. It\u2019s important not to confuse causes with effects: first, you work according to SRE principles, and only then do you embody these principles through specific technical solutions. Meanwhile, SRE is a very complex methodology that is not about how to set up Jenkins, but revolves around five key principles:<\/p>\n

<\/p>\n