Defining DevOps

In this blog I will talk about all things DevOps. As the blog title suggests, these are my own views on what constitutes DevOps culture and practices. So it seems appropriate in this first post to present my own definition of DevOps.

For me DevOps describes best practices that have actually existed in the most successful agile companies for a long time. It is the process of removing walls between departments and ensuring a close collaboration between operations and engineering departments involved in the creation of systems.

What has become known as DevOps culture or practice is actually central to the success of agile development.

Agile, like the term DevOps, can mean all things to all people. According to the Agile Alliance:

In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.

Taking this definition of Agile, DevOps becomes a logical extension of Agile. Whereas the Agile Manifesto speaks of “deployable business value” DevOps speaks of “delivering operational systems.”

The challenge is to bring operational skill sets to projects earlier in order to encourage development to think about what is required to build scalable systems that can be managed operationally.

Hiring for DevOps

Coming from the operations side of DevOps, I am seeking to recruit ops guys who “get” DevOps. It has become almost obligatory to include the term DevOps engineer in a job description, if not in the actual title, in order to differentiate from the perception of old school sys admins who act as the gate keepers of production, waiting for code to be thrown over the wall to be deployed in their Kingdom.A good candidate for working in a DevOps culture is not someone who knows Puppet or Chef or other tools. Chances are the right candidate will have a good tool set but that’s not my main criteria for hiring. A good sys admin will have actually been using the main practices contained within the DevOps model, without necessarily applying a name to it. Breaking down walls between operations and engineering, automating processes, advocating continuous integration and frequent releases. These are all things that make a sys admin’s life a little less painful.

When recruiting developers for a DevOps environment, experience with configuration management and even specific tools, Puppet, Chef etc., becomes important. Also important is an understanding of a collaborative workflow, git pull requests, discussing with operations early in the development life cycle. These ways of working are often far newer to the dev side of the house than they are to operations. Recruiting the right people on both sides of DevOps is the single most important factor in a successful implementation of DevOps. When tasked with introducing DevOps in an organization that is fully staffed, look for ways to bring in "new blood". In any company there is a natural turn over of staff, take advantage of this to introduce the right type of people to the teams. These new forces, whether on the ops side or development can then become advocates for DevOps within their own teams.

Culture

Many companies, particularly start-ups, spend a lot of time seeking to define company culture, values etc. Often this involves a top down approach. Senior executives come up with some set of values that define a company culture that is then to be adopted by the ranks. For more successful companies, those values develop organically out of the day to day collaboration of people with shared interests and goals. It is no different with DevOps culture. It is extremely helpful to have executive buy-in to a DevOps program and support for the ways of working that go with it. But trying to define a DevOps culture top down is a mistake. If we are really adopting DevOps methods and practices, the culture will flow from that.

The DevOps Team

Many blogs and presentations advise “Do NOT call your team DevOps or yourself a DevOps manager”. This arises from a couple of major concerns.

DevOps is a culture and as such requires buy-in from the entire company. No team has the single responsibility for introducing a new culture.
There is a very real danger that a DevOps team becomes just another silo between Dev and Ops.

These are very valid concerns and if you are building DevOps in a new startup I would strongly encourage you not to call a team DevOps. Implementing DevOps in a large enterprise with dispersed operations teams who have traditionally seen themselves as production gate keepers, all the while using DevOps terminology without understand it, is a little different. In such an environment, introducing a DevOps team made up of people who have "done DevOps" before can have some advantages.

There can be some value to labeling a team DevOps in order to emphasize an outlook and commitment to DevOps practices. The team can establish itself as a center of excellence for DevOps best practices across the company. The name does not automatically make it a new silo anymore than not using the name guarantees against silos.

Measuring DevOps adoption

Companies are often asked, what is the current state of adoption of DevOps. In some cases they attempt to answer this in the manner of a check list: Are we doing CI? Do we have configuration management etc.

I don’t think this approach gets us very far. A better question would be, how close are we to solving the problems we are seeking to solve by adopting DevOps? For me, DevOps is not about everyone getting along and dev and ops hanging out at the bar together. That’s often useful and desirable but more importantly what we are trying to do is work together to solve the problems which call for a DevOps culture and practices.

I’ve seen various approaches to “implementing” DevOps ranging from management sub-committees to discuss endlessly what DevOps means for a given company, what should we be doing etc., to gorilla movements by devs or more commonly ops people to enforce change from below. What’s the correct route? Whatever works for you. It’s all about breaking down barriers to get the job done.

There are many ingredients to moving to a DevOps culture but to really succeed with DevOps, I believe we have to define goals. What are we trying to achieve with the DevOps program?

My goal is to deliver scalable systems that are supportable in production. This is something that programmers, QA testers, ops people and even product managers need to be on board with and play a role in, for DevOps, and ultimately the entire company, to be successful.