How to Enter the World of DevOps: A Recipe for Beginners and Not So Beginners
Who 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 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. He is solving the problems 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.
Tips for beginners
It is important to understand how git tools, *nix systems, networks, databases work. Learning how code is built, what happens after the code is built, what role information security plays in software development is an additional area called DevSecOps.
I recommend books:
- “Kubernetes Patterns” by O’REILLY;
- “The Linux Bible” by Christopher Negus;
- Andrew Tanenbaum – he has tutorials on both networks and operating systems.
By the way, you can find a lot of lectures on DevOps on YouTube if you want. CEH courses on ethical hacking and various courses on Udemy are not out of place.
A good DevOps engineer in any situation must be able to find the most effective solutions, adapt to the situation and constantly look for points of improvement regardless of the tasks. It is important to have a flexible mind and a desire to do a great job every day.
And most importantly, communicate with people. DevOps is primarily an ideology, not a specialty. Only by uniting your colleagues around the task and helping them with automation tools you can achieve really good results. Without a great mood and a highly motivated team of professionals you can come up with a million techniques and scripts, but the result is always made by people united by a common goal!