DevOps. DevOps. DevOps. We keep hearing this term over and over and over again, but really, what does it mean? Especially to those of us who aren’t currently Dev or Ops? Or are we? Let’s try to figure out what everyone is talking about.
First, let’s take a look at what we mean by Dev. Dev, or development, is exactly that. It is the developers in our organizations that are working on our key products. But they are doing more than simply coding. Often, or Devs are using a CI/CD model, or Agile development methodologies. Both of these stress collaboration and communication within the organization, and not just between the developers themselves.
When we talk about Ops, we’re really talking about the components that the Devs are doing their work on. If Devs can rapidly spin up their environment, by simply ordering it from a menu of infrastructure components in a couple of clicks, versus having to wait for someone to build it for them, they’re given a ton of time back. They can be innovating instead of waiting around for people to deploy their infrastructure. It is Ops job to make sure that the Devs have the ability to do that. Ops is about automating the infrastructure tasks that are key to the Devs, from spinning up development environments, to moving code to production. It is about the processes we need to have in place to get there.
So Who’s DevOps?
I don’t think there’s organizations that are formed out of DevOps people, meaning people doing the Dev and the Ops…or if they are, they may have the wrong idea. DevOps is about Operations empowering development by working closely together. DevOps is about Development working with Operations to ensure the infrastructure meets their needs, and allows them to be agile. The Devs are good at Development, we should let them do their thing. The Ops people are good at operations, and by operations, I mean the designing, deploying, and running of infrastructures, not just Ops in the sense of supporting an infrastructure. If we try to combine this into a person that’s doing both, I don’t think we’re helping ourselves. If our DevOps team consists of 10 people, we need a balance of Devs and Ops, depending on the size of our infrastructure and our business needs.
The DevOps Mindset
If we let our Devs continue to work they way they have, and our Ops continue along their path, by creating a DevOps team we’re not really there. DevOps is about changing the mindset and processes of both groups to enable each other and work together. One of my favorite books about the topic is a novel called The Phoenix Project. It does a great job of explaining how organizations need to change to adapt the model, and how they actually go about doing it. It is also a really easy read that sort of just gets you into the mindset without any effort. Another great resource is a series called Devs are from Venus, Ops are from Mars from the About Virtualization blog. This series is breaking down topics pertaining to DevOps from both sides. The DevOps Enterprise Summit also as a great YouTube channel with various talks on how organizations have gotten there.
Are you ready for DevOps?
This is the big question that you have to ask of yourself and your IT organization. Remember, DevOps is more than just a person or a team, it is a methodology. The trick with bringing DevOps practices into your organization is to make sure that you work with your processes first. There are lots of tools that can help along the way with CI/CD but the real challenge will be building the feedback loop between the teams. A great way to think of that is to follow what Gene Kim, co-author of the Phoenix Project shows us, which is what is called the 3 Ways. Once you start bringing that into your teams, you may find your way towards becoming a DevOps practitioner at your organization. Then the real winner is everyone, including your business and your customers.
Song of the Day – Milky Chance – Stolen Dance