What is not DevOps?

For those who have been working with DevOps for years and are heavily involved in this methodology, its growing popularity is as exciting as it will get its first job right after graduation! Well, maybe not as exciting, but still really great. More and more companies of all sizes are opting for DevOps, implementing methodological practices directly into their basic strategies.

On the one hand, this situation gives the teams everything they need to get started with DevOps or to develop existing applications to a greater extent. On the other hand, when this method becomes mandatory, a part of the bottom-up passion for it can be extinguished because the word itself is increasingly being misused or used in an inappropriate way.

DevOps includes a new culture of collaboration that incorporates numerous practices combined for continuous software implementation methodology. This methodology places considerable emphasis on feedback loops, collaboration and continuous improvement. It requires fundamental changes in culture and involves so many practices that it can be overwhelming for those who are just starting out with this method.

Instead of emphasizing everything DevOps is, I think it would be good to emphasize what it is not.

DevOps doesn’t simply connect teams of developers and administrators

We all heard it when someone starts talking about DevOps. “Let’s connect the teams of administrators and programmers and voilà! We have DevOps! This method combines a set of processes and practices that need to be adopted throughout the solution delivery process and also involves many stakeholders. Several key practices in adopting the method include Continuous Deployment (CI) and Continuous Delivery (CD). A simple combination of these two teams and naming them DevOps does not implement these practices.

DevOps is not a separate team

Setting up a separate team is another trap into which many organizations starting their adventure with this method fall. Generally speaking, I’m not a DevOps fan, because it ultimately leads to more silos. I’ve also noticed that creating such teams can lead to further ambiguity if the mission is not clearly defined.

There are cases where temporary DevOps teams make sense – they can help you run the processes and potential instrumentation needed to adopt these processes. However, it is crucial that this situation is temporary, which often works better in theory than in practice. You can find some great blogs that the teams discuss. One such blog is Matthew Skelton’s blog: “What is the right team structure for DevOps’ development? What Team Structure is Right for DevOps to Flourish?

DevOps is not a tool

In fact, I am delighted with the growing number of tools with which we can continue to develop DevOps applications. However, I have noticed that using one or two tools starts to lead to a situation where DevOps is perceived as a tool. How many times have you heard:

“We are already using DevOps. We have the Ansible tool.
“We use DevOps. We use the Jenkins tool for automatic deployment.

I’m a huge fan of Ansible, Puppet and Jenkins tools, but I think the power of DevOps is not fully exploited when you compare the use of a single automation tool with success. The use of automation and instrumentation is of course part of DevOps, but this is only the case when combined with complex practices of increased collaboration with continuous integration/continuous delivery, increased feedback loop and continuous improvement (to give just a few examples)! DevOps is a journey, and the journey can start with a tool. However, the goal should be to identify a strategy beforehand and then to find a tool or a chain of tools to meet this goal.

DevOps is not a strategy that fits everything

Since there are so many business driving forces and technologies that need to be taken into account when determining the overall strategy for adopting the DevOps method, as well as the identification of the tool chain for this methodology, it is important to apply the same DevOps principles in the strategy related to this method. Accept change, collect metrics, understand feedback, quickly fail and quickly return to the right course. For example, if you initially identify a tool that no longer works for your technology and environment, abandon it and continue with the next steps. Just because you’ve used it in an earlier project, it doesn’t mean that it’s perfect for the next one. We must first understand the current strategy and environment and then react accordingly.

DevOps is not automation

Such a statement could have attracted the attention of several people, so I will explain: DevOps is not just automation. Automation is an absolutely huge part of this method, but not the only one. The implementation of a certain degree of automation is often used interchangeably with DevOps. I think that understanding key DevOps practices is an excellent start to ensuring that this method is seen as more than just automation. Understanding the main principles of DevOps is the key to understanding the real benefits of adopting this methodology.

DevOps is a lot of aspects – I think that my great passion for this method is not isolated. There are also many aspects that DevOps is not, or is not exclusively. If you are just starting your journey with this method or developing an existing model, make sure that all people in the team have a basic knowledge of the method and are aware that the DevOps strategy is crucial for your project. It’s very important to help everyone else understand how many aspects DevOps includes. And how much it does not include.