In this episode of the DevTalk podcast, my colleague Kerry Lothrop and I have a conversation about the state of DevOps. We have known each other for many years at Zühlke, and Kerry wanted to pick my brain on what DevOps really means today, where companies struggle, and where the industry is heading.
What DevOps Really Means#
One of the first things Kerry asked me was to define DevOps. For me, DevOps is a mindset, a culture, and a set of technical practices that allows us to continuously deliver value. It brings all the people, all the technology, and all the methodology together so that we can continuously deliver value to our clients.
The mindset part is especially important. When you have a DevOps mindset, you think in products. It is about the outcome you want to achieve, not the output. Instead of maximizing the number of features, you focus on implementing that one feature that is good for the customer. You bring the user into the center and aim to solve their actual problem.
“DevOps is a mindset, a culture, and a set of technical practices which allows us to continuously deliver value.”
The Origin Story: We Had It Before#
Interestingly, when I look back to the early 2000s, people were already working in what I would call a DevOps operating model. You had small teams that did project management, requirements engineering, testing, development, and operations. Everything was in one team, and there were no silos and no walls of confusion.
Then things got more complicated. Companies decided to scale up software development by creating specialized teams for each discipline. That is when the silos were introduced. The problem is that value does not flow through silos. Instead, things get thrown over walls of confusion, and that is where the problems begin.
DevOps Starts Before Code#
Kerry was surprised when I explained that DevOps starts much earlier than most people think. It begins when the business has a bright idea. Not all ideas are worth turning into a project, so in a DevOps world, you first identify the hypothesis behind the idea and understand what problem you are trying to solve.
Then you define leading indicators to measure success. You go to the customer with UX methods to validate the hypothesis. You define the minimal amount of architecture needed. You break things down into features and user stories. And you develop with continuous testability and operability in mind. After building the continuous delivery pipeline, you measure whether the hypothesis is true and adapt accordingly.
This is the full cycle of the DevOps infinity symbol.
Measuring What Matters#
When it comes to measuring software delivery performance, I always point to the book Accelerate and the DORA metrics. The four key metrics are:
- Lead Time for Changes: How long from code commit until production
- Deployment Frequency: How often you deploy to production
- Change Failure Rate: The percentage of deployments causing failures
- Mean Time to Recovery: How quickly you restore service after an incident
It is important to understand the difference between deployment and release. A deployment brings new code into production with the feature toggle off. A release is switching on the feature toggle. This distinction enables high deployment frequency without disrupting users.
Not every company needs to deploy every 15 minutes. It is perfectly fine to deploy daily or in a two-day cycle. The key is to have a conversation about what makes sense for your context.
The Rise of Digital Factories and Platform Engineering#
When Kerry asked where DevOps is heading, I shared my vision of the age of industrialization of software development. We are moving toward digital factories where teams work on conveyor belts of automation, continuously delivering their products.
These conveyor belts are platforms, built by platform teams doing platform engineering. The platform teams enable the product teams to do DevOps. This is the direction the industry is heading: platforms that reduce cognitive load and let teams focus on delivering value.
“We are entering the age of industrialization of software development. Platform engineering enables product teams to do DevOps.”
AI in DevOps: Already Making an Impact#
We also talked about AI. At the time of the podcast, ChatGPT 4 had just been released. I shared that AI is already helping in the operations space through AIOps. At one of my clients, we generate roughly 16 terabytes of telemetry data every day. That is a big data problem, and AI is excellent at pattern matching to identify problem areas and do root cause analysis.
I predicted that AI will expand beyond planning and building into releasing, monitoring, and deploying. The tools are rapidly evolving, and AI will continue to help us do a better job across the entire DevOps cycle.
Key Takeaways#
- DevOps is a mindset first. The culture and product thinking matter more than the tools.
- Think in products, not projects. Focus on outcome for the customer, not output for the organization.
- Start with the hypothesis. Before building anything, understand what problem you are solving and how you will measure success.
- Use DORA metrics wisely. They are scientifically proven, but apply them to your context rather than chasing elite status.
- Platform engineering is the future. Digital factories with internal developer platforms will enable teams to do DevOps at scale.
- AI will transform the full DevOps cycle. From planning through monitoring, AI is already making an impact and will continue to grow.