Doing DevOps the right way

For several years now, DevOps has been one of the hype words, due to the desire to run development and operations of company software with more efficiency and predictability. This often takes the form of dumping operators into a development team and subsequently declaring it ‘done’. Of course, nothing could be further from the truth.

What is DevOps

So, this is a tricky one. In its most basic form, it’s just the contraction of Development and Operations, but the more important idea is that there is a fluent integration between both disciplines. Developers who understand operations and take that knowledge into account when building software, operators understanding software and influencing how it is made and deployed.

We’ve been here before

In a way, DevOps is nothing new in the world of software development. We used to have other roles that were formally separated back in the dark ages of waterfall style software development. Information analysts, functional designer, programmer, tester were all roles that were considered to have strict boundaries which lead to excessive (mis)communication, slow development, much frustration and eventually end-user disappointment.

We tried to change all that with the Agile Manifesto, focusing on team work, multi disciplinary team members and short feedback cycles to go towards a constantly improving way of building better software.

And this process has also seen its fair share of disappointment, especially when introduced as a mandatory process without the necessary vision.

DevOps is like the cloud

So, here is how I personally view DevOps: Instead of considering what kind of application we are making for a customer, we now consider what kind of service we are providing to that customer.

Because in the end, applications are a tool, that help an organization fulfil in their primary mission. For the customers of that organization, the most important part is the fulfilment of those functions. They do not care what technology is used, they care about the outcome. Fast, secure, accurate, and so on.

So the team (previously the development team and the operators) should be responsible to fulfil that need. They share the responsibility for the function being available and to the customers satisfaction. With the emphasis on share.

Constraints

Since with DevOps, the team is not just responsible for the building of an application, but also for the running of said application, this means that the team has more responsibility but should also receive additional mandate. Just as we have seen with the Agile movement, that you can not hold a team responsible if they are micro-managed, the same holds true for DevOps.

The team should be able to control and provision their own platforms on which the service runs. Of course within the boundaries of the agreed architectural principles of the organisation, but you can not ask a team to be responsible for a platform if another party in the organisation controls what happens on that platform.

Keep in mind that this also means that the team needs to have greater knowledge. Just like in an Agile Dev-team you expect every member to be able to design, build and test, in a DevOps team, you expect understanding of operational procedures besides those development skills. How do we monitor our service, what do we need to log, what should our update procedure look like.

You don’t expect every team member to excel in every skill, but at least understand the requirements, create basic solutions and while sparring with a more skilled team member solve the complex problems.

And of course, DevOps should be on top of Agile software development. If the development part is still waterfall, it is a chain of separate teams or individuals, so there wouldn’t even be a single team to integrate operations into.

So, are we doing DevOps?

With the previous remarks in mind, I think the following are good signs that you start to embrace DevOps:

• Teams are proud of, and feel responsible for, their service.
• ALM becomes important. Not just continuous integration, but also deployment becomes more and more automated.
• Testing expands from just unit-tests to fully automated functional and integration tests.
• Access to self-provisioning platforms, be it in the cloud, on premise with virtual machines or with a container platform.
• Moving from continuous delivery to continuous deployment.
• So called ‘non-functionals’ are considered right from the start of any design.
• Stand-by duty rotates within the team. Since the team is confident and makes sure their application works, nobody needs to fear that phone-call at 2am.

Keep in mind that just like Agile development, there isn’t an end-state, just a continuous process of improving and running services ever more smoothly.