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

1. DevOps: What is it and Why Should You 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 communication 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

2. 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 focused 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 facilitating 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.

3. 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 ).
Jean-Christophe Huc
4 november 2106