DevOps? More like DevUse!

I had this rant^w topic on my mind for a couple of month now, at least. Driven by Cindy Sridharan’s recent post popping up on my Medium suggests, I finally felt inspired enough to get it on (virtual) paper.

Most Developers ain’t no Ops and are never going to be!

If you are a startup, a small-ish company with less then a handful of products or even a mid sized agency doing project work all day long: You don’t need ops. If you don’t need ops, you don’t do DevOps. And that’s a good thing.

Put money where value is generated

Most of the time it is in developing features. When you are putting up your shiny new web service on Heroku, click the addon buttons, install a log analyses tool which automatically gets fed your apps logs, all that deployed on push and CI green via Git{hub,lab} and WhateverCI, thats not “Ops tasks”. In my opinion that’s ‘using a platform’. That’s why I think the term DevUse should be used.

“[…] More and more of the Ops function is ripe for being commodified and the most successful Ops vendors will be ones who will appeal to developers the most.”

This perfectly underlines my view on the developers being the users, the consumers, the target audience of services and platforms.

Now, at this point some people would certainly raise their voices and say something along “No no no, what you are describing is NoOps”. Fine. But why would one leave out the important part (the ‘Dev’), just to say that the other part (the ‘Ops’) isn’t there anymore? Just image we would have called our classic sysops work ‘NoDev’ in the past? ;-)

But the developers are writing their own deployment scripts/recipes/tools!?

That’s great! If for some reason or another the product team cannot use a off-the-shelve service for their needs then there is no blame in taking the more-work route. However, just for writing a shell script or an automation runbook; that’s not “Ops tasks” either. Lets call this DevDep.

What is Ops then? And the rise of SRE

As Cindy Sridharan puts it:

More and more companies require developers be on-call for their own services with Ops/SRE teams taking on more of a consulting role.

Although being on call certainly isn’t the only left over ops task, the associated responsibility and care-taking is likely the most important.

It seems to all depend on the level of abstraction one chooses when looking for platforms and services. To stick with the above example: using SaaS (for CI and code hosting) and PaaS (Heroku) instead IaaS (i.e. AWS EC2 or on-premise VM orchestration) one is so far away from managing infrastructure that there ultimately is no need for a special role to keep the software running. An SRE couldn’t change the products fate when Heroku goes down anyway.

At a certain size or importance, you’d need to cover as much of the stack as possible

That’s were systems engineers enter. Most stuff is not that important, however.

The rise of SRE as a working model kind of feels like the result of consequently applying product-thinking to Operations engineering. In many cases in the past Operations and Development had very different approaches on timelines, responsibilities and long-term goals. With the focus shifting more towards building products instead of doing projects, both disciplines share a common sense of responsibility for ‘the thing’. This allowed a healthy exchange of ideas, best practices and understanding of each other. This, in my view, is the fundamental benefit this whole “DevOps” movement brought us engineers.