Devops is Not All About Automation

#devops Tools are for automation, devops is for people

It’s easy to get caught up in the view that devops is all about automation. That’s because right now, most of the value of devops and repeatable processes is focused on deployment of applications within virtual or cloud computing environments and dealing with that volatility requires automation and orchestration to combat the growing dearth of human resources available to handle it. But devops isn’t about the environment, or the automation. Those are just tools, albeit important ones, to achieving devops. Devops is more about the agility and efficiency gained through streamlining processes and being able to react rapidly. You know, agile. It’s about iterating over processes and refining them to make them more efficient. You know, agile.

Devops is about continuity; about ensuring continuous delivery. More often than not this focuses on automated and integrated deployment processes enabling rapid elasticity, but that’s just the most obvious use case. Not every process can be automated, nor should they be. Agility is about being able to react; to have processes in place that can efficiently and effectively address challenges that crop up from time to time.

The programmability of infrastructure, for example, can enable devops to put into place processes that define how IT reacts to emerging threats. This is one of the promises of SDN and OpenFlow – that the network can adapt to external pressures and events through programmatic intervention. With generally new and unknown threats, there’s no immediate remediation available and no button operations can push to deploy a preventive measure against it. Programmatic intervention is necessary. But who is responsible for intervening? That’s part of the question devops should be able to answer.

AN EXAMPLE

If we take as an example the typical response to an emerging threat, say a 0-day threat, we can see how devops applies.

Initially, organizations respond by panicking (more or less. The agitated state of a security professional upon learning about the threat appears similar to panicking in the general population). The response is unpredictable and reactive. If the threat is in the application or application server infrastructure layers, no one’s quite sure who is responsible for handling. The threat may remain real and active for hours or days before someone figures out what it is they’re going to do.

In a more mature devops stage, experience may have taught operations what to do, but response is still reactive. Operations may not always proactively monitor or scan for potential threats and thus may be caught off-guard when one suddenly appears on the threat radar. The process for handling, however, is repeatable on a per-service basis.

As organizations continue to mature, standards evolve regarding how such threats are handled. Potential threats are monitored and processes are in place to manage eventual emergence. Responsibility is well understood and shared across operations and development. Operations understands at this point how what stop-gap measures – such as network-side scripts to prevent penetration of emergent application layer threats – are likely to be needed, and development and administrators understand which of these threats must be addressed by whom, and at what point in the process they must be mitigated.

Quantifying metrics for success follows, with both development and operations using the same metrics. Time to initial redress, time to complete resolution, time at risk, etc… Finally optimization – streamlining – of processes can begin as devops fully matures. Substitution of automated scanning and virtual patching for scanning and manual mitigation occurs, speeding up the process as well as assuring a higher security profile for the entire organization.

Most of this maturation process does not involve nor require automation. Most of it requires people; people who collaborate and define processes and policies that govern the delivery of applications. Devops must first define and refine processes before they can be automated, thus automation is unlikely to occur except in the most mature of devops-enabled organizations.

In many cases, processes will still comprise manual steps. Some of those steps and tasks may be automated at a later date, but until an organization is fully invested in devops and allows the maturation process to occur organically (with guidance of course) automation may result in nothing less than what developers and architects got with SOA – lots of duplication of services that made the entire system more complex, more costly to manage, and more difficult to troubleshoot.

Devops is a verb. It’s not something you build, it’s something you do.