How do you start with DevOps?

Start small and insist on more money, panel agrees

What are the first steps in DevOps? That was the central theme of the first panel at Computing's annual DevOps Summit, held today at the Hilton Tower Bridge in London. While the panel's title was ‘Legacy, Enterprise and DevOps', panel members Nic Ferrier (head of DevOps, HSBC); Stuart Miller (development team lead, LV=); Barrington Clarke (DevOps lead, Zurich Insurance); and Stephen Walters (lead solutions consultant, Micro Focus) kept returning to the topic.

Clarke recommended choosing a small app to start with - and, unlike Zurich, making sure that it's small (not "a whirling maelstrom of code" under the hood, as his team discovered). Walters agreed but added that it is important to have an appreciation for all parts of software delivery lifecycle before getting involved in a DevOps way of working.

Ferrier also recommended starting small; the problem, though, is that everyone - especially in a large organisation like HSBC - wants to do a massive thing. You need to be resolute about doing small things, and keep doing them. For example, committing to pushing out more releases but fewer incidents; either one is easy to do individually, but both together "move the dial".

A common DevOps mantra is ‘It's not about the tools, it's about the people'. Choosing the right tools is important, though - and it's equally important to start off small. Ferrier said that HSBC's mainframe team bought a powerful, expensive mainframe tool when DevOps began to be implemented, but his team realised that they could just run Jenkins on their Z series - and implementing that, although it was complex, was much more efficient and collaborative.

You're never done, ever - Nic Ferrier

"The really difficult thing [about DevOps] is that you're never done, ever, but managers don't want to hear that," said Ferrier. This concept is difficult but important to get across to managers and business leaders, especially when it comes to securing budgets.

"Normally things are funded through the prism of projects, and they have a beginning, a middle and an end," said Clarke. "Initially, our DevOps was funded through projects, but I had to have multiple meetings with management and tell them ‘You are killing DevOps,' to get them to fund it through webstreams; I needed to be able to sit in a room somewhere with an agile budget."

Budgets might mean starting with a very small team: Clarke began with just four business engineers and a data specialist. There was no UI/UX expert, because of budget concerns, and that was fine - initially. However, the UI and UX are important to DevOps, so you will want such an individual soon.

With such a small team, Clarke found that he ran out of resources very quickly, because people got very excited when they realised how fast they could push a project live and made a lot of demands. "You need to expand fast," he said. For his part, Clarke used the team to promote DevOps practices around Zurich.

Returning to UI, Miller said that it was best to work with people who are not obsessed with "the latest whizzbang." It's important to keep any sort of UX simple, structured and usable. Ferrier had a more succinct way of describing it: "The problem is that people are always trying to do a good job." The worst UIs are those built by someone who is working too hard to make it perfect; the best, he claimed, are those made by lazy people who rely on their own learned experience and will just make it ‘good enough'. "Perfect is the enemy of better," he added - a quote that rather perfectly suits DevOps (although probably wasn't the original context that Voltaire was thinking of).