BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

What Is (Not) DevOps, and How Do We Get There?

by Abel Avram on Mar 06, 2014 |

In this article we discuss some of the misunderstandings surrounding DevOps and provide an introduction to a process that can bring the cultural shift that DevOps is all about.

In a post entitled “No, You Are Not a DevOps Engineer”, Mike Kavis,  VP/Principal Architect for Cloud Technology Partners, has addressed some of the misconceptions surrounding DevOps. For example, he mentions how some teams are misusing the term DevOps:

Enterprises are struggling with DevOps. They all want DevOps even though many do not know what it is. In many cases, I see infrastructure teams who are calling themselves DevOps leading a grassroots initiative. When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.”

Some engineers advertise themselves as DevOps, but they are not, according to Kavis, because “DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one.” If DevOps is not a role, a qualification, a title, then what is it? Kavis’ definition is:

DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better-quality software more quickly with more reliability.

He then details:

DevOps is the progression of the software development lifecycle (SDLC) from Waterfall to Agile to Lean. DevOps goes beyond Agile and focuses on removing waste from the SDLC. Often, the waste or bottlenecks are found in the forms of inconsistent environments, manual build and deployment processes, poor quality and testing practices, lack of communication and understanding between IT silos, frequent outages and failing SLAs, and whole suite of issues that require precious IT resources to spend significant time and money keeping the systems running. …

Another reoccurring pattern I see is that a “DevOps” team’s first step is often to figure out if they are going to use Chef or Puppet (or Salt or Ansible or whatever else is hot). They have not even defined the problems that they are setting out to solve, but they have the tools in hand to solve them. Often these teams wind up building thousands of lines of the scripts, which raises the question, “are we in the business of writing Chef scripts or in the business of getting to market faster with better quality and more reliability?” Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.

If DevOps is a cultural change meant to bring better communication and collaboration between various teams involved in creating a product, the next question that comes to mind is how do we get there, how do we bring this change into our company?

Damon Edwards, co-founder of DTO Solutions, keynoted on “How to initiate a DevOps Transformation” during DevOps Days Mountain View 2013, presenting a three-steps process he is recommending to introduce the DevOps culture into an organization:

1. Build the “Why?”

According to Edwards, it is important to start by having a clear understanding of why the members of an organization are there, what they are trying to accomplish, what is their purpose. To find out that reason, one could simply socialize with people in the organization and ask them why they are there. The main purpose of the organization is the only reason for implementing a DevOps culture, and there is no other.

Edwards considers that DevOps is just a means to reach an end, and not an end in itself: “DevOps is not your why, not your co-workers’ why, certainly not your business’ why.” He even suggests forgetting the DevOps term, noting the he’s using service delivery instead because “we are in the business of making a service.”

2. Building Organizational Alignment

The next step in Edwards’ process is to align the entire organization so everyone would work “towards a common goal under a shared set of assumptions and rules.” An organization is correctly aligned when giving the same goal to multiple people, they choose the same way to achieve the respective purpose; they have the same answers for the same problem. That would be the “ultimate dream of the organizational alignment.”

To achieve this alignment, one needs to develop a DevOps Vision within the organization. That is not obtained by teaching a process, because people will simply try to mechanically follow some steps. What is needed is to teach a way of thinking. According to Edwards, this can be achieved by following the next steps:

  1. Teach the basic concepts, such as “single piece flow, working in batches, limit work in progress, pull vs. push, continuous delivery”, the tools that can be used, etc., concepts that make up a common vocabulary to be shared by the organization.
  2. Getting everyone on the same page through
    a. Value Stream Mapping – a Lean concept detailing the flow of information and artifacts going on inside an organization, leading to value creation.
    b. Timeline Analysis – attempts to discover where time is spent, where are the bottlenecks.
    c. Waste Analysis – determining all sorts of waste that are produced by an organization in order to eliminate them as much as possible
  3. Developing metrics chains, which are meant to measure the activity across the value delivery chain and how one’s activity impacts others’.
  4. Identify projects/experiments against baseline. Identify which projects or activities deviate from the baseline and take corrective measures.
  5. Repeat steps 2-4. This constitutes a Continuous Improvement process.

In order to implement these ideas, Edwards proposes a 3-days program:

  • Day 1 – Teach the principles, present a case study, patterns and anti-patterns
  • Day 2 – Analyze the current status of the organization providing problem identification techniques and improvement metrics
  • Day 3 – Discussing solutions and tool-chain automation principles, building a roadmap

3. Continuous Improvement Loops

These loops are meant to continually improve the process by Making Plans, Implementing Plans, Measuring Outcomes, and Deciding on How to Continue.

Edwards has recently presented these principles during his QCon London 2014 session called "Dev ‘Programming’ Ops For DevOps Success", session that will be later made available on InfoQ.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

DevOps = principles and practices by chris haddad

DevOps value is derived in the core principles that started the movement:

Iterative
Incremental
Continuous
Automated
Self-service
Collaborative
Holistic

Teams should analyze existing processes against the principles, and see where DevOps practices can add value. A few identified DevOps practices include:


Self-service configuration
Automated provisioning
Continuous build
Continuous integration
Continuous delivery
Automated release management
Incremental testing


As Mike and Abel mention, teams commonly focus on tools instead of value. DevOps friendly tooling delivers:


Self service project via project configuration portals
Policy configuration for Security, service levels, frameworks, usage, topology concerns
Automated platform provisioning via service tier templates, frameworks, and policy enforcement points (PEP)
Process automation with Continuous build, test, and deployment. Code promotion and synchronization across environments and servers
Dependency analysis and impact analysis

For value metrics, break up DevOps goals into foundational, optimal, and transformational categories. For example,

Foundation
* Time and effort to create new application environment
* Time to redeploy application
* Time to promote application into a new lifecycle phase
Optimize
* Dynamically right-size infrastructure scale
* Re-use existing platform services and business services from resource pool instead of re-building solution stack
Transformation
* Time and effort required integrating business process, event processor – creating a complex app.
* Time and effort required to apply policy across tenant(s)
* Cost to operate application per user or transaction

an alternative engineering perspective by William Louth

"DevOps should be imbuing software/systems w/ self awareness & adaptive capabilities...anything else [less] is one side talking."

plus.google.com/+WilliamLouth/posts/dJfXT5NDywn

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT