IT Language of DevOps engineers

— I have been in DevOps for more than seven years. Prior to that, I worked in various positions in the field of networking technologies for five years, before I realized that there wasn't much growth in the networking aspect. Since December 2021, I have been working at Naviteq as a team lead specialist who handles projects and also interacts with clients, sells services, prepares architecture, and so on.

In addition, I have a hobby — I enjoy sharing knowledge. My friends and I have a podcast called DevOps Kitchen Talks, where we discuss DevOps topics and try to make them understandable for everyone — from juniors to technical professionals who may not be familiar with a particular domain area.

What is DevOps?

— I like my colleague Victor’s encyclopedic explanation of what DevOps is. Now, I will share my own perspective. When we have a basic understanding of what happens in tech companies, and we hear a reference to DevOps, we roughly understand that they are the people responsible for the infrastructure and automation to make everything run smoothly and efficiently. That's one point of view.

People outside of tech have no idea what DevOps engineers are. I still can't make my relatives and some friends understand what I do.

The business perspective on DevOps is unique. Clients come in who may not understand the technical side of the position, but they have heard that DevOps can solve their business problems. These clients and customers have a distorted view of DevOps. They think it's a "silver bullet"; that a DevOps engineer can fix everything. But that's not the reality.

To begin, it is important to understand that DevOps is not a specific technology or tool. It's hundreds of tools and dozens of different approaches. Most importantly, DevOps is about communication. Its goal is to help departments collaborate through negotiations and automation that reduces the need for those negotiations. This includes automating everything that the business ultimately needs to simplify and accelerate the work of teams involved in product development. This perspective is very interesting to me.

In classical terms, DevOps is a combination of approaches, patterns, processes that are established, and technologies that are implemented, to solve specific technical and process-related problems and accelerate the delivery of a final software product to customers. That's the general idea. If we break down DevOps into parts, "Dev" stands for development, and "Ops" stands for operations. Together, DevOps sits in the middle.

The novel "The Phoenix Project" precisely addresses issues related to DevOps. To summarize, there are developers and there are those who are necessary to deploy what developers create so that end-user clients can access it. The teams involved in development constantly pass tasks back and forth, blaming each other. DevOps is needed to optimize the communication between them by implementing processes and technologies that minimize and automate it. Generally speaking, DevOps implements a proper ticketing process (tasks) in a system like Jira. Or it implements an optimized pipeline that allows developers to automatically test their work and, if necessary, pass it on for testing, as well as conduct an automatic quality assessment and produce a finished solution that will be deployed somewhere.

DevOps is something of a buzzword today. Not everyone understands what it means, but everyone has heard of it, and representatives from different industries may define it very differently. Each of them might be right in their own way. Various subdivisions have started to emerge within the profession: DevSecOps, MLOps, AIOps, and so on. There are many different abbreviations that represent specialized domains, approaches, and techniques being implemented. Under the hood, however, it's the same people who understand operating systems, have knowledge of networking, can write code, and are familiar with tools specific to the DevOps world.

Prospects for the DevOps profession

— In my opinion, DevOps is still the most complex and least understood specialization. It encompasses a wide range of concepts. If you doubt this, just look at the classifications of DevOps engineers in large companies. Therefore, DevOps requires constant learning and keeping up with trends.

The profession is very promising. In my experience, there are still many clients at a relatively low level of automation. With those clients, everything is done hastily, processes are not streamlined, and there is a lot of work that could be done in the DevOps area. In addition, since the start of the COVID-19 pandemic and the boom in IT projects, the number of cloud providers has expanded tremendously. More and more clients are migrating between clouds to optimize costs. Everyone is trying to find ways to save money. As a result, there are many projects for which only DevOps specialists can implement the necessary automation solutions in the cloud. The profession continues to be ranked highly in many forecasts, and it is not now at risk of being displaced by technologies like ChatGPT.

I really enjoy this profession for the simple reason that I can constantly learn something new. This is simultaneously a plus and a minus. All clients and requests may begin to seem similar — "we are building the same castle with different building blocks." This makes sense because in the end, all clients want to accelerate their code delivery, reduce the number of errors, optimize costs, and pay less for infrastructure that performs better. By implementing certain technologies, stacks, and more, DevOps ultimately delivers a "building" to them. On one hand, it can sometimes be tedious to discuss and propose the same things repeatedly. On the other hand, with repetition comes expertise and each project and stack do have their own unique context.

Currently, the biggest anti-pattern is maintaining separate DevOps teams. In my opinion, it's misguided to have a DevOps team as an autonomous unit working solely within a DevOps department. DevOps is about communication. DevOps engineers should intensively collaborate with development and testing teams.

How to understand DevOps engineers better

— Whether you work directly with DevOps engineers, or not, you may hear certain key abbreviations and words used during meetings or calls that can be confusing if you are not familiar with them. I have identified the following terms that a novice DevOps engineer, or someone aspiring to enter the profession, should be familiar with:

1. CI/CD (Continuous Integration and Continuous Delivery or Continuous Deployment) — this is a continuous automated process of delivering software code from idea to end customers. It involves pipelines where developers write code, push it to version control, and where various "under the hood" actions take place, such as code compilation, testing, and interaction with other departments. Ultimately, the piece of code becomes accessible to end customers. Key metrics for evaluating CI/CD quality include lead time, which measures the time it takes from idea to customer delivery. CI/CD is undoubtedly present in any DevOps-related project, except for very specialized cases that deal solely with infrastructure, and even then CI/CD is likely involved to some extent.
2. Cloud — everyone has heard about cloud computing and cloud technologies. Generally, at this point in time, we don't rely on a physical server located in our basement. Instead, we pay someone who stores and manages servers in large quantities. For example, if we want a certain number of CPU cores and memory from a large server to deploy our website, we pay for and are given a virtual slice of that resource to use. Today, there are key vendors in the international market, such as Amazon Web Services, Microsoft, Google Cloud Platform, as well as other emerging players like Oracle, IBM, and so on. Additionally, some clients build their own private clouds. What does that mean? They have a server infrastructure, and they deliver resource slices to their internal clients and departments. The infrastructure is maintained by their own dedicated team. Generally speaking, a user doesn’t need to think about where the server is located; for them, it's just an entry point to the program where everything works.
3. Configuration management — a class of tools that permit the desired state of a system to be described using declarative language. For example, if we need to install software on a computer, such as a program or a browser, we can do that manually. If, however, we uninstall that program, we would need to remember how we initially installed it if we want to reinstall it again. Configuration management allows us to describe the necessary steps for installing software in a human-readable language, which is then transformed into actual commands by software tools on the operating system. DevOps engineers do this to ensure quick recovery in case of manual changes and to facilitate rapid updating of configurations across hundreds or thousands of servers.
4. Infrastructure as Code — similar to the previous point in that we describe servers using declarative language. For example, we state that we want two virtual machines in the cloud. We write the text structure according to the documentation and, with the help of tools like Terraform, the entities are automatically created in the cloud through specific APIs. We can also quickly modify and update them without having to click through interfaces. DevOps engineers do not like clicking around with a mouse. If an operation is performed more than once, DevOps will likely want to automate it to avoid errors and ensure efficiency.
5. Alert — the most disliked word for a DevOps specialist. An alert means that the DevOps engineer needs to investigate and fix something that is not functioning properly. Maintaining a high-quality and constantly operational solution built under the DevOps approach always includes monitoring. Monitoring is not just about capturing system metrics; it should also track negative changes. If something undesirable occurs, we receive an alert. For example, if someone accidentally deletes our virtual machine, we receive an alert. If someone accidentally exposes an internal IP address on the internet and someone else tries to exploit it, we receive many alerts.
6. SRE (Site Reliability Engineering) — a process initially described by Google, where engineers using SRE approaches are heavily involved in ensuring the reliability of an application. If something goes wrong with an application, they are the first to investigate and resolve the issue. They monitor specific metrics and strive to minimize the number of alerts. It is challenging to distinguish between SRE and DevOps. Some people performing very similar functions identify themselves as SRE, others as DevOps. Essentially, they perform the same work. The only difference is that SREs are expected to have more programming skills than DevOps. If something happens with the system, an SRE can go into the code and fix the error themselves.
7. SLA (Service Level Agreement) — SREs love this term. It represents a numerical value pertaining to a specific system characteristic. For example, we might state that our system will be available to the customer for 95% of the total time in a year. This means we guarantee that our system will be unavailable only 5% of the time throughout the year. Both parties sign the agreement, and it forms the basis of the contract. SREs are responsible for creating and monitoring adherence to such metrics.
8. Script — typically a text document that, using a programming language or a script language like Bash, enables the execution of a series of manual commands in an automated manner. It is used to automate tasks that were previously performed manually and to avoid repeating them in the future. Scripts are usually lightweight and intended for straightforward tasks that need to be automated. For example, if we need to go to a server once a month and delete unnecessary files to free up some disk space, we won't do it manually each time. Instead, we will write a script that will automatically perform this task for us.

Find the best IT profession for you and study the slang associated with it:

• IT language of the Tester
• IT language of the Business Analyst
• IT language of Data Analysts
• IT language of UI/UX Designer