I'd like to preface this post with an acknowledgement: this blog's adventures have kinda been all over the place. For that, I apologize - I've been unfocused and inconsistent. I'm hoping to fix that.
(To that end, I'd greatly appreciate if you send some feedback, let me know if you find this useful.)
So let's get started, shall we? I picked a topic - something I learned a lot about over the past few years and I have lots of thoughts on: DevOps, and what it means to me as someone with a career.
The Target Audience
I would suggest that there are two major groups of folks that could benefit from what I'm planning to write about:
- Experienced developers who have not tried DevOps yet and want to understand what all the noise is about.
- New developers, who might have been self-taught or following some tutorials to learn to code, and want to add some professional "zing" to their work.
If you think I've missed the mark - well, that's why I asked for your feedback 😏 so don't be shy - I'd be happy for us to debate, discuss, and learn from each other!
What's a DevOp and Why Would I Want to Be One?
Ok, ok, so right out of the gate, there's no such thing as "a DevOps".
DevOps is a portmanteau of "Developers" and "Operations". These two groups are, in traditional shops, distinct groups that do not mingle. In this world, the rules are straightforward and strictly held:
- Developers write code and ship it.
- Operations keeps systems running.
For many years, this is how work was divided up. It was intended that Developers would be focused on creating and Operations would be focused on maintaining.
This didn't work.
Well, that's unfair. I should say, "This didn't scale". On paper, it's fine - "hey look, we've separated concerns and established teams to focus on each concern. This is great! We have builders over here on a team and maintainers over there on a different team. This is expert-level Management!"
That's out of the standard management playbook, right? Split the organization, give people their own part to focus on, let them develop expertise in their function. It usually works. But in software, it created problems! Why?
Losing sight of the goal
The reason that it doesn't work here is that both teams, while operating on specific functions, are still part of the same ecosystem. The dev team is responsible for building features, right? The ops team is responsible for maintaining whatever new features are built, right? And those features are part of... the same overall system. The two teams' work is inextricably linked to each other.
That by itself isn't the problem-creator, though: what hurts is that the teams' incentives are not only misaligned, they're in direct opposition! Think about it: devs get paid for making more stuff as fast as they can. Productivity is king, we're always looking to ship the next big thing! Ops, however, is incentivized to keep things stable. And the natural means to incentivize stability is... to minimize the amount of change.
Now you've got a dev who wants to go to production as soon as possible, and ops who wants to slow down the release of new stuff into production so that the system stays up more reliably. Their very nature sets them up to oppose each other! Some great teamwork you've created there, huh? Two teams, each whose only way to "win" is to make the other team "lose"... add in something like a performance bonus for each of them, and watch the deathmatch start! 🙃 It becomes quickly apparent that we've gone from "not helping" to "actively hurting".
Enter the DevOps
So this is why we need DevOps. It's a set of principles that help us re-align these teams so that their goals aren't directly opposed anymore.
How do you do that? Well... it's a bit of compromise, really. The first step is to realize that both Dev and Ops have the same goal: to Help the Business Win.
Mythbusting
Some common myths in organizations prior to them understanding DevOps:
- The Iron Triangle. You'll often hear this one as "better, faster, cheaper... pick two." It's a belief that we can't improve all 3 aspects of any given system at the same time.
- We do this for Compliance reasons (note the Capital C). Things have to be the way they are because Auditors say so!
- We don't have time to make these kinds of improvements because we have delivery dates to meet. Our organization is already stretched thin - adding this DevOps work on top is only gonna make us slower!
As a budding DevOp, it's your job to realize that these are excuses, and they're based in either intellectual laziness or outright ignorance. While I certainly would NOT recommend that you use that line in your presentation to management 😬, you must recognize the myth as such when it's brought up, and overcome it. We'll learn how to do that in a later Adventure... stick around! 😉
What's in it for me?
Let's say my organization adopts these principles and makes a good solid run at implementing and practicing them. What do we get out of it?
Better Systems. Your builders will be more responsive to their customers' needs. They'll be able to more readily recognize opportunity and prioritize more valuable work. Their work will be less inclined to be buggy and broken when it's pushed to production, keeping the burden on Ops lighter.
Faster Delivery. Your builders will be able to ship that better code faster! The new tools, processes, and capabilities that you implement for your dev teams will make their delivery process smoother and more mundane.
Cheaper Projects. With fewer bugs and faster delivery at the same time, your projects will have less opportunity to languish and drag on until they're over budget.
Happier Ops. The improved quality reduces the stress of being in Ops. Implementations will be less painful. Uptimes will improve, and preventable outages will be prevented.
Happier Devs. Developers are incentivized to ship code, remember? So what happens when they're suddenly able to ship with impunity? Delivery pipelines and automation all around will thrill them! We've often heard it said that happy developers are productive, but the inverse is also true... productive developers are happier!
Wrapping up
The journey to DevOps for some goes very, very quickly... but for others, very, very slowly. It's always a worthy journey! Tune in next week as we talk about How to Start a Project!
Top comments (2)
I've always said that DevOps is the natural progression of Agile. When we are doing waterfall, the rate of change being introduced is relatively low and the dynamics of the Development and Operations teams kind of works. Certainly, there are still the issues you point out above, but the interactions are fewer and therefore more manageable. When a company starts to embrace Agile, the pace at which Development teams attempt to push code into Production environment increases which makes the issues amplify. This is where I believe DevOps comes in.
Agile is the Why, DevOps is the How... :)