DevOps works through successful integration of people, process and technology. To me, DevOps begins broader with cultural learning underpinning all success. In my book, “Confident DevOps” (Kogan Page, 2024), I explore defending the DevOps culture, picking the right technological process, and expanding into DevOps’ cultural foundation. Each exploration is supported by analogy, use-case, and a detailed model to reach the next step. I call myself a DevOps junkie as I need my daily fix, and hope this book helps you reach the same place.
With my work at Raft, we focus on three areas; the Raft Data Platform, Raft Data Fabric, and delivering complex applications. While each satisfies a slightly different perspective, implementing an underlying DevOps culture to deliver value quickly provides essential support. Many of our teams already engage in Devops methodologies. A key to DevOps, much like any other practice, is to never forget to practice the basics. When one first practices a sport, like baseball, throwing is a critical skill. One never forgets to practice throwing, but as skills improve, the emphasis changes to incremental progress through body position, hand position and release points, and the same focus holds true in DevOps. The book emphasizes the big movements, and then the small changes to create success.
In the book’s first section, I explore the DevOps history. Understanding the beginnings from meetings and presentations builds your initial perspective. This perspective allows comparing other project methodologies and cultures, as tied to a Software Development Lifecycle, to share a Strength-Weakness-Opportunity-Threat analysis for how Waterfall, Spiral, SAFE, GitOps and other methodologies perform. An analytical foundation allows a first look at how flow, feedback, and continuous improvement within DevOps guide the culture. Flow determines the rate for process, feedback creates observability, and then improvement ensures learning does not disappear. However, DevOps success depends on technology, leading to the next section.
Similar to any technical process, DevOps begins with architecture. Too many developers assume an emphasis on fast delivery minimizes architectural needs, however, architecture provides the foundation allowing quick completion. Sound architecture ensures observability occurs, beginning with exploring pipeline processes and continuing through testing. Pipelines built on observability usually do so through an emphasis on effective testing. Each section explores the basics, establishes some tools, and suggests guidelines for picking the right people to manage technology.
The final section explores the mindset, basic hiring practices, creating process, and integrating technology before delivering an overall security perspective. As a security expert, one might question why I put security last. Security occurs early in many processes must be implemented first and last. One must implement initial governance and guidelines within deployment through observable pipelines and then conduct continuous checks once software reaches production. These security checks support platform stability rather than ignoring stability for a feature that only looks good during the initial demonstration. The recent CrowdStrike example demonstrates even when security patches are available, sometimes stability has suffered when one does not fully understand the customer mindset, architecture, and internal process.
My favorite parts to write was the metrics analysis in Chapter 5 and establishing the mindset in Chapter 8. I am a huge fan of metrics, and developing successful metrics starts with some basic questions; how do you know, what happens next, and are the underlying assumptions true. These questions then lead to ensuring one’s metrics compare apples to apples and not oranges to elephants. After all, oranges and elephants have tough skins, a navel, and a juicy inside but comparisons rapidly disappear beyond that initial point. One often sees this with runtime success in testing without production or high availability with minimal users. Both show only a part of the necessary metric to make decisions. Metrics are a key part for Raft in building success through demonstrating how data platforms and data fabrics improve usability, stability, and security for a wide range of customers.
Beyond simple metrics, there is a mindset to apply to DevOps. Each developer, operator and manager begin with their own experience, subsequently shaped by team, and organizational constraints. These experiences shape how each level handles challenges. One common example, based on research, is many program managers consider security and function as different elements. At the developer level, these two aspects are the same, each being merely different aspects of the same code. Managing discrepancies relies on understanding bias, and preparing the culture for success.
If there was one writing area I wish I had more time to consider, it was considering the DevOps’ future. It is well and good to continue future trends as evolutionary goals but the revolutionary changes often occur just out of our conceptual grasp. I see the future in quantum technologies, especially when considering data analysis, and the potential for DNA memory coding can drastically increase storage. The challenge with these sections is often before one can see the full potential, the outcomes are already present in the market. People discuss AI/ML options as a future trend but the truth is, most of these solutions are already present in the marketplace, it is the process and integration that lags behind.
Overall, I wrote “Confident Devops” to share my DevOps learning, stories, and understanding. I attempted to integrate a short history, compare to other previous methods, and then build through initial concepts. This lead to suggesting some technical DevOps processes required to allow cultural success, and how culture, more than any other aspect, impacts the ability to provide value. I concluded with thinking about impacts from bias, linking security and stability across a DevOps organization, and suggesting where DevOps might improve. I enjoyed writing, and hope you enjoy reading.
