Devops Manifesto

Prologue

Let’s be clear here, I think DevOps is an often abused 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 lens based on the experience working for the Google's and Amazon's of this world - because they have no visibility into the small army of folks that enable the environment they utilise they believe they aren't required.

For sure things are changing, the days of a few ‘heroes’ 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 management APIs and abstraction layers it becomes far less magical.

  • Developers make life shitty for Operations people.
  • Operations people make life shitty for Developers.

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 success.

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 create 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.

Devops starts with a solid foundation in Systems Management and Product Development, if you can bring about this cultural shift that allows those two groups to work effectively together, you're on to something.

The Agreement

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

System Message: WARNING/2 (<string>, line 44)

Bullet list ends without a blank line; unexpected unindent.

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.

Ops / System people need to realise their platform is a product, used by a customer, it's essential that you cater to the needs of your customer, whilst levereaging the fact that your customers customer has the same goals as you - stability.

Moving Forward

Your existing platform needs work, no matter how mature it's capabilities, it's what you build and how you build it that counts.

Your job as a devops engineer is not to stop your product developers from running with scissors, it's to put guards in place so that they can't hurt themselves or anyone else. We should be building tools and systems that simply work in the background, developers shouldnt' have to deviate from their standard workflow, we should trigger pertinent routines at key checkpoints in their SDLC, whilst at the same time, mandating instrumentation for use in automated remediation.

Taking a leaf from the Product development playbook, Infrastructure, wether cloud based or not, needs to be developed and enhanced using a product management mindset.

Your customer, the deverloper, drives requirements, whilst operations drives acceptance criteria - this information all needs to be captured in a document called a 1-Pager. The 1-pager also needs capture the business value of the system or product, how does it aliagn to your leaderhsip's goals? Is this driving towards a required capability?