DevOps: it’s a culture, not a role (or how I learned to love IT again)

I’ve worked in IT for a longer time than I’d care to admit. I saw the advent of the web, the rise of mobile and the move from waterfall to agile (some good, some bad, currently amazing). After years slowly moving into management I recently switched back to hands-on development. The new world is amazing and the instant gratification of the cloud takes me back to my uni days, but the thing that truly reignited my love for IT has been DevOps.

As many of you probably have, I’d read a lot about DevOps but it always felt like something that companies like Netflix and Airbnb did. Having only ever worked in “legacy” companies with their own data centres, this seemed so far away. Even with the eventual shift to the cloud, there seemed to be a drive to centralise the “DevOps” team.

This all changed a little over a year ago when I joined the development team at Sainsbury’s in Manchester. No theory could have prepared me for how amazing it could be when DevOps is truly embedded in the culture of the team.

Over the last year, I’ve been working in a team where not only did we build and test our application, we also built our AWS infrastructure using Terraform. Having only worked with centralised environment teams in the past who were managing on-premise tin, where server requisitions took months, I found this amazing. It reignited my love of IT to levels I hadn’t had since my early days.Nothing prepared me for what was to come next…

Recently we’ve started looking at performance testing and system acceptance testing (breaking things). We would be the first to admit, that this should have been going on in earlier sprints rather than left to the end, but that’s what retrospectives are for, right?

This is where my mind got truly blown. I was so used to this being run by some other team or a third party company. We wrote performance tests using Gatling. This enabled us to run tests repeatedly and learn so much about our system, tweaking code, trying different EC2 types, in some cases removing entire applications.

We made some major findings, and learnt how to scale our systems out in the most effective way. This would never have been possible the old way, where performance was pass or fail (or add more servers).

System Acceptance Testing brought about other new and exciting discoveries. We took down servers, looked at how long it took to recover, and black holed traffic to see how things behave. This gave us new insights into the infrastructure as well as our code.

I’m not going to try and pretend that running performance tests over and over again and tweaking things didn’t get boring. But the outcome was fantastic, we understand our system so well now and had no fear of going into production. We also have performance tests that we can run anytime we like as we iterate on the product.

In my opinion for DevOps to really work you need a couple of things:

  • A Product Owner who sees the value, or at the very least trusts you to prove it to them. We spent a number of sprints building up infrastructure and writing tests and our PO trusted and supported us through it all and is now a DevOps convert.
  • A strong Scrum Master or Agile Coach, who believes in DevOps to support the team and can explain these things to the PO and other stakeholders.

Now I think about it, there is a third …

  • A development team who is willing to just get stuck in. We’re not ninjas or gurus or rockstars! We’re just a bunch of developers who want to produce the best thing we possibly can, and are given the space and trust to do it. We aren’t precious about the code we write, every code review and outcome from testing is just another learning experience.

I’m sure I’m supposed to sign off with some slick one liner to summarise it all. But it’s Friday night, the systems are running fine and I’m going for a beer.