Let’s be clear here, I think DevOps is an often mis-used term that’s widely overused. You’ll read articles where people say ‘devops’ shouldn’t be a separate group, you’ll read posts that say we don’t need systems people anymore, there’s job postings blatantly looking for ‘infrastructure’ engineers but rejecting anyone with too much ‘operations’ experience - frankly it’s all a bit much, these articles are written with a very narrow lense.
For sure things are changing, the days of a few ‘heros’ restarting services on 200 servers are gone, with the acceleration in automation technologies and cloud computing in the last 5-10 years those skills just aren’t as valuable as they once were. With that said, systems engineering, platform engineering, system operations - whatever you want to call it, still has an important role to play. Even with cloud computing, you still need a decent understanding of basic networking, security and systems management, without it you’re just going to end up with an expensive unsupportable mess. After all, the cloud is really just someone else’s computer, once you accept that Cloud is simply Infrastructure tools and Virtualization with a management API it becomes far less magical.
In short - I don’t believe in Devops, because historically:
- Devs make life shitty for Ops people.
- Ops people make life shitty for Devs.
This mindset has to be changed and that can only happen with cultural shifts on both sides, you can’t simply combine the 2 groups and expect unicorns and rainbows.
Ops people need to get out of the way of the Devs so they can push their latest idea out quickly, without deviating from their standard SDLC workflow.
Devs need to operate within a set of well defined boundaries to avoid causing security incidents, outages and other issues the Ops people eventually have to deal with.
Another common misconception for organisations embracing the DevOps model is that a shiny magic tool will be a utopian dream of frictionless systems management. That’s also rarely the case, unless you’re amazon, google or someone else with a billion dollars and hundreds of engineers to throw at commissioning the tool.
Wether your Devs and your Ops guys are in the same team or in different teams, the first thing that needs to happen is understanding. Each side needs to understand the others workflow, their pain points, what they don’t like dealing with and what frustrates them:
- Ops guys need to understand the SDLC process, Dev guys may need to slightly adjust their branching strategy.
- Dev guys need to understand what compliance steps have to be met before deploying new code to production, Ops guys may need to invest in automating some of those steps
In general, this is usually where the 2 groups have deviated in the past; Operations guys throw up a bunch of blockers because they perceive Devs as not playing by the rules. Developers try and bypass what they perceive as idiotic process that prevent them from deploying their code and meeting their targets.