Becoming a DevOps Engineer is not a trivial occasion, it requires some career planning and, while being very lucrative, is a very demanding, rapidly changing field of work, where extensive knowledge over a broad array of technologies is required.
I have been doing DevOps work for the last couple of years, and coming from a background in Microsoft-based IT System Administration, I thought I could guide other enthusiastic IT workers through this transition.
So, to celebrate me starting a new job at Dream, an AI-focused cybersecurity startup, I have decided to publish this post. We’ll go over both the soft skills and technical know-how you need to bring to the table, and I would like to to think about how these technologies and skills can be used to impact real-world scenarios.
I would also like to say that this is in no way a comprehensive list, nor am I trying to present myself as an all-knowing expert. My experience is my own, and if sharing my experience inspires people to make the switch – I did my job!
Soft Skills
There are many soft skills you should possess in order to be a good DevOps Engineer; Most of them are quite universal to office work in general and working in the tech sector itself. Therefore, I will be mostly focusing on the core soft skills in the heart of DevOps work.
Informal Leadership
Being a DevOps Engineer does not mean sitting in front of the computer and calling it a day, it’s a job that requires a lot of social interaction and architectural decisions. Taking those decisions is the easy part, but since your proposed architecture/CI/whatever else change has more stakeholders than your immediate teammates (in most cases, it’s the R&D folks), you’ll have to effectively communicate the changes, as clearly as possible, while eliminating friction.
Humans are averse to change, so this isn’t as easy as it looks, which is why a good DevOps Engineer needs to be able to explain concepts that might be foreign to others, and be a leader without having the title.
I can recall a few instances where I was required to perform breaking changes in a system in process R&D uses, and having to make sure everyone was aware of the changes and how they affect their work. For example – upgrading a major version of a dev-environment CLI tool, requiring the development teams to engage with it in a different way than they previously have.
Critical Thinking & Problem Solving
“Putting a bandage”, so to speak, is a very tempting solution to many of our problems (and I myself am guilty of doing that more than once), but eventually, the technical debt catches up to you. Sure, I could hardcode some non-sensitive value in a Terraform module or Helm chart, but the work I save myself now will come back to bite me when we have to scale in the future and now that very same “bandage” will cost me hours or even days of troubleshooting and/or refactoring. That’s why it’s important to always be able to weigh different approaches to a problem and choose a path to continue on.
Patience
If you’re looking for instant gains, working in DevOps might not be the field for you. DevOps is a process-centric role. You’re going to have to build and/or deploy complex systems, and constantly make the infrastructure more resilient, efficient, secure, and cheaper to run.
Those things don’t happen in a day, a week, or even a month. The benefits of your work will show themselves with time. I always say, “a DevOps Engineer’s role is to make himself redundant”. You basically want to automate most of your work as efficiently as possible, and that requires patience.
Feeling Comfortable Around Code
Being a DevOps Engineer will, most likely, require you to be able to read code and understand many programming concepts like packaging, dependencies, and you are likely to write a script or two, or probably closer to a hundred. Knowing a programming language or two is beneficial. Python is pretty standard, and Go is also great to know because a lot of the tools built for DevOps are written in Go.
Tools & Methodologies
CI/CD
A very important part of doing DevOps work is making sure code is able to be tested and deployed as fast, efficiently, and securely as possible. This is where CI (Continuous Integration) and CD (Continuous Deployment) tools shine. Implementing CI is enabling developers to get input on their code as fast as possible, you can define various CI pipelines in accordance to different scenarios in your R&D team’s workflow.
For example, as soon as someone opens a pull request, you can run tests on their code, then package the application in a container image, and then deploy it to their dedicated development namespace (assuming you’re using Kubernetes). There are many possibilities.
Most popular CI tools today use YAML for configuration (Let’s leave Jenkins out of this for now), and have an ecosystem of various community-made pre-defined actions such as checking out a repository or uploading a container image to some remote registry.
Some of the popular CI tools include:
implementing CD, on the other hand, means putting in place processes that enable the application to be deployed as automatically and quickly as possible. Coincidentally, you can create a CI pipeline that triggers when the master branch has been merged into or when a release is created, which in turn will put in motion the CD process.
Some of the popular CI tools include:
Workload Orchestration
Business continuity is very important for most, if not all organizations. In order to keep everything running smoothly, we usually use some form of tool to orchestrate our workloads, taking care or availability, scaling, disaster recovery and easy debugging. There are a few tools being used in the industry, but I’ve found Kubernetes to be the most popular, by far.
Some of the (other) popular workload orchestration tools include:
Observability
Keeping tabs on what’s happening with your workloads at all times is essential for a good DevOps Engineer. In order to be able to “see and hear”, so to speak, we leverage popular observability tools for collecting, storing, and analyzing logs & metrics.
Dealing with observability usually involves mapping the relevant logs/metrics to collect, writing queries, creating dashboards, and even creating alerts so that if a certain criteria is met, you and your team can be notified by your preferred method.
Some of the popular observability tools include:
- PromStack (The holy trifecta of Prometheus, Grafana, and Loki)
- Jaeger
- OpenTelemetry
- FluentBit
IaC
Infrastructure as Code (IaC) tools are like the secret sauce in a DevOps engineer’s recipe for success. They let you turn tedious, manual, error-prone infrastructure tasks into sleek, repeatable code.
Instead of clicking through a UI or running a script, you can use an IaC tool which will make sure your infrastructure is up to spec, and the current state matches your desired one.
Some of the popular IaC tools include:
Source Control Management
Coming from dealing with infrastructure, a lot of IT professionals don’t really experience the development side, and are unfamiliar with Source Control Management systems. Source Control Management systems (or SCM for short), enable developers to upload, download, and merge code, allowing them to work together.
The most popular SCM is git, and is implemented in a wide array of providers, each with their own spin and additions. You can manage git repositories in Github, GitLab, BitBucket, and many, many more. Some of them also offer CI infrastructure, issue tracking, approval frameworks, and release management capabilities.
Computer Networking
DevOps work leans very heavily into the networking aspect of computing. Whether it’s planning and creating virtual networks, implementing a particular load balancer, creating a site-to-site VPN, networking is a very integral part of our work. In a lot of companies, it’s not only vanilla TCP/IP you need to worry about, but cloud networking, which works quite differently from the way you’re used to with on-prem configurations and/or workstations.
Cloud Computing
Following up on the previous topic, most companies I’ve worked with use the cloud in some capacity, big or small. They might use AWS, Azure, GCP, or another, smaller provider. Each cloud provider works a little differently, be it in the way they name things, the ways you can interact with their platform, their offerings, and many more.
Final thoughts
The scope and nature of being a DevOps engineer can vary quite substantially from place to place, which makes the role very dynamic since you’re almost guaranteed to run into “blindspots” in your technical resume wherever you go.
Therefore, it’s important that you feel comfortable always being out of your comfort zone; The tools and technologies rapidly change and there’s a new, exciting up-and-coming solution coming out every other day.
You need to love digging deep into stuff, and troubleshooting is a very integral part of being a DevOps Engineer. There’s also a much bigger emphasis on understanding and taking part in the company’s development process. When friends ask me what it’s like, I claim it’s “like IT on steroids”, which is understandably not for everyone.
So, if you feel like moving on to DevOps might be for you, start learning some of the tools mentioned in this post, and if you have any more questions, you know where to find me 😉 ([email protected])
No responses yet