What Is DevOps?

DevOps is a term for a group of concepts that, while not all new, have catalyzed into a movement and are rapidly spreading throughout the technical community. Like any new and popular term, people may have confused and sometimes contradictory impressions of what it is. Here’s my take on how DevOps can be usefully defined; I propose this definition as a standard framework to more clearly discuss the various areas DevOps covers. Like “Quality” or “Agile,” DevOps is a large enough concept that it requires some nuance to fully understand.

Definition of DevOps

DevOps is a new term emerging from the collision of two major related trends. The first was also called “agile infrastructure” or “agile operations”; it sprang from applying Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world (cf. Operations: The New Secret Sauce).

One definition Jez Humble proposed to me is that DevOps is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.”

History of DevOps

The DevOps movement started to coalesce some time between 2007 and 2008, when IT operations and software development communities got vocal about what they felt was a fatal level of dysfunction in the industry.

They railed against the traditional software development model, which called for those who write the code to be organizationally and functionally apart from those who deploy and support that code.

Developers and IT/Ops professionals had separate (and often competing) objectives, separate department leadership, separate key performance indicators by which they were judged, and often worked on separate floors or even separate buildings. The result was siloed teams concerned only with their own fiefdoms, long hours, botched releases, and unhappy customers.

Surely there’s a better way, they said. So the two communities got together and started talking – with people like Patrick Dubois, Gene Kim, and John Willis driving the conversation.

What began in online forums and local meet-ups is now a major theme in the software zeitgeist, which is probably what brought you here! You and your team are feeling the pain caused by siloed teams and broken lines of communication within your company.

You’re using agile methodologies for planning and development, but still struggling to get that code out the door without a bunch of drama. You’ve heard a few things about DevOps and the seemingly magical effect it can have on teams and think “I want some of that magic.”

The bad news is that DevOps isn’t magic, and transformations don’t happen overnight. The good news is that you don’t have to wait for upper management to roll out a large-scale initiative. By understanding the value of DevOps and making small, incremental changes, your team can embark on the DevOps journey right away. Let’s look at each of these benefits in detail.

Teams that work in siloes often don't adhere to the 'systems thinking' of DevOps. 'Systems thinking' is being aware of how your actions not only affect your team, but all the other teams involved in the release process. Lack of visibility and shared goals means lack of dependency planning, misaligned priorities, finger pointing, and 'not our problem' mentality, resulting in slower velocity and substandard quality. DevOps is that change in mindset of looking at the development process holistically and breaking down the barrier between Dev and Ops.

Release faster and work smarter

Speed is everything. Teams that practice DevOps release more frequently, with higher quality and stability.

Lack of automated test and review cycles block the release to production and poor incident response time kills velocity and team confidence. Disparate tools and processes increase OPEX, lead to context switching, and slow down momentum. Through automation and standardized tools and processes, teams can increase productivity and release more frequently with fewer hiccups.

Accelerate time to resolution
The team with the fastest feedback loop is the team that thrives. Full transparency and seamless communication enable DevOps teams to minimize downtime and resolve issues faster than ever before.

If critical issues aren't resolved quickly, customer satisfaction tanks. Key issues slip through the cracks in the absence of open communication, resulting in increased tension and frustration among teams. Open communication helps Dev and Ops teams swarm on issues, fix incidents, and unblock the release pipeline faster.

Better manage unplanned work

Unplanned work is a reality that every team faces–a reality that most often impacts team productivity. With established processes and clear prioritization, the Dev and Ops teams can better manage unplanned work while continuing to focus on planned work.

Transitioning and prioritizing unplanned work across different teams and systems is inefficient and distracts from work at hand. However, through raised visibility and proactive retrospection, teams can better anticipate and share unplanned work.

If we could sum up DevOps culture in one word, it’d be “collaboration” – and if we were allowed two words, they’d be “cross-functional collaboration.” (Ok, that’s more like three words.)

All the tooling and automation in the world are useless if they aren’t accompanied by a genuine desire on the part of development and IT/Ops professionals to work together. Because DevOps doesn’t solve tooling problems. It solves human problems. Therefore, it’s unlikely you’ll poke your head out of the cubicle one day, look around, and discover that teams at your company embody DevOps culture. But there are simple things you can do to nurture it.

Think of DevOps much like agile, but with the operations included. Forming project- or product-oriented teams to replace function-based teams is a step in the right direction. Include development, QA, product management, design, operations, project management, and any other skill set the project requires. At Atlassian, we even embed marketing with our product teams.

Few things foster collaboration like sharing a common goal and having a plan to reach it together. At some companies, switching suddenly to project-based teams is too much, too soon. So take smaller steps. Development teams can – and should – invite appropriate members of the operations team to join sprint planning sessions, daily stand-ups, and sprint demos. Operations teams can invite key developers. It’s an agile and organic way to keep on the pulse of each other’s projects, ideas, and struggles. The time spent listening and cross-pollinating subject-area knowledge pays for itself by making release management and emergency troubleshooting far more efficient.

And speaking of emergencies, they’re an effective test of DevOps culture. Do developers, operations, and customer support swarm on the problem and resolve it as a team? Does everyone start with the assumption that their teammates made the best decisions possible with the information and resources they had at the time? Is the incident post-mortem about fixing processes instead of pointing fingers? If the answer is “yes,” that’s a good indication that your team functions with DevOps culture at its core.

Note that the most successful companies are on board with DevOps culture across every department, and at all levels of the org chart. They have open channels of communication, and talk regularly. They make sure everyone’s goals are aligned, and adjust as needed. They assume that keeping customers happy is just as much product management’s responsibility as it is the development team’s responsibility. They understand that DevOps isn’t one team’s job. It’s everyone’s job.

Automation

Investing in automation eliminates repetitive manual work, yields repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for teams who don’t have them in place already. And hey: what better reason for developers, testers, and operators to work together than building systems to benefit everyone?

Teams new to automation usually start with continuous delivery: the practice of running each code change through a gauntlet of automated tests, often facilitated by cloud-based infrastructure, then packaging up successful builds and promoting them up toward production using automated deploys. As you might guess, continuous delivery is not a quick and easy thing to set up, but the return on investment is well worth it.

Why? Computers execute tests more rigorously and faithfully than humans. These tests catch bugs and security flaws sooner, allowing developers to fix them more easily. And the automated deploys alert IT/Ops to server “drift” between environments, which reduces or eliminates surprises when it’s time to release.

Another of DevOps’ major contributions is the idea of “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. That same thinking can be extended to the infrastructure that hosts them, whether it lives in the cloud or on the company's own network.

True, systems are always changing. But we can create a facade of immutability by using code for provisioning so that re-provisioning a compromised server becomes faster than repairing it – not to mention more reliable. It reduces risk, too. Both development and operations can incorporate new languages or technologies via the provisioning code, and share the updates with each other. Compatibility issues become immediately apparent, instead of manifesting in the middle of a release.

“Configuration as code” and “continuous delivery” aren’t the only types of automation seen in the DevOps world, but they’re worth special mention because they help break down the wall between development and operations. And when DevOps uses automated deploys to send thoroughly tested code to identically provisioned environments, “Works on my machine!” becomes irrelevant.