The topic of DevOps has dominated discussions at many of the major IT conferences this year, with suppliers and analysts lining up to warn enterprises about the business risks of failing to adopt a more agile approach to software development.
Enterprises that want to maintain their competitive edge, it’s often claimed, can no longer afford to embark on large and lengthy software development and testing cycles, presided over by disparate groups of developers and IT operations staff.
Instead, software should be created in a more collaborative way with developers and operations working in small teams to test and release updates and new products at a faster rate than ever before, using automation and monitoring tools.
But, for enterprises entrenched in the old way of software development, adopting a DevOps style of working isn’t going to be easy for CIOs without buy-in from the whole IT department.
"On the face of it, DevOps sounds brilliantly straightforward, but the worlds of 'development' and 'operations' hide a variety of job functions. Moreover, the teams in these camps have traditionally had very little interaction with one another," says Gautam Mitra, founder of IT training company Unicom Seminars.
"It's relatively easy to put the right tools and processes in place, but you can't ignore culture – and getting these two camps to work together and collaborate calls for a big change."
Jumping in with DevOps
Ordnance Survey, while famed for the production of paper-based maps, also develops software for its in-house teams of cartographers and surveyors, government agencies, utility companies and building firms.
Keith Watson, agile delivery manager at Ordnance Survey, has gone down the DevOps route as part of a wider push to improve communication and collaboration between its various teams.
In the past Ordnance Survey ran a software infrastructure team and a second team for building the environments required.
"There was a degree of customer dissatisfaction with the service we provided, in the sense that we couldn’t keep up with the demand from developers, which meant there were long lead times in providing them with environments; and they were created in a manual way with semi-automated scripts," says Watson.
"So, not only did it take us a long time to provide these individual environments, sometimes they weren’t always the same."
This often led to disagreements between the software development and infrastructure building teams, as the environments they delivered didn’t always quite fit the bill.
To rectify this, Watson created small groups of developers and infrastructure architects, while doing away with the ticketing system used to communicate requests between these groups.
"After they got into the teams, the value of sitting everyone next to each other became apparent very quickly – not only in understanding their requirements but they all got to see that the developers and the environment team were real people and they got on quite well," explains Watson.
Changing the technology game
Embracing a DevOps way of working may sometimes require the overhaul of a company’s IT infrastructure, and many organisations advocate moving to the cloud as an important first move.
Cloud services – such as Amazon Web Services EC2 – can provide DevOps teams with quick, on-demand access to the computing resources required, affording them a level of agility they might not get from on-premise technologies.
"Cloud, much like DevOps, emerged as a way to improve flexibility in organisations, helping projects react more quickly to changing circumstances," Unicom's Mitra explains.
"There’s some debate about whether cloud is driving/facilitating DevOps or if DevOps is prompting the need for cloud. No two implementations will be the same so, depending on the case in hand, either scenario could hold true – but what is clear is that DevOps and cloud are intricately linked."
But that’s not to say cloud is a necessity for DevOps success, says Jon Cowie, staff operations engineer at online marketplace Etsy, which has taken a DevOps approach to software delivery since 2009. Cowie says the approach allows it to update the site every 20 minutes with no loss of service for its 20.8 million users.
While he admits the cloud has its place in some DevOps deployments, his firm’s operations are underpinned by on-premise infrastructure in its own datacentre.
"Because of the way our site traffic works, we don’t have to deal with bursts of traffic, because our traffic pattern follows relatively predictable seasonal trends, and we are actually able to predict with a high degree of accuracy what our traffic is going to look like at any given point," he says.
"If we were dealing with bursty traffic like Netflix and sudden peaks in demand, it’d be a much different story."
Getting started with DevOps: Show results to overcome managerial scepticism
Barry Crist, CEO of IT automation vendor Chef, says the best way to get started with DevOps is to line up a small but non-trivial project that would lend itself well to the DevOps approach – and instruct the team to get stuck in.
"It’s difficult to change a way of thinking sometimes, as it involves altering how people interact with technology so they can adopt this high-velocity, small-batch approach," he says.
"That’s why the best way to drive change is, instead of having a very conceptual conversation about things, to get people from across the whole IT stack and get them working on one thing. The results and benefits will become readily apparent."
This approach is also crucial for winning over sceptics in senior management fearful about the impact of the change on the rest of the organisation.
"The funny thing with large enterprises is, a lot of organisations will tell you that 'Big Bang' IT projects do not work – and yet a lot of organisations persist in doing it," says Crist.
"But the benefit of DevOps is that – with the help of automation – you can simultaneously increase quality, the rate of innovation and then pick up other things, such as better consistency in your products.
"Imagine being an executive at a company trying to argue against achieving all those things. It’s a completely redundant discussion." he adds.
Appraise aims before investing in DevOps
In Ordnance Survey's case, there wasn't much in the way of technology preparation, recalls Watson, as the organisation was already using internal clouds, side-by-side with Microsoft Azure and Amazon Web Services, in developing software.
Even if they weren't, Simon Parkes, an infrastructure architect at Ordnance Survey, says that wouldn’t have stood in the way of the organisation's DevOps push.
"There is a danger – particularly when you look at other case studies on DevOps – that technology can end up being a barrier to getting going, because it requires a lot of upfront technology investments in building out cloud capabilities," says Parkes.
"Because ours was a cultural and working practice change, first and foremost, we took the view of just finding a project and getting started straightaway, instead of getting too bogged down in the technology groundwork."
Clearly, going down the DevOps route requires a lot of business and technology preparation – and it’s not necessarily a way of working that will suit every organisation.
"There’s not a definitive end to DevOps – it's a way of approaching development – but have a good idea about what you hope to achieve before implementing the change, as the investment can be high," cautions Mitra.
"In other words, don’t do it just because everyone else is."
