Reviv­ing DevOps: Embra­cing a Product-Cent­ric Approach (DevOps 2.0)

You don’t do DevOps. DevOps isn’t a role. DevOps is a fun­da­mental shift in how devel­op­ment and oper­a­tions col­lab­or­ate. And unless you accept this, DevOps won’t work.

What you’ll learn by read­ing this art­icle: 

1. Why DevOps Isn’t a Role
2. A His­tory of DevOps and its Objectives
3. A Real­ity Check on DevOps Adoption
4. Chal­lenges in Imple­ment­ing a Product-Cent­ric DevOps Culture
5. The Cost of DevOps Inefficiency
6. Embra­cing a DevOps + Product Mindset

What is DevOps 2.0? 

Think of DevOps 2.0 as the new era in our tech play­book, where we blend devel­op­ment and oper­a­tions with a sharper focus on what users really need. It’s all about cut­ting through the clut­ter, boost­ing pro­ductiv­ity, and mak­ing sure we’re not just using tools, but max­im­iz­ing their poten­tial for bet­ter outcomes.

DevOps His­tory and Objectives 

15+ years ago John All­s­paw and Paul Ham­mond demon­strated the power of get­ting devel­op­ment and oper­a­tions closer together. Their ground-break­ing present­a­tion, titled “Velo­city 09″, showed that by doing so, you could the­or­et­ic­ally achieve numer­ous pro­duc­tion pushes a day (10+). 

Every­one was impressed, and in a few years, tech com­pan­ies world­wide were try­ing to close gaps between devel­op­ment and oper­a­tions teams. 

The Phoenix Pro­ject and CI/CD

Fast for­ward­ing to around 2012, two other events were help­ing to shape DevOps and mak­ing it mainstream:

• “The Phoenix Pro­ject” by Gene Kim, Kevin Behr, and George Spaf­ford pop­ular­ized three ways to apply­ing work man­age­ment prin­ciples from fact­ory pro­duc­tion lines in IT envir­on­ments: (1) Flow/Systems Think­ing; (2) Amp­lify Feed­back Loops; and (3) Cul­ture of Con­tinual Exper­i­ment­a­tion and Learn­ing. – it helped cre­ate and shape culture.
• The devel­op­ment of Con­tinual Integration/Continual Devel­op­ment (CI/CD) prac­tices, which solid­i­fied the move towards more agile soft­ware deployment. 

DevOps quickly matured into a frame­work for diverse prac­tices, all of which centred around CI/CD. It became an umbrella of prac­tices and prin­ciples that wel­comed other prac­tices and principles.

This includes Site Reli­ab­il­ity Engin­eer­ing (SRE), which, although not strictly part of DevOps, has become a cru­cial ele­ment in the con­tinuum. It also includes Chaos Engin­eer­ing and Observ­ab­il­ity, neither of which were part of the ori­ginal Phoenix Pro­ject. DevOps’ ascent has also driven numer­ous tech­nical advance­ments, like Infra­struc­ture-as-code (IaC), orches­tra­tion, and shift left security. 

All of this has con­trib­uted to DevOps becom­ing a catch-all term for prac­tices aimed at mak­ing the entire Soft­ware Devel­op­ment Life­cycle (SDLC) value chain more effi­cient and higher in quality. 

Which would be great… if that’s what were actu­ally happening. 

The Real­ity Check 

DevOps has yet to shift towards a product-cent­ric model. Instead, it is fall­ing into the cat­egory of frame­works, prac­tices that had their day in the sun and faded away. Many teams “do” DevOps the same way they “do” Agile and Scrum. 

We pride ourselves on exper­i­ment­ing with solu­tions for DevOps effi­ciency, but when out­siders come in and ask developers for best prac­tices, we can’t give an easy answer. Why? Because so little is stand­ard­ized, and we haven’t developed the requis­ite pro­cesses to cre­ate the standards. 

Unsur­pris­ingly, 88% of com­pan­ies sur­veyed on the Google’s State of DevOps report can’t deploy more than once a week. Most organ­iz­a­tions are stuck in the middle layer of adoption.

Is it because tools aren’t optim­ized? No. 
Is it Jen­kins’ fault? Nope. 
Are we not “DevOpsing” enough? Def­in­itely not. 

It’s because the exper­i­ence of imple­ment­ing DevOps, the way we con­cep­tu­al­ize it, is miser­able. Since the Flickr talk 14+ years ago, all that’s changed is the tools we use.  

Everything except the work­flow has evolved. 

Chal­lenges in Imple­ment­ing a Product-Cent­ric DevOps Culture 

Developers primar­ily aim to cre­ate and oper­ate soft­ware. They don’t want to get bogged down with infra­struc­ture main­ten­ance. Still, many are stuck per­form­ing repet­it­ive tasks which, if not stream­lined, can lead to a host of com­pli­ance issues, dis­par­ate prac­tices cross teams, and unsus­tain­able main­ten­ance procedures. 

Most infra­struc­ture teams also oper­ate in a siloed, single-threaded man­ner. One per­son is tasked with over­see­ing the vis­ion, tack­ling engin­eer­ing prob­lems, and man­aging demands. Teams like this are not usu­ally assigned product man­agers to guide a product-driven approach, and without this addi­tional lead­er­ship, infra­struc­ture team lead­ers can’t achieve a cus­tomer-cent­ric focus. 

Gran­ted, there’s noth­ing inher­ently wrong with not hav­ing a product man­ager. But it’s essen­tial to break apart engin­eer­ing man­age­ment and product man­age­ment within any platform. 

It’s also not fair to solely expect infra­struc­ture teams to be faster and smarter without address­ing under­ly­ing organ­iz­a­tional issues. How­ever, approach­ing exec­ut­ives to hire more roles, espe­cially CFOs, is not an easy con­ver­sa­tion to have.

The Cost of Inefficiency 

These prob­lems have tan­gible con­sequences if left unnoticed for too long. Developers seek­ing effi­ciency through auto­ma­tion and improved internal ser­vices get frus­trated fast. The moment they stop accept­ing the status quo, they’ll pack their bags and leave. 

Let’s piggy­back on our exper­i­ences with enter­prise cli­ents to show you what we mean. Based on an engin­eer­ing team of 60 engineers:

Cost-to-value:

• 10% of their time is spent on repet­it­ive tasks due to a lack of tools and stand­ard­ized processes. 
• Another 15% is ded­ic­ated to onboard­ing until a con­tri­bu­tion is made. 
• Assum­ing a com­pany cost of 90k per engin­eer, the total cost is 4.2M with a neg­at­ive yearly cost-to-value impact of 1M. 

Cost-bene­fit:

• Assum­ing an avg. salary of ~70k/year per engineer.
• In the first year of hir­ing an engineer:~15k is spent on recruit­ing,
  ~15k on onboard­ing and repet­it­ive tasks, plus ~21k on taxes. 
• 50% of the engin­eer’s salary is wasted.  

The Future and Rel­ev­ance of DevOps 

Many enter­prises are stuck in their DevOps adop­tion and are still wait­ing for the prom­ised bene­fits. How­ever, there is a future.

While we’ve spent a lot of time build­ing tools, and in the future, organ­iz­a­tions will embrace DevOps as the toolkit that enables a value stream to achieve its goals. This is a good start, but more is needed.

Organ­iz­a­tions need a team respons­ible for a plat­form that enables developers, oper­ates with a product-cent­ric approach, listens to cus­tom­ers, and builds accord­ingly. By pick­ing the best tools, prac­tices, and prin­ciples from the DevOps umbrella, organ­iz­a­tions can shape the busi­ness needs effi­ciently and quickly. 

In short, treat your developer eco­sys­tem as a product, own it, and build what mat­ters. Enable developers to impact the value stream as fast as possible. 

This is what reviv­ing, rebuild­ing, or re-writ­ing DevOps could look like. 
For the time being, let’s call it DevOps 2.0: A DevOps + Product mindset. 

Stay tuned for Part II

Learn how you can apply these con­cepts in Part II. We will dive into con­crete use cases of how we are apply­ing these pro­cesses at xgeeks, and the impact it brought to our cus­tom­ers.

Stay tuned, we’ll be shar­ing it soon.

In the meantime:

• Check our approach to Plat­form Engineering
• Watch our panel dis­cus­sion Reviv­ing DevOps: Bridging the Divide between Prom­ise and Reality