Core and Orbital Functions of DevOps
Every-so-often I see an article talking about highly functional SRE organizations, and then see it offset by learning about yet another company who have renamed their operations team “SRE”. I also worry about the opportunity for roles like SRE becoming a breeding ground for silos.
As with much of what I write, this piece is grounded in opinions based upon perspective and experience. Although it’s not prescriptive, it is intended to at least give cause for thought and discussion.
Classically, we talk about the cultural side of a DevOps transformation being about integrating the roles of Dev and Ops in order to integrate objectives and eliminate the conflict caused by developers wanting to deliver features at speed, while operations folks are pushing for stability.
You might see the “Sec” for security thrown into the mix as well, with DevSecOps implying how developers should also have an awareness-of and responsibility-for security aspects of the features that they deliver.
I was thinking about this the other night, and realized that the “Dev” circle is already incredibly interdisciplinary, and we often don’t give development teams credit for the broad range of skills that their work encompasses.
Perhaps you’ll have a dedicated scrum master rather than filling that role from within the team, perhaps you’ll segregate front-end and back-end systems development. Almost certainly team members will spend time debugging and refactoring. But that’s just detail.
The precise list of knowledge domains will change from team-to-team, and from company-to-company, but the degree of diversity in core skills and functions of a full-stack team rarely does.
This doesn’t mean that each individual is an expert at everything, but it does mean that a highly performant team will have a spectrum of abilities in each of critical areas of responsibility, and avoid having single points of expertise (and thus eventual failure) which would lead to reduced predictability in times of absence.
So given that the development teams already have this broad skills base, what’s special about “Ops” and “Sec”? I argue nothing, assuming it’s done in a thoughtful way.
Aside from any transition needing to be highly iterative, first-look has two distinct problems:
We can’t just give developers a bunch more work to do. Even with additional automation, there will still be additional concerns which need to be managed;
What happens to all the hard-working souls who have been fulfilling the roles of those traditional operational silos?
Now I’m deliberately using the words functions and roles here, rather than jobs… people are employed in a job, but they may perform several functions or roles in executing their work.
There is much camaraderie at a ten-person start-up and everyone typically pursues a single, highly focused objective, contributing where ever they can. Larger companies are different, though.
For a company with a dozen or more engineering teams, it doesn’t make sense for each team to reinvent the wheel, with their own distinct workflows, CI/CD tooling, development standards and so on.
In reality, there are a number of groups within the organization (such as IT and HR) who provide supporting services. Why should it be any different for DevOps related concerns?
In the diagram above, I’ve divided these orbital functions into three distinct categories:
Oversight Orbitals provide developers with direction (the what), such as which features are the most strategic to deliver first.
Advisory Orbitals provide developers with domain-specific expertise on an as-needed basis (the how). These orbitals might mix their time being embedded for a while, but always come back to understanding industry trends and driving best practices across the organization in that particular discipline.
Service Orbitals provide developers the tools and infrastructure required to do their jobs (and the various roles within). The trick with these is to ensure that the services provided can work asynchronously, so as to avoid need for blocking/silo related activities: for example, a database service orbital keeps all the database tooling available for developers, which is different to a database operations team where developers need to log tickets to get databases created or modified.
Together, these orbitals help homogenize best practices as the organization scales. Remember, though, that these orbitals are still just roles, and don’t mandate specific teams or isolated job responsibilities. Also, it’s likely that any given company will have some variation on this list.
One of the things I love about orbitals is that they help an organization scale well! From supporting just three or four micro-services to several hundred, plus embedded pipelines, we only needed to grow our tools team by a small increment. Compare this to adding SRE support to each team.
I think a lot of that has to do with how the team made itself approachable, while encouraging and empowering a high degree of self-service. But that’s a story for another day.
Summary
Going back to the introductory paragraph, the idea of SRE as an embedded resource within a team makes me feel uneasy, as it remains an overhead and silo. As the development team matures and stabilizes, then the need for SRE time should reduce. With reduction comes opportunity for time-sharing with other development teams, but then what happens when demand for the individual again outstrips supply? I feel like SRE as an advisory organization, where there is a right-sized pool of individuals available on demand allows for better scaling.
But that’s not all.
DevOps transformations can be fraught with fear for those who see their position being adversely affected. Unchecked, this fear, uncertainty, and doubt can catalyze bad behaviors within an organization and impede evolution.
It doesn’t have to be that way! Hear the good news!
Unless you’re someone who is complacent, content, and otherwise unemployable, DevOps is a win for you. Yes it’s hard, and cognitive bias isn’t going to make it any easier. If you’re working in an operational silo today, these orbitals provide plenty of roles to go around, all of which are likely to be more engaging, more rewarding, contain less drudgery, and have greater productive influence than what they replace.
Let’s get started.
Follow us on Twitter 🐦** and Facebook 👥 and join our Facebook Group 💬.**
To join our community Slack 🗣️ and read our weekly Faun topics 🗞️,** click here⬇**
If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇
This article originally appeared on Medium.