DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How are you handling the data revolution? We want your take on what's real, what's hype, and what's next in the world of data engineering.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • From Chaos to Collaboration: Transforming DevOps With RACI Matrices
  • Empowering DevOps: The Crucial Role of Platform Engineering
  • Implementing DevOps Practices in Salesforce Development
  • Unraveling the Siloing Issue When Using Argo CD With Other Similar Tools

Trending

  • Software Specs 2.0: An Elaborate Example
  • Micro Frontends to Microservices: Orchestrating a Truly End-to-End Architecture
  • Building V1 Gen-AI Products at Scale: Technical Product Patterns That Work
  • Docker Model Runner: Running AI Models Locally Made Simple
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. DevOps and CI/CD
  4. The DevOps Equation

The DevOps Equation

A lot of teams adopting DevOps repeat the same problems. Follow these good examples to plan out your processes and pipelines properly.

By 
Stefan Thorpe user avatar
Stefan Thorpe
DZone Core CORE ·
Apr. 10, 18 · Opinion
Likes (4)
Comment
Save
Tweet
Share
6.5K Views

Join the DZone community and get the full member experience.

Join For Free

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.”

#DevOps equation

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“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.

DevOps teams

Published at DZone with permission of Stefan Thorpe, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • From Chaos to Collaboration: Transforming DevOps With RACI Matrices
  • Empowering DevOps: The Crucial Role of Platform Engineering
  • Implementing DevOps Practices in Salesforce Development
  • Unraveling the Siloing Issue When Using Argo CD With Other Similar Tools

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: