Tonight was another gathering of the nlscrum crowd. The speaker today was someone I had seen present at devoxx before, Patrick Debois. I left his session at devoxx quite unsatisfied, so I figured I’d take the opportunity of this smaller group to see what his brainchild, DevOps, is really all about.
The presentation Patrick and his co-host gave left me unsatisfied yet again. Patrick is stating that there is a big problem between Developers and Operations. Dev always think that Ops is not flexible enough and Ops always say that Dev are cowboys. Admittedly, Patrick is a good presenter and brings a nice story. He tells a story from his development past about building an application that would occassionally crash and eventually burns to the ground. His point is that there is a big divide between how a developer thinks and how an operations person thinks. The differences come from the following I think:
|Are responsible for||New Functionality||Non Functional Requirements|
My problem is that in both his presentations Patrick only puts down a problem and the message is that we should change our mindset. We should embrace each other and learn to think alike. That’s really, really not tangible enough for me. I feel the problem since I am in a role as both Dev & Ops to an extent and want to get some good advice on how to combine the two better. So far, the 2 DevOps presentations did not deliver.
At the end of our meetup, we always have a lot of room for discussion. I put a topic on the board which was meant to lure Patrick and his co-host out and into the open. I titled it “The Hollow Phrase – DevOps”, hoping to get a good discussion going. It appears I was being a little too Dutch and straightforward so my fishing hook didn’t directly receive a bite. I managed to find Patrick anyway and opened up the discussion with him and a few others. It turns out, there are a few tangible things we can take away when we think of having Dev and Ops play nice.
Lessons for Developers
Focus on Non-Functionals
Developers should really have Non Functional Requirements in mind when building an application. This sounds like a real no-brainer, but in most projects and teams, important things like scalability and performance are only an afterthought.
There is however a practical way to make sure that this is considered core and also gets attention: make sure the product owner has Non-Functionals in his field of vision. Plenty of ways to do this right:
- in smaller organizations, have the end-customer define what level of pain they are willing to take
- in bigger organizations, make sure that an architect from the Operations department is a regular partner for the product owner
Share the responsibility
The problem gets worse when Developers are only responsible for delivering new functionality and Operations are only responsible for maintaining stability. Make sure both parties are responsible for changes and stability. Developers can also be held accountable for the number of incidents on their software after release. Operations can also be held accountable for the number of successful changes they manage to implement. In organizations with bonuses, it pays off to define the bonuses on both these levels.
Handling incidents in iterations
In organizations, such as Amazon (and Compare Group 😉 ), the developers are also responsible for the operation of the software they build. The problem you run into with this combination, is that your Sprint commitments are endangered the moment you run into an incident on your live environment. The solution is simple: assign incidents a value, just like the stories on your Sprint. This value can be in story points, in hours, whichever works for you. At any given time your commitment stands to deliver a certain number of value points in a Sprint. The only discussion you need to have is: what do we take out of the Sprint now that we have run into this. In my opinion, this should be a natural part of the negotiation between Product Owner and Scrummaster anyway, so use that mechanism.
Lessons for Operations
Use virtualization and cloud technology
New technologies such as virtualization can make an Operations team’s life a lot simpler. No longer do you have to be reliant on this one server, but in case of failure you can simply move your virtual machine somewhere else and be guaranteed it will work again. Also, this type of technology facilitates scaling a lot better, since it’s extremely simple to clone environments.
Infrastructure as code
Work on repeatable and durable solutions, stay away from quick one-time fixes. A good way to do this is to make automation a key part of your Operations. Setting up a server is something you can have a script do for you. Write the installation process once and then run it twenty times. Automation not only saves time in the short run, it also prevents a lot of errors in the long run because there are a lot fewer places for errors between chair and keyboard.
Empower the business
Delegate recurring change requests to your customer. Simple change requests still take up a lot of time of Operations teams, the customer is quite capable of doing them himself if he has the necessary tooling. In many cases you will need to make a user interface available for your customer, but after that he is in control. He won’t need to get in touch with your helpdesk anymore to get his password changed, he can just receive a new one in the (e)mail. This frees up your time as Operations to work on longer lasting changes.
DevOps has some abstract points. As Developers it is important to think about what your software will do in a production environment. As an organization, it is important to make sure that the responsibility of the Non Functional Requirements is not guarded solely by your Operations team.
There are also some concrete points to take away, but that requires peeling away some layers of the onion. That’s really a shame, since Patrick and both his co-hosts had good looking presentations that had obviously received a lot of work. Still, it was good fun to discuss this with Patrick and his co-host and I have every bit of respect for what he has accomplished so far.