Senior DevOps Manager at Wipro Consulting, Andrew Hardie, cited obstacles to DevOps at the National DevOps Conference last month.
Introducing DevOps is a big, challenging and complicated process. There are many obstacles, technical and organisational, that are likely to get in the way. Hardie highlighted some of the anti-patterns that are going to cause problems. These range from apparently simple technical items that can have big consequences down the line to the far greater people and organisational behaviour patterns that have to be confronted and changed.
Just because you’re “doing agile” doesn’t mean you can just overlay DevOps on top of it – the two are very different and not directly related. The decision has to be made as to how far you want to go with DevOps – are you ready for true “continuous delivery” and, if so, what anti-patterns are going to stop you? “To embed or not to embed, that is the question,” said Hardie.
Of course, tech is complicated and ever changing, but Hardie believes that it’s the culture and work pattern changes that are the hardest things to accomplish. Developers, ops, security, programme managers and delivery managers play a huge part in DevOps transition.
“If management have difficulty understanding certain tech it can be hard; they appear to worry about what is an information control, like agile, and CI/CD. They should understand and support the benefits and should be used to push organisational change top-down,” advised Hardie.
“The solution is to set goals, set targets, to buy-in and support essentials,” he added.
DevOps is about speed, and speed can deploy bad effects as quickly as the good. Microservices and Docker can bring extra security challenges, noted Hardie.
“Agile and DevOps together is a big challenge. Without agile DevOps is hard. Be very clear about what it is you want to achieve with DevOps – don’t do it because it’s fashionable. Make sure ABCs are helping achieve what you want to do, not what they want,” said Hardie.
Further concluding to other DevOp enthusiasts that tech is hard; they should start with codebase (if possible), shouldn’t introduce agile separately, should make all tests automatic wherever possible, and allow defect count reduction or code quality targets.
Written by Leah Alger