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ās 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.
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.
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: ' ā 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āll explain everything now.
About culture and processes
Letās 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āt care how and why the software is written, support becomes a nightmare.
For example, the description of the difference between sysadmin and SRE approaches to service management Interesting research has been conducted within ā 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 ). How do they achieve this? 'Excel or die' ā says one of the reportās headlines. For a detailed discussion of this statistics in terms of testing, you can refer to Baruch Sadogursky's keynote at another one of our conferences, Heisenbug.
'When there is no agreement among comrades,
Their business will not go well,
It will yield not a deed, only suffering.
Once upon a time, the Swan, the Crab, and the Pike...'
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.
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.
Vicious circle
So where did the discipline of āDevOps engineeringā 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.
Imagine this: yesterday you were flipping shawarma in Khimki, and today youāre a senior recruiter. Thereās a whole process of searching and selecting candidates, and itās not simple, you need to understand it. Letās say the department head says: find a specialist in X. We add the word āengineerā to X, and itās done. Need Linux? Well, thatās definitely a Linux engineer; want DevOps? Then itās 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ā'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.
Thus, a meaningless and ruthless image of some super-hero āDevOpsā has taken root in people's minds, someone who will set up everyoneās 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ās a trendy word; the keywords are the same, they should bite.'
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ās 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 ā what has happened is what has happened.
So, we have demand and supply. A closed loop that feeds itself. This is what we are fighting against (including creating the DevOops conference).
Certainly, besides sysadmins who have rebranded themselves as 'DevOps', there are other participants ā such as professional SREs or Infrastructure-as-Code developers.
What People Actually Do in DevOps
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āt the way.
If there is work, someone has to do it. Weāve already figured out that itās 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.
Firstly, you can engage with the very heart of DevOps ā 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 :
āCulture is shaped by the core values of the organization. People usually donāt 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ās happening. We call it the 'scent'. Sometimes this scent is really good. Sometimes it makes you feel nauseous. (ā¦) 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.'
There is certainly a technical aspect to the question. If your new code arrives for testing in a month, but the release doesnāt 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ās 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:
- Improving collaboration between roles and departments
- Accepting mistakes as an integral part of work
- Gradual implementation of changes
- Utilizing tooling and other automation
- Measuring everything that can be measured
This is not just some set of statements, but a concrete . For example, on the path to accepting mistakes, you'll need to address risks, measure the availability and unavailability of services using something like SLI () and SLO (), learn to write postmortems, and ensure that it isnāt daunting to do so.
In the discipline of SRE, the use of tools is just one part of success, though an important one. We need to continually develop technically, keeping an eye on whatās happening in the world and how we can apply it to our work.
In turn, Cloud Native solutions have become very popular. According to the modern understanding of the Cloud Native Computing Foundation, Cloud Native technologies enable organizations to develop and deploy scalable applications in today's dynamic environments, such as public, private, and hybrid clouds. Examples include containers, service meshes, microservices, immutable infrastructure, and declarative APIs. All these techniques allow loosely coupled systems to remain elastic, manageable, and well-observed. Good automation enables engineers to make significant changes frequently with predictable results, without turning it into a painstaking ordeal. All this is supported by a stack of well-known tools like Docker and Kubernetes.
This rather complex and extensive definition relates to the fact that the field itself is quite complex. On one hand, it is stated that new changes to this system should be added fairly easily. On the other hand, to understand how to create a containerized environment in which loosely coupled services live on software-defined infrastructure and are delivered there through continuous CI/CD, and to build DevOps practices around it ā one must have considerable experience.
What to do with all this
Everyone solves these problems in their own way: for example, one can post regular job vacancies to break the vicious cycle. One can figure out what terms like DevOps and Cloud Native mean and use them correctly and purposefully. One can develop in DevOps and demonstrate the right approaches by example.
We are organizing a conference , which provides an opportunity to delve deeper into the topics we just discussed. There will be several groups of presentations for this purpose:
- Processes and Culture;
- Site Reliability Engineering;
- Cloud Native;
How to choose where to go? Thereās a subtle point here. On one hand, DevOps is about interaction, and we really want you to attend talks from different areas. On the other hand, if you are a development manager attending the conference to focus on a specific task, no one is stopping you ā clearly, that would be the block on processes and culture. Remember, after the conference, you will have recordings (after filling out the feedback form), so you can always watch the less important talks later.
Itās obvious that at the conference, you canāt attend three tracks at once, so we structure the program to ensure there are topics for every taste in each time slot.
You just need to figure out what to do if you are a DevOps engineer! First, try to determine what exactly you do. This term is usually used to refer to:
- Developers who work with infrastructure. You will find the groups of talks on SRE and Cloud Native most suitable for you.
- System administrators. This is more complex. DevOops is not about system administration. Fortunately, there are many excellent conferences, books, articles, videos online, etc. on system administration. On the other hand, if you are interested in developing your understanding of culture and processes, learning about cloud technologies, and the details of life with Cloud Native, we would be happy to see you! Consider this: if you are doing administration, what will you do next? To avoid finding yourself in an unpleasant situation suddenly, itās worth learning now.
Thereās another option: you persist and continue to claim that you are a DevOps engineer and nothing else, whatever that means. Then we regret to inform you, DevOops is not a conference for DevOps engineers!
Slide from in Munich
DevOops 2020 Moscow will take place on April 29-30 in Moscow, tickets are already available .
Additionally, you can by February 8. Please note that when filling out the form, you must select the target audience that would benefit the most from your presentation (thereās a surprise hidden in the list).
Source: habr.com
