I can start this post talking about what is DevOps from a pure academic perspective but, instead of doing the obvious: I am going to tell you what DevOps is not.
DevOps is NOT
Many companies seek online for “DevOps Engineers”, showing that they do not understand what they are asking for. DevOps basically includes everything that happens in an IT organization.
I am pretty sure why someone would look for a person like that, you know; the same people looking for “Full Stack Developers”.
DevOps is about bringing together development and operations to the same table, so: setting up a separate DevOps team is a trap many organizations fall into when beginning their DevOps journey. I would not recommend the creation of a DevOps team as I believe it leads to more silos in the end. I have also found the creation of these teams can lead to further confusion when the mission is not clearly defined.
There are some cases where a temporary DevOps team may make sense to help enable the processes and potential tooling that may be needed for adoption, but the key is making it temporary -which is often better in theory than in practice.
I love the growing number of tools that enable us to continue maturing our DevOps adoptions, but I have noticed the use of one or two tools starts to lead to the perception that DevOps is a tool.
- “We’re already doing DevOps. We have Puppet.”
- “We do DevOps. We automatically deploy through Jenkins.”
I am already tired of hearing stuff like that.
Using Puppet, Chef, Docker, Ansible, Jenkins or any other tool does not mean that you are “doing DevOps”. The power of DevOps is drastically underutilized if you are equating the utilization of a single automation tool to DevOps success. Adopting automation and tooling is, of course, a part of DevOps, but only when combined with end-to-end practices of increased collaboration with continuous integration/continuous delivery, amplified feedback loops and continuous improvement (to name a few)!
DevOps is a journey and that journey may start with a tool, but the goal should be to first identify your DevOps strategy and then find a tool or tool chain that meets those goals.
No, DevOps is not a culture in itself but it does require a strong cultural and structural change in order to be implemented. A cultural change towards cooperation, communication and in its end to the complete integration of the old development and system areas.
This cultural change is so complicated to achieve in some organizations that there are many who directly related it to DevOps, but let’s remember: DevOps is a software development methodology, and a cultural change is not a way of developing software in itself.
I am pretty sure that one caught the eye of a few people, so I will clarify: DevOps is not solely automation. Automation is absolutely a huge part of DevOps; however, it is not the only part, and deploying some degree of automation is often used interchangeably with DevOps. I think understanding the key DevOps practices is a great precursor to ensuring DevOps is viewed as more than just automation. Understanding the core DevOps principles is key to understanding the true benefits of DevOps adoption.
A Silver Bullet
Because there are so many different business drivers and technologies to consider when setting up an overall DevOps adoption strategy as well as identifying your DevOps toolchain, it is important to apply the same tenets of DevOps to your DevOps strategy. Embrace change, gather metrics, understand feedback, fail fast and correct your course quickly.
As an example, if you initially identify a tool that no longer works for your technology or environment, abandon it, and move on. Just because you used it on the last project does not make it a silver-bullet fix for the next one. We need to first understand our current strategy and environment, then react accordingly.
This is the first of a series of articles looking at DevOps from the very bottom to the latest trends in the industry, to read the next one, please go here.