What does it take for an IT company to succeed in 2019? Speakers at conferences and meetups use many loud and not always comprehensible terms for regular people. The battle for deployment time, microservices, abandoning monoliths, DevOps transformation, and so much more. If we set aside the verbal beauty and speak plainly, it boils down to a simple thesis: create a quality product, and do so comfortably for the team.
The latter has become critically important. Businesses have finally come to the realization that a comfortable development process increases productivity, and if everything is fine-tuned and runs like clockwork, it also provides some room for maneuver in critical situations. At one time, for the sake of this maneuver, a wise individual invented backups, but the industry has evolved, and we have arrived at DevOps engineers ā people who turn the interaction process between development and external infrastructure into something reasonable and unrelated to shamanism.
All this talk about 'by modules' is wonderful, but... It just so happened that some admins were abruptly dubbed DevOps, while DevOps engineers are now expected to possess, at the very least, telepathy and clairvoyance skills.
Before discussing the modern issues of infrastructure provision, let's clarify what we mean by this term. At this point, the situation has developed in such a way that we have arrived at the duality of this concept: infrastructure can be conditionally external and conditionally internal.
By external infrastructure, we mean everything that ensures the operation of the service or product being developed by the team. This includes application or website servers, hosting and other services that ensure the product's operability.
Internal infrastructure includes services and equipment used by the development team itself and other employees, who are usually quite numerous as well. This includes internal servers for code storage, locally deployed task managers, and everything else that exists within the corporate intranet.
What does a system administrator do in a company? Aside from managing the corporate intranet, they often handle various logistical concerns to ensure the office equipment is operational. The admin is that one person who quickly grabs a new workstation or a ready-to-use spare laptop from the storeroom, hands out a fresh keyboard, and crawls around the office pulling Ethernet cables. The admin is the local master and ruler not just of the internal and external systems, servers, but also of the office equipment. Yes, some administrators may only work in a systems capacity, without dealing with hardware. They should be distinguished as a separate subclass of 'infrastructure system administrators.' Others specialize exclusively in maintaining office equipment, especially if the company has more than a hundred employees, as the work never truly ends. However, neither of them can be classified as DevOps.
So, who are DevOps? DevOps professionals are the ones who focus on the interaction between software development and external infrastructure. More specifically, modern DevOps are involved in the development and deployment processes much more deeply than administrators ever were, who merely uploaded updates via FTP. One of the key tasks of a DevOps engineer today is to ensure a comfortable and efficiently managed interaction process between development teams and product infrastructure. These individuals are responsible for deploying rollback and deployment systems; they alleviate some of the workload from developers and focus intensely on their critically important task. At the same time, a DevOps professional will never pull new cable or hand out a new laptop from storage (c) KO.
What's the catch?
When asked, "Who is a DevOps specialist?" half of the professionals in the field start responding with something like, "Well, it's basically an admin who..." and continue from there. Yes, a long time ago, when the profession of DevOps engineer was just emerging from the most talented service-admins, the differences between them were not obvious to everyone. But now, when the roles of a DevOps engineer and an admin in a team have become radically different, confusing them or equating them is unacceptable.
But what does it mean for the business?
It's all about hiring.
You open a job posting for a "System Administrator," and it lists requirements like "collaboration with development and clients," "CI/CD delivery system," "maintenance of company servers and equipment," "administration of internal systems," and so on; you realize that the employer is talking nonsense. The catch is that instead of "System Administrator," the job title should actually be "DevOps Engineer," and if you change the title, everything falls into place.
However, what impression does such a job posting create? That the company is looking for a jack-of-all-trades who can set up version control and monitoring systems and chew through tasksā¦
And to avoid raising the level of confusion in the job market, it's enough to call job titles by their proper names and clearly understand that a DevOps engineer and a system administrator are two different entities. Yet, the insatiable desire of some employers to present a broader list of requirements leads to the understanding that "classic" system administrators no longer grasp what is happening around them. Has the profession mutated, and have they fallen behind?
No, no, and no again. Infrastructure admins who will manage the company's internal servers or occupy L2/L3 support positions to assist other employees are not going anywhere and have no intention of disappearing.
Can these specialists become DevOps engineers? Of course, they can. In fact, it's a related environment that requires system administration skills, but in addition, it involves working with monitoring, delivery systems, and overall close collaboration with the development and testing teams.
Another problem of DevOps
In fact, it's not just about hiring and the ongoing confusion between admins and DevOps teams. At some point, the business faced issues with delivering updates and the interaction between the development team and the end infrastructure.
Perhaps it was when an uncle with sparkling eyes took the stage at some conference and said, "We do it this way and call it DevOps. These guys will solve all your problems" ā and began to explain how great life is in a company after implementing DevOps practices.
However, it is not enough to hire a DevOps engineer for everything to work "as it should." The company must undergo a complete DevOps transformation, meaning that the role and capabilities of our DevOps must also be clearly understood by the development and product testing teams. We have a "wonderful" story on this topic that fully illustrates the sometimes chaotic nature of what is happening.
The situation is as follows. The DevOps team is asked to implement a version rollback system without much insight into how it should function. Letās assume that within the system, the Users consist of separate fields for first name, last name, and password. A new version of the product is released, but for the developers, a rollback is simply a magic wand that fixes everything, and they have no idea how it works. For instance, in a recent patch, the developers combined the first name and last name fields and pushed it to production, but for some reason, the version is lagging. What happens next? Management approaches the DevOps engineer and says, "Pull the switch!" meaning they want to revert to the previous version. What does the DevOps engineer do? He rolls back to the previous version, but since the developers didnāt bother to understand how the rollback is performed, no one informed him that the database also needed to be reverted. As a result, everything crashes, and users see a "500" error instead of a lagging site because the old version is incompatible with the new database fields. The DevOps engineer is unaware of this. The developers are silent. Management starts losing patience and money, recalling backups and suggesting rolling back from them to "get something working." Consequently, users lose all their data for a certain period.
Of course, the DevOps engineer gets blamed for not creating the proper rollback system, while the developers, who are at fault in this scenario, go unpunished.
The conclusion is straightforward: without a proper approach to DevOps, its value is significantly diminished.
The main thing to remember is that a DevOps engineer is not a magician, and without quality communication and two-way interaction with the development team, he will struggle to fulfill his responsibilities. DevOps engineers cannot be left alone with their "problems" or given the order to "stay out of the developers' way; their job is to code," and then hope that everything will work perfectly in a critical moment. Thatās not how it works.
Essentially, DevOps is a set of competencies at the intersection of management and technology. Moreover, it is far from obvious that there should be more technology than management in this mix. If you truly want to build faster and more effective development processes, you need to trust your DevOps professional. They know the right tools, they have executed similar projects, and they know how to do it. Help them, listen to their advice, and donāt try to isolate them into a separate department. While admins can work independently, DevOps professionals become useless in such scenarios; they won't be able to help you improve if you arenāt open to receiving that help.
And lastly, stop belittling system administrators and infrastructure engineers. They have their own, extremely important area of work. Yes, an admin can become a DevOps engineer, but that transition should happen out of their own desire, not by pressure. Thereās nothing wrong with a system administrator wanting to remain a system administrator; itās their distinct profession and their right. However, if there is a desire for professional transformation, itās crucial to remember that not only technological skills will need to be developed, but managerial ones as well. You will likely be the one who needs to bring all these people together and teach them to communicate in the same language.
Source: habr.com
