DevOps : what does this term mean and why should we care?

DevOps

What does this term mean and why should we care?

The term, DevOps, seems to have begun to be popularized sometime around 2008, coming out of that year’s Agile conference.  The movement gained ground via a number of “devops days” in 2009, which have continued around the world ever since.

According to Webopedia, “DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units.”

To put it another way, the purpose of DevOps is to create better overall collaboration between the people in the back and the people on the front lines.  Some would call it a cultural movement in the software industry, one that places a strong emphasis on collaboration and communtication between software developers and IT professionals while marrying the process of software delivery to infrastructure changes.

Neil Garnichaud suggests that DevOps is “about breaking old habit – like the natural tendency to focus on software bug counts as a measure of quality!” (emphasis added).  In other words, accepting an “acceptable” level of tech debt… That can quickly snowball out of control…

DevOps is sometimes considered to be the evolution of the ALM or Application Lifecycle Management system for software development and integration.  Perhaps it can be considered an accurate statement to say that DevOps is a more personable form of the latter.

As you read this article, keep these definition and comments in mind.  If something comes to mind, perhaps you can share it in the comments, below.

What is certainly true is that DevOps has evolved from “agile system administration” aka “agile operations” and the expanded understanding of the importance of collaboration between operations and development teams throughout the entire development process in the creation and operation of any service, with a greater and greater realization of how critical operations now are in an expanding service-oriented world.  Bottom line – PEOPLE, not software, love to be stroked.

Jez Humble of  Continuous Delivery , who says  DevOps are for “big hairy enterprises” (some people would say “big scary enterprises), describes DevOps as a “cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.”  In other words, DevOps describes a group of people from every area of software development, sales, operation and maintenance who get along well enough to stay focussed on their common goal.

Jez knows what he’s talking about.  When he hit the real world right out of university, the dotcom crash was just beginning… and he survived.

Ernest Mueller of the agile admin defines DevOps as:  “the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.”  That fits the definition above to a “T,”  people from all areas and disciplines working together in harmony.

To that he adds the corollary, that DevOps is “also characterized by operations staff making use (of) many of the same techniques as developers for their system work.”  Another way to say this is that the people in back and the people on the front lines are using the same tools.

In fact, the term doesn’t differentiate between the different areas of discipline in the overall, very integrated scheme.  “Ops” covers everyone including systems engineers, network engineers, security pros, operations staff, system admins, and others.  Everyone involved in operations is “Ops,” but also “Dev” can be “Ops!”  Often the best way to help a software engineer understand exactly what is needed is to put him on the front line, hands on, where the needs of the customer can be readily seen and understood. I remember the day when 10 engineers and I went to a customer (we were lucky the customer was close to the office) and spent all day watching the users (at least what they were doing) doing their job with our software. This day was very beneficial for all: the engineers understood why our customers had requested some improvements and the users were guided to enhance the way they used some complex functions.

“Dev” is shorthand for developers, yet the reality is that it includes everybody involved in the development of a product, which, you guessed it, can include everybody!

What has been learned from the Agile and Lean approaches is that you can cause more harm than good by keeping development and operations separated.  In fact, DevOps is the obvious evolution of Agile, which calls for tight collaboration between all those involved in the final product, including customers, managers, developers, and anyone else involved in the continuous delivery of a working, quality product.

DevOps is not something new, but the natural evolution of Agile principles to cover the entire delivered service, including the product AND the continuing value it brings to the client.

Again, Ernest Mueller builds on definitions pulled from Wikipedia and the Agile Manifesto  to offer a more in-depth definition which clearly demonstrates how DevOps is not different from Agile, but a better, stronger, expanded, evolved development of Agile.

These include Agile values, principles,  methods and  practices, as found in the manifesto, and to these he adds a new one, Agile Tools – aka – the technical side of these practices for facillitating work carried out following the above-mentioned methods.

Naturally, DevOps values are very much the same as those in the Agile Manifesto.  If anything new, they are again an evolution of the original manifesto, adding a higher level of service and “bug free” software for the customer.

DevOps principles are a little harder to find complete agreement on.  James Turnbull of Kartar.Net has tried with no small amount of humor to take a stab at defining them, and John Willis had come up with the term, CAMS, or Culture, Automation, Measurement, Sharing, in his 2010 attempt.  I particularly like Willis’ statement that “Devops is not a plan, it’s a reaction.”

This system deals with some issues that can cause endless headaches for a software company.  On one side, there is the push to get the running software out on time (development side) and on the other side is IT (operations), tasked with making sure the software stays up and running and the customer is happy.  If these could partner with the common goal of delivering working, stable software that does what the customer wants and reliably CONTINUES to do what the customer wants, inagine how much sooner new features could reach production and be debugged when necessary while minimizing downtime for the customer.

Basically, a few developers started doing more than simply developing, delivering and debugging software;  they started keeping their fingers on the pulse of their clients and development teams, listening to their problems, discussing them with others in the industry, blogging, meeting with other, like-minded individuals… kind of like what resulted in the Agile Manifesto.

An excellent example of how even  a small company can use DevOps is the Spanish software company, NELIO, owned and operated by a team of three, yet able to operate both in the Spanish and English community, mainly because of their ability to collaborate with each other, with other companies, with their customers, and with other like minded professionals.   Theirs is a fascinating story, and their blog is well worth following.

Speaking of the Agile Manifesto, Ernest Mueller took a stab at creating a  DevOps Manifesto, based on a rough draft from a meeting on the same subject, in 2010. Compare it to the original Agile Manifesto.  Note that, as with the Agile Manifesto, the key is the people involved.  Collaboration is what makes both Agile and its child, DevOps, work. And of course, collaboration means people working together.

For me, the whole idea of DevOps is for everybody to come out of their “silos,” both on the development side (customers, engineers, QA) and on the operations side (managers, sales staff, customers, QA).

Did you notice that some of the same people showed up on both sides?  That’s why DevOps is the natural evolution of Agile.  Agile saw the need for collaboration in software development, while DevOps saw the need for collaboration between software development people and people operating software.

According to Webopedia,  the “guiding principles of DevOps include culture, measurement, automation and sharing.”  The point, or why, then, is that by working together at all levels in a friendly, civilized manner, it becomes possible for a software company to achieve optimally running software with minimal problems, because more  processes are automated by new tools that are packages in the cloud (e.g., Amazon AWS ).

What’s next?  Where are we going as we continue in this evolution?  Is there still room for improvement?  What can we do better?  Please offer your comments below.