DevOps is Broken.
Updated: May 20, 2022
Here are three reasons why we are hearing this from a number of customers and prospects and why they want to offload the complexity of DevOps and CI/CD processes
We at Cornerstone and TruStacks have been saying it for the last few months. DevOps is in fact broken. The original idea of DevOps was to bring a culture and a subset of best practices and processes in order to bring Development and Operations teams together in order to deliver their product more efficiently, securely and with a higher quality standards.
In ten (10) years of our Consulting practice at Cornerstone, I can safely say that maybe 20% of our customers implemented DevOps properly; and I'm trying to be nice with that estimate.
Late night deployments and lack of confidence in your process should be a thing of the past, but they unfortunately are not.
DevOps is still needed but I think we need to address two things:
Why is DevOps Broken?
Why you might need a "DevOps Reset"
1. ) Why is DevOps Broken? It depends on the organization
Reason#1: DevOps is too complex
One of the main reasons we say "DevOps is broken" is that DevOps has become so complex that we have now seen a trend where organizations believe they have the need to hire a third (potentially siloed) team called "DevOps Engineers".
On average, for every seven developers there is a need for one DevOps Engineer
If we reflect on the original intention of DevOps, why do we need this third role? Although I don't agree with the creation of this new role I can at least empathize with how it may have been created out of necessity.
We as an industry have complicated DevOps with tool overload, new regulatory/compliance standards and new security requirements. We have now outpaced our ability to fully automate and no one is pausing to address the need.
DevOps is not a person, it is not a tool and it is not a platform however we still find ourselves thinking this way.
Reason#2: Teams are still siloed
Pre-COVID we used to teach hands-on Red Hat Ansible Automation workshops. I had a favorite slide I would spend a bit of time on that said "Automated Silos are still Silos"
I believe automation is still the best facilitator and first step towards a proper DevOps culture. It forces communication between teams and people that normally did not work together but are now required to in order to adopt a DevOps environment.
Many companies are trying to do "DevOps" and they still do not have their automation story figured out. You are trying to fit processes, CI/CD pipelines and tools into an organization that never addressed the silos the first place. Maybe look at automating before hiring a "DevOps Engineer"?
Reason#3: We're doing the same thing over-and-over-and-over (aka. "Technical Debt")
This will be a post on its own. After watching our Cornerstone consultants implement the same technology, the same CI pipeline step, the same ArgoCD, the same GitLab configuration, deploying to the same Kubernetes or Red Hat OpenShift environment we finally asked ourselves "Why?". Why are we and in turn our customers bogging ourselves down with technical debt?
Development teams can recoup more than 20% of their development time through an orchestration platform
Your team is bogged down by technical debt they cannot currently avoid. I agree, DevOps has become complicated by:
New security requirements by shifting security left
Tool overload and fragmentation
Multi-Cloud deployments require configuration of multiple deployment targets
New tools needed to accomplish a desired outcome, or tool overload
Microservices are necessary but sometimes require more integrations and add complexity
Your development team was hired to be creative and bring your product to market. Your operations team was hired to ensure that cloud environment the product is running on is stable, secure and scalable.
Enable them to work together and focus on the product not the process.
2. ) Why you might need a DevOps Reset
If you can relate to any of the reasons we think DevOps is broken, you are primed for a DevOps Reset. Later this week you will learn more about how you can lead your own DevOps reset by either automating, or finding a platform that can take much of that load off you and your team.
In the meantime, feel free to reach out with any questions or comments about how you can lead your own DevOps reset