DevOps will shift from being a niche approach to application development and deployment and move into the mainstream over the next 12 months or so, according to Gartner.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In fact, so appealing will this grassroots philosophy prove that it will be taken up by a quarter of Global 2000 organisations, creating a software tools market forecast to leap in size by 21.1% from $1.9bn last year to $2.3bn in 2015, the market researcher believes.
Such interest is expected to be generated pretty much across the board. Until recently, DevOps was employed mainly by cloud providers or early adopters in the financial services or telco worlds simply wanting to experiment.
Now adoption is starting to spread more widely, at least in pockets, if not on an enterprise-wide basis, into other sectors ranging from manufacturing and retail to pharmaceuticals and life sciences.
Despite take-up being on an "upwards curve", Ben Saunders, DevOps and continuous delivery practice lead at IT consultancy Xceed Group, points out that a lot of organisations are still "a bit sceptical" about it all.
Ben SaundersXceed Group
Not only is the "movement still in its infancy", which means people are unsure whether it will be just another IT industry flash-in-the-pan, but there is also no single agreed definition as to what it actually is. "So a key challenge for a lot of people is just where to start," says Saunders.
He describes DevOps as being about enabling application development and operations groups to work together, so that any issues can be tackled as they emerge rather than leaving it all to deployment time.
"It's all about sharing and team cohesiveness so that you can develop at pace," says Saunders. "The idea is that the operations team feeds back any problems about how the application is behaving to the development guys, so that they can make sure they're creating the best possible solutions."
And it is the idea of "pace" that is at the heart of the matter. Jay Lyman, research manager at 451 Research, explains: "It generally starts with speed, time to deploy applications, time to market, competitiveness -- that kind of thing."
Demonstrate the benefits of DevOps
But as organisations continue down this route, he says, they often discover that, as their activities become more efficient and responsive -- at least partially due to increased levels of process automation -- they gain significant cost savings, as well as benefits in human resources (HR) terms.
"Organisations, and large enterprises in particular, want to attract and retain good talent, but if they're viewed as fuddy-duddy, they won't appeal to or keep the cool kids," says Lyman. "And there's real demand for this kind of expertise."
But that's not to say that everything will be rosy in the garden when adopting a DevOps approach. The key challenge, for many, is change management and simply getting staff to buy into the concept, mainly on the operations side as this is predominantly a grassroots developer's movement.
Read more about DevOps
- What is DevOps?
- Clive Longbottom: virtualisation, cloud, software-defined everything, big data, everything as a service -- are all forcing IT to change and look at a new beast called DevOps
- What's the best way to come up with an accurate DevOps definition? Explain what it's not, application development experts say.
"There's always resistance at first because people don't like change, especially if they think it'll have a negative impact on them," says Xceed's Saunders. "So if you say to a tester, we're going to automate a test case, the fear is that they'll automate themselves out of a job."
This means it is important to demonstrate the personal benefits of a DevOps approach, for example by providing staff with metrics gleaned from a pilot project to show just how much time has been saved in simply fire-fighting.
Giving the whole team incentives in the form of a joint bonus if they get a project out faster can help too.
But it is also important to bear in mind that DevOps, by its very nature, is not appropriate for all kinds of development. For example, given the fact that it generally goes hand-in-hand with agile, it is best suited to creating composite web or mobile apps that are continually updated, have lots of small releases and short delivery timescales.
Using it to build monolithic batch mainframe programs, or even traditional client-server ones such as Microsoft's Excel, would prove a mismatch of styles.
Nonetheless, says 451's Lyman, "DevOps is here to stay as it represents the new way of doing things".
While he acknowledges that there will probably be resistance, he also believes that the benefits in terms of responsiveness when apps don't work or sites go down means that it will start to become a requirement.
"Once rivals start using it, organisations will have to respond and so I think it'll be around to stay," Lyman concludes.
Case study: Postcode Anywhere
"DevOps is the future," believes Mike Cook, chief information officer of Postcode Anywhere.
"As the tech industry increasingly goes towards much quicker release cycles, the business inevitably has to change to deliver what users want -- and using traditional waterfall methods, you'd struggle to support that," he explains.
The organisation, which was set up in 2001 and provides customers such as Tesco, Manchester City Football Club and Fiat with cloud-based address management services, started transitioning to a DevOps way of working in early 2014.
The move came as part of a wider review of all the firm's business processes to support higher rates of business growth and took 12 months in total.
During the first stage of the initiative, the IT department "isolated" a series of cross-functional product development teams, identified their roles and introduced them to agile software development methods.
"Agile is a good fit with DevOps," says Cook. "It's not inherent, but it goes hand-in-hand as they're both about making quick decisions and ensuring collaboration and good communications."
Team members were then asked to apply for the positions of product owner, who acts as the voice of the customer, and scrum master, who makes sure the team stays on track in terms of producing deliverables on time.
"You've got to ensure the right people are in the right roles. The aim is to help with scalability and so the people piece is absolutely key -- it can't be over-stressed," says Cook.
But just as crucial in a cultural change project of this type is helping staff from both the development and deployment sides understand their role in the process, how it will affect their jobs and also how it will benefit them. The aim is to ensure that they buy into the situation and do not feel threatened.
The second step was to create an overall project team to ensure everyone was aligned with company goals. As a result, a full-time project manager and assistant were taken on to "ensure that messages were cascaded down and everyone was on the same page strategy-wise, from the board to the development teams," says Cook.
The final step was to standardise toolsets by introducing Atlassian's Jira issue and project tracking software and Confluence team collaboration package.
Mike CookPostcode Anywhere
"The pricing wasn't prohibitive and it's very simple to use," says Cook. "It's fundamental to ensure your toolset is adopted well as very complex tools will slow you down."
The change has been hugely beneficial in helping Postcode Anywhere achieve its goals. The time to produce software releases has now plummeted from six months to two weeks, for example, which has greatly minimised business risk.
"There's always a risk when you press the 'run' button, but if you can break things down into lots of tiny risks rather than a single big one, the danger of brand damage is minimal compared to what it would have been," says Cook.
Perhaps the biggest benefit of all, however, has been creating a more motivated and happy IT department. "Because you devolve responsibility for decision-making to the team and are no longer dictating to them, personal empowerment is massive and really helps with job satisfaction -- and that really is positive," Cook concludes.
Case study: DigitasLBi
Without having introduced a DevOps way of working, global marketing and technology agency DigitasLBi believes it could never have delivered new releases quickly enough to hit schedules when working on a major client project.
The agency is just over one year into a three-year programme to create a global customer engagement portal for the Renault-Nissan Alliance. After having used DevOps internally, the alliance had indicated in its request for proposal document that employing it here was a key requirement.
"It was an agile-based programme of such pace and scale, and with so many releases, that it needed a particular approach," says Adrian Le Grand, service delivery director at DigitasLBi. "DevOps was a good answer as the key issue was speed. I can't imagine how we could have done it any other way."
The agency was already familiar with DevOps as it had been using some tenets more informally on smaller projects elsewhere. But this was the first time that it was formally adopted as the key operational philosophy.
As a starting point, two DevOps enthusiasts, one a Java developer and the other an architecture specialist from the firm's managed hosting and infrastructure group, were asked to form a virtual team to co-ordinate configuration and deployment management and release.
The team comprised a total of six people -- three programmers and three from the infrastructure group -- but members varied as they were rotated in and out as required.
"DevOps is a grassroots thing and so probably a bit difficult to manage from the top down, but we were keen to leave it that way," says Le Grand. "To stand a chance of success, you have to get your key technologists interested and let them lead -- although you also have to be a bit careful that it doesn't turn into a sandpit."
Another important consideration was ensuring that the team had a shared understanding of how development, testing and deployment processes worked.
"They're not processes in the same way that they are in ITIL," says Le Grand. "It's more a set of principles or guidelines that you need to monitor, reflect on and correct -- for example, keeping environments as uniform as possible so there are no surprises in production."
Uniformity of technology use, which includes infrastructure automation tools such as Chef, was considered equally important to ensure consistency.
Adrian Le GrandDigitasLBi
But despite such desire for consistency, Le Grand points out that large amounts of change were inevitable, particularly in regard to team roles and ways of working.
"For some people, it'll look like you're giving them more work or asking them to do things they're not used to, which can seem daunting if they're working to exhilarating timescales," says Le Grand. "So it's important to articulate the value -- that is, 'we'll be doing it much faster, there'll be fewer surprises, less stuff will break and hopefully the quality will be better'."
Overall the chance to develop new and marketable skills has put a "bit of a spring in people's steps" and the response has been "pretty enthusiastic", he adds.
"I would certainly use DevOps again on projects of this type," Le Grand concludes. "But in a few years, it's likely that projects will all be this type -- that is, big agile ones where you need to build constantly changing products and platforms quickly. So yes, I think DevOps probably is the future."