Fundamentals of DevOps & Software Delivery • Yevgeniy "Jim" Brikman & Kief Morris
Yevgeniy "Jim" Brikman, author of "Fundamentals of DevOps and Software Delivery," discusses his journey from app developer to DevOps advocate, triggered by LinkedIn's deployment crisis. The discussion with Kief Morris explores the practical definition of DevOps, the relationship between infrastructure as code and application orchestration, the necessity of frameworks over custom wrapper scripts, and emerging paradigms including infrastructure from code, infrastructure as graph models, and interactive runbooks.
The Journey to DevOps: A Lesson from LinkedIn
Yevgeniy “Jim” Brikman’s career transitioned from application development to the DevOps space due to a pivotal experience at LinkedIn around 2011. Despite impressive external growth, the company faced a severe internal crisis: they could not reliably deploy updates to their product. A failed two-day deployment effort, which led to a complete rollback, culminated in “Project Inversion”—a company-wide freeze on all feature development for months.
This period was an “all hands-on deck” exercise focused entirely on fixing software delivery. The team implemented practices we now associate with DevOps, such as CI/CD, trunk-based development, automated deployments, and feature toggles. This transformation successfully enabled LinkedIn to move from painful bi-weekly deployments to hundreds of successful deployments per day. This experience, Brikman notes, highlighted that where there is pain, there is opportunity, and drove him to found Gruntwork and author books on the subject.
Defining DevOps and the Platform Engineering Landscape
Brikman offers a pragmatic definition of DevOps, cutting through the common abstract debates: it’s a “methodology for doing software delivery efficiently.” The primary goal for most teams is to get software to users in a reliable, secure, and repeatable manner. The discussion outlines the typical division of tooling:
- Infrastructure as Code (IaC): Tools like Terraform, Pulumi, or OpenTofu are used to manage foundational infrastructure (servers, networks, databases) that changes relatively infrequently.
- Application Orchestration: Tools like Kubernetes, AWS Lambda, or Autoscaling Groups manage dynamic, frequently changing application concerns like scaling, auto-healing, and service discovery.
The common pattern involves an operations team using IaC to provision the core infrastructure, including an orchestration platform like a Kubernetes cluster. The development team then uses tools like Helm or Kustomize (sometimes even IaC tools) to deploy their applications onto that platform. The combination of the CI/CD pipeline and these application deployment configurations forms the crucial “API” between the development and operations teams.
Frameworks vs. Custom Wrappers
A significant challenge in the industry is the proliferation of custom wrapper scripts built around tools like Terraform to handle environment management, code reuse, and CI/CD orchestration. Brikman points out that these custom solutions are often poorly documented, tested, and maintained, creating significant risk when their original author leaves.
He argues for the adoption of frameworks, stating, “Either you use a framework or you create your own.” Tools like Terragrunt, an open-source project from Gruntwork, serve as an opinionated framework for Terraform. Much like Ruby on Rails provides a structure for web development in Ruby, Terragrunt provides standardized solutions for managing multiple environments, keeping code DRY, and handling deployments at scale. While frameworks are opinionated, adopting a well-maintained, open-source standard is generally preferable to building and maintaining a fragile, bespoke solution. Mature frameworks often allow for customization where it’s truly needed, providing an 80/20 balance between convention and configuration.
Exploring the Future of Infrastructure Management
While acknowledging the immense progress made with IaC, Brikman also recognizes its current limitations, such as difficulties with importing existing resources, managing drift, and testing. He discusses several emerging paradigms, while cautioning that they are still maturing and advocates for the “choose boring technology” principle.
-
Infrastructure from Code: Tools like Amped and Nitric analyze application code and automatically infer the required infrastructure. This approach moves infrastructure definitions closer to the application but raises questions about how to handle complex deployment strategies and avoid creating a “leaky abstraction.”
-
Infrastructure as a Graph/Model: Projects like System Initiative model infrastructure as a graph of data, separating the state of the infrastructure from the code that manages it. This model facilitates better testing, validation, and management of relationships between components. Kief Morris refers to this as “infrastructure as graph.”
- Interactive Runbooks: This paradigm transforms static, text-based operational playbooks into interactive web applications. Described as “Jupyter Notebooks for DevOps,” these tools allow operators to interact with systems directly within the runbook—viewing live charts, seeing logs, and clicking buttons to execute commands like a redeploy. This makes operations more intuitive, auditable, and even enjoyable.