As demand for ever-increasing flexibility and faster delivery of IT and technology grows, tearing down silos between development and operations is key.
A DevOps culture is emerging to support this drive towards more agile and automated processes, which are replacing long development and testing cycles and delivering faster and better. How to do this and what DevOps really means were among the topics discussed at Computer Weekly’s latest CW500 Club event.
On the surface, DevOps sounds remarkably straightforward, but getting software developers and IT operations personnel, who come from different worlds and traditionally keep interaction to a minimum, to talk and work together can be tricky.
“It’s about getting people to sit together, talk together and have honest conversations,” says CW500 panellist John Fredrickson, online DevOps and cloud manager at Sky. “It’s about getting different teams to talk about what you like to have, what’s working, what’s not working and seeing what you can do about it.”
DevOps requires cultural change
The idea is to enable IT departments to test and release updates and new products faster, increasing automation and monitoring tools. With the emergence of DevOps, suppliers are pumping out different products to help this agile way of working, but Fredrickson warns people not to get too caught up in buying different tools.
“The main challenge is not really a tech challenge, but a communication challenge. If we can get people to communicate and collaborate more, the technology just seems to work,” he says.
“There’s a huge choice of technology for automation, for delivery. There seems to be a new DevOps tool out every week. The constant factor is the people and the teams. If we can get people together to share ideas and see what works, that’s how DevOps is most successful for us,” he adds.
John Fredrickson, Sky
Traditionally, the real problem with delivering technology is hand-offs between teams. To update a product, the job may be passed between several teams, some of which may be “very innovative” whereas others may operate in a different way. This drags out the development cycle and is not really in line with fast delivery.
So how do you solve that? “There’s no magic bullet,” says Fredrickson.
Another challenge is attracting people with the right skills. “One of the problems in the DevOps world is recruitment, and I’m not sure we’ve totally cracked it. Mention DevOps to anyone and it’s an extra 20% in salary. It can be really difficult to retain and recruit the right people,” says Fredrickson.
At Sky, the goal is to get everyone involved in the process. “Our systems talk to each other, so if we roll out a feature in one system, people need to be talking to each other as well,” he says.
To do that, Sky has begun to make a range of the environments on which it delivers services widely available in the business so people can share ideas and innovation.
“That can make us do things a bit quicker,” says Fredrickson.
Development and operations versus DevOps
Another organisation which has embraced DevOps is British Gas Connected Homes. The company, which operates much like a startup, is a fully autonomous unit of its parent, British Gas.
Connected Homes has a complex structure, with a range of products that vary in their maturity levels and product teams that work from different locations in the UK.
When it first decided to embrace DevOps, Connected Homes ran a centralised DevOps team across all its products, but the varied levels of maturity and different technologies made servicing the requirements very difficult, says CW500 panellist Chris Livermore, head of operations at Connected Homes.
Instead, Livermore now has around 14 DevOps engineers embedded in the various teams. To him, DevOps is the collaboration between developers and operations. “You know you are doing DevOps if you have a collaborative DevOps team,” he says.
Chris Livermore, British Gas Connected Homes
“If you have an operations team and a development team, plus a DevOps team that sits in the middle, you have somewhat missed the point,” he adds, although he acknowledges that it could be a way of transitioning to a “full-blown DevOps”.
“I like to see our operations engineers being part of the full lifecycle of the software. They’re as much entitled to have an opinion on how the software should be designed and architected as the architects and software developers,” says Livermore.
He adds that there is clear demarcation between what he expects a technology developer to do and what he expects an operations engineer to do: “In my world, the developer is responsible for the code, and those two teams come together to create the solution. You should be able to move people around; the development team needs to understand operations and the ops guys need to understand the development experience.”
Change processes are often long, laborious and involve various levels of sign-off, but if companies are to keep up with competitors and push out new features and updates quicker, something has to give.
“A bugbear of mine is change control risk management,” Livermore says, adding that he hates change request forms. “I absolutely refuse to complete any kind of paperwork like this. It has no place for me in a world of automated deployment and testing,” he says.
“To me, the change process happens at the development and design part. Releasing a code to live should be a formality. My issue with change control is it has to happen in the right point of the process. The developer should not even be working on a feature if it hasn’t been approved, so that’s where you do the change control.”
The problem, he says, is that when something doesn’t work, it’s easy to fall back to “what you know” and wrap more process around it.
Read more coverage from the Computer Weekly CW500 Club
- At some point businesses will need to invoke a disaster recovery plan, but does it cover everything the modern digital company needs?
- As more things become internet-connected, systems designed to authenticate people now need to deal with machine-to-machine authentication.
At Connected Homes, some of its more mature products have automated change processes, especially those that have full, continuous integration into delivery. Product owners are in complete control over when they release, and can release as often as they want, says Livermore, and the release process is enforced by the automation.
For less mature products that aren’t automated, Connected Homes has an offshore testing centre in India. “However, I think about 20% of that time is spent trying to automate tests, so with every release the idea is that the manual testing gets less and automated more,” he says.
At Sky, the approach is to “be friendly with our change management colleagues”, says Fredrickson. “Some of our teams are happy to do continuous deployments and demonstrate what they’re doing, how they’re doing it and hopefully get buy-in that you don’t need to follow a process, you’ve got the process baked in.”
Sky started off with a compromise that some teams that do small changes would have approval to do that, and adjust the change request when a major change is to take place. “It’s a small victory, you can’t win everything,” he says.
Making DevOps work
Going down the DevOps route requires stamina, determination and, most of all, getting your IT department on board with it.
Fredrickson says making things that used to take a while – such as firewalls and some domain name system (DNS) changes, which used to be process driven – faster and self-service are real wins which “people get quite excited about”.
“Look to see where you can reduce friction in your organisation and see if you can find ways of making things more self-service and make things faster,” he says.