The devops movement is well and truly mainstream, but what's next? Where do we go from 'devsecops'? And will the culture finally kill off the traditional operations team, like has so often been claimed?
Read on for our devops predictions for 2018.
Will the ops in devops finally be pushing up the daisies in 2018? Owen Garrent, head of products at NGINX says of course not.
"Traditional monolithic applications will be with us for many more years, and many organisations will continue to develop new applications in this fashion," Garrent says. "Where the role of 'traditional ops' is threatened, smart staff will see the way that the industry is changing and find ways to insert their hard-earned knowledge into new devops processes."
But, retorts Mandi Walls, technical community manager EMEA at Chef, yes, many of them will be retired, especially "if we're thinking about 'traditional ops' being rack-and-stack," she said.
Mainstreaming devops: where will change come from?
Devops is "largely mainstream" now, according to Walls at Chef. However, at its core devops stands for a cultural shift within an organisation.
"We've seen the sort of monetisation of buzzwords that happens when a paradigm gains speed," she adds, tongue in cheek. "As well as other interesting indicators like devops certifications that point to more organisations being aware of devops, but possibly not all it might entail."
That doesn't mean that certain industries aren't lagging when it comes to embracing devops, namely "those that aren't technology first but technology dependent," Walls said.
"We've seen technology take an increasingly important role in everything from banking to healthcare to education to construction, while lagging industries include insurance and utilities – heavily regulated environments where the constraints have bred an ecosystem of specialised practitioners. These industries look like they may eventually move en-masse when their baseline concerns have been satisfied by a specific solution."
Walls believes that in an ideal world large change initiatives will be "centred around specific business outcomes," as well as having support from the executive leadership, and to "include the teams and individuals affected by the change."
"It's not unlikely that in some organisations these initiatives could be started by development organisations in order to facilitate better response to some organisational goal," Walls adds. "Some changes that we are already seeing, like migrations to new version control systems, have been largely within the workflow of development teams in service to increasing throughput and efficiency."
Lately we have seen 'devsecops' gaining traction, so what's next, if anything? Opinions differ: Andrea Hirzle-Yager, head of IT at devops-friendly financial service business Allianz thinks that ideally she'd throw architects into the mix.
"The close collaboration between devs and ops is increasingly gaining importance – our cloud project was so successful because from the start colleagues from all departments were involved," Hirzle-Yager says.
"For me, the next bundle of letters is 'DevSecArchOps' - it is extremely important that these four groups, developers, security, architects and operations work well together. The more the IT architects are involved, the better. The ideal scenario would be architects who know how to code as well."
But Simon Ratcliffe, business strategist and evangelist at IT services company Ensono believes that the movement will go back to its roots.
"I see the culture going back to the Japanese philosophy of Kaizen - small incremental daily improvements," Ratcliffe says. "As an industry, we're guilty of making IT a monolith, and in fact the massive sweeping changes are not what we need.
"This seems to come from the business need to have IT 'sorted', which suggests there is an end point that can be reached. IT is never 'sorted', it is an ongoing saga. Ideally, we should be applying the devops processes of iterative changes to devops itself."
Open source leads the way
It's important to reiterate that devops isn't something you can buy off the shelf, says Owen Garrett at NGINX.
"It's a rich combination of products, services, and open source components, stitched together in the way that best suits each business, with custom integrations," he says. "Going down the 'buy in devops services' route will be expensive, but for some businesses who have clear and urgent goals, that will be necessary."
The open source factor provides proven technology, a wide ecosystem of solutions and support, Garrett says, as well as making it easier to hire and retain talent. Plus you get control over the direction of the technology you're using.
Of course, the vendor support route means quick and confidential technical support, plus access and influence over a roadmap, some proprietary features you might not have, as well as managed updates and security patches.
But beware vendor snake oil: devops comes 'from within'
Carlos Sanchez, an engineer at CloudBees reasserts that devops isn't about the tooling but the culture. That should be a "culture of shared goals and no finger-pointing, but collaboration to resolve issues and, ultimately, accelerate the software."
"In that sense, it is very unlike the cloud and VM tools that are purpose-built for cloud and VM applications. With that caveat, there is a common set of tools found in many companies that have successfully adopted devops.
"Some examples are Maven, Jira, Jenkins, CloudBees, Git, Puppet, Chef, Docker, Subversion, Nexus, Ansible, Vagrant… These are not 'devops tools' but they are tools that enable companies to optimise their software pipelines and transform to a devops culture."
Jason Yee, technical evangelist at Datadog, agrees that there is a fundamental difference between the proprietary tooling providers and the early days of cloud or VM.
"In the early cloud days, we saw organisations blindly move into the cloud, only to see their infrastructure costs skyrocket compared to what they had been managing on-premise," Yee says.
"This was largely a result of not understanding what they had or what they were buying. So, from that perspective, yes, we will see the same as companies try to buy DevOps from vendors. There are amazing tools and services that you can buy, but if organisations aren't first getting their teams adopting devops culturally, many of those tools and services will have poor ROI."
And Patrick Hubbard of SolarWinds believes that businesses thinking of devops as a vendor landscape are actually contributing to the lag in adoption.
"Looking at devops as a typical vendor solution is significantly contributing to the ongoing lag in adoption. There's no such thing as devops-in-a-box and CIOs must stop shopping for it. Devops comes from within."