Traditional technology roles within an organization function separately from one another. Developers come from a mindset where change is what they're paid to accomplish. The business depends on them to respond to changing needs, so they're usually encouraged to create, innovate, and generate as much change as possible. By contrast, operations sees change as the enemy. The business depends on operations to keep the lights on and deliver the services that generate money for the business today. Operations is motivated to resist change, because it undermines stability and reliability.
These objectives make sense independent of each other, but the organization has to be able to function as a whole, which means setting aside conflicting agendas and working for the common good. This is the premise of DevOps.
Developers develop
A developer is someone who writes and debugs code to create software and applications. Once an application is deployed in a production environment, the developer will generally monitor performance and gather feedback from users to implement changes and updates to make the software better. The goal of a developer is to continually create new applications and modify existing ones to make them better—effectively introducing change to the environment on a regular basis.
A traditional developer's role is measured by his or her ability to effect change. The developer's worth to the organization—as well as the developer's salary and bonuses—are typically a reflection of the developer's initiative and ability to generate new applications and innovative features that help users be more productive.
Operations operates
IT operations or IT admins have one objective: make sure everything is operating optimally. Operations ensures that network resources are available and functioning at peak performance. Once that equilibrium has been achieved, any new demands on the network resources threaten the stability of the environment and require operations to invest time and effort to make sure they're still performing as expected.
A traditional operations role is measured by its ability to provide a reliable, optimized infrastructure. In effect, that means ensuring as little change as possible in order to guarantee that network resources are available so users can be more productive.
The culture clash
Ultimately, both developers and operations are striving for the same thing: to make the organization as productive as possible. In spite of their similar objectives, though, it's easy to see how these conflicting roles can get in the way of each other. Developers are trying to create and improve applications as quickly as possible, and operations is doing everything it can to prevent changes from occurring in the environment. Something has to give in order for the organization to function effectively and efficiently.
"In traditional ops organizations, we often have chosen functional-orientation, organizing our teams by their specialties—we put the database administrators in one group, the network administrators in another, server administrators in another, and so forth," says Gene Kim, coauthor of The Phoenix Project and the upcoming DevOps Cookbook, and a driving force behind the currently running DevOps Enterprise Summit in San Francisco. "Among the consequences for this is long lead times. For complex activities such as large deployments, we must open up tickets with multiple groups, coordinating hand offs, with work waiting in long queues, with implementers often having little visibility of how the work relates to the value stream goals."
Kim also talks about how the issue is exacerbated because developers are optimizing for speed over stability. Operations is focused on delivering a reliable, optimized network experience and can't keep up with the demands from new or changed applications, which results in large queues, longer lead times, and poor hand offs. Ultimately the organization ends up with bottlenecks, delays, and quality issues resulting from the conflicting goals of dev and ops.
"Development just wants to get product out the door as fast as possible, regardless if it increases security risk, downtime, or any other risk. Operations will try to be the levelheaded rock for which the business can be assured that they will always fight for stability and uptime. As a result, operations will be viewed as the bottleneck to everything," explains Andrew Storms, VP of security services at New Context.
Embracing DevOps
That's where DevOps comes in. It's a seismic shift from the traditional IT culture—one that brings developers and operations together to cooperate toward common goals. It requires that each understand the objectives of the other and that all parties set aside conflicting agendas and work together to do what's best for the organization as a whole.
Colin Campbell, director of patterns and practices at Chef, shares his thoughts on why organizations need DevOps: "Customers in every industry have zero tolerance for bad software, so delivering good software quickly is everyone's job, not just developers. DevOps eliminates silos between dev and ops using practices, like smaller, much more frequent releases and blameless postmortems, in combination with tools, like automation, which empower transparent communication and cooperation 'across the aisle.'"
The challenge for many organizations, though, begins with defining what DevOps is and what value they hope to derive from it. Kim describes DevOps in an excerpt from DevOps Cookbook:
Broadly speaking, in DevOps, our goal is to reduce the effects of functional-orientation ("optimizing for cost") and enable market-orientation ("optimizing for speed") so that small teams can quickly and independently deliver value to the customer, reducing or eliminating its reliance on other teams.
Taken to its extreme, market-oriented teams are responsible for not just feature development, but also testing, securing and deploying their code into production themselves, as well as being responsible for production operations and availability.
Making the switch
TK Keanini, CTO of Lancope, cautions against trying to define DevOps by calling out the differences between dev and ops. "It is like trying to define the game of hockey in all the ways it is different from the game of soccer. While there are similar terms and such, hockey is really just hockey."
He recommends that organizations redefine roles, processes, and technologies from the ground up, from the perspective of what is most effective for the business.
"So much of DevOps is culture and second are the tools and processes. Putting lipstick on a new group of sys admins with some developers and calling them DevOps isn't going to work," stresses Storms. "There has to be real and significant change that is fully supported by the management of a company. Just like so many things in life, compromise and understanding that everyone involved ultimately wants the same goal will help to drive change."
The difference between the traditional approach and a DevOps culture is often described as simply the breaking down of the typical silos in an organization. It's viewed as a streamlining of the way an organization works by removing the friction and unnecessary bureaucracy between departments to enable them to work together more effectively.
Ultimately, DevOps culture is about changing the perspective on responsibility. In DevOps Cookbook, Kim quotes John Vincent:
DevOps means caring about your job enough to not pass the buck, wanting to learn all the parts as a whole, and not just your little world. People need to actually work with each other and not just occupy space next to each other. That means Developers need to understand the infrastructure, and Operations people need to understand code.
When everyone takes responsibility for achieving common goals, and you eliminate the ability of one individual or team to simply point the finger at another, it enables productivity. When individuals and teams are allowed to take responsibility for delivering results without the usual administrative overhead, it fuels efficiency.
Campbell sums it up: "At its core, DevOps puts people before products before companies. Empowering dev and ops to share common goals and tools within trusting environments makes for happier teams that will build better software."
A square peg in a round hole
Keanini points out that DevOps may not be for everyone and may not work in every organization. He stresses that in order for a DevOps culture to prevail and survive, the business needs to require the qualities that DevOps delivers. "The bottom line is that DevOps is a way of running your business, not just a way a few departments have organized themselves. I've seen the same pattern as people 'try out' agile methodologies. Either move as a system as wide as the organization or die as a department."
Developers develop as quickly as possible, and operations provides optimized network resources as reliably as possible. In most cases, those roles develop friction. Transitioning to a DevOps culture requires redefining objectives so these two teams can shift their legacy thinking and work cooperatively on shared goals.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
