Building apps for the cloud? Want to become more efficient? DevOps can offer an excellent way forward. But, be careful, says Dootrix’s head of engineering, Craig Rowe. Simply calling something DevOps doesn’t make it so.
Lots of words and phrases get emptied of meaning over time. Once, ‘artisanal’ meant something made by someone who had mastered their craft. These days it can mean little more than putting a picture on a label of a bloke with a lumberjack beard. It’s been debased by misuse.
The same applies to buzzwords in software engineering. Agile development began very much as a culture or mindset, and then, all too often, it can end up being tools – reduced to little more than a performance with story cards that people hold up, or ceremonies. Often someone will say ‘I’m an agile practitioner’, when what they mean is that they know how to run scrum ceremonies or another element of wider agile culture.
DevOps – how it is commonly interpreted
DevOps is another such buzzword. DevOps is, at heart, a pretty straightforward concept. You bring together the application development, the automation of deployment and ongoing live monitoring so that they inform each other throughout the project.
Occasionally you’ll meet organisations that are building applications for the cloud that know they would benefit from a DevOps approach, and therefore hire people describing themselves as DevOps engineers. However, what that can mean is they are involved heavily in making automated deployment pipelines for code to get from development to production. It doesn’t necessarily mean that they have experience as an application developer writing code or making an application.
It’s all too easy to end up with a group of application developers and another group of automation of deployment people – and never the twain shall meet.
DevOps as a culture for better outcomes
There is a better way. The approach Dootrix prefers is based on two things; skills and mindset. At Dootrix we almost never hire a ‘DevOps person’ – i.e. someone whose skills in fact lie almost wholly in automation, rather than encompassing a wider set of skills. Rather, we look for people who are not only able to do both application development and automated deployment, but who are also prepared to treat every task as important and part of a process that ends with an application working optimally in the cloud. It is also very much about ownership; if the pager goes off at midnight, you want a team whose members don’t see things as ‘someone else’s problem’.
By having a multi-skilled team, application development is undertaken with an eye firmly on deployment and support; the deployment being performed with a thorough understanding of how the app is built. You want your application developers not just writing the code that deploys the app, but also heavily involved in the deployment and the provisioning of the live services, as well as managing them afterwards. Knowing that you can’t pass the buck if anything breaks really focuses the mind.
It also makes operational sense. You might need an intensive period of work on automated deployment at the outset of a project and thereafter in fits and starts, however the bulk of the effort will almost always be on development. You don’t want a dev team waiting on the automation people or the automation people twiddling their thumbs through most of the project.
Yes, you may find you have people on your team who feel that, for example, editing a JSON file that defines the infrastructure is really boring and not as valuable a use of their time as cranking out features in JavaScript, C# or Java, but that mindset is what you’re aiming to grow beyond.
Change management required to underpin the move to a DevOps approach
So, how do you move from where you are now, perhaps with a team that’s mainly skilled in application development, to a DevOps approach and mindset? A key part of this is change management. Whoever is leading that change will need to command the respect of those who are trusting them to show the way.
We find it helps to have an experienced point of reference on, or available to, the team; a senior colleague who understands all the engineering challenges and how to bring them together.
If you don’t already have such a person, you’ll want someone with at least five years’ experience – ideally more – in both the technical and cultural aspects of DevOps. You have the option of hiring that person – Dootrix has helped a number of clients recruit the right people – or of bringing in that expertise on a consultancy basis. At Dootrix, we have decades of experience under our belts and can help with both skills transfer and organisational change.
Yes, there is some front-loading as you make the transition to DevOps, but most of us with long experience in the field would agree that, in the medium to long term, it’s worth it; your projects will run better and the end products will really benefit.
