yes. devops is a title. a role. and a team.
and there is no devops without dev.
in 2009 devops was coined - I’m on record for objecting at the time (and for years after). I believed that systems administration was apropos and devops just described “how we should and have been doing it for years”
but I missed something.
devops is about dev, and devops is about ops - it’s about running the code the business is writing, and running that code as a product, in production.
we think about it mostly in terms of SaaS these days - but there are a lot more than SaaS products involved here.
a decade later I realized that we need a title to describe these people - ops shaped people - who run the software we build. sysadmin covers it, yes, but sysadmin is also about running servers and off the shelf software. there are miles and miles of overlap.
but when we start building and running software as a team, the specific approaches we take change - we have control over the process. we’re shipping new versions constantly. we’re much closer to our customers, and our customers are using the infrastructure and the software in combination.
a few things devops is not - it’s not about config management, infrastructure as code, tools, languages - and it’s not about servers.
devops is about operating the product.
as businesses grow, scale, shrink, the exact people involved in doing this will evolve. the nature of the product itself, and it’s stability, compliance, security, and risk (life or business) will impact this.
devops may be an entire engineering team responsibility - and your feature, frontend, backend, data, and ML engineers may all have cycles dedicated to thinking about things from a systems view, and they may even enjoy it.
but that engineering team might be packed with 80 hours of story points per engineer every 2 week sprint, with no thought given to running the software. the individual engineers may not like touching servers or IAC or CF or cloud guis or shells. or building monitoring systems, managing metrics and logs. and they may not have experience doing that, either.
as you start to dedicate the role (even if not the people), you start to need to label it. “joan is on devops backlog this sprint, and sam will support her since he was on-call last sprint”
as this dedicated role’s responsibility grows, and you have people allocated to this full time - that teams needs a name. you’ve got your mobile team, your backend team, your frontend team, your ML team, and your data team. you need to call your devops people something.
when you start trying to hire for people with the unique skills and desire and mindset, you craft job descriptions. your job description is an advertisement, and it needs to catch the eye of the right candidates.
systems oriented folks may never apply to that sr backend software engineer role that happens to also say “and chef, terraform, grafana, bigbrother, puppet, tailscale, ansible, linux kernels, rundeck, jenkins, java, python, go, php, ipsec, javascript, elixir, cacti, rust, dash, redis, mysql, ssl, redshift, postgresql, membase, vpc, bgp, dns, openvpn”.
anyway. I’ll jump off the soapbox for now.
tl;dr - titles are important to simplify the description of roles, and devops is just as important to title as backend and frontend and mobile.
comments? hate? ping me via my contact page or join the conversation on linkedin