This is not a rant. Promise. But in encountering businesses who are attempting to convert to DevOps, I’ve started to see a common pattern emerge. Many IT teams are concentrating on certain aspects of their development pipeline while neglecting or disregarding others. I’m not pointing accusatory fingers or preaching from a soapbox here. Most of the time this inattention is subconscious; teams lean heavily on one solution (most often infrastructure as ops) and the other areas of DevOps fall by the wayside.

Believe me; I’m not attempting to sound accusatory or holier than thou here. Often, my situation enables me to see this with IT teams because, as a DevOps consultant, I’m an outsider looking in. I’m not attempting to redefine DevOps or rewrite The DevOps Handbook. This is simply an opinion.

Essentially, the aim of DevOps is to merge the boundaries between, well, development and ops. (Yes, we got it—no need to point out the obvious, right?) However, achieving this requires a significant cultural shift in the workplace that improves the flow of feedback between all teams and promotes knowledge-sharing. Everyone is enabled to expand their skill set and redefine ‘set roles’. Becoming, instead, part of a bigger ideal that encourages cross-departmental development and responsibility.

One of the merges that develop these capabilities between departments is a cultural change in how those teams work together. But what I see in the industry, rather than addressing how teams work together and culture needed to achieve synergy, is a concentration on automated ops and it being labeled as DevOps.

This focus on automated ops comes from seeing the results that it can bring. But it is only a small element of a bigger equation to achieving DevOps. As the saying goes, “The whole is greater than the sum of its parts.”

And I fully acknowledge that this is just the tip of the DevOps iceberg. There’s so much else going on below the surface of the water with DevOps that the true synergistic equation would continue off the page. (Actually, it already goes on for exactly 437 pages in paperback form and is called The DevOps Handbook.)

“DevOps iceberg, right ahead!”

Let’s consider Google. The company bridged its ever-widening gap between R&D pushing new features and Operations trying to keep production stability with a team that had a background in both. Now, Site Reliability Engineers (SRE) keep production running smoothly, while also committing to developing new features and operational advancement. The 50/50 SRE team makeup of software engineers and system administrators encourages development work in line with organizational goals. At the same time as automating solutions and promoting code quality improvements.

SREs help product teams self-manage their own services in production. Google has two critical safety checks the transition must undertake before releasing any new services. The first step, Launch Readiness Review (LRR) is a self-reporting checklist the product teams conduct before the service goes live to customers. While the second Hand-Off Readiness Review (HRR) happens when the service transitions to ops management. The HRR is much more rigorous and demanding than the LRR. This practice forces devs to experience the work of ops to improve the standard the service transition makes from creation through to launch.

The SRE team also holds reviews every quarter to evaluate how much ops work other Google teams have going on. These external reviews assess if a team is under overload and take corrective action. To the point of dissolving a team if necessary. The exercise’s aim is to ensure that teams maintain a harmonious balance together of 50% ops and dev together.

While ops are solely responsible for operations, there will always be a divide. Devs need to take some responsibility for infrastructure and OP’s need to get involved sooner. No team can achieve true DevOps until they encourage synergy between the two teams to overcome this divide with every element of the DevOps methodology.

Herein ends this message: Strive for harmony in all aspects of the DevOps equation in your working environment—not just by automating operations.

Keen to continue an exploration of DevOps? Check out Caylent's DevOps Handbook Summary Series.