How to start learning DevOps?
What is the DevOps? (Theory part)
You can read every day about DevOps in almost every type of media. The term DevOps has become familiar now and is very established in the Job market. But the DevOps practices are still young and are evolving. Every company defines the DevOps roles, targets, and paths based on their perspective and needs.
If you ask different people about DevOps — you will probably get different answers. There are many articles defining their vision of DevOps but for the sake of the article, we will define it by ourselves, again.
DevOps is culture. Something like Agile. You have a manifesto and instructions on how you should do it — but every company implements the practices in their own way. Deviation is a common thing in the real world.
The main idea behind DevOps is: You build it, you own it. That’s pretty much it. Software engineers are responsible for the product they are building in the next areas:
- Creating the software
- Implementing an automated pipeline for software delivery a.k.a CI/CD
- Operating the software in the production and other environments
- Measurements of the key indicators for the software
- Interpreting measurements and acting on them to improve
Bam! You are practicing DevOps in your team.
As you can see that is a closed loop.
What was there before DevOps?
Short answer DevOps.
Long answer:
The tale old as there is time (or collaboration?) — Developers created software and handed over the complete solution to the Operations. So two separate departments.
After the Developers deliver the code with needed features, Operations would need then to operate on the complete product in production. Easier said than done. If you don’t consider the architecture and the infrastructure to run the software from the beginning it will create problems down the hill.
Also if you don’t know how software behaves and is written, you will have a fun time trying to operate it and understand the behaviors.
So like everybody is saying — a wall was placed between Dev and Ops.
To summarize here is the visualization.
Same as DevOps but much, much slower. What do you mean same as DevOps!? There was also automation, there was measuring, there was software development, and iterations — more like ping pong but still iterations.
Why was it slow? Inter-department communication is pretty slow because of procedures but human psychology plays its part also. If you don’t know the struggles of the other side, you don’t understand them, and you don’t care about them. I’ll do my job and that’s all I am gonna do.
In short: a bunch of problems were thrown over the wall in the ping-pong manner. Result: slow deliveries.
A new way of doing things
So to overcome the issues of old times, teams were created responsible for the software: from the beginning to the end. You create a team of software engineers who will own the software from the start to the end. In that way, the wall is broken and cooperation is enabled and very much easier. Result: things go faster.
If you know you will own the software to the end — you will take care of many more things than if that would be someone else problem.
People got better at collaboration, new tools emerged and philosophy shifted toward DevOps. The companies are still in transition to DevOps but I think it took over and will stay here for some time. Why? Because it works better.
What is a DevOps engineer then, eh?
DevOps engineer is a coined term for some time — imposed by the job market. And it is here to stay. It’s wrong to say it because — DevOps is culture. Anyhow learn to live with it. Okay, but what is a DevOps engineer job?
The intro talk was all about theory but in real world theory, things tend to be different. Software engineers/Developers still see operations as a hurdle and tend to their job of creating features. This is not a rule but it is a case, very often.
A lot of impact on the Job market had the emergence of a cloud. Cloud technologies are very diverse and it’s an ocean in itself. For one person to be an expert in software engineering and all of these emerging technologies is a heavy toll and rare case.
So the need for a person who is in touch with the cloud technologies, automation, and operations showed up. A gap needed to be filled. DevOps engineer comes to the rescue.
Basically what a DevOps engineer is doing is described above, not limited to — but often:
- Managing infrastructure and cloud technologies
- Automation
- Operations
Doing the three above is really hard if a DevOps engineer doesn’t:
- Understand the software product
- Know the architecture of the software product
- Know how to configure the software product
- Know how to build a software product
The more skilled the DevOps engineer is — the more contributions to different fields. So walking in the Software engineering part when needed, and walking in the Operations part when needed. The key is the right balance.
Cloud technologies are still evolving and CNCF is imposing standard tooling — the standard for the tooling/technologies needed to support usage, development, and taking advantage of cloud technologies.
To take advantage of the tools and patterns of emerging technologies DevOps engineers should know how to architect and influence the development of software products in terms of:
- Implementing Observability (Monitoring, Logging, and Tracing)
- Configuration management
- Build and release management
- Containerization
- Selecting the right tools for the job and binding them to software product
- Building internal tools
- Architecting software
Coding is a big part of the job. DevOps engineers shouldn’t implement the features but affect the product in terms where it makes sense. The list above is a good starting point.
Another categorization
New job terms emerged in the meantime — apart from the DevOps engineer:
- Platform Engineer
- SRE
- Cloud Engineer
SRE
SRE are engineers specialized in handling incidents and making production work flawlessly — in short. Quote from Google — as Google is the place where the term and SRE practices are born.
What is Site Reliability Engineering (SRE)?SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and capacity. — https://sre.google/
Cloud engineer
Cloud engineering is a specialization in cloud infrastructure.
Platform Engineer
Same with DevOps — different answers are out in the wild.
Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application- https://platformengineering.org/blog/what-is-platform-engineering
All of these three are overlapping at some points. Every position is a specialization born from DevOps practices.
Beware more unknown terms ahead (GitOps, FinOps…)
Naturally, when you start doing new things for some time, you get better at it and new things/results/practices/phenomena emerge from doing new practices.
GitOps is the one phenomenon talked about in the previous sentence.
GitOps is the idea that the state of the entity is defined in the Git repository and the current state of the entity is reconciled to the definition in the repository itself. Hence the name GitOps(Git; Operations). Pretty simple concept.
The entity could be (most often):
- Infrastructure
- Application
But It can be also, something else.
For example:
FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions. — https://www.finops.org/introduction/what-is-finops/
So many terms are floating around. Arranging and understanding them is the key to successfully navigating in this new world. For the newcomers, it can be scary and too much but with the right navigation, you will not get lost.
Summary
Now you should have a picture of a job done by DevOps engineers. This is part 1 of the series. In the next parts, we will focus on the learning paths, concrete tutorials, and advices.
If you are interested in the topic, have any advice/criticism, or have any questions feel free to hit me up on LinkedIn.
