What’s next in DevOps: 5 trends to watch

The term “DevOps” is typically credited to this 2008 presentation on agile infrastructure and operations. Now ubiquitous in IT vocabulary, the mashup word is less than 10 years old: We’re still figuring out this modern way of working in IT.

Sure, people who have been “doing DevOps” for years have accrued plenty of wisdom along the way. But most DevOps environments – and the mix of people and culture, process and methodology, and tools and technology – are far from mature.

More change is coming. That’s kind of the whole point. “DevOps is a process, an algorithm,” says Robert Reeves, CTO at Datical. “Its entire purpose is to change and evolve over time.”

What should we expect next? Here are some key trends to watch, according to DevOps experts.

1. Expect increasing interdependence between DevOps, containers, and microservices

The forces driving the proliferation of DevOps culture themselves may evolve. Sure, DevOps will still fundamentally knock down traditional IT silos and bottlenecks, but the reasons for doing so may become more urgent. Exhibits A & B: Growing interest in and adoption of containers and microservices. The technologies pack a powerful, scalable one-two punch, best paired with planned, ongoing management.

“One of the major factors impacting DevOps is the shift towards microservices,” says Arvind Soni, VP of product at Netsil, adding that containers and orchestration are enabling developers to package and deliver services at an ever-increasing pace. DevOps teams will likely be tasked with helping to fuel that pace and to manage the ongoing complexity of a scalable microservices architecture.

2. Expect fewer safety nets

DevOps enables teams to build software with greater speed and agility, deploying faster and more frequently, while improving quality and stability. But good IT leaders don’t typically ignore risk management, so plenty of early DevOps iterations began with safeguards and fallback positions in place. To get to the next level of speed and agility, more teams will take off their training wheels.

“As teams mature, they may decide that some of the guard rails that were added early on may not be required anymore,” says Nic Grange, CTO of Retriever Communications. Grange gives the example of a staging server: As DevOps teams mature, they may decide it’s no longer necessary, especially if they’re rarely catching issues in that pre-production environment. (Grange points out that this move isn’t advisable for inexperienced teams.)

“The team may be at a point where it is confident enough with its monitoring and ability to identify and resolve issues in production,” Grange says. “The process of deploying and testing in staging may just be slowing them down without any demonstrable value.”

3. Expect DevOps to spread elsewhere

DevOps brings two traditional IT groups, development and operations, into much closer alignment. As more companies see the benefits in the trenches, the culture is likely to spread. It’s already happening in some organizations, evident in the increasing appearance of the term “DevSecOps,” which reflects the intentional and much earlier inclusion of security in the software development lifecycle.

“DevSecOps is not only tools, it is integrating a security mindset into development practices early on,” says Derek Weeks, VP and DevOps advocate at Sonatype.

Doing that isn’t a technology challenge, it’s a cultural challenge, says Red Hat security strategist Kirsten Newcomer.

“Security teams have historically been isolated from development teams – and each team has developed deep expertise in different areas of IT,” Newcomer says. “It doesn’t need to be this way. Enterprises that care deeply about security and also care deeply about their ability to quickly deliver business value through software are finding ways to move security left in their application development lifecycles. They’re adopting DevSecOps by integrating security practices, tooling, and automation throughout the CI/CD pipeline. To do this well, they’re integrating their teams – security professionals are embedded with application development teams from inception (design) through to production deployment. Both sides are seeing the value – each team expands their skill sets and knowledge base, making them more valuable technologists. DevOps done right – or DevSecOps – improves IT security.”

Beyond security, look for DevOps expansion into areas such as database teams, QA, and even potentially outside of IT altogether.

“This is a very DevOps thing to do: Identify areas of friction and resolve them,” Datical’s Reeves says. “Security and databases are currently the big bottlenecks for companies that have previously adopted DevOps.”

4. Expect ROI to increase

As companies get deeper into their DevOps work, IT teams will be able to show greater return on investment in methodologies, processes, containers, and microservices, says Eric Schabell, global technology evangelist director, Red Hat. “The Holy Grail was to be moving faster, accomplishing more and becoming flexible. As these components find broader adoption and organizations become more vested in their application the results shall appear,” Schabell says.

“Everything has a learning curve with a peak of excitement as the emerging technologies gain our attention, but also go through a trough of disillusionment when the realization hits that applying it all is hard. Finally, we’ll start to see a climb out of the trough and reap the benefits that we’ve been chasing with DevOps, containers, and microservices.”

5. Expect success metrics to keep evolving

“I believe that two of the core tenets of the DevOps culture, automation and measurement, are never ‘done,’” says Mike Kail, CTO at CYBRIC and former CIO at Yahoo. “There will always be opportunities to automate a task or improve upon an already automated solution, and what is important to measure will likely change and expand over time. This maturation process is a continuous journey, not a destination or completed task.”

In the spirit of DevOps, that maturation and learning will also depend on collaboration and sharing. Kail thinks it’s still very much early days for Agile methodologies and DevOps culture, and that means plenty of room for growth.

“As more mature organizations continue to measure actionable metrics, I believe – [I] hope – that those learnings will be broadly shared so we can all learn and improve from them,” Kail says.

As Red Hat technology evangelist Gordon Haff recently noted, organizations working hard to improve their DevOps metrics are using factors tied to business outcomes. “You probably don’t really care about how many lines of code your developers write, whether a server had a hardware failure overnight, or how comprehensive your test coverage is,” writes Haff. “In fact, you may not even directly care about the responsiveness of your website or the rapidity of your updates. But you do care to the degree such metrics can be correlated with customers abandoning shopping carts or leaving for a competitor.”

Some examples of DevOps metrics tied to business outcomes include customer ticket volume (as an indicator of overall customer satisfaction) and Net Promoter Score (the willingness of customers to recommend a company’s products or services). For more on this topic, see his full article, DevOps metrics: Are you measuring what matters? 

No rest for the speedy

By the way, if you were hoping things would get a little more leisurely anytime soon, you’re out of luck. 

“If you think releases are fast today, you ain’t seen nothing yet,” Reeves says. “That’s why bringing all stakeholders, including security and database teams, into the DevOps tent is so crucial. The friction caused by these two groups today will only grow as releases increase exponentially.”