I’ve been thinking about this for a while and I came to the conclusion that I needed to start at the beginning. I know, it’s a cliche, but it’s true. Everyone seems to feel that they know what DevOps is, how it works and why they are the only shining example of DevOps in their organization.
Let’s talk to our friend at Wikipedia and see what they say about DevOps:
DevOps (a clipped compound of “development” and “operations”) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.
What does that actually mean? It is important to note that there is a separation between software development and software operations. If you are maintaining an application, that is still development. A team that is performing maintenance on an application is not an operational team, they are a software development team.
I personally like the phrase that “DevOps is the operational response to Agile”. To me that sums up what it means. BMC, however, says that “While Agile was a response to waterfall methodologies, DevOps was not a response to Agile.” They contend that is ITOps (IT Operations) and DevOps (Development Operations) and the two are completely separate “theories”. Indeed, BMC goes on to state some proponents “believe that DevOps can be seen as an extension of Agile“.
I find that thinking somewhat limiting, however, in that one of the key ideas in DevOps is that walls are broken down. Creating another side of operations – ITOps – doesn’t break down walls, it just adds more walls.
XebiaLabs has a Periodic Table of DevOps Tools where they list the “functions” required in their Periodic Table and some of the tools available that perform that function. I personally lean towards XebiaLabs as I believe that DevOps is about getting applications into production in a safe and controlled manner. This may mean encapsulating and automating what “ITOps” would be responsible for and sometimes it won’t.
Humans have a tendency of putting things into buckets. Easier to count, easier to examine, easier to understand. We don’t like things that fall outside those buckets, it makes us uncomfortable. If we already have a model in mind (IT Operations and Development Operations versus Operations) then when we look at the world we look at it through that lens and things may be altered based upon what we see.
In my mind IT Operations comes from big iron, the mainframe data centres where everything follows specific rules and only those rules or the world will grind to a halt. That sort of pre-web thinking is what DevOps needs to overcome in order to be successful.
Do you need your own data centre? No. You can rent someone else’s equipment. Whether that is through a dedicated data centre that someone operates for you or through cloud resourcing, does it really matter?
Do you need the rules that big iron came with, or do you need the results? And that is where the difference comes in. People are coming to the realization that the process is not nearly as important as the result. If you can accomplish the same thing, 90% of the time, in three steps as opposed to ten steps, why would you follow the ten steps? That 10% of the time? Those are exceptions and handle them as exceptions. Don’t cause 90% of your workload unnecessary delay because of the 10%.
DevOps strips through that <insert expletive> and cuts to the core: do what needs to be done and no more.
DevOps is fundamentally about changing how operational tasks are done so as to provide as little impediment as possible to the successful implementation and operation of an application.