Fundamentals of DevOps & Software Delivery • Yevgeniy "Jim" Brikman & Kief Morris • GOTO 2025
Yevgeniy (Jim) Brikman, author and co-founder of Gruntwork, discusses the pragmatic definition of DevOps as a methodology for efficient software delivery, born from his experience with a deployment crisis at LinkedIn. The conversation with Kief Morris explores the modern infrastructure stack, the critical role of frameworks over custom scripts, and emerging paradigms like Infrastructure from Code and interactive runbooks.
Yevgeniy “Jim” Brikman’s journey into DevOps was forged in the fire of a real-world software delivery crisis at LinkedIn around 2011. Despite impressive external growth, the company’s deployment process was so broken that a single failed rollout cascaded into a two-day ordeal, culminating in a complete rollback. This led to “Project Inversion,” a multi-month, company-wide freeze on all feature development to overhaul the entire software delivery mechanism. This transformation, which involved implementing CI/CD, trunk-based development, and automated deployments, successfully enabled hundreds of deployments per day. The immense pain of that process highlighted the need for better, more accessible solutions, inspiring him to found Gruntwork and author books on the subject.
A Pragmatic Definition of DevOps
Frustrated with abstract, philosophical definitions, Brikman defines DevOps in practical terms: it is a methodology for doing software delivery efficiently, securely, and reliably. The core problem most organizations face is the pain of getting their software in front of users. DevOps, therefore, is the collection of techniques and technologies the industry has developed to solve that specific problem.
The Modern Infrastructure and Application Stack
The landscape of managing infrastructure and applications has evolved beyond manual “click ops.” Today’s approach can be broadly categorized into two layers, with CI/CD acting as the connective tissue.
Two Buckets of Tooling
- Infrastructure as Code (IaC): Tools like Terraform, OpenTofu, or Pulumi are used to manage foundational, less frequently changed components such as servers, load balancers, and networking.
- Application Orchestration: Tools like Kubernetes, AWS Lambda, or Autoscaling Groups manage the dynamic, rapidly changing aspects of applications. They handle concerns that change on a seconds-to-minutes basis, such as autoscaling, auto-healing, service discovery, and load balancing.
The interface between these two layers—how developers define and deploy their applications onto the orchestrated platform—becomes the crucial API between the development and operations teams. This is often managed with application-specific tools like Helm or Serverless Framework, which offer more concise abstractions and local testing capabilities than using a pure IaC tool for app definitions.
The “Impedance Mismatch” of Alternative Models
While models like Crossplane attempt to unify this stack by managing infrastructure using application-centric tools (e.g., Kubernetes YAML), they often introduce an “impedance mismatch.”
In the app world, we’re used to, for example, deploying things by doing a zero downtime rollout and maybe do a blue green deployment. You don’t have that at infrastructure, right? like you have a database or you don’t have a database. The network is configured or it’s not.
This difference can lead to “footgun situations,” where a reconciliation loop designed for stateless apps might inadvertently delete a stateful database. The model feels like a leaky abstraction, similar to Object-Relational Mapping (ORM) tools in database management.
The Inevitability of Frameworks
Many organizations build custom wrapper scripts around tools like Terraform to handle real-world complexities like managing multiple environments, code layout, versioning, and CI/CD integration. This often results in more code than the infrastructure code itself.
Brikman argues that you cannot avoid having a framework; you either use an existing one or you build your own.
Congratulations. Either you use a framework or you create your own. And the thing that happens when you create your own is it’s probably not going to be very well documented. It’s probably not going to be very well tested. It’s probably not going to be maintained.
Tools like Terragrunt are designed to be an off-the-shelf, opinionated framework for Terraform, providing standardized answers for these common challenges. Just as Ruby on Rails provides a structure for web development, a good infrastructure framework provides a necessary structure that prevents teams from constantly reinventing the wheel. The goal of a mature framework is to standardize the 80% of common problems while allowing customization for the unique 20%.
The Future of Infrastructure Management
While existing IaC tools have limitations around importing existing resources, drift detection, and testing, the solution isn’t always to chase a new paradigm. Often, maturing existing tools is more valuable. However, several interesting new paradigms are emerging.
- Infrastructure from Code: Tools like AMP and Nitric infer the necessary infrastructure by analyzing the application code itself. This reduces the need for a separate body of infrastructure code but raises questions about how to handle leaky abstractions and complex deployment strategies without cluttering app code.
- Infrastructure as Model/Graph: Projects like System Initiative model infrastructure as a data graph rather than as a declarative script. Code is attached to nodes in the graph (e.g., a server, a database), which could simplify relationships, testing, and validation.
- Interactive Runbooks: This approach, akin to “Jupyter Notebooks for DevOps,” transforms static documentation (e.g., outage playbooks) into interactive web applications. These runbooks can display live charts, logs, and action buttons, creating a more dynamic and observable way to manage operational processes, including CI/CD.