Part of the problem can be the different roads that new vs established organizations take in their adoption DevOps.
Two Roads To DevOps
There are two roads to DevOps. The first is from the birth of hot new startups like Netflix and Etsy. This is generally a group of developers who have no desire to hire an Operations person. There are enough good open-source tools available and infrastructure services like Amazon Web Services are easy to consume. They have the know-how to build their infrastructure themselves, but they do not want the burden of operational maintenance, so they automate everything they can. They also build efficient test-driven pipelines that run all the way from development to production.
“Netflix is a developer-oriented culture, from the top down.” – Adrian Cockcroft in a 2012 post.
As these startups grow, they retain the desire to minimize Operational overhead. Bigger and better tools are developed internally to fulfill this desire. Automation grows. Pipelines become more mature. After a while, nobody really questions this. It’s just the way it’s done. This is their culture. Some might even call this “DevOps culture”.
The Road More Travelled
The second path usually comes from traditional enterprises. They see these newer companies growing quickly and they marvel at the incomprehensible resilience of their infrastructure. “We want be to like that! How do we get there?”.
DevOps Days and conferences like O’Reilly’s Velocity have become the place for engineers to learn about the DevOps way. This new way brings new tools, new ways of thinking and new culture. The latter is the hardest, so usually deferred. Tools are easier to consume and easiest to bring into an organization.
I have been to a few DevOps Days events now. I have even organized one and spoke at one. They are great events and I always recommend anyone interested in DevOps to attend one.
Attendees are mostly Operations engineers and when they are not they are employees of vendors like Chef, Puppet or cool new companies like Netflix and Etsy.
This is the second route of adopting DevOps: by Operations engineers who already have established technologies, infrastructure, culture, and politics. This is a hard path to travel, due to the weight they have to carry and the change they have to bring. It is also the most common path and the one that most IT departments in enterprise organizations will have to face.
Putting Developers First
Of the two roads to DevOps, the road travelled by Developers to me feels like the truer one.
Developers doing their own Operations are the customer and provider. They want to solve the Operational maintenance issues quickly and get the Operations out of the way. They have the motive for NoOps and DevOps is the result of this desire and the closest we can realistically get to that goal.
Operations engineers, on the other hand, want to do better Operations. They do not want to do away with Operations. Operations is at their core and DevOps tooling will help them do it better. And it does. But where is the “Dev” in this equation?
Silos
The result of the Operations path to DevOps often results in another silo. Only when Operations engineers care deeply about their Developers needs, and can work closely with them, do we have a chance of reaching DevOps utopia via the Operations path.
The Developers path to DevOps makes it hard for them to become a silo, unless they break ties from development or actually have no real control over production. Developers involved in DevOps will have high-touch on both Dev and Ops, rather than just doing better Ops.
Better Ops Ain’t So Bad
Better Operations is not a bad thing. All the tooling coming out of the DevOps movement is empowering Operations teams to move more quickly. They have new ways to build infrastructure, track changes, build ephemeral clusters and reproduce environments on-the-fly.
But we want to do better, don’t we?
Taking the first path to DevOps, that of the Developer, is not an option for most organizations. Therefore, instead of forcing Operations engineers down a path defined by Developers, we need to define a new path for them to follow.
Don’t Serve. Enable
I think if any company wants to really succeed in DevOps then focusing on the needs of Developers would be a good start. As someone wiser than me once said, “focus on your customer and you can’t go wrong”. Developers are your customers.
Most folks get this. “We’re Operations. We’ve been serving the needs of those Developers for years”. But this is the wrong approach.
You need to increase the throughput of the system that gets software into production. If you are standing between your Developers and production, then you are the bottleneck. If Developers need to give you things, be it tarballs or Docker images, then you are getting in the way. This is serving Developers, not enabling them.
Instead of Operations being a reactionary service for placing the pieces of your infrastructure in the correct places on production, be proactive. Decide ahead of time where the pieces should go in a way that will scale with the demands of your Developers and your business. Build the systems to do this and give the Developers an interface to it. Then step out of the way.
Self-Service
I have written about self-service for Developers before and I think it is one of the key pillars of understanding what DevOps is all about. There are many other aspects to good DevOps, but if you get this one right, then you are at least on the right path.
Find our resources on how to improve your CI/CD implementation from Github actions to Jenkins here.
Related Reads
