DevOps is a young field at the intersection of development and system administration. It appeared only in the 2000s, but even now no major project is unthinkable without it.
DevOps is a young field at the intersection of development and system administration. It appeared only in the 2000s, but even now no major project is unthinkable without it.
DevOps is not just a set of tools, methods and practices, but a whole movement that helps developers, operations engineers, monitoring and support services to find a common language and launch projects from the beginning to the end.
About the beginning of my career path
While still a student, I started working in the call-center of an ISP as a technical support specialist. There I realized that the work in the technical support though fun, but not very interesting. After college I got a job as a system administrator. I supported users, servers, routers and other hardware. Nowadays it is called a fancy combination: full-stack-admin.
I have been a sysadmin for about seven years now. I managed to gain experience working with helpdesk-departments, went as far as designing and implementing my own architecture, optimized IT-infrastructure in companies, recruited and trained people for the formation of the 1st-3rd lines of technical support.
At some point I heard the new word DevOps. A year and a half of intensive self-study followed. And I became a devops engineer. Now I supervise the work of specialists in the group of automating the processes of developing digital solutions. We are engaged in automation of software delivery to the testing, production and so on. We develop DevOps-practices, make things better and more comfortable for everyone.
What makes good DevOps engineers?
There’s a joking definition that DevOps is a sysadmin on steroids. The path to DevOps is well formed when you already have extensive knowledge of the infrastructure, experience with the architecture of the company as a whole – where and which solutions are best to use both at the software and hardware level, when it’s better on premise, when it is worth looking at the public cloud, when it is better to use good old SQL, and where it makes sense to use modern noSQL databases, when rabbit / Kafka will be useful and not harmful, when it is better to use a small script on bash, and when it is “use Ansible”, when iops, inode and other terms are not empty words.
It’s not necessarily the case that DevOps grows out of sysadmins. Another way is to get out of development. For example, a person goes to work as a software developer, but later understands for some reason that it does not suit him very well, he is attracted to infrastructure and debug related to infra. The ideal choice in this situation is to move from development to DevOps/SRE.
But you have to understand that it’s hard, sometimes even impossible, to describe with some specific tasks a specialist working on DevOps practices in a company. In one project or stream, an expert will conditionally create a pipeline of delivery of microservices to testing and production servers without going into details of what kind of microservices and what software is used for them. And in the neighboring stream DevOps will be deploying legacy code and databases, determining which tables are needed in the database, which legacy application with which can stand on the same server, and which can’t. In the third, a specialist will code the infrastructure, taking care of the reliability and performance of the systems as a whole. The level of abstraction and product immersion can be diametrically opposed from project to project.
To work with DevOps practices, you need to feel free to work within the containerization ideology, understand it not as the only docker containers, but also understand other systems: Linux Containers, Podman and so on. Podman is slowly coming to the forefront, but in general it is very similar to Docker.
Next, master orchestration with Kubernetes alternatives: Docker Swarm, Rancher, Nomad, and OpenShift. OpenShift is a paid solution from Red Hat, based on k8s with nice and handy bonuses from RedHat, second most popular after Kubernetes.
What gradation do DevOps engineers have
Junes should know Linux. At least superficial knowledge of kernel, confident working with the command line, SELinux system and iptables utility.
From the tools you have to learn Docker, Kubernetes, Ansible, Helm, Git, Zabbix, ELK, Nexus, Prometheus and Grafana. For databases, it’s a good idea to learn MySQL, PostgreSQL, Microsoft SQL Server.
Middles should be able to do anything with a Linux server or virtual machine at the snap of their fingers. For example, run commands remotely, correctly assign rights to users, configure policies on SELinux and filters in iptables, write automation scripts, break everything and fix it quickly.
Senor will be different in scale. He is not looking at an individual machine, but at the IT infrastructure as a whole. It solves problems of the level of “how to raise and configure the environment with Ansible and Terraform”, “how to configure integration with related systems and take into account all the nuances of implementation.
