DevOps progress: spotty, siloed and sporadic, but still moving forward

Software industry experts weigh in on whether DevOps has made a difference yet. 'it can appear that there are long periods of inaction. In reality, there's just a bit of a tail to implementation.'
Written by Joe McKendrick, Contributing Writer on

DevOps and agile methodologies have never been more important than now, with the growing complexity and interconnectedness of information technology -- and, even more importantly, enterprise reliance on IT to move forward in markets. These aren't necessarily new concepts; DevOps has been around since for more than a decade, and agile for more than two. But what is new is the intense level of reliance on software to connect with customers, keep employees engaged, and to track events and developments across markets. 

Photo: Joe McKendrick

To get a sense of how things are progressing, I went out to industry leaders and experts to gather their perspectives on how and whether DevOps and agile -- two intertwined methodologies -- are serving the needs of today's digital organizations. Here is what Grant Fritchey, DevOps advocate at Redgate Software, Raj Patnam, VP of global solutions for ScienceLogicAlyson Simkins, director of developer operations at Catalytic, and Rick van Galen, security engineer with 1Password, and  have to say on the matter.  

DevOps: Everyone says they are pursuing DevOps, but what has been the reality on the ground? Is it spotty, sporadic or cohesive? 

Grant Fritchey, DevOps advocate at Redgate Software: "The reality is that while, to a degree, the growth of DevOps and similar automation mechanisms seems sporadic, the trend is towards more and more adoption. Because there is a lag between deciding to implement structural changes to the way software is delivered and the actual delivery of software using these new mechanisms, it can appear that there are long periods of inaction. In reality, there's just a bit of a tail to implementation."

Raj Patnam, VP of Global Solutions, for ScienceLogic: "The reality is every organization is pursuing DevOps, but they are all pursuing it in different ways and with varying levels of gusto. Generally, we see an evolution from DevOps starting almost a skunkworks type operation where they're put off in their corner to build then operate a single application or function for the business. But the level of this effort differs from company to company, and many still have DevOps teams that are completely siloed from the rest of the business."

Alyson Simkins, director of developer operations at Catalytic: "DevOps is not a bright and shiny feature, and oftentimes the impression is that if things are working as-is, there isn't a need to prioritize the work. But the reality is that DevOps should be iterative and agile. In a world where software development is adopting a very agile approach, legacy DevOps implementations are neglected instead of growing alongside the rest of the software development lifecycle process. Since there isn't a direct monetary value tied to an improved DevOps flow, it is not an area that is first looked to when allocating engineering resources. The reality is, however, that an efficient and concerted DevOps workflow indirectly provides immense value."

Rick van Galen, security engineer with 1Password: "DevOps purists will say that things are not moving fast enough, and that people are not taking the principles far enough. And they're probably right. Moving forward from old to new modes of working will always be spotty, sporadic and non-cohesive."   

Anything being missed with DevOps efforts? If so, what are the missing pieces to building DevOps environments and workflows?

Fritchey: "The one thing missed in a lot of DevOps efforts isn't so much missed, as skipped because it's hard: databases,. Due to challenges that data presents, from the need for persistence, to data size, to regulatory compliance, databases are frequently missed, sidestepped or just ignored. There are solutions to the challenges, but adoption is still growing slowly."

Patnam: "Most of your best developers like to develop and want to spend as little time as possible on anything else. At the same time, if you have legacy applications that require a lot of hand-holding, you will have a higher dependency on operations. The best teams balance the need for new features with the need to keep the lights running, and this can be done through more organizational structure, tools for troubleshooting, and automation to avoid outages in the first place."  

Simkins: "Focusing efforts on establishing and constantly improving upon your DevOps environment is the first step to building a strong foundation for your engineering team, which in turn will increase speed and efficiency. Taking the time to identify the areas where an improved DevOps cycle would provide value and prioritizing the work alongside the rest of your software development process is an important investment when it comes to growing your agile team."

van Galen: "The concept of DevOps as many view it does not go far enough. It is usually interpreted as building your software and infrastructure out in the same way. It integrates the concerns of infrastructure building right into your deliverable package. But many are still missing out on integrating other cross-cutting concerns, importantly security and privacy -- DevSecOps -- but also usability and accessibility."  

Agile: are we finally delivering on the promises of the Agile Manifesto (close collaboration, interactions over processes)?

Fritchey: "I was never a fan of the Agile Manifesto, but a lot of what it was asking for is being delivered, better, by DevOps. Parts of the manifesto made sense, and that's why they're championed within DevOps, such as the need for real collaboration. However, much of the manifesto was focused on specific methods of implementation which have been correctly left behind by the DevOps movement."

Patnam: "The overriding desire for operations to follow processes, ITSM, ITIL, and various security processes means DevOps teams end up following more procedures than they'd like, and the massaging between both groups has been fascinating to see. On the one hand, you're seeing operations teams using more agile and holding scrum meetings to gather control of their daily challenges better, but they're still bound by the rules or structure that's been in place for quite some time. This is one of the reasons we have seen more mature companies struggle to adopt DevOps. The synapses of operations following a strict process are hard to break." 

What types of technology initiatives are helping things along?

Fritchey: "Without a doubt the biggest driver here is the cloud. Those who are able to control their cloud systems through an automated, DevOps-style, approach to development, deployment and management, are reaping the most benefits. The legacy systems on local servers are not making the shift into DevOps as quickly."

Patnam: "You are starting to see more companies utilize SaaS and cloud tools for purposes outside of IT and digital experience. There is also a whole host of data-gathering and logging technologies that are in place on the developer and operations side. The best companies are putting all this data together to make DevOps' operations side easier while also allowing the customer-facing side of the business more tools to get information and adapt faster to changes." 

van Galen: "Resource allocation and administration of your process must be eliminated where that is possible. Automate, automate, automate is the mantra -- remove the friction for your developers. Modern development environments -- code repositories, continuous integration and deployment tools, change and review automation -- remove friction from the development process. Being able to spin up cloud databases, machines, containers or serverless functions with the snap of a finger tremendously removes friction from deploying infrastructure. What is left for the developers and infrastructure, security, privacy, and usability engineers is a focus on delivering a quality product or service - which is what it should all be about."

Editorial standards