What is needed for the success of an IT company in 2019? Lecturers at conferences and meet-ups say a lot of loud and not always clear words about it. The struggle for the deployment, microservices, the rejection of the monolith, DevOps transformation and much, much more. If you discard verbal beauty and speak directly, it all comes down to a simple thesis: make a quality product, and do it with comfort for the team.
The latter has become critically important. Business finally came to the conclusion that a comfortable development process improves productivity, and if everything is debugged and works like clockwork, it also gives some space for maneuver in critical situations. Once, for such maneuver, some smart person invented backups, but the industry is developing, and we came to DevOps engineers – people who turn the process of interaction between development and external infrastructure into something adequate and not related to magic.
The whole story about it is in general beautiful, but … It happened so that part of the system admins were called DevOps and the DevOps engineers themselves began to require at least telepathy skills.
Before talking about the modern problems of providing infrastructure, let’s decide what we mean by this term. Nowdays, the situation has developed in such a way that we have reached the duality of this concept: infrastructure can be conditionally external and conditionally internal.
An external infrastructure should mean everything that ensures the serviceability of a service or product that the team is developing. These are application or site servers, hosting and other services that ensure the product’s performance.
The internal infrastructure includes services and equipment used by the development team itself and usually a lot of other employees. These are internal servers of code storage systems, a locally deployed task manager and everything-everything-everything that exists within the corporate intranet.
What does the system administrator do in the company? In addition to administering this corporate intranet itself, he is often responsible of economic worries to ensure the availability of office equipment. The admin is the same guy who quickly drags a new system unit out of the back room or a spare laptop ready for work, gives out a fresh keyboard and crawls on the floor around the offices, stretching out the Ethernet cable. Admin is a local master and master of not only internal and external servers, but also a business executive. Yes, some administrators can work only in the system plane, without hardware. They should be distinguished in a separate subclass of “infrastructure system administrators.” And someone specializes in servicing exclusively office equipment, fortunately, if the company has more than a hundred people, the work never ends. But they all are not DevOps.
And who are DevOps? Devops are guys who are talking about the interaction of software development with external infrastructure. More precisely, modern DevOps are involved in the development and deployment processes much deeper than were ever involved the administrators who simply flooded updates on ftp.
One of the key tasks of the DevOps engineer now is to ensure a comfortable and efficiently built process of interaction between development teams and the product infrastructure.
It is these people who are responsible for deploying rollback and deployment systems, who take part of the load off developers and concentrate as much as possible on their extremely important task. In this case, the DevOps will never stretch a new cable or give out a new laptop from the back room.
How come?
To the question “Who is DevOps?” half of the sphere’s employees begin to answer something like “Well, this is, in short, such an admin who …” and so on. Yes, once upon a time, when the profession of DevOps engineer was only just making out of the most talented administrators in terms of servicing, the differences between them were not obvious to everyone. But now, when the functions of the DevOps and admin in the team began to radically differ, confusing them among themselves, or even putting an equal sign between them, is unacceptable.
But what does it mean for business?
Hiring, it’s all about it.
You open the vacancy “System Administrator”, and there are listed the requirements “interaction with development and customers”, “CI / CD delivery system”, “servicing the company’s servers and equipment”, “administering of internal systems” and so on; you understand that the employer is saying some nonsense. The main point that instead of “System Administrator” in the title of the vacancy should be “DevOps engineer”, and if this title is changed, then everything comes to the right place.
However, which impression you have while reading such a vacancy? That the company is looking for a multi-tool operator, which will deploy both a version control and monitoring system and connect needed cables and so on, so on.
But in order to well explain the need of business on market, it is enough to call the vacancies by their proper names and clearly understand that the DevOps engineer and system administrator are two different persons. The only irrepressible desire of some employers to present to the candidate the widest possible list of requirements leads to the fact that the “classical” system administrators cease to understand what is happening around them. What, the profession changed and they lag behind life?
No, no and one more time no. Infrastructure administrators who will manage the company’s internal servers or occupy the positions of L2 / L3 support and help other employees, have not gone anywhere and are not going to disappear.
Can these specialists become DevOps engineers? Of course they can. In fact, this is their native environment, which requires system administration skills, but in addition, work with monitoring, delivery systems and, in general, is added tight interaction with the development and testing team.
Another DevOps Problem
In fact, everything is not limited just in hiring and constant confusion between administrators and DevOps. At some point, the business was faced with the problem of delivering updates and the interaction of the development team with the final infrastructure.
Perhaps this was when an uncle with exited face came to the scene of a conference and said, “And we are doing this and call it DevOps. These guys will solve all your problems”- and began to tell how well he lives in the company after the implementation of DevOps practices.
However, it’s not enough to hire a DevOps engineer to make things work as they should.
The company must completely go through the DevOps transformation, it means, the role and capabilities of our DevOps should be clearly understandable for the product development and testing team. We have a “beautiful” story about this subject, which fully illustrates the reality.
Situation. DevOps are required to deploy a version rollback system, without particularly understand how it will work. Let’s imagine, inside the Users system, these are separate fields under the first name, last name and password. A new version of the product is released, but for developers, “rollback” is just a magic wand that will fix everything, and they don’t even know how it works. So, for example, the developers in the next patch combined the first and last name fields, rolled it out into the productions, and the version slows down for some reason. What’s happening? The manual comes to the DevOps and says “Bring it back!” What does DevOps do? He rolls back to the previous version, but since the developers didn’t want to understand how this rollback is done, no one told the DevOps that it was also necessary to roll back the database. As a result, falls down everything, and instead of a slowing down site, users see the error “500”, because the old version doesn’t work with the fields of the new database. DevOps doesn’t know anything about it. Developers are silent. The management begins to lose nerves and money, thinks of backups, offering to roll back to them to make “at least something works”. As a result, users lose all their data for some period of time.
The problem came, of course, because DevOps, who “didn’t make the right rollback system,” and the fact that the real reason in this story are developers doesn’t bother anyone.
The conclusion is simple: without a normal approach to DevOps, there is not much benefits from it.
The main thing to remember: DevOps engineer is not a magician, and without high-quality communications and two-way interaction with development, he will not be able to cope with his tasks. DevOps cannot be left alone with their “problems” or given the command “don’t go to developers, their business is code”, and then hope that at a critical moment everything will work as it should. It doesn’t.
Essentially, DevOps are competencies on the edge between management and technology. Moreover, it is far from obvious that in this cocktail there should be more technologies than management.
If you really want to build faster and more efficient development processes, you must trust your DevOps.
He knows the right tools, he has implemented similar projects, he knows how to do it. Help him, listen to his advice, don’t try to isolate in some autonomous department. If admins can work on their own, then DevOps are useless in this case, they will not be able to help you become better if you yourself don’t want to accept this help.
Well, the last thing: about infrastructure administrators. They have their own, extremely important field of work. Yes, the admin can become a DevOps engineer, but this should happen because of wish of the person himself, and not because of push of management. And there is nothing wrong with the fact that a system administrator wants to remain a system administrator – this is his separate profession and his right. If there is a desire to make a professional transformation, then we don’t have to forget that it will be necessary to build up not only technological skills, but also managerial ones. It’s most likely that you as a leader will have to bring all these people together and learn to communicate between each other in one language.