“When two tribes go to war, a point is all that you can score” – Two Tribes, Frankie Goes To Hollywood.
DevOps, like Agile and Lean before it, is often heavily resisted by established companies struggling to accept that traditional ways of working are not necessarily effective in today’s constantly changing world.
I’ve heard many explanations for why organisations are unwilling to adopt a DevOps model or practices, often based on incorrect assumptions. In this article, I’ll debunk some of the common myths about DevOps; my vision is to empower change agents to challenge erroneous beliefs within their organisations and encourage them to reconsider taking a DevOps approach.
Myth #1 DevOps creates a Two Tribes mentality
In the Agile world, we have adopted ‘tribe’ or ‘guild’ vernacular to describe modern cross-functional teams that can make decisions locally to improve their effectiveness. These aren’t the tribes I’m referring to.
In traditional IT, the plan – build – operate model has created a disconnect between the development team (the people who build the software) and operations (the people responsible for looking after the software in production). These two tribes are often at war. Historically, poor implementation of IT Infrastructure Library processes has created strong demarcation between these two functions and negatively affected the flow of working software into the production environment.
The level of mistrust between these two groups is high.
Operations teams are concerned that in a highly complex environment (and under business pressure to deliver), development teams will put technical debt into production for operations to support — an “all care, no responsibility” approach to software development. On the other side of the coin, the development teams are frustrated by the time it takes to make configuration changes, open up firewall rules and deploy their applications.
Often, the mention of DevOps as a way to solve these problems leads to paranoia that each team’s special skills will be eroded. In fact, nothing could be further from the truth. DevOps supports cross-team collaboration, encouraging both teams to work together to address each other’s concerns about quality software being deployed.
Puppet’s 2016 State of DevOps1 Report provided key metrics around IT and organisational performance.
Puppet’s report showed that teams that adopt DevOps principles realise a 22% decrease in unplanned work and rework.
Myth #2 DevOps adds risk with continuous delivery
I remember the pre-Agile days in IT when there was a single release of software at the end of a project. People had to cancel their leave around the go live date, and everybody was expected to work an entire weekend. The whole event was very stressful and failure was not an option.
In almost every other pursuit in life, if something is this risky then the smart thing to do is to practice it. Strangely, suggesting this approach in a traditional IT organisation is usually met with shock, mainly because most deployment processes are poorly implemented.
A well-crafted delivery pipeline has all of the governance processes built in, reducing the risk of deployment and application. DevOps adds value throughout the entire software creation process, using a combination of Agile and Lean techniques to ensure that the software is of a high standard, its functionality delivers the highest value to the customer, and its passage into the production environment is low risk.
Puppet found that DevOps teams report a 3X reduction in change failure rates and a 24X faster recovery from failure rate than traditional IT environments.
Myth #3 DevOps is just another excuse for IT to spend money on tools
It’s true that if you store your infrastructure as code, automate all of your tests and monitor all of your environments, you’ll have to invest in technology to enable this, but it doesn’t need to cost a lot of money. In fact, almost everything that you need to enable DevOps is open source.
Some organisations choose to pay for product support for commercial products, however this investment represents a fraction of the value that a 2000X improvement in lead time can give an organisation.
Myth #4 DevOps creates a security nightmare
Complex environments generate threats to an organisation’s security. Migration to offsite infrastructure, creating consistent-looking environments and sharing enterprise space (as per the practice of Continuous Integration) have all created opportunities for hackers to infiltrate an organisation’s technology platforms.
The establishment of infrastructure-as-code, multiple deployments a day and giving developers access to production environments are looked at as security risks, and often used to justify resistance to the adoption of DevOps practices by many organisations.
According to the latest data, DevOps adopters spend 50% less time remediating security issues than others, because their information security objectives are integrated into their daily work.
Myth #5 DevOps is all about release management
Release management is undoubtedly an important component of DevOps. Unless you can safely deploy your code into the production environment and into the hands of your users, your organisation is not banking the value that your software delivers. However, it’s important to acknowledge that there’s more to DevOps than release management.
If your code is fragile and you have no way of automatically verifying the software’s quality, users will not find it useful if it’s riddled with defects, regardless of how safely the code was shepherded into production.
DevOps encapsulates good software practices including architectural decisions to reduce batch sizes, and a quality first approach to writing software to ensure clean, organised and maintainable code. Testing should be optimised for automation so that quality can be assured before software is deployed.
Automated builds, testing, deployment and provisioning provide consistency when moving software into environments, increasing speed and reducing risks.
Why DevOps does not create a two tribes mentality
As you can see, there are still a lot of myths surrounding what is DevOps. This blog aims to explain that DevOps is more than just release management, encapsulating software architecture and quality assurance as well.
It’s also a risk mitigation strategy that enhances your capability for consistency and security and most importantly, creates an opportunity for people to align and collaborate to reach a common goal.
DevOps lowers the cost of the transaction of getting into the production environment which enables small and frequent changes. This aspect supports faster delivery and unlocks customer value as more regular releases allow the organisation to respond to feedback and tailor changes to deliver even higher levels of customer satisfaction.
Reference:
