The 10 Myths of DevOps

Although not officially coined until 2009, DevOps ideals have been explicitly discussed since at least 2006. Recently, however, the term "DevOps" has gained increasing popularity across a variety of fields and industries. DevOps is not a development methodology or technology; DevOps is an ideology. It is a way to facilitate organizational prosperity and growth while increasing each individual employee's happiness along the way. As DevOps has gained in prominence, a gap has been created between the original definition of DevOps and this new "enterprise-ready" buzzword. In honor of the holiday season, I present to you the 10 Myths of DevOps!

Myth #1 - You can hire a DevOp

If you have not watched Ryn Daniels's (@beerops) DevOps is Dead (Long live DevOps) talk from DevOps Days Minneapolis, stop. Go watch it right now! It is an excellent talk and explains many of the industry's fallacies.

It is no coincidence that this is the first myth on the list. By far my biggest pet peeve is when organizations post job positions for "DevOps engineers" or "DevOps specialists". I realize this may come as a shock, but there is no such thing as a DevOps Engineer!

The purist definition of "DevOps" is actually a ideology - it is the concept of two or more units (teams) working together for a common success criteria. Originally DevOps was coined to specifically address the growing gap of concerns between Developers (the men and women who author code) and Operators (the men and women who keep that code running on production systems). For a more detailed history, please watch my Brief history of DevOps talk.

DevOps proposes more communication and collaboration between these highly-related organizational units - Development and Operations. While this may seem like common sense today, it was met with both praise and harsh criticism. Since that time, many organizations have shared amazing successes implementing DevOps principles include Etsy, Facebook, and Flickr.

It is important to note that none of these organizations hired a "DevOps Engineer". Their successes can be attributed to cross-team collaboration and willingness to change their current processes and procedures toward a common goal.

The role of a so-called "DevOps Engineer" or "DevOp" would be to encourage cross-team collaboration and ensure organizational units regularly share ideas and goals. Sound familiar? It should - we call those people "managers". You cannot hire a DevOp to fix your organization because there is no such thing as a DevOp.

Myth #2 - DevOps is a panacea

Far too many times I have heard someone say "we just need to implement better DevOps". What does that even mean?

In one such occasion, I chose to play troll and explore a bit deeper. The person in question explained that they have no monitoring or alerting on their production infrastructure. They went on to explain how the organization needed to hire "DevOps" people with skills in managing Linux infrastructure and working in an on-call rotation, all so the developers could focus more on writing code. That is literally anti-DevOps! This particular organization was severely misguided into believing that "Operations" is DevOps. If this organization were to implement "DevOps" in their current understanding, they would only be widening the gap between business units, further exacerbating the problem.

How many organizations were "saved" by Waterfall? Agile? Extreme Programming? Kanban? Pair Programming? The burnout rates for Extreme Programming are some of the highest in the industry, Agile makes "big picture" items difficult to visualize, and Waterfall does not deliver new features fast enough. While DevOps is much more than a development methodology (it is an organizational philosophy), DevOps is not the panacea for all your problems.

Myth #3 - You can be certified in DevOps

The was some controversy when Amazon Web Services announced their DevOps certification. I will be totally honest with you: it's total bullshit. You cannot be certified in DevOps because you are already certified in DevOps! Let me prove it to you... POP QUIZ:

Name: ______________________________________

1. Have you attended and passed (with a C or better) either the
   first (1st) or second (2nd) grade of elementary school?

   Answer: ______________________

If you answered "yes", "I think", or "I don't remember" - CONGRATULATIONS! You are officially certified in DevOps! If you recall to the first myth, DevOps is about collaboration and working together. As part of the early development years, children are taught to share their toys and work together. The only difference between second grade and the tech industry is the size of the toys we play with. Oh, and "time-out" is called "getting fired". But why do we lose the desire and willingness to work with others?

In secondary and post-secondary education, we are actively discouraged from working with others. Our elementary educators spend so much time and energy getting us to foster our inner creativity and collaboration, then high school and college squash us into isolated boxes of self-efficiency. But I digress...

If there was such a thing as a certification in DevOps, the questions would have nothing to do with your ability to be in an on-call rotation or debugging a Linux kernel panic; they would focus on your ability to collaborate and work effectively with others. If you need a certificate to say that you play well with others, I think you have bigger problems than a bullet on your resume; that is why you cannot be certified in DevOps!

Myth #4 - DevOps is using CAPS

Some of the original pioneers of the DevOps philosophy actually started in the Configuration Management circle. Whether it is Puppet's Annual State of DevOps Report or Chef's hillarious DevOps: No Horse Shit, it may appear that you must be using these hip new configuration management tools in order to be "doing DevOps right".

Fortunately DevOps has nothing to do with which Configuration Management software you chose. As I will discuss a bit further in another "myth", the technology stack an organization chooses in no way impacts its ability to practice DevOps. While I can appreciate the effort Ansible, Chef, Puppet, and Salt have put into supporting and evangelizing DevOps, DevOps has nothing to do with Ansible, Chef, Puppet, Salt, or any company for that matter.

Myth #5 - DevOps is just for dev and ops

In the purest definition of DevOps, this myth is actually true. In the original form of DevOps as proposed many years ago, DevOps proposed to bridge the gap between engineers and operators. However, organizations began to quickly realize that DevOps principles extending far beyond the engineering realm.

In many organizations, DevOps principles are being applied to sales and marketing positions, consulting engagements, and leadership teams. At the atomic level, DevOps is about collaboration and communication toward a common goal, not a particular technology or task. As such, DevOps can be applied unilaterally across an organization.

Myth #6 - DevOps is going to conferences

In my opinion, one of the biggest reasons for the spread and adoption of DevOps has been the local DevOps Days Conferences. As one of the organizers for DevOps Days Pittsburgh, I can attest that the DOD conferences are some of the best environments for learning and collaboration. If there is a local DevOps Days conference near you, make every effort to attend; if you are a manager, force your entire team to go. The cost for attendance is relatively inexpensive and the ticket-to-reward ratio is well worth it.

That being said, DevOps is not attending conferences. An organization can implement successful DevOps practices without anyone ever setting foot in an auditorium or conference center. While attending conferences of any kind can bring new ideas and change into an organization, DevOps has nothing to do with attending conferences.

Myth #7 - DevOps is using "the cloud"

"The Cloud" is this mythical creature whose definition changes whether you are an engineer, sales person, or Google. Unfortunately there is often a tight coupling with "the cloud" and DevOps practices. This coupling is completely false; there is no correlation between teamwork and using a virtualized environment.

A public cloud, private cloud, or any virtualized environment is not required to implement DevOps practices. Whether you are running on AWS or bare metal, DevOps is possible. You do not need to use "the cloud" to do DevOps.

Myth #8 - DevOps is doing the same as [big corp]

We often aspire to the achievements of the Googles, the Facebooks, the Twitters, and the GitHubs of the world, yet we fail to acknowledge when they are in a different problem space. Have the strategies these organizations chosen allowed them to be successful? Or have the organizations chosen those strategies so that they could be successful? Does it really matter? Why are we still holding examples from 5 or 10 years ago on a pedestal? Why do we practice the glorification of snapshots in time? Yes. That totally did happen. And it worked for that small subset of people. Back then. But this is now.

The successes (and failures) those organizations experienced were unique and specific to their problem domain. If you are not running a hosted git service fronted by a Rails application for collaboration or an online store front to buy and sell handmade items, then you are not GitHub or Etsy. These organizations have been successful because they chose or built the tools and processes that worked best for them at the time. Google and Amazon do not need to worry about cloud outages because they built their own!

We should use Rails because GitHub did. We should write our StatsD service in Node.JS because Etsy did. We should use PHP because Facebook did. We should start with a Rails app and then migrate to a highly-distributed, multi-tiered, Scala-based service after a year because Twitter did. The logic in those statements should sound insane! It is absolutely ludicrous! Yet that is exactly what some people think DevOps is, but on a much larger scale. DevOps is not conforming to the norm; it is defining it.

As Abraham Maslow said in his 1966 book The Psychology of Science, "if all you have is a hammer, everything looks like a nail". The "DevOps" and "Thought Leadering" companies exist today because they dared to defy the standard, but that does not mean we should follow directly in their footsteps. We can learn from their successes and explore new ways to innovate. DevOps is doing what is in the best interest for the success of your organization and its individual members.

Myth #9 - DevOps is using new technologies

All too often large enterprises feel left behind in the technology industry because they cannot play with the "cool new toys". I recently ranted on Twitter about the Enterprise Fizz Buzz implementation for marginalizing the current practices of enterprise technology. Thankfully, DevOps is language and technology agnostic!

DevOps is a cultural movement focused on collaboration and innovation. The tools and technologies an organization chooses are in no way impacted or affected by DevOps. In fact, DevOps has proven to be successful in startups as small as three people to enterprise organizations with thousands of employees. As such, you can implement DevOps regardless of your technology stack!

Myth #10 - DevOps is just a fad

Unlike Agile or mainframes, DevOps is not a development methodology or technology; DevOps is an ideology. Is it a way to facilitate organizational prosperity and growth while increasing each individual employee's happiness along the way. I do not know about you, but that sounds pretty sweet to me. I hope DevOps is not a fad.