Seven Myths about DevOps?

Original blog published on: Jul 12, 2017

Let us start with a short history of DevOps.

  • 2008: Andrew Shafer and Patrick Debois held a "birds of a feather" session in 'Agile Toronto.'
  • 2009: "DevOpsDays" conference started in Belgium by Patrick Debois, and term "DevOps" coined
  • 2009: "10 Deploys per Day at Flickr" talk by John Allspaw and Paul Hammond in "Velocity" conference
  • 2009: In 'velocity' conference, Andrew Clay coined "Wall of confusion."
  • 2009: Mike Rother wrote Toyota Kata and defined 'Improvement Kata'
  • 2010: "Continuous Delivery" book from Jez Humble and David Farley, described the "deployment pipeline."
  • 2011: "The Phoenix Project" book from Gene Kim and Kevin Behr
  • 2011: Amazon deploys to production every 11.6 seconds
  • 2014: "DevOps for Dummies" book by Sanjeev Sharma
  • 2014: Etsy uses more than 50 times a day
  • 2015: Amazon claims 1,30,000 deployment per day
  • 2016: "The DevOps Handbook" book by Gene Kim and Jez Humble

Purpose of DevOps (as described by wiki)

  • Faster time to market
  • Improved deployment frequency
  • Lower failure rate of new releases
  • Shortened lead time between fixes
  • Faster mean time to recovery

What is DevOps ?

DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution.

Now, Let us explore the Popular Myths about DevOps

1) DevOps is just about Automation (or “Infrastructure as Code”)

One of the most important reasons to go for DevOps is Automation, what if we can automate the entire process from “Concept to Cash” and there could be virtually a “Deploy button” and if we click this button, deployment should be done in a few minutes.

Creating consistent environment is time consuming, difficult and monotonous and equally painful is deploying to production, Why can’t we automate our own “IT”?

Infrastructure as a code (IAC) is one such technique which automatically manage and provision through code. With a click, your infrastructure (Environment) is ready.

Infrastructure as code (IAC) means writing code to manage configurations and automate provisioning of infrastructure in addition to deployments. This is not simply writing scripts, but involves using tested and proven software development practices that are already being used in application development. For example: version control, testing, small deployments, use of design patterns etc. In short, this means you write code to provision and manage your server, in addition to automating processes.

As book “The DevOps Handbook” explains:

While many of the DevOps patterns shown in this book require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation.

SAFe’s ‘CALMR’ approach to DevOps covers the five main aspects


Culture: DevOps is a culture of shared responsibility, the collaboration between Development teams and Operations team, fail fast, tolerance for failure and rapid recovery, risk-taking, sharing practices, discoveries, tools, automation to provide speed, consistency, and repeatable process and automatic environment creation.

Automation: DevOps simply recognizes that manual processes are the enemy of fast value delivery, high productivity and safety. It also enables the creation of repeatable environments and processes, self-documenting, automated continuous delivery pipeline to achieve a fast, Lean flow. Automation facilitates faster learning and response to market demand and customer feedback. Builds, testing, deployments, and packaging that are automated to improve the reliability of processes that can be made routine. 

DevOps believes in automating everything, for example:

  • Application Lifecycle Management (Ex; CA Agile Central, JIRA, Rally, Version One, Agile Craft)
  • Code Review (Ex: Gerrit )
  • SCM (Ex: Git)
  • Code Quality (Ex: Sonar)
  • Artifact management (Ex: Artifactory, Archive, JFrog, Confluence)
  • Build(Ex: Ant, Maven, Bamboo, Jenkins)
  • Testing (Ex: xUnit, Cucumber, FitNesse)
  • Continuous Integration (Ex: Jenkins, Cruise Control, Continuum)
  • Continuous Deployment (Ex: Chef, Puppet, Ansible, SaltStack, UrbanCode)

Lean Flow: DevOps teams strive to achieve a state of continuous Flow, enabling new features to move quickly from concept to cash. The three primary keys to implementing Flow makeup Visualize and limit WIP, reduce batch sizes, and manage queue lengths. All three are integral to systems thinking and long-term optimization. Lean Flow identifies bottlenecks, and balance the amount of WIP against the available Development and operations, decrease the batch sizes of the work, and manages and reduce queue lengths.

Measurement: As Peter Drucker rightly said, "What gets measured gets managed. Telemetry is an automated collection of real-time data regarding the performance of solutions, helps to assess the impact of frequent application changes quickly. Resolution happens faster because teams don't need to wait for a different group to troubleshoot and fix the problem. DevOps helps in collecting data on business, application, infrastructure, store logs in ways that enable analysis, broadcast measurement, and continuously improve telemetry during and after problem-solving.

Recovery: To support the continuous delivery pipeline and the concept of Release on Demand, the system must be designed for low-risk component or service-based deploy-ability, release-ability, and fast recovery from operational failure. DevOps follows techniques like Stop-the-line mentality, Plan for and rehearse failures (Ex: Chaos monkey) and Build the environment and capability to fix forward or rollback. Also use tools like Feature toggles (allows teams to modify system behavior without changing code), Dark launches (allows gradual release to consumers to get user feedback and test performance and to find if user love it or hate it), and Canary Releases (by slowly rolling out the change to a small subset of users before making it available to everyone).

2) DevOps is only for Startups or small software companies

List for the companies, who are practicing DevOps is significant, which includes: Google, Amazon, Netflix, Etsy, Flickr, GE, Starbucks, Target, HubSpot, LinkedIn, HSBC, Airbnb, eBay, Disney, Nike, Intuit, NASA and many more. DevOps is for everyone, either you are Internet "unicorn" or traditional "horse" organizations. Every company is trying to improve its Time to market or cycle Time. DevOps have helped companies to improve cycle time from 2-4 years to 3-8 months to 2-6 weeks. So this means every company should embrace DevOps. DevOps is no more optional or luxury; DevOps is the need of the hour for every company.

3) DevOps replaces Agile

DevOps is not a replacement for Agile. We can consider DevOps as a logical continuation of Agile journey or maybe enabler for Agility.

Agile Manifesto Principle no. Three describes, "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to shorter timescale."- And DevOps helps you achieve Continuous Integration (CI), Continuous Deployment (CD), and Continuous Delivery in terms of Continuous Delivery Pipeline. DevOps help you realize "Potentially shippable code (PSI)" at the end of each Iteration. So Agile and DevOps go hand-in-hand.

4) You don't need Lean-Agile to have a successful DevOps implementation

Lean is all about Eliminate waste or achieve the sustainably shortest lead time with the best quality and value to people and society.

Shiegeo Shingo from Toyota Production System(TPS) defined seven major types of manufacturing waste: Inventory, Overproduction, extra processing, transportation, waiting, motion, and defects. Seven types of software waste are: Partially work done, Extra process, Extra feature, Defect, multi-tasking, waiting, and movement.

Agile is all about the 'Iterative and Incremental' way of developing software, receive fast feedback, and continual learning with Inspect and Adapt by responding to change even late in Development.

So Lean and Agile help create the ground works for DevOps adoption in terms of creating a culture of a shared goal, team commitment, collaboration, Iteration, time box and eliminating any types of waste, either it could be Inventory or small batch size or short queue.


5) DevOps means eliminating IT Operations or "NoOps."

NoOps (no operations) is the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house. Even people discuss like "microservices" could make the "Ops" in DevOps obsolete. However, this could rarely be the case that everything is automated in such a way (Nirvana) that we wouldn't need Ops. While the nature of IT operations work may change, it remains as crucial as ever. IT Operations collaborates for earlier in the software life cycle with Development, who continues to work with IT Operations long after the code has been deployed into production.


6) DevOps is only for Open Source Software

Although many DevOps success stories take place in organizations using software such as the LAMP stack (Linux, Apache, MySQL, PHP), and any many open source tools like Git, Jenkins, Nexus, Docker, Chef, Nagios, Ansible, Pupper, ELK, Gerrit, and Sonar. Achieving DevOps outcome is independent of the technology being used. Many companies are using Microsoft.NET, COBOL, and mainframe assembly code, as well as with SAP and even embedded systems.


7) DevOps is Incompatible with ITIL

DevOps is very much compatible with ITIL or ITSM process. However, to support the shorter lead times and higher deployment frequencies associated with DevOps, many areas of the ITIL processes becomes fully automated, solving many problems related to the configuration and release management processes (ie, keeping the configuration management database and definite software libraries up to date). And because DevOps requires fast detection of service design, incident, and problem management remain as relevant as ever.


Please Visit Remote Training Calendar 2022

Remote Training Calendar 

Like this post? Share it with friends