Rawpixel - Fotolia
Overcome these 5 DevOps challenges
DevOps adoption isn't easy, but the results are worth it. Learn how to collaborate, cooperate and coordinate with better organization and DevOps tooling.
As DevOps matures into its second decade, more IT organizations see its benefits. But the journey from traditional, siloed IT workflows into more cohesive, collaborative pipelines is fraught with setbacks and failures.
A DevOps challenge can arise in cultural or social struggles as well as from technical inefficiencies. A distinct DevOps team that becomes siloed from the rest of IT is a clear example of a DevOps failure -- but so is an IT organization that doesn't standardize on tool sets, especially if that variability creates additional work.
In its beginnings, DevOps was a response to an observation of the status quo, said John Allspaw, advisor at Primary Venture Partners, a seed-stage venture capital firm based in New York.
"In those [early] days, a lot of it was … 'Hey, Sysadmin doesn't have to be a jerk. Sysadmin can [talk] with an application developer about what their goals are,'" he said. DevOps then was less to improve the speed of IT and more to rebuild broken-down relationships between IT specializations.
In the decade since, however, what DevOps is and means has grown. "Ten years ago, it was pretty much all grassroots developer-driven, and today we see much more of the management and leadership involved," said Jay Lyman, principal analyst at 451 Research. In 2020, DevOps is both a technical and a cultural force in the IT industry. Streamlined, automated continuous integration and continuous delivery pipelines replace larger, staggered release cycles. Infrastructure moves to cloud platforms. And scalability and high availability rule.
Here are five DevOps challenges that companies face in this transition.
1. Miscommunication and scattered priorities
Most DevOps challenges are people problems. Grudges, misconceptions and stereotypes between departments run deep.
Conversations that reflect that negativity can derail DevOps. For example, we ask how to prevent security from slowing down developers, rather than how the security team can strengthen an app's development, Lyman said. "Software security is a type of software quality, and that's something that developers appreciate." To speak their language, he said, frame security as a vital aspect of software quality.
DevOps is a way to connect the goals of disparate IT teams, as well as their work. When the security team can weigh in on application or infrastructure design, the product is stronger, because those security measures aren't late-stage complications. The software product performs better and requires less troubleshooting and mediation because work was done upfront to counter potential problems.
2. Siloed DevOps teams
John Allspaw
Perhaps the most subtle DevOps problem is when an IT organization creates a new, distinct DevOps team. "Some practitioners believed that […] there's some sort of a social or political clout that you'd get by naming your team 'DevOps,'" Allspaw said.
In reality, DevOps isn't meant to eradicate domain expertise, nor to make generalists out of specialists. It is beneficial to both IT professionals individually and to the overall IT department to redistribute some responsibilities, though, even temporarily. For example, when app developers, who know their code's intended result from the get-go, take over deployment, the shift can foster an understanding of the IT operations perspective. This cross-functional work potentially can heal some of the rift between these two groups, wrought by tensions of mismatched goals. It also means that developers must take more responsibility for the quality of the code they produce.
To encourage collaboration rather than an isolated DevOps team, IT leadership should tie incentives to various stages of a project's development -- but base those incentives on the performance of another team, Lyman said. For example, if the developers' incentive hinges on how well the IT operations team does, the developers will strive to provide IT ops the best version of their deliverables. Those incentives can cross many categories, from personal improvement opportunities to new, innovative projects.
3. Narrow thinking
In its beginnings, DevOps' advocates suggested that DevOps should be synonymous -- and replaceable in any sentence -- with the three Cs: collaboration, cooperation and coordination.
"Collaboration, cooperation, coordination was the perspective that devs [could] anticipate, understand and empathize with the position that ops engineers are in, and ops engineers [could] empathize, understand and potentially build on -- in a collaborative way -- the roles and responsibilities that devs have," Allspaw said. To "do DevOps," the different IT teams must pursue a common goal with compassion for others' positions and a drive to make things work. To create a DevOps team is to merely divide two IT teams and create a third.
But this milestone only marks a failure if the journey ends here.
On the contrary, one of the biggest challenges in DevOps is to get all stakeholders together at the same time. And it's here where the DevOps question becomes the DevSecOps -- and sometimes BizDevOps -- question.
Jay Lyman
DevOps has key stakeholders outside of the development and IT operations teams, namely in security and networking, but also in management and on the business side. The DevOps team must include network, security and QA professionals -- alongside business leaders, project managers and data scientists -- for the best chance of success. To neglect these areas is a huge hindrance to DevOps success. When an IT organization creates software with DevOps, it needs all the other non-DevOps IT teams and departments to complete its goals -- and to help them reach theirs. "[IT organizations] need this effort for the storm … to spread this beyond just the team," Lyman said.
Specifically, bring DevOps upward into management. A DevOps team's initiatives and wins are limited if leadership doesn't drive them into the rest of the organization.
4. Too many tools
An organization can have a CI/CD pipeline without DevOps, but it cannot have DevOps without a CI/CD pipeline. Just as one can't learn how to drive without a car, an IT organization can't learn to automate app deployment if they don't have the tools in place. Don't let DevOps tooling selection get out of hand.
Historically, many organizations gravitated toward single-supplier suites of tools, fully integrated out of the box, with support. IT complexity has led to a proliferation of niche tools, however, which leads to a piecemeal collection of tools that organizations must integrate themselves. There's also a growing range of cloud-based services for development, test, deployment, CI/CD and more. And with open source tools, anyone can pick a product that best suits their skills and work.
"I don't know if any organization -- you know, a large enterprise -- can get everything they need, technically, from one provider for a DevOps implementation," Lyman said.
Without oversight, an organization can end up with dozens of unnecessary tools in use. Attempt to standardize on as few DevOps tools as possible. To do so, staff and management must come together to determine important features and functions and how best to accommodate the specialized needs beyond them.
5. Too much change too soon
It's tempting to adopt DevOps in one fell swoop -- replace monolithic architectures on VMs and servers with shiny new cloud platforms and SaaS and FaaS applications, automated pipelines, containers and monitoring dashboards. There are too many pieces of an IT environment to change all at once; and the dependencies between applications pose a big challenge. DevOps implementation and scaling within an organization should include careful planning and cross-group collaboration. Evaluate security risks and potential bugs, as well as unnecessary complexity that will create future problems.
To overcome this DevOps challenge, create a center of excellence where team members from multiple disciplines can build a list of projects, tools or technologies to update, prioritized by biggest impact and ease of transition. A center of excellence can often start with the initial DevOps champions, to help establish internal policies and structures for the organization and measure how well DevOps is going. Tie these efforts to an in-house training program, clear documentation and resource hubs.
