So you wanna do DevOps, well here is a take from a guy who has never been in a DevOps role, and has never utilized DevOps practices in an environment, and lets face it, I really have no idea what “Modern DevOps” is. In fact, I hate the notion of “DevOps” as a snapshot of any time period, and I also hate adding security to a pipeline and thus changing the naming to “DevSecOps” so you can get compliance and security environments into the mix with product advertisements and targeting different areas that have been labeled “Ill-equipped” for DevOps. Lemme level set something. DevOps works everywhere, because its not tied to a tool, or an environment. DevOps isn’t about tools, and its certainly not about fitting it into an environment. What it is, is a singularity inside an individual to fix problems outside of your role. Probably this will come across as inflammatory statement, and I may have already lost my readers, but if your still here, and want me to try to backup my wild accusations hear me out.

DevOps, as we all know, is a monniker of developers and operations to work together. For me, in order for DevOps to do this it needs to fill in the gaps in a business and move to a end state that enables data flows, automation, and documentation across roles. This means the Developer has some understanding of operations, and it means that the operator has some understanding of the developer. Now, I’m not saying that the end goal is to “cross the streams” of the roles, but rather to communicate, and care for each other.

I mentioned how I have not been a part of multiple DevOps roles, or areas, but I have seen DevOps fail multiple times repeatedly. I’ve also spoken to customers who state they are, “DevOps” because they utilize a CI/CD tool. Would it surprise you that I met a customer who uses Terraform, Ci/CD pipelines through AWS services, and utilizes all infrastructure as software defined, but they still had an application outage for over 8 hours. What is missing? They are using all the DevOps tools that need to be running right?

By now you can guess the whole point of this blog is probably not about the toolset to help enable DevOps. Those are great, but they are not the whole point. The point of DevOps is the mindset. The mindset that you have will help you understand if you truly are a DevOps minded individual, or if you should focus more on a specialty that allows you to work in your world and not touch others.

First. What is your role? (This is a trick question) Can you guess? In my opinion, your role is to help provide a service for the business that writes your checks. So the 2nd question gets easier. Who is your customers? Notice the question is plural. If your role is to help the business then the customer is… everyone in the business? Well no, because then you wouldn’t get anything done. Besides you wouldn’t be able to talk to everyone in the day. No your customers are the closest individuals that you are allowed to work with. Now you may not have access to developers, or accounting, marketing etc. but you may have access to an SRE and someone that is blended into your group. This is where you find where you can “help” and grow in that area. Where I see DevOps work, is where people talk to each other, define action items and who can take them. Then execute on those action items that will then lead to new discussions and new action items.

This is where the SRE teams come in. To me SRE teams are silly, as they are a construct created so grumpy people don’t have to work with others, and so they created a role specifically to play intercession for each role. However, that being said, it works. SRE works between the groups and they get things done. However, the SRE guy normally works with the mindset of bridging the gap. If the operator had that same perspective, wouldn’t they connect with the other groups?

I’ll give another perspective to what DevOps is. Imagine a startup company with 5 individuals. At this stage, you don’t have a C-suite of people working just to build the business. At this point you just have the people that build the application that does the service consumers will purchase. Notice the separators here? Everyone has the same role. Build the app. Now each team member may have a specialty in an area, but they wont have the ability to say, “That’s not my job”. The goal here is to keep pushing the stone up the hill together, everyone has the same direction and the same end goal. There is no sideline goals.

In fact, saying “That’s not my job” defines a non-devops mindset. A more Devops minded individual would say something like, “I’m not skilled for that” or “I don’t see how I can execute on that in a timely manner”. Its not that its a solid “Not my problem” type answer, its that the way they are going to fix the problem is off target, and thus needs to be adjusted. DevOps doesn’t work very well in hard rules where people can be forced to do things. Instead it needs to be setup with the possibility of “Can you do this?” and the answer back would be more of a “I don’t think I can execute that because X”. Its a different perspective.

Just some of my musings around the idea of DevOps. Mainly because I’m tired of people using 1 “DevOps” tool and say they are a “DevOps” shop. I’m a grumpy DevOps guy. Its about the mindset, not the tool. #EndRant