DevOps: The Path to Defeating Fear

Like Agile, DevOps has become part of the vocabulary of almost all modern software development organizations. As with Agile, the actual DevOps practiced by many organizations is often half-hearted and timid, leaving most of the core benefits on the table instead of revolutionizing their approach to rapid change with legendary reliability.

It can be daunting to decide which of the many best practices that DevOps espouses are the most important and how to determine if they are delivering the goods. Some organizations make a few changes and prematurely decide “we’ve done it” or that to do more would be too disruptive. This early decision to stop the journey is most often a product of not being completely sure of the goal of DevOps and charting progress to achieving that goal.

Releasing Without Fear

The key question that members of organizations should be asking themselves is: Can we release everything we build to production any time of the day or night without fear? If the answer is no, then the trek toward becoming a DevOps-empowered team is far from over.

DevOps may seem to be a random hodgepodge of excellent self-documentation, quality assurance, test automation, user segmentation, infrastructure management, build, release, observability, and resiliency techniques that have been gathered under one brand by some technical evangelists. It is anything but random. The nexus those things join through is frequent, effortless, and low-/no-risk deployment of working software that consistently improves customer satisfaction.

DevOps provides teams with a vision that releasing improvements on a continuous basis can be done without fear and that the practice of releasing continuously can make customers happier. It then backs up that assertion with hard data showing that the highest performing teams with the fewest bugs in products, the more reliable production performance, and with the least customer churn are the ones that are continuously innovating to achieve this vision. Lastly, it provides a rich collection of techniques enabling teams to achieve the vision of continuous, low-/no-risk deployment that don’t break the bank.

Move Everything to the Left

As with its child, Reliability Engineering, DevOps builds this collection of techniques on top of the core observation that everything should be “moved to the left”: that is, any task that is performed frequently should be automated through software and it should be made a deliverable of the development process itself rather than added on after “development is done.” Quality assurance, testing, securing, building, provisioning, deploying, distributing, segmenting, and monitoring applications should be an integral, technical responsibility of Agile product teams. (I would argue that user training should be added to this list, but I have not seen a ton of examples of this out there…yet.)

Holding the product teams accountable for more than just features, but the whole of what makes an application valuable is an essential prerequisite for frequent deployment without fear. Every additional hand-off from the work of the product team to the point where code is in use by the customers is an opportunity for negative impacts on the users to go unnoticed because one or both of the teams doesn't view that domain as their. Worse still, is when a misunderstanding between groups results in problems actually getting introduced.

How Humans and Software Rock Differently

Humans are good at abstract thinking, innovation, and complex synthesis, but they are terrible at precise execution on long and complicated process chains. Software is not near as powerful as humanity in deciding why to do something or discerning whether it is valuable by themselves, but it is second to none at quickly and consistently repeating a previously validated sequence of steps. DevOps encourage teams to leverage humans and software each for their best strengths.

In the modern software consumer space, the most important feature of any product is rapidly becoming velocity of change. The DevOps core ethos of frequent releases of small changes addresses this overarching customer expectation. Small changes bound the complexity of what could be introduced in production, making it easy for the team to tackle the hiccups that might be seen. By making quality assurance, testing, security, provisioning, segmenting, distributing, and monitoring applications first class citizens in the development process, the team is further armed with the means of controlling which users are exposed to changes, how to verify proper performance, the impact of attempted exploits, and how to reduce or eliminate changes from production using automation as needed.

The DevOps Toolbelt

The usual suspects in the DevOps arsenal are:

• Continuous Integration/Continuous Delivery/Continuous Deployment (CI/CD/CD)
• Infrastructure as Code
• Feature, Stability, and Performance Test Automation
• Secure Containerization
• High Availability Distribution
• Auto-Scaling
• Static and Dynamic Security Test Automation
• Red/Green, Canary, and Traffic-Shaping User Segmentation
• Loosely Coupled Software Architecture
• Service Level Indicator/Objective/Agreement Operationalization

With the mass scale of AWS, Azure, and GCP an intrinsic extension of the list above is to use the services of one or more of those platforms as often you possibly can. The existing accounting treatment of the costs of using public cloud services can make that challenging in some companies, but the unmatched accelerators to team velocity, security, stability, scalability, adaptability, and observability in those platforms make them the fastest way to institutionalize DevOps practices more quickly than you can develop all the domain knowledge yourself.

The DevOps Why

Just remember that the why for all those techniques and the use of the cloud is to lose your fear of deployment. Having the confidence to release new value to your users on a continuous basis is essential to satisfy the feature velocity expectations of all customers, whether they are inside or outside of your organization. The techniques above will provide you with the tools to deliver what’s required in the digitized world we live in.

Further Info

Some excellent books on DevOps if you want to really dig in are:

• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Patrick Debois, John Willis, and Jez Humble
• Accelerate: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim

You can also search for “State of DevOps Report” on the web to hook up with the latest findings.

Until next time.