Fundamentals of DevOps & Software Delivery • Yevgeniy "Jim" Brikman & Kief Morris
Yevgeniy "Jim" Brikman, author of "Fundamentals of DevOps and Software Delivery," and Kief Morris, author of "Infrastructure as Code," discuss the practicalities of modern software delivery. Jim recounts his career-defining experience at LinkedIn, where a deployment crisis led to a company-wide focus on fixing delivery pipelines. The conversation explores the pragmatic definition of DevOps, the interplay between Infrastructure as Code and application orchestration tools like Kubernetes, the necessity of frameworks like Terragrunt over custom wrapper scripts, and a look at emerging paradigms like Infrastructure from Code, Infrastructure as a Graph, and Interactive Runbooks.
Yevgeniy “Jim” Brikman shares his journey from an application developer to a DevOps advocate, a path heavily influenced by a significant deployment crisis at LinkedIn around 2011. The company, despite its external success, was unable to reliably update its own product, leading to a multi-month freeze on all feature development. This “project inversion” forced the entire company, including developers, designers, and product managers, to focus on fixing software delivery. This experience, which Brikman retrospectively calls a “DevOps transformation,” involved implementing CI/CD, trunk-based development, and automated deployments, ultimately enabling hundreds of deployments per day with fewer issues.
A Pragmatic Definition of DevOps
Brikman expresses frustration with ambiguous definitions of DevOps that focus more on what it is not. He proposes a practical definition: DevOps is the methodology for doing software delivery efficiently. The core goal is to get software to users in a reliable, secure, and repeatable manner. This pragmatic view frames the entire discussion, focusing on the concrete techniques and technologies that enable effective software delivery.
The Tooling Spectrum: IaC and Application Orchestration
Modern software delivery relies on a spectrum of tools that can be broadly categorized into two buckets:
- Infrastructure as Code (IaC) Tools: Tools like Terraform, OpenTofu, and Pulumi are used for managing foundational infrastructure (servers, networks, databases). These components change relatively infrequently, on the order of days.
- Application Orchestration Tools: Tools like Kubernetes, AWS Lambda, and Autoscaling Groups manage the application layer. They handle dynamic requirements that change on a second-to-second basis, such as autoscaling, auto-healing, service discovery, and load balancing.
CI/CD serves as the connective tissue between these layers. The combination of orchestration tools (e.g., Helm for Kubernetes) and CI/CD templates (e.g., GitHub Actions) effectively becomes the API between the development and operations teams, forming the basis of what is often called a platform.
The Inevitability of Frameworks
Many teams build custom wrapper scripts on top of tools like Terraform to handle complexities like managing multiple environments, reducing code duplication, and orchestrating deployments. Brikman argues that this leads to creating bespoke, poorly documented, and unmaintained internal frameworks.
He advocates for using standardized, open-source frameworks like Terragrunt (a tool from his company, Gruntwork). He draws a parallel to web development frameworks like Ruby on Rails, stating, “You can’t not have a framework. Either you use a framework, or you create your own.” Adopting a well-maintained, opinionated framework provides out-of-the-box solutions for common problems, allowing teams to focus on more valuable work instead of reinventing the wheel.
Questioning IaC and Exploring New Paradigms
While IaC is a massive improvement over manual processes, it has limitations regarding importing existing resources, handling drift from manual changes, and testing. Brikman discusses several emerging paradigms that attempt to address these challenges, cautioning that they are still immature and that choosing “boring technology” is often wiser for production systems.
-
Infrastructure from Code: Tools like Ampt and Nitric infer the necessary infrastructure directly from application code. For example, they analyze a Node.js application and automatically provision the corresponding cloud services. This reduces the need for separate IaC, but the abstractions can be leaky and the tools are still in their early days.
-
Infrastructure as a Graph/Model: Championed by tools like System Initiative, this approach models infrastructure as a data graph rather than a pile of declarative code. Each node in the graph (e.g., a server, a database) has associated code (e.g., in TypeScript) that defines its behavior. This model excels at managing relationships and allows for custom logic, validation, and testing. The main skepticism is around the long-term viability of the visual editors often paired with these systems.
-
Interactive Runbooks: This paradigm treats operational playbooks not as static documents but as interactive web applications. Similar to Jupyter notebooks for data science, these tools (which can be managed as code) embed live charts, logs, and action buttons directly into the runbook. This allows operators to visualize state and execute commands (e.g., redeploy a service) within a single, interactive context, making operations more efficient and even enjoyable.