A DevOps Engineer is a great job that often has you working as a combination of a developer, a systems operator, and an automation expert. As a result, there are always interesting problems to solve on a variety of topics.
Common DevOps job roles
I’ve worked in many teams doing this job, and I’ve also helped thousands of students who are currently in this role or want to do this job.
However, the title “DevOps Engineer” itself is confusing, and no one can agree on what precisely a DevOps Engineer is (or does). So, for now, let’s list some typical activities you might have in this role:
- Providing leadership and guidance for reducing the time it takes to deploy a software change.
- Managing CI (continuous integration) systems and pipelines.
- Creating automated software builds and testing.
- Designing and implementing infrastructure.
- Automating infrastructure buildout and maintenance.
- Managing and enhancing logging and monitoring systems.
- Providing developers with self-service tools for provisioning systems, deploying code, and running tests.
That is a small subset of the likely tasks you’ll be doing when working in a DevOps Engineer job. Day-to-day activities will vary widely based on the organization’s culture and maturity (which I’ll talk about in a bit).
The problem: DevOps is a generic title
I often call myself a DevOps Engineer, but I don’t like that title, and it shouldn’t exist.
Let me explain.
In my previous article What Is DevOps: How To Build An Efficient DevOps Team, I broke down the elements of DevOps patterns and workflows and gave you a 15-question assessment to help you determine your team’s DevOps maturity.
In that post, I briefly mentioned that “DevOps is not a title”:
DevOps, like Agile Software Development, isn’t a job role. Everyone in the software organization needs to be on board with the DevOps objectives for it to work. One (or a few) people labeled as “the DevOps Engineer” usually means that everyone else is ignoring the required collaboration and changes they need to make as well. Better titles might be “QA Engineer,” “Reliability Engineer (SRE),” or “Build Engineer.” These job roles (and many more) control a piece of the software lifecycle that affects your DevOps results.
That’s why the generic job title DevOps Engineer might be confusing and needs to go away. But we haven’t uncovered a better universal title.
Junior vs. senior DevOps engineer
I get asked how to get a DevOps Engineer job with little to no experience in a software development team. The reality is, it’s hard to get a Junior DevOps Engineer position without at least some experience in development or operations teams first.
One of the major goals in DevOps is to help teams work better together through improved tooling, processes, and automation. Achieving that means you need to understand the traditional “problems of making software” and what can make it better. No two organizations do it the same, and the matrix of processes plus tooling can be vast. So how do you know that world without experience?
I often suggest to students that if they have a hard time breaking into the DevOps role, they can try for a job they qualify for, that is close to the DevOps job they want. These will often overlap with a few expected skills of a DevOps Engineer. Titles could include “Build Engineer,” “Testing Engineer,” “QA,” or just “Cloud Sysadmin.” Look for any job description where you’ll be handling the dev team’s custom code, controlling infrastructure, and automating systems and workflows.
However, it’s still possible to get a Junior DevOps Engineer position without much experience, in organizations that are at the beginning of their DevOps journey. Many teams are short-staffed, and there’s a lack of available DevOps talent. These realities make it easier to break into the DevOps field.
Organizational maturity affects what a DevOps engineer job is (to them)
If DevOps culture were everywhere in every organization, we’d all just think of this as “the normal way to do software engineering.” Unfortunately, we’ve got decades of old habits to change in millions of people, so we still need a single term to identify as “The New Way.” That’s what the term DevOps has become: a more generic, watered-down term for all the activities and beliefs around the modern software lifecycle where we’re continually improving the velocity and reliability of deploying software and the systems underneath.
Organizations advanced in their DevOps culture, processes, and tooling may not have a generic job title of “DevOps Engineer” anymore. In these cases, there’s no room for a generic DevOps job because everyone is already on board with the ideas of DevOps and doing their part to further its agenda in their various engineering roles.
Instead, you may see titles like “Automation Engineer,” “Cloud Architect,” “Distributed Systems <something>,” and “Site Reliability Engineer (SRE).” They may have jobs that are even tool-specific in larger teams, like “Kubernetes Engineer/Admin/Architect,” “Terraform Engineer,” or “AWS Architect.” Look for jobs where DevOps is mentioned in the description along with DevOps buzzwords like automation, release, continuous deployment, CI/CD, GitOps, autoscale, DevSecOps, FaaS, Serverless, ChatOps, and containers.
Common tools that will coincide with more modern cultures include Docker, Terraform, Kubernetes, Helm, ArgoCD, Pulumi, OpenShift, Rancher, EKS, AKS, and GKE. Look up the CNCF organization’s landscape list to see how many Cloud Native tools there are.
What to learn for a DevOps engineer job
I get this question a lot in my Docker Mastery and Kubernetes Mastery Udemy courses, which are critical tools in DevOps and generally expected that you know today in a DevOps team. I also discuss this topic in my open GitHub AMA.
Because there are so many different types of jobs within the word DevOps, it can be a challenge to list all the skills you will need for any potential job. We can, however, agree on a set of fundamentals that you will be expected to know for any DevOps-related job.
- DevOps principles and mindset. Before learning tools, you need to know what problems DevOps is trying to solve and what typical DevOps workflows and patterns look like. You also need to understand what DevOps isn’t. My What is DevOps article goes deeper into this.
- Linux medium-level admin. Sure, there are other operating systems, but Linux is the default in the cloud. You should be able to build, maintain, and troubleshoot a Linux server. Ideally, you also learn to use one or more tools to control many of them at once (Ansible, Terraform, Pulumi). This is somewhat changing as Microsoft’s market share grows.
- Solid understanding of networking. TCP/IP, packets, routers, NICs, switches, standard TCP & UDP ports, proxies, firewalls, IPv4 vs. IPv6, and DNS are a must. Everything communicates using these fundamentals, and knowing them like the back of your hand will serve you your whole career.
- Distributed systems design. Understand how web apps talk to databases, how containers communicate with other containers, and how cloud services work with your app. We no longer deploy a simple single server with one website and one database. A modern solution will be dozens of little pieces that all use networking to function together. Knowing the difference between “better or worse” distributed systems design is vital.
- Know the Git version control tool and how to use it in a team’s workflow. You’ll use this for nearly all your work in DevOps land. The easiest way to do this today is to learn GitHub (one of many places to store files in the git standard) and the “GitHub Flow” workflow.
- Pick a cloud and know the essential services well. You don’t need to know all the “big three” clouds (AWS, Azure, Google). Pick one cloud (AWS would be my default) and become skilled at managing servers, load balancers (proxies), storage, networking, and databases.
- Pick your first development language and learn it as best as you can. DevOps doesn’t always mean you’re a developer, but you will at least be handling other people’s code often. Learning one language goes a long way to picking up others as you need them. I recommend Python, JavaScript/Node.js, or Go as options for your first.
- Know how to automate the Linux CLI with Bash Scripts. They are everywhere, and I’ve never seen a DevOps team without them.
- Learn a general automation solution. Sometimes this is called CI/CD. These tools are the bedrock of automating the building, testing, and deploying of apps and infrastructure. This includes dozens (if not hundreds) of tools like Jenkins, CircleCI, and GitHub Actions, with the latter being my favorite.
Must I be a developer to be a DevOps engineer?
The short answer: not always, but likely.
Much of a DevOps Engineers daily tasking won’t be writing new software code, but so much of the work is related to understanding code that others wrote. It is crucial to understand what the code intends to do, what resources it needs, and its dependencies.
The better you are at modern development and software design, the better you’ll know how to properly build, test, and deploy that software in a DevOps job.
If you’re someone like me who came from a sysadmin and operations background, you’ll want to focus on learning a programming language ASAP. The essential parts for a junior DevOps job are understanding how the team’s software is built, the dependency tools used, and the app configuration of the languages used.
Because DevOps Engineering is often a hybrid of developing and operating skills, the opposite also holds true. A pure developer will need to improve their systems architecture and Ops skills. For example, suppose you come from a pure development background, where you never had to build out and maintain automated infrastructure or design distributed systems. If that were true, you’d need to focus on improving your understanding of those gaps to become a more well-rounded DevOps Engineer.
DevOps engineer vs. SRE (site reliability engineer)
You might have heard about SRE jobs, which are becoming more common in teams that have already had their DevOps culture transformation. In mature software organizations that live and breathe the DevOps attitude of “continual improvement of the systems and processes that run our software,” there is often a need for developers that are more involved in production operations.
SREs aren’t focused on your product (app) end-user features but on improving the reliability of that app running in production. They still have the DevOps mindset like everyone else.
Yet, their job role is specific to production operations improvements rather than the typical “build, test, automate” focus of a general DevOps Engineer. DevOps Engineers (regardless of job title) would work with SREs to improve the software and infrastructure lifecycle. Google is known for its many SREs and says this:
“SREs are focused on finding ways to improve the design and operation of systems to make them more scalable, more reliable, and more efficient.”
Google also has some of the best information about SREs in the Google SRE book.
What is the future of DevOps engineering?
DevOps, as an idea, is over a decade old now.
One of the problems with the definition of DevOps is that it lacks detail and has become a generic industry term that means everything and nothing. It’s become as bad as using the 50-year-old System Development Life Cycle (SDLC). Everything seems to be labeled DevOps now, which waters down what it is and isn’t.
We’re starting to see ideas on what’s next in defining a standard set of cultural guidelines, job roles, and workflows for what a modern software team should look like and the activities they should be performing. Sometimes I hear “DevOps 2.0,” but I already don’t like that idea.
One recent example is Emily Freeman’s tongue-in-cheek teaser video on the problem with thinking “DevOps has solved everything” and her excellent follow-up GitHub Universe talk on an idea for a “Revolution” framework.
I originally posted this article on Udemy’s Blog as Becoming a DevOps Engineer: Understanding the Role and Responsibilities