What is DevOps anyway and why does it matters?

Posted 2021-04-16 AgileWand

We all might have heard of DevOps and every time we might get different definition from different practitioner. So just what is it?

According to Wikipedia, DevOps is "a portmanteau of 'development' and 'operations'" and is "a software development method that stresses communications, collaboration, integration, automation and measurement of cooperation between software developers and other IT professionals".

If that doesn't help to explain, try this: "One way to understand DevOps is through the acronym CALMS- Culture, Automation, Lean IT,Measurements and Sharing."

DevOps movement isn’t that old and all started in 2008 when Patrick Debois an Independent Consultant working on Data Center Migration project for Belgian government started applying Agile practices in System administration work, later alongwith Andrew Shafer formed an Agile System Administration group in 2008.

Movement got momentum when in 2009 Velocity Conference John Allspaw and Paul Hammond gave talk“10+ deploys a day at Flickr” where John and Paul explained how Developers and Operations teams working together at Flickr were doing multiple deployments a day.

The DevOps movement was born with a belief that there’s a better way - a way of building teams, and building software that can solve common problems in IT industry (or to be more specific software industry):

Fear of change

Once an application is delivered, the business tends to be tremendously afraid of change. The suspicion is that the software itself, and the platform upon which it sits, is somewhat brittle and vulnerable. Bureaucratic change-management systems are put in place, and it takes a painfully long time to introduce new features, or fix problems with the application.

Risky deployments

Another symptom of the malaise is the concept of the ‘risky deployment’. This is the situation in which no-one is really terribly confident that the software will work in the live environment. Will the code behave as expected? Will it cope with the load? Often we don’t have the answers to these questions - we just push it out at a quiet time, and watch to see if it falls over.

It works on my machine!

A common situation we experience is one in which a problem manifests itself once the site is live. These problems are typically picked up by systems administrators, or helpdesk /client services people. After investigation (although to be fair frequently without) the problem is reported to the developers. The developers take acursory look, and retort: “It works on my machine”.

Siloisation

On most projects in most organizations, the project team is split into developers, testers, release managers and sysadmins working in separate silos. From a process perspective,this is dreadfully wasteful. It can also lead to a 'lob it over the wall' philosophy - problems are passed between business analysts, developers, QA specialists and sysadmins. Furthermore, we see a replication of this silo structure within the teams - it’s not uncommon to see dedicated database and network people in the same system team, alongside sysadmins. Often the larger silos aren't in the same office, the same city, or in sometimes not even in the same country. The result is an ‘us and them’ mentality - groups of people who are simultaneously suspicious of and afraid of each other.

 

Recently we have seen organizations embracing DevOps start reaping the benefits as confirms by the 2016 State of the DevOps Report by Puppet Labs

The fifth annual State of DevOps Report confirms and highlights the fact that achieving higher IT and organizational performance is a team effort spanning development and operations— and it’s an investment that can deliver powerful returns….

Key Findings by Fifth annual State of the DevOps Report

1. High-performing organizations aredecisively outperforming their lower-performing peers in terms of throughput.  High performers deploy 200 times more frequently than low performers, with 2,555 times faster lead times. They also continue to significantly outperform low performers, with 24 times faster recovery times and three times lower change failure rates.

2. High performers have better employee loyalty, as measured by employee Net Promoter Score (eNPS). Employees in high-performing organizations were 2.2 times more likely to recommend their organization to a friend as a great place to work, and 1.8 times more likely to recommend their team to a friend as a great working environment. Other studies have shown that this is correlated with better business outcomes.

3. Improving quality is everyone’s job. High-performing organizations spend 22 percent less time on unplanned work and rework. As a result, they are able to spend 29 percent more time on new work,such as new features or code. They are able to do this because they build quality into each stage of the development process through the use of continuous delivery practices, instead of retrofitting quality at the end of a development cycle.

4. High performers spend 50 percent less time remediating security issues than low performers. By better integrating information security objectives into daily work, teams achieve higher levels of IT performance and build more secure systems.

5. Taking an experimental approach to product development can improve your IT and organizational performance. The product development cycle starts long before a developer starts coding. Your product team’s ability to decompose products and features into small batches; provide visibility into the flow of work from idea to production; and gather customer feedback to iterate and improve will predict both IT performance and deployment pain.

6. Undertaking a technology transformation initiative can produce sizeable cost savings for any organization. Every technology leader wants to know what return to expect on investing in a technology transformation. Using key metrics from this report, as well as industry benchmarks, we’ve provided formulas to help you quantify your potential cost savings, using metrics from your own organization. We also provide suggestions for reinvesting those savings to improve IT and organizational performance.

 

Conclusion and Where to go next?

DevOps is no longer a mere fad or buzzword, but an understood set of practices and cultural patterns. People turn to DevOps not just to improve daily working life and get time back for family, friends and entertainment, but to improve their organization’s performance, revenues, profitability and other measurable outcomes.

If you are interested to learn more about DevOps, a good place to start with is attending workshops and/or training sessions provided by us on periodical basis. Make sure you follow our public Wechat account and look for upcoming training sessions in your city.

For further reading material you are encouraged to read Gene Kim et al “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” and “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations”.