A few years ago, if you had asked a group of C-Level executives to project which software delivery trend would be more important for organizations, most would have ranked DevOps ahead of containers. DevOps promised to profoundly refocus and reenergize software teams while containers looked like an interesting new way to repackage resources that were already there.
Today, the rankings have flipped. Container adoption is accelerating—and the technology that orchestrates container usage, Kubernetes, is regularly being described as “revolutionary.” DevOps? While it’s still popular—up to three quarters of all organizations use a DevOps blueprint—more users say they’re struggling with integrations. One survey showed 86% of organizations consider software delivery a top priority but only 10% say they’re successful at it. A dozen years after the term was first coined, DevOps may be heading for Gartner’s so-called “Trough of Disillusionment.”
The good news is that DevOps, like many technology concepts, will likely climb out of the trough and head toward the fourth and fifth stages of Gartner’s “Hype Cycle”—a “Slope of Enlightenment,” leading to a “Plateau of Productivity.” What organizations need to do is be patient and understand that DevOps—unlike a move to containers—is a journey that takes time and will, by nature, have its ups and downs.
Kubernetes is, at its core, a game-changing technology. Organizations use container platforms to create and run applications a whole new way—and Kubernetes orchestrates the way container infrastructures operate. Kubernetes opens up a whole new way of delivering services—providing scalability, portability and better economics. It allows development teams to move faster, work more cost-efficiently, move applications on any cloud or on-premises platform. These are tangible technical and financial benefits that won’t diminish over time.
Kubernetes is following the same trajectory virtualization did back in the 2000s. Virtualization essentially solved many of the storage and resource constraints organizations were experiencing using physical servers. Now containers present a lightweight alternative to virtual machines, and Kubernetes provides a framework for managing containers at scale.
Challenging Operational Complexity
DevOps is more complicated—and more of a trigger for frustration. It’s focused on restructuring teams and processes. It attempts to solve a process challenge of operational complexity and miscommunication. Rather than have developers and operations teams working in silos on different schedules with different priorities, DevOps attempts to bring them together as one cohesive unit.
The problem is, DevOps isn’t a cookie-cutter approach that works the same way with every organization. Some entities are able to use DevOps to sort out inefficiencies and get intransigent workers aligned on a common goal. Others run into trouble getting workers motivated or managing the change process. While some organizations are able to implement DevOps quickly, others find it can take time. It all depends on the culture of the organization.
DevOps aims to reduce complexity—but for some organizations it can have the reverse effect. Teams have to get used to whole new sets of rules, timetables, reporting structures and general working conditions. Workers may need to be retrained or reassigned, which introduces more complexity into an already challenging process of delivering software.
Although DevOps introduces some technical changes, it mainly involves making a cultural shift. Cultural shifts are the hardest kinds of reorganizations to pull off. They require buy-in from workers at all levels – and they usually take time to execute correctly.
DevOps depends heavily on automation. Essentially, the goal is to automate as many tasks as possible to ensure that the overall system runs like a clock—moving builds from step to step, performing regular tests, catching flaws and capturing data. It’s a lofty goal, but in practice it’s hard to do. Even the most efficiently designed software pipelines have to be configured correctly and then monitored and managed to account for variants in delivery processes.
Plus, is automating every task always the best strategy? Business needs, timetables and staff resources evolve day by day, month by month, quarter by quarter. Some tasks that need to change constantly might be better performed by a human who has the experience to tweak a process on the fly. Alternatively, some tasks that are performed infrequently—say, once a year—might be better performed slowly, with a high degree of analysis. If you don’t automate those tasks, you don’t technically have true DevOps. You have human factors in the middle that slow it down. It’s this yin and yang. Because processes are always evolving, automation can annoy stakeholders when it doesn’t do everything it promises.
Workers on some DevOps teams are finding that silos are easier to eliminate on paper than in actual practice. In other words, “DevOps” engineers get hired and then are put in charge of an issue—managing infrastructure, security, scaling or fault-tolerance—without developer involvement. While the goal was to create a team approach, team leaders still put individual tasks in silos. Best practices like test-driven and behavior-driven development, and agile/scrum processes are ignored when it comes to managing infrastructure.
Airing Frustrations
If organizations don’t commit to developing and sustaining a DevOps culture, it can lead to other frustrations.
- The initial euphoria teams experience when new work patterns are introduced fades over time. If team members lose interest in the project or fail to generate the results they’re looking for, they can become disenchanted.
- With new processes comes more demands. Muscled up with a new DevOps practice, the company overpromises on delivery schedules, forcing team members to scramble and fall short of expectations.
- Leadership engagement drops off. If managers aren’t committed to a DevOps initiative, team members can lose focus, leading to diminished effectiveness for the DevOps project overall.
- Respected evangelists leave or move on to new roles. Team-focused environments can suffer if they lose key members that played important roles.
On the positive side, one benefit many organizations are seeing doesn’t focus on the delivery of software itself. It focuses more on the broad-based success of the company itself.
What DevOps has done is given the software delivery function a seat at the table to decide the direction of the company. Since DevOps itself is iterative and incremental, the team members who drive the discipline bring a certain pragmatism to the decision-making process. They can provide insights the organization needs not only about how software needs to be part of every decision but also about what will work and what won’t. Installing a DevOps process provides a gut check for the business about what can and should be rolled out before investing large sums in an initiative that will fail.
Reaching the Productivity That DevOps Promises
The best way organizations can fight through feelings of disillusionment over DevOps is to recognize that they’re there and commit to a long-term vision for the overall process. They need to invest in the tools and the training to reinforce the initiative. They must continually evolve their software delivery strategies to meet their business requirements—and perhaps inject more human involvement in certain tasks if it can make a difference. By making these moves and working with team members to address their frustrations, organizations can set their sights on the productivity that DevOps promises.