DevOps engineer everyday life

In the first post of the series, we've looked over the theory part of the DevOps world. Since we're familiar with the terms we can dive deeper this time. So where are the goodies? Let's try to answer a few questions you may be having.

What is expected from the DevOps engineer?

DevOps engineers are wearing many hats. Different companies evaluate the term from their standpoint but in a nutshell:

• The understanding of the software development cycle
• Being able to read, understand, and build source code
• Automation of the processes
• The knowledge about infrastructure platform

• The knowledge about observability
• Debugging the software problems

The divider is intentionally there. Points after divider are going more in the SRE field but often this is the requirement of the job.

The understanding of the software development lifecycle

The process from writing software source code to running it in production is an ecosystem for itself. If you were thinking about the process, something like this:

1. Write software
2. Build it
3. Run it

Well, let me shatter your dream - it's not that simple.

Building great tools takes many people to build. One man cannot build an airplane. Same in software development you need more people to build great tools. When you have many people working together you need a system in place so that everyone can contribute.

The people part (the way I call management) of the process is handled by the POs/PMs. Delivering a small part of the problems to the engineers which can be later assembled into one functionality.

The technical part on the other hand is having the next challenges:

• Branching strategy
• Versioning strategy/Release strategy
• Build and deployment

Basically what you want is next:

Software engineers work without colliding code using a specific branch strategy and the software is versioned and deployed to the proper environment and work can continue in a loop without affecting any other already working part.

DevOps engineers can affect every aspect of this process using automation and enabling that work can continue easily. In the next part, we will discuss these three topics mentioned above.

Being able to read, understand, and build source code

It's the most helpful asset you can have. Various projects use different technology stacks so you will meet different languages, package managers, compilers, parsers, configuration patterns, etc.

To manage your time and to be good at your job this is the most important skill you will need.

Real-world tasks:

You need to create a CI/CD pipeline with two backend APIs written in Java and a React frontend app. Create an automated pipeline for building everything and deploying to 2 environments.

You need to know how to configure the backends and frontend. Also, you need to understand how configuration is externalized.

When you know that you can easily configure it and prepare everything so that the build process is working locally and on the pipeline. Also, configuration needs to work on the two environments without a problem.

Don't let the simple requirements fool you. There is a lot in the background. If you can navigate yourself easily in the source code this task becomes much more simpler.

Automation of the processes

Automation. Automation. Automation. We've heard it already. But what is behind this? As we saw in the previous section real-world examples. Pipelines are one aspect of automation. But let us use that one.

For example, if you have 5 environments instead of 2 - automation becomes a necessity. Why?

Including the whole SDLC and CI/CD process, it would be almost impossible to manage everything using hands without many errors.

Apart from the pipelines, infrastructure also needs to be automated. You don't want to manually create an environment when it's needed. You want this automated. Why? It is error-prone and environments will look the same. We will talk about the infrastructure in the part.

Beware: Good automation takes a burden from the team not introducing it.

The knowledge about infrastructure platform

Build software needs to be running somewhere. We have various platforms today. Containers, Kubernetes, Openshift, PaaS solutions, Serverless solutions, On-Prem Cloud, Public cloud providers, and Virtual Machines.

To configure the software to interact with the infrastructure it's running on - you need to know that infrastructure.

For example, software needs to get secret credentials and connect to the database running on the same infrastructure. The database is in a private network but the software is exposed to the public.

So your task is to configure the infrastructure to handle the

• Storing and getting secret credentials
• Network segmentation
• Routing

This is a simple case scenario. You could have a job with the LoadBalancing, Scaling, Container orchestration, etc.

A few examples of the infrastructure problems are given below.

Traffic engineering with Traefik on k3s distribution of Kubernetes

Traefik is one of the most popular ingress controllers on Kubernetes. Traefik v2 brought some major changes in the usage of the controller itself. It brought the approach of heavy usage of Custom Resources on Kubernetes to provide reconfigurability and expanded fields of operation apart from the Ing…

qdnqnAdnan Selimovic

Networking on Kubernetes with Calico and eBPF

Kubernetes networking is a complex topic. There are multiple layers present — from the containers to the underlying infrastructure. Let’s dig in. Kubernetes defined the network model and the network drivers are implementations of that model. In that way, you can have multiple network drivers implem…

qdnqnAdnan Selimovic

The knowledge about observability

Observability gained traction in the open cloud foundation. It's a good signal that it is an important aspect of the system. System observability is defined by the:

• Metrics
• Logs
• Traces

These three will make your life easier when running software that is used by end-users in production. Why? Triangulation and finding out the root cause of the problem is much simplified when you have a good UI and can easily access all the information you can.

DevOps engineers should affect the process by deploying proper tools, introducing new concepts and ideas to the team, and automating this process.

For example, blog post below describes how tracing can help.

OpenTelemetry, Spring Boot, Kafka and Jaeger in action

Finding the root cause of problems in the software is a pretty complex topic. With distributed systems, another layer of the ultimate complexity, the problem becomes harder to solve. To make a distributed system more observable, one needs to implement proper tracing, apart from logging and metrics.…

qdnqnAdnan Selimovic

Debugging the software

Often when software is deployed on the environment initially or when a new feature is delivered it causes malfunctions. Finding out the root cause needs cross-team effort. It can be malfunctioning software or misconfiguration.

DevOps engineers should effectively find this kind of problem.

For example, the post below describes the process of debugging on Kubernetes and shows in more detail this aspect of the job.

Debugging on Kubernetes

Even with the best designs, patterns, and processes implemented, there is a tendency for errors to show up and crash the party. If you are coming from another field or just starting up with Kubernetes - there would be needed effort and time to pass so that the shift in

qdnqnAdnan Selimovic

In short: these points are the most important part of the job. It's a cross-over of Software engineering and infrastructure engineering.

If you are interested in this field or you are a newcomer feel free to subscribe and learn about when new useful posts are published.