World Class On-Call & Alerting - Free 14 Day Trial: Start Here.
This question, “What is a DevOps engineer?”, may seem like a simple one if you’ve worked in software development, IT operations or application security for the last few years. But, multiple definitions are often applied to engineers in DevOps roles, leading to confusion and potential inefficiencies.
Teams will often have dedicated DevOps teams full of DevOps engineers. But, in reality, DevOps is more of a mindset and cultural shift that needs to be adopted across all disciplines of IT operations, security and software engineering. You can’t expect every engineer to know everything about every single part of the software development, delivery, release and maintenance lifecycles. You need a number of individuals with deep skills in singular areas with a broad understanding of the rest of CI/CD and incident management.
DevOps engineers often become scapegoats for service reliability. Organizations will put the burden of uptime, performance and development speed on the siloed “DevOps team” – a group of people who may or may not have anything to do with the service being built and shipped to production. So, we wanted to go over the real roles and responsibilities of a DevOps engineer in today’s landscape.
A DevOps engineer is really just a frontend developer or a backend engineer or an IT security analyst. The official job title of DevOps engineer only starts to apply when you begin working at an organization where they silo DevOps teams from their development and IT operations teams. However, this defeats the entire purpose of DevOps – now you’ve created more silos (3) instead of reducing silos (2). Because of this, more and more private lines of communication will open up and transparency between developers and IT teams could become even foggier.
Because DevOps engineers aren’t often called DevOps engineers, it can sometimes be hard to screen for the right people in DevOps job interviews and ensure you’re getting the right people. Think of it this way, DevOps is more of a mindset taken on by every engineer and IT practitioner in your industry. DevOps is about continuously improving the way development teams work with operations teams – optimizing transparency and collaboration – ultimately leading to faster development of more reliable applications and services.
So, when you talk to a job candidate, try to assess their ability to work well with conflicting viewpoints, learn how they’ve built visibility and collaboration across disciplines in the past, and see if they have a deep skillset in one area as well as a broad understanding of the rest of the CI/CD pipeline.
You’ll often find a long list of DevOps best practices when you look online. But, any single list of tools, techniques and best practices for DevOps simply can’t be the end-all-be-all. DevOps should only be applied in a unique way to your organization based on the way your organization operates. What type of product, service or application do you build? How big is your team? How is the team structured today? What are the top three problems you’d like to solve by implementing DevOps? These types of questions can help you better understand how DevOps should look within your own team.
Take lessons from other engineering teams and apply them to your organization – but only if they work for you. Thinking that there’s only one way to build out a solid DevOps culture would basically be saying that Spotify and the US Department of Defense should build web apps the same way. But, as you can imagine, stringent security requirements in certain services at the DoD would be much more important than most parts of Spotify’s application.
The point and purpose of the entire product you support
How the application or service you support benefits customers
How the application or service you support benefits other engineers and their applications or services
Know the most important aspect of any project you work on (e.g. security, speed, testing, observability, etc.)
The CI/CD pipeline for all of engineering
Your own accountability
Because of the ambiguity around DevOps engineers, you don’t always know what to learn or how to train for such a role. Focus on what you’d like to be the best at – whether that’s data science, frontend, backend, QA, data engineering, etc. Learn the core programming languages used by your team and ask questions to understand how these teams all work together at your company. Then, continue to learn new skills and techniques. Take courses online or work cross-functionally with other developers on your team to share knowledge and learn from each other.
As you’ve already found out, being a true DevOps engineer isn’t as simple as applying for a role with that title. DevOps is often about thinking outside the box to improve the way people work together. Once people are working more closely and they have the tools and context they need, application delivery speed and quality naturally follows suit. As we think about DevOps engineers in 2020 and what that really means, we need to think about people who are laser-focused on efficient processes that benefit the full technology stack – including people operations.
If you’ve worked for years in a NOC, as a SysAdmin or an IT operations analyst – much of this doesn’t seem new to you. The only new things could be the programming languages you’d need to learn in order to move into a DevOps-minded role. As a developer, being on-call and helping fix issues in the middle of the night could be a new practice. But, the fact is, the people who build applications and services have the most knowledge of those applications and services. So, they should also bear the responsibility for fixing issues that come up in production.
Don’t think of DevOps engineers as individuals who know everything about development and IT, think of them as individual pieces of a larger, well-oiled machine. At the end of the day, the only responsibility of a DevOps engineer is to deliver value quickly and reliably to customers. Notice I didn’t mention applications or services – I wrote value. Customers will often see value from new features or services when you release them to production. But, the speed at which you deliver incremental, reliable value is what customers really care about.
Want to read more about the benefits of DevOps collaboration and transparency for software delivery and incident management? Check out our guide, Why DevOps Matters, no information required, to see how modern teams are quickly building more reliable services and delivering more value to customers.