For those who have been embracing and championing DevOps for years, the growing popularity of DevOps is as exciting as landing your first job out of college! Okay, maybe not that exciting, but still really cool. More and more companies of all sizes are embracing DevOps by including the adoption of DevOps practices directly into their fundamental strategies.
On one side, this is giving teams the leverage they have needed all along to either begin their DevOps journey or to increase the maturity of existing DevOps adoptions. On the other side, when DevOps becomes a mandate, some of that grassroots passion can become watered down, as the use of the word becomes increasingly overused or incorrectly used.
DevOps incorporates a new collaborative culture that embraces numerous practices combined together for a continuous software development methodology that places significant emphasis on feedback loops, collaboration and continuous improvement. DevOps requires fundamental cultural changes and includes so many practices that can be overwhelming to those just starting their journey.
Instead of highlighting everything that DevOps is, I thought it would be good to take a step back and highlight what DevOps is not instead.
1. DevOps is not simply combining Development & Operations teams
We’ve all seen this one when the term DevOps comes up. “Let’s combine the Development & Operations team and, voilà!, we now have DevOps.” DevOps combines a set of processes and practices to be adopted throughout the entire delivery pipeline and spans multiple stakeholders. A couple of the key practices within DevOps adoptions include continuous integration (CI) and continuous delivery (CD). Simply combining two teams and calling it DevOps cannot accomplish those practices.
2. DevOps is not a separate team
Setting up a separate DevOps team is another trap many organizations fall into when beginning their DevOps journey. In general, I’m not a fan of the DevOps team as I believe it leads to more silos in the end. I’ve 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. There are several great blogs out there discussing DevOps teams such as Matthew Skelton’s blog, “What Team Structure is Right for DevOps to Flourish?”
3. DevOps is not a tool
Let me be the first to say I actually love the growing number of tools that enable us to continue maturing our DevOps adoptions, but I’ve noticed the use of one or two tools starts to lead to the perception that DevOps is a tool. How many times have you heard?
“We’re already doing DevOps. We have Chef.”
“We do DevOps. We automatically deploy through Jenkins.”
Keep in mind, I’m a big fan of both Chef and Jenkins, but I think the power of DevOps is drastically underutilized if you’re 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.
4. DevOps is not a one-size-fits-all strategy
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 tool chain, it’s 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 doesn’t make it a silver-bullet fix for the next one. We need to first understand our current strategy and environment, then react accordingly.
5. DevOps is not automation
That one may have caught the eye of a few people, so I’ll 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.
There are a lot of things that DevOps is and I think I share a widely spread passion for DevOps. There are also a few things that DevOps isn’t—or isn’t solely. If you’re just starting your DevOps journey or still maturing your existing model, making sure everyone on your team has some basic DevOps education and is aware of the DevOps strategy for your project is key. It will go a long way in helping everyone understand that DevOps is about a lot of things. It’s also not about a lot of things.
The list above isn’t exhaustive and I’m sure you all have a few you’d like to see on the list. I’d love to hear you thoughts and suggestions at @Shelbee_SE.
You also can download and browse through the DevOps for dummies e-book.
About the author/Shelbee Smith-Eigenbrode
Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM Cloud Infrastructure Center of Competency. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.
Very nicely said. DevOps is a cultural mindset , a shift in our thinking , not
a new team but a re-org, engaging early, a formation which challenges unwanted
loops or iterations, having feedback loops at every level, and most importantly it’s NOT only
automation or requiring somebody who knows both coding and ops!
Great article!
@debajitkataki:disqus – Thank you for reading and posting a comment! I love seeing comments/feedback on here. I’m always interested in everyone’s perspectives. I love that you emphasized the feedback loops..I think we miss that way too often and is so key to success as well!! Thanks again for taking the time to read and comment!
Interesting perspective on DevOps. It is not one thing and there is no silver bullet to implementing DevOps in an organization. It requires the proper people, process and tools to do what is need to drive the business forward.
@disqus_ADDXBmKwBx:disqus – Thank you for taking the time to read it. I completely agree that we tend to lose focus on making sure there is that end-to-end adoption including people, processes and tools. Thank you again for reading and providing feedback!
Like it. Unfortunately I am seeing more and more in the field, companies are “adopting Devops” by doing the exact same 5 things you point out not to do 🙂
@maketing4success:disqus Thank you for the feedback! So glad you liked it. I agree…”adopting DevOps” has become more of a label in a lot of cases as opposed to truly embracing the DevOps we all know and love 🙂
Devops journey for any team or company also depends upon DevOps roadmap that we create for application ,if we have enterprise application, then its become difficult to apply all Devops practices , Some time it mix with waterfall,agile and Lean 🙂
@devopsgrit:disqus :
100% agree…we definitely have situations where we are “agile’ish” for
business reasons, architectural reasons, …the list goes on and on
:)! I wish there was a silver bullet / one-size-fits-all strategy or
approach but sometimes we have to do some hydbrid DevOps at times.
Thanks so much for reading and taking the time to comment!!
Agree with most; the other three I keep seeing:
1. Devops is a fancy build engineer that knows jenkins
2. Devops is putting a developer in OPs and having him/her automate the deploy
3. Devops means we get rid of OPs and just have DEV deliver product to customer directly
Not sure I agree on devops is not a team item. This works in reference to certain models where you are deploying to cloud, just a software widget or you don’t own the hardware. There are some definite companies with paradigm shifts that require a devops team.
Now full appliances in which you have to combine custom hardware and multiple custom software packages into 1 working appliance changes this constraint. This requires a system integration team; there is no way around this. In most cases you will find making this team the devops er “philosophers” very important to push the feedback and CI models to all the DEV teams feeding them upstream. Then down to QA and eventaully OPs.
DevOps is not just automation but if we want it to make it a zero-touch automation, then we should be able to do it.