How to start learning DevOps?
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 own 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:
- Write software
- Build it
- 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.
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.
You need to create CI/CD pipeline with two backend APIs written in Java and 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
This is a simple case scenario. You could have a job with the LoadBalancing, Scaling, Container orchestration, etc.
Few examples of the infrastructure problems are given below.
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:
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.
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.
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 to qdnqn and learn about when new useful posts are published.