What DevOps is Not

For people who have embraced and standing by DevOps, the growing popularity is exciting as ever. More and more organizations of different sizes are embracing the system via including the direct adoption of the DevOps practice into their strategies. This is providing teams the leverage they needed to either start the DevOps journey or to boost the maturity of existing adoptions. On the one hand, when DevOps becomes a mandate, some grassroots passion could be watered down, such as the use of the word is increasingly overused or used incorrectly. DevOps is a cultural movement covering many soft issues. Even as the technology environment changes drastically, the tool chain has been made invalid by more than ever the need for more agile and dynamic infrastructures, virtualization, computing that is and other related technologies.

DevOps integrates a new collaborative culture which embraces several practices joined together for a continuous software development method which puts considerable emphasis on collaboration, feedback loops and continuous enhancement. It needs fundamental cultural changes as well as includes numerous practices that could be overwhelming to those who are just beginning in their journey.

Numerous blog posts have been written on what DevOps is or what it means to certain people. While these posts are well worth reading and fantastic, still there seems to be many misconceptions around the meaning. Some of the misconceptions that people have about it is that it is simply PR. There’s an element of truth in this. In a lot of cases, there were teams who did what is called DevOps today. The aim of the DevOps movement is to create a focus point wherein new people could discover easily mailing lists, blog posts, same-minded individuals and even conferences and books that help spread the word regarding how people think teams and individuals must work. Contrast this to just searching the web for books or guides on good Systems Administration practices. While they do exist, their scope has the tendency to be very broad with many background information and deep technology. This makes them difficult to digest for people who are not that keen on being a full-time operations persons.

To know better what DevOps is, a good idea would be to check out what DevOps is not. There are several points that would explain what it is not about to get to know it better.

1. DevOps isn’t a separate team. Setting up a separate team is a trap that a lot of organizations fall into when starting their DevOps journey. There are some instances wherein a temporary DevOps team may make sense to enable processes and prospective tooling that may be required for adoption. However, the key is to make it temporary, which often is better in theory rather than in practice.

1. DevOps is not just combining the development and operations teams. The usual case when the term comes up is to combine the development and operations team and thus there is DevOps. The system combines a set of practices and processes to be adopted all through the entire delivery pipeline as well as spans several stakeholders. Some of the key practices within DevOps adoptions are CI or continuous integration and CD or continuous delivery. Simply combining operations and development and calling it DevOps could not accomplish the practices.
2. The system is not a one-size-fits-all strategy. With so many various business drivers and technologies to take into consideration when setting up an overall DevOps adoption strategy and identifying the DevOps tool chain as well, it is important to apply similar tenets of DevOps to the strategy. Gather metrics, embrace change, comprehend feedback, fail quickly and correct the course rapidly. For instance, when initially identifying a tool that does not work anymore for one’s environment or technology, it would be better to abandon it and move on. Simply because it is used on the last project doesn’t mean that it is a silver-bullet fix for the next project. First understand the current environment and strategy, then react accordingly.
3. DevOps is not a tool. There are indeed several tools that enable the continuous maturing of DevOps adoptions. Nevertheless, utilizing a single or a couple of tools begins to lead to the belief that the system is a tool. The power of the system is underused drastically if equated to using a single automation tools to its success. Adoption tooling and automation, is a part definitely of DevOps, but only with a combination of end-to-end practices of improved collaboration with continued integration, amplified feedback loops, continuous delivery as well as continuous enhancement. DevOps is a journey and it could begin with a tool. However, the goal should be to identify the DevOps strategy first and look for a tool or a too chain that would be able to meet those goals.

5. DevOps isn’t automation. It is not solely automation. While automation is absolutely a big part of DevOps, it’s not the only one and the deployment of some degree of automation often is interchangeably used with DevOps. Understanding the practices is a big precursor to making sure that DevOps is seen as more than automation. Furthermore, understanding the core principle is the key to understanding the real benefits of the adoption of the system.