DevOps Team Roles And Responsibilities

A good DevOps team is a mix of Developers and Ops Engineers who can do each other’s work, isn’t it? Well, it’s as far from reality as it can be, and today we show you the real DevOps team roles.

When the DevOps culture was just starting back in 2009, its founders thought of it as a mix between developers, QA engineers and Operations engineers.

The definition of DevOps practices that was suggested back in the days was revolving around the changes to the system, made by the DevOps team, and did not specify the recommended team composition, individual member roles or responsibilities. It goes like this:

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. © Wikipedia

However, the diagram above and the looseness of this definition has lead to a sad fact. Many people who were not acquainted with the reality of DevOps workflow thought the goal of the movement is to combine the Dev, QA and Ops departments into a single team, share their roles, teach them to use each other’s tools and let the DevOps magic work. Far too many companies tried this way and failed.

The adjustments DevOps has brought to software delivery

In fact, the true DevOps team cannot be farther from a mix of Devs, QA and Ops engineers. The point is, DevOps is a culture, a set of practices, an approach to building the workflows to endorse collaboration between these departments — yet the differentiation remains.

The problem the DevOps initiative was trying to solve is that for developers and QA engineers the project was completed as soon as the app or new feature code has passed the tests successfully. Then they literally threw it over the wall, and from that moment it was the Ops responsibility and headache to push it into production and maintain its performance there.

However, mixing the Developers with Ops engineers would not allow to solve this problem. The solution was altering the approach to software delivery in favor of 3 core DevOps values:

1. Infrastructure as Code (IaC) — server environments are described in declarative manifests, that are stored as code, can be adjusted by any team member and reused multiple times to provision the required infrastructure for testing or building the code, as well as for maintaining the app in production.
2. Continuous Integration (CI) — the feedback from project stakeholders and end users is constantly integrated into the product in form of specs and feature requests for the next iteration of software development.
3. Continuous Delivery (CD) — automatic code delivery pipelines are in place to ensure all the required resources are provisioned automatically and the code is pushed into production as soon as it passes the tests, without additional manual actions of the DevOps engineers or without interrupting the end user experience. Achieving the “no service downtime” is available due to using rolling updates and other DevOps practices.

As you can see, this approach is also centered on the processes, not on the particular DevOps roles. The Ops engineers do write code — but it’s the infrastructure provisioning code, not the app code. The Devs are indeed engaged as QA specialists — but only because they write automated unit tests prior to writing the app code itself. This way, the true DevOps differs much from the mix of various specialists.

The real-life DevOps team composition

To make it clear, DevOps engineers should concentrate on one thing, and one thing only: cloud infrastructure management. The main difference is that they follow the “you built it — you run it” paradigm, and they have to evaluate the possible bottlenecks of running the app in production from the very beginning of the software delivery process.

This is why they facilitate the “shift to the left” approach, where all kinds of testing are done after pushing each new batch of code to the repo before building the new software version. The DevOps specialists think of how the app will run long before the app is created, and they write scripts to create CI/CD pipelines that guarantee faster time-to-market for the product and positive end user experience.

To ensure this approach is feasible, there must be the following DevOps roles:

1. Product owner — the intersection between the team and the customer, the person that understands how the app should run to deliver value to the users, and what cloud infrastructure is needed to support the app in production. This can be a person on the customer’s side, or on the side of an outsourced DevOps team, depending on the project requirements and other factors.
2. Team Lead — this is the position for the most experienced team member, who can analyze the required skill set for each project and delegate the DevOps responsibilities across the team.
3. Cloud Architect — the person with ample hands-on experience with building cloud infrastructures and understanding what they have to include to support various types of apps and services in production.
4. Site Reliability Engineer (SRE) — the DevOps specialist concentrated at ensuring stable performance and uninterrupted availability of high-load apps across large-scale systems.
5. DevOps system administrator — one of the main DevOps roles, as cloud monitoring accounts for more than a half of all DevOps tasks and time. Each team member has to be able to handle the support tasks, yet these are the bread and butter for the support administrator.

This is the real-word DevOps team composition that allows to reach the needed results and successfully launch the products. As one of the top-10 Managed Services Providers worldwide according to Clutch, IT Svit composes the teams for each project according to this scheme.

Final thoughts on DevOps roles and responsibilities

Following this approach through more than 6 years of providing DevOps-as-a-Service allowed us to accumulate a vast expertise. Our Product Owners know what the customers actually NEED to leverage in order to get what they WANT for their products; IT Svit Team Leads ensure the projects are accomplished on time and under budget; our Cloud Architects can design resilient and fault-tolerant cloud infrastructures on AWS or Azure, GCP or DigitalOcean; IT Svit Site Reliability Engineers have in-depth experience of maintaining massive workloads in large-scale environments, and our support engineers can use multiple cloud monitoring solutions to detect and prevent any issues with the customer’s infrastructure.