Reviving DevOps: Embracing a Product-Centric Approach (DevOps 2.0)
You don’t do DevOps. DevOps isn’t a role. DevOps is a fundamental shift in how development and operations collaborate. And unless you accept this, DevOps won’t work.
What you’ll learn by reading this article:
- Why DevOps Isn't a Role
- A History of DevOps and its Objectives
- A Reality Check on DevOps Adoption
- Challenges in Implementing a Product-Centric DevOps Culture
- The Cost of DevOps Inefficiency
- Embracing a DevOps + Product Mindset
What is DevOps 2.0?
Think of DevOps 2.0 as the new era in our tech playbook, where we blend development and operations with a sharper focus on what users really need. It's all about cutting through the clutter, boosting productivity, and making sure we're not just using tools, but maximizing their potential for better outcomes.
DevOps History and Objectives
15+ years ago John Allspaw and Paul Hammond demonstrated the power of getting development and operations closer together. Their ground-breaking presentation, titled "Velocity 09", showed that by doing so, you could theoretically achieve numerous production pushes a day (10+).
Everyone was impressed, and in a few years, tech companies worldwide were trying to close gaps between development and operations teams.
The Phoenix Project and CI/CD
Fast forwarding to around 2012, two other events were helping to shape DevOps and making it mainstream:
- “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford popularized three ways to applying work management principles from factory production lines in IT environments: (1) Flow/Systems Thinking; (2) Amplify Feedback Loops; and (3) Culture of Continual Experimentation and Learning. - it helped create and shape culture.
- The development of Continual Integration/Continual Development (CI/CD) practices, which solidified the move towards more agile software deployment.
DevOps quickly matured into a framework for diverse practices, all of which centred around CI/CD. It became an umbrella of practices and principles that welcomed other practices and principles.
This includes Site Reliability Engineering (SRE), which, although not strictly part of DevOps, has become a crucial element in the continuum. It also includes Chaos Engineering and Observability, neither of which were part of the original Phoenix Project. DevOps’ ascent has also driven numerous technical advancements, like Infrastructure-as-code (IaC), orchestration, and shift left security.
All of this has contributed to DevOps becoming a catch-all term for practices aimed at making the entire Software Development Lifecycle (SDLC) value chain more efficient and higher in quality.
Which would be great… if that’s what were actually happening.
The Reality Check
DevOps has yet to shift towards a product-centric model. Instead, it is falling into the category of frameworks, practices that had their day in the sun and faded away. Many teams “do” DevOps the same way they “do” Agile and Scrum.
We pride ourselves on experimenting with solutions for DevOps efficiency, but when outsiders come in and ask developers for best practices, we can’t give an easy answer. Why? Because so little is standardized, and we haven’t developed the requisite processes to create the standards.
Unsurprisingly, 88% of companies surveyed on the Google's State of DevOps report can't deploy more than once a week. Most organizations are stuck in the middle layer of adoption.
Is it because tools aren't optimized? No.
Is it Jenkins’ fault? Nope.
Are we not “DevOpsing” enough? Definitely not.
It’s because the experience of implementing DevOps, the way we conceptualize it, is miserable. Since the Flickr talk 14+ years ago, all that’s changed is the tools we use.
Everything except the workflow has evolved.
Challenges in Implementing a Product-Centric DevOps Culture
Developers primarily aim to create and operate software. They don’t want to get bogged down with infrastructure maintenance. Still, many are stuck performing repetitive tasks which, if not streamlined, can lead to a host of compliance issues, disparate practices cross teams, and unsustainable maintenance procedures.
Most infrastructure teams also operate in a siloed, single-threaded manner. One person is tasked with overseeing the vision, tackling engineering problems, and managing demands. Teams like this are not usually assigned product managers to guide a product-driven approach, and without this additional leadership, infrastructure team leaders can’t achieve a customer-centric focus.
Granted, there’s nothing inherently wrong with not having a product manager. But it’s essential to break apart engineering management and product management within any platform.
It's also not fair to solely expect infrastructure teams to be faster and smarter without addressing underlying organizational issues. However, approaching executives to hire more roles, especially CFOs, is not an easy conversation to have.
The Cost of Inefficiency
These problems have tangible consequences if left unnoticed for too long. Developers seeking efficiency through automation and improved internal services get frustrated fast. The moment they stop accepting the status quo, they’ll pack their bags and leave.
Let's piggyback on our experiences with enterprise clients to show you what we mean. Based on an engineering team of 60 engineers:
Cost-to-value:
- 10% of their time is spent on repetitive tasks due to a lack of tools and standardized processes.
- Another 15% is dedicated to onboarding until a contribution is made.
- Assuming a company cost of 90k per engineer, the total cost is 4.2M with a negative yearly cost-to-value impact of 1M.
Cost-benefit:
- Assuming an avg. salary of ~70k/year per engineer.
- In the first year of hiring an engineer:~15k is spent on recruiting,
~15k on onboarding and repetitive tasks, plus ~21k on taxes. - 50% of the engineer's salary is wasted.
The Future and Relevance of DevOps
Many enterprises are stuck in their DevOps adoption and are still waiting for the promised benefits. However, there is a future.
While we've spent a lot of time building tools, and in the future, organizations will embrace DevOps as the toolkit that enables a value stream to achieve its goals. This is a good start, but more is needed.
Organizations need a team responsible for a platform that enables developers, operates with a product-centric approach, listens to customers, and builds accordingly. By picking the best tools, practices, and principles from the DevOps umbrella, organizations can shape the business needs efficiently and quickly.
In short, treat your developer ecosystem as a product, own it, and build what matters. Enable developers to impact the value stream as fast as possible.
This is what reviving, rebuilding, or re-writing DevOps could look like.
For the time being, let’s call it DevOps 2.0: A DevOps + Product mindset.
Stay tuned for Part II
Learn how you can apply these concepts in Part II. We will dive into concrete use cases of how we are applying these processes at xgeeks, and the impact it brought to our customers.
Stay tuned, we'll be sharing it soon.
In the meantime:
- Check our approach to Platform Engineering
- Watch our panel discussion Reviving DevOps: Bridging the Divide between Promise and Reality