I ran across an interesting post by Dmitriy Samovskiy about the difference between a DevOp and a Sysadmin and it raised up some thoughts I’ve had about the classification of different kinds of sysadmin types and the confusion that the “Ops” part of “DevOps” sometimes causes.
I think that using “DevOp” as a job or role name isn’t a good idea, and that really what the term indicates is that there are two major classes of technical role,
- Devs – people who work with code mostly
- Ops – people who work with systems mostly
You could say a “DevOp” is someone who does some of both, but I think the preferred usage is that DevOps, like agile, is about a methodology of collaboration. A given person having both skill sets of fulfilling both roles doesn’t require a special term, it’s like anyone else in IT with multiple hats.
Of course, inside each of these two areas is a wide variety of skills and specialized roles. Many of the people talking about “DevOps” are in five-person Web shops, in which case “Ops” is an adequate descriptor of “all the infrastructure crap guy #5 does.”
But in larger shops, you start to realize how many different roles there are. In the dev world, you get specialization, from UI developers to service developers to embedded developers to algorithm developers. I’d tend to say that even Web design/development (HTML/CSS/JS) and QA are often considered part of the “dev side of the house.” It’s the same in Ops.
Now, traditionally many “systems” teams, also known as “infrastructure” teams, have been divided up by technology silo only. You have a list of teams of types UNIX, Windows, storage, network, database, security, etc. This approach has its strengths but also has critical weaknesses – which is why ITIL, for example, has been urging people to reorganize around “services you are delivering” lines.
In the dev world, you don’t usually see tech silos like that. “Here’s the C programmer department, the Java programmer department, the SQL programmer department… Hand your specs to all those departments and hope you get a working app out of it!” No, everyone knows intuitively that’s insane. But largely we still do the same thing in traditional systems teams (“Ops” umbrella).
So historically, the first solution that emerged was a separate kind of group. Here at NI, the first was a “Web Ops” group called the Web Admins, which was formed ten years ago when it became clear that running a successful Web site cannot be done by bringing together fractional effort from various tech silos. The Web Admins work with the developers and the other systems teams – the systems teams do OS builds, networking, rack-and-jack, storage/data center, etc. and the Web Admins do the software (app servers, collab systems, search, content management, etc.), SaaS, load balancing, operational support, release management, etc. Our Web Admin team ended up expanding very strongly into the application performance management and Web security areas because no one else was filling them.
In more dotcommey companies, you see the split between their “IT group” and their “Engineering” or “Operations” group that is “support for their products,” as two entirely different beasts.
Anyway, the success of this team spawned others, so now there are several teams we call “App Admins” here at NI, that perform this same role with respect to sitting between the developers and the “system admins.” To make it more complicated, even some of the apps (“Dev”) teams are also spawning “App Ops” teams that handle CI work and production issue escalation, freeing up the core dev teams for more large-scale projects. Our dev teams are organized around line of business (ecommerce, community, support, etc.) so they find that helpful. (I’ll note that the interface between line of business organization and technology silo organization is not an easy one.)
Which of these teams are the “DevOps?” None of them. Naturally, the teams that are more in the middle feel the need for it more, which is why I as a previous manager of the Web Admins am the primary evangelist for DevOps in our organization. The “App Admins” and the new “App Ops” teams work a lot more closely together on “operational” issues.
But this is where the term “Ops” has bad connotations – in my mind, “operations”, as closely related to “support”, is about the recurring activities around the runtime operation of our systems and apps. In fact, we split the Web Admin team into two sub-teams – an “operations” team handling requests, monitoring, releases, and other interrupt driven activity, and a “systems” team that does systems engineering. The interface between systems engineering and core dev teams is just as important as the interface around runtime, even more so I would say, and is where a lot of the agile development/agile infrastructure methodology bears the most fruit. Our system engineering team is involved in projects alongside the developers from their initiation, and influence the overall design of the app/system (side note, I wish there was a word that captured “both app and system” well; when you say system people sometimes take that to mean both and sometimes to just mean the infrastructure). And *that’s* DevOps.
Heck, our DBA team is split up even more – at one point they had a “production support” team, a “release” team, an “architecture” team, and a “projects” team.
But even on the back end systems teams, there are those that have more of a culture of collaboration – “DevOps” you might call it – and they are more of a pleasure to interface with, and then there’s those who are not, who focus on process over people, you might say. I am down with the “DevOps” term just because it has the branding buzz around it, but I think it really is just a sexier way to say “Agile systems administration.”
On a related note, I’ve started to see job postings go by for “DevOps Engineers” and other such. I think that’s OK to some degree, because it does differentiate the likely kind of operating environment of those jobs from all the noise posted as “UNIX Engineer III”, but if you are using “DevOps” as a job description you need to be pretty clear in your posting what you mean in terms of exact skills because of this confusion. Do you mean you just want a jack of all trades who can write Java/C# code as well as do your sysadmin work because you’re cheap? Or do you want a sysadmin who can script and automate stuff? Or do you want someone who will be embedded on project teams and understand their business requirements and help them to accomplish them? Those are all different things that have different skill sets behind them.
What do you think? It seems to me we don’t really have a good understanding of the taxonomy of the different kinds of roles within Ops, and thus that confuses the discussion of DevOps significantly. Is it a name for, or a description of, or a prescription for, some specific sub-team? Which is it for – production support, systems engineering, does IT count or is it just “product” support orgs for SaaS?
the agile admin 