What makes a successful DevOps professional?

Ian Miell (IM): I started off as a developer at the turn of the century, working for a company that did online gambling software. As you can imagine, working in this industry the customer was amongst the most demanding there is, and our customers were in an arms race with each other to try and deliver new features faster. As a result, I was naturally in an environment where software delivery had to be quick and it had to be cheap.

We tried to set up a support department and it kind of failed, so they essentially made developers into the support engineers. I moved into that team and helped develop it into a much more structured operation until we essentially became close to what Google were calling an SRE team; we were coders liaising with the development team to provide feedback and fixtures, and all of us were liaising with the end-user. In this remit I was called the DevOps manager, so that’s really how I got into DevOps.

IM: I remember before even Source Control was mainstream, so I guess what’s really changed is that it’s moved from something that was previously done by hand into something that has now been automated.

That process of automating laborious work has spread into other areas, and remits of IT that were previously resistant to programming and automation are increasingly becoming automated. The likes of testing, networking and provisioning are all doing through the same changes as software is rapidly taking over IT, and that’s the biggest change I’ve seen in my 20 years!

IM: It’s related to the above, because automation is my thing and so what interests me is the fact that the tooling around that is exploding. Take Kubernetes, which basically takes away the concept of the server to a developer, so that they can deploy an application onto an infrastructure that exists on an API.

Terraform is also interesting because it’s providing a way to repeatedly automate your infrastructure set up. I do also find the trend towards serverless interesting, but I’m a bit nervous about it because you really need to understand that you’re getting locked into something, even though it might not be a server.

IM: I don’t think there will be any step change happening; I think there will just be more and more tools coming onto the scene that seek to automate the workflow. Because it’s operations and not development you will usually see an explosion of technologies around a hot area and then consolidation to a few key areas.

Kubernetes is a good example of that; when Docker came out the industry realised the value was in the orchestration layer and there was an explosion of tools in that space and Kubernetes won out. I think you might see that happening more and more as people go towards the few main players for their technology.

I’m interested to see how the big players – AWS, Google and Microsoft – work with each other because they’re all going to be around for a while. It’s always been talked about that you’ll get tools that abstract away from multi-cloud providers and give you a layer on top but that’s definitely a hard nut to crack whether it’s in 6 months or 10 years. Kubernetes could be seen as the first stage of this because it’s an API that transcends cloud, and I think that this is another area that things will begin to evolve in over time.

IM: I think that digital transformation means different things for different people, so I like to be specific about what is really trying to be achieved by these initiatives. Technologists tend to overestimate the importance of technology when they talk about digital transformation, but it’s important to understand what the drivers and constraints for these changes are.

It’s always easier to say let’s use X technology, and to give the resources to someone with the right knowledge, but without understanding the organisational, technical or regulatory constraints on that adoption it’s always going to be difficult. So, I don’t think it pays to focus too much on how DevOps can influence digital transformation if you don’t first understand the problem you’re trying to solve.

IM: I guess there are two things. Firstly, you need a breadth of knowledge about technologies and their ramifications; there’s a lot of technologies and tools out there, and you can’t master them all, but if you’re going to be effective across an organisation then understanding the power and limitations of them is really important.

The other thing that I think makes someone successful if an awareness of the fact that all of these technologies don’t necessarily solve the problem an organisation faces, and it’s critical that professionals acknowledge this, so they can find the best solution to their challenges.

IM: Put it this way; you would want your doctor to know about the basics of anatomy, but a successful GP doesn’t just know these things, they also know about how to work with people, about how the NHS operates and so on. Really, it’s those things that sit around a basic technical competence that make the difference and make your successful in your field.

IM: Yes; one of the things I’ve learnt in the last few years is that the ability to program and think about a problem in the right way and then automate it is extremely rare, and even rarer than I first thought.

The company I work for now has 20,000 people in the IT departments, but the number of real programmers I’ve met is relatively small and I think finding those people is hard – and is becoming harder – because they don’t market themselves or simply aren’t interested in moving jobs. You really have to ferret out the rare skill and convince these people to move on, and that’s a real struggle at the moment.

IM: Yes, broadly. I’ve found that the real challenge lies in the fact that when people say ‘DevOps’ an engineer will say it means one thing, and a business leader will think it means another.

For instance, a technologist will think it means using things like Docker and being on call, whilst a leader will want to use it make things simpler for an organisation and reduce cost, and whilst those things aren’t in conflict with one another, if you don’t have senior management aware of what you’re trying to achieve then it makes it even harder to instil a DevOps culture.

A good rule of thumb I heard a while back was that whenever everyone says they’re doing DevOps the first thing someone should ask is “how did the conversation with HR go?”. If that individual says they “what conversation” then you know that they’re not really doing DevOps; to change an organisation in that way, and to truly change how you work, there is going to be an impact on people and HR needs to be involved.

The other challenge is if you have people in your organisation who aren’t interested in programming, there is an inherent limit to what you can do with DevOps, and you might need to get rid of a lot of people. Again, this is where it comes back to having the support of the senior leadership and HR who need to be driving the move to DevOps.

I have, in the past, tried to encourage good practice in run books and documentation, and my success has been mixed.  Usually failure to change culture is associated with a lack of authority on my part; when I’ve had the ability to, say, fire someone or make them get behind me in other ways then the process of change is a lot easier. So really, you need that senior leadership support because DevOps is not just using or suggesting processes or technologies, it’s about putting it together and making it work by seeing it through.

IM: I’ve seen agile drives at a number of organisations, with mixed outcomes. One of the main drivers of failure is due to senior leadership not knowing what’s going on on the ground. So, whilst they can say we need to be more agile and do more sprints, when you actually talk to people and realise the constraints they work under, you see that that doesn’t really work because of regulations and organisation structures.

We can do agile in the sense that we use Jira or run sprints, but the real change is much more fundamental if there’s no real engagement from management with their teams then you’ll struggle to make a real change I have actually written about this conundrum previously in my blog as it’s something I think is really key to getting this change right.

IM: I think DevOps represents a real change in software, which is reflected in the technology changes of the last 30-odd years. If we go back 30 years you were delivering software by writing something and putting it on a CD and sending it through the post, and now everything is done on the server side and delivered through APIs. As a result, development and operations have truly become one thing, so I don’t think DevOps is a hype, but it does reflect a real and genuine change in the industry.

In reality, one of the things that strikes me – and that I didn’t speak about in public for a long time – was how companies actually haven’t got this nailed. In the first talk I gave I felt like a fraud by admitting people hadn’t gotten DevOps right, but everyone agreed.

I see this where I work now; people get things right usually because a particular challenge forced them to confront it and focus on it. The simple truth is that sometimes businesses will get things really right, and sometimes businesses won’t, and I encourage people not to believe the hype about how people have solved all their challenges and problems, because the reality is never as rosy as it’s painted.

IM: No, I don’t think that can work. It goes back to the issue of culture; you can’t just repeat what someone else has done because if you haven’t been through the same pains of getting your organisation right then your heart won’t really be in it. Working in financial services there is a strong collective memory of a certain incident in 2008, and no one wants that to be repeated, so every technical change is filtered through a lens to reduce the risk of this happening.

So, we can’t just say we’ll do what Google or Netflix is doing, because it just wouldn’t work. You can’t just copy something, you have to be really empathetic to what your business does and what changes are being made, and that involves patience and a true understanding of why things the way they are.