Will the real DevOps please stand up

There’s a reason why DevOps is one word. The reason is that it’s one team: a DevOps team that is accountable for both development and operations. Over the past decade I’ve seen a lot of companies doing DINO: DevOps in name only. Sure: there’s a Kanban-board with colorful sticky notes (or if you’re lucky teams use online tools for this), there are sprints in development and go-live and there are teams with fantastic names such as ‘Warriors of the Galaxy’ or ‘The Duckies’ (I’m not making this up - and I’ve seen worse. At times I did get the impression that teams spent more time in inventing goofy names than actually thinking of doing a proper job).?

First of all: that’s not DevOps. It’s sort of agile working, at best. But what is DevOps then? It’s a mindset, to start with. Perhaps it’s a culture. That might be a strong statement, but what I mean is that DevOps is all about trusting the people working on the products that make money for your company. Nothing else. It’s not a bunch of cool tools or about slick programming. It’s about this: you build it, you run it. And: you break it, you fix it. The latter preferably completely automated. Even: you destroy it, you rebuild it better. As long as no-one gets hurt, but the software improves, then even that’s ok.?

Here’s an anecdote. In interviews for assignments or jobs I typically got this question: when are you successful? My answer to that question: when I made myself obsolete. The rationale: if I have made myself obsolete, I probably did a proper job in automating a lot of stuff. (And then I figure out what I will be doing next since I still have quite some years to go before my retirement - duh).?

Let’s get into the trenches of what true DevOps should be and why it’s so incredibly hard for earth-born companies to work in a true DevOps fashion. Keep one word in mind when you read this: trust.?

Change vs. Stability

Here’s the challenge in DevOps. We have developers who want change. That’s what they do for a living: they write new or change existing code. Either way, there’s a change as a consequence of their actions. There’s a new product or new features of that product. If we’re lucky then the code is free of bugs and works like a charm. Unfortunately, that’s rarely the case.?

That’s where ops comes in: operators who seek nothing else than stability. That’s what they get paid for: to keep stuff alive. In the old days, developers would just throw new code over the wall and leave the ops teams to manage it. In DevOps developers and operators are in the same boat. They build the code together and make sure that it can be operated with minimal effort.?

Six principles become seven

I like to present DevOps in six principles. No, I did not invent these myself, but I’ve adopted these.?

PRINCIPLE 1: Customer-centric action - or: what does the customer really want? Tip: something I learned from AWS is ‘working backwards’ which is an excellent way of defining first what the customer need is and then work your way back to the technical solution.

PRINCIPLE 2: Create with the end in mind. That doesn’t mean that you have to build the ‘end’ already. In this case a principle of continuous architecture applies: leverage the power of small. Designs will change as a consequence of changing requirements and hopefully because of changing customer demand. So, architecture will develop and evolve. DevOps teams should be able to work with that. Indeed: micro-services. ?

PRINCIPLE 3: DevOps teams are end-to-end responsible for the delivery of the product. This automatically leads into the fourth principle:

PRINCIPLE 4: Cross-functional autonomous teams. The T-shaped engineer does not exist. I’ll repeat. The T-shaped engineer does not exist. I guess you’ve seen the job advertisements asking for engineers who can do all public clouds and master the full Periodic Table of DevOps Tools. You’re asking for an IT-department, not for an engineer. You need teams that bring together all the different skills.?

PRINCIPLE 5: Continuous improvement. There’s no reason in doing DevOps if your software gets released once and never receives updates and upgrades.

PRINCIPLE 6: Automate what you can and automate it to the bone. Remember the anecdote.?

Over the past years I added a seventh principle: Trust your teams. So:

PRINCIPLE 7: Trust your professionals.

If you can’t trust your teams, you haven’t trained them well enough or proper guardrails have not been implemented. It’s that simple. In other words: enterprises - and here’s the role for the enterprise architect - need to facilitate proper guardrails that allow DevOps teams to work on products, autonomously, with end to end responsibility.?

Release management and responsibility

Key in DevOps is release and feature management. Now, release management as-we-know-it (typically ITIL based) is something different than release management in DevOps. Release management is about scheduling and maintaining new deployments, but before DevOps the operators would receive the code from developers and next decide when this new code would be implemented, whilst maintaining uptime for all the existing services. In DevOps the team plans, schedules and controls development and deployment end-to-end, allowing for constant feedback and faster releases.?

That comes with responsibility. Teams need to ask themselves three crucial questions, after each release.?

• Did everything work successfully last time?
• Why did it not work?
• What can be changed to make it better?

Allowing teams to do this, comes with trust. That’s why DevOps is so much more than a bunch of cool tools, pipelines and code. It’s a way of doing business at scale and speed.?

So: are you doing true DevOps? In that case: do stand up. Daily.?

Want to read more and understand what your role as an architect is in enterprise DevOps? Then I would like to encourage you to read my newest book. Oh - and open for discussion (hopefully IRL soon again…)

Order the book (Packt Publishing) here: Enterprise DevOps for Architects