The DevOps movement is young and still emerging, especially among enterprises. Like any new movement or trend, it has attracted myths and fallacies. Some of these myths may have originated in companies or projects that tried and failed to adopt DevOps. What’s true in one situation, however, may not necessarily be true in others. Here are some comm. on myths about DevOps — and the facts:
DevOps Is Only for Web based organizations
What is generally referred to as DevOps originated in “born on the web” companies (companies that originated on the Internet) such as Etsy, Netflix, and Flickr. Large enterprises have been using DevOps-aligned principles and practices to deliver software for decades, however. Furthermore, current DevOps principles, have a level of maturity that makes them applicable to large enterprises that have multiple-platform technologies and distributed teams.
DevOps Is Operations Learning How to Code
Operations teams have always written scripts to manage environments and repetitive tasks, but with the evolution of infrastructure as code, operations teams saw a need to manage these large amounts of code with software engineering practices such as versioning code, check-in, check-out, branching, and merging. Today, a new version of an environment is created by an operations team member by creating a new version of the code that defines it. This doesn’t mean, however, that operations teams need to learn how to code in Java or C#. Most infrastructure-as-code technologies use languages like Ruby, which are relatively easy to pick up, especially for people who have scripting experience.
DevOps Is Just for Development and Operations
Although the name suggests a development-plus-operations origin, DevOps is for the whole team. All stakeholders in the delivery of software — lines of business, practitioners, executives, partners, suppliers, and so on — also have a stake in DevOps.
DevOps Isn’t for ITIL Shops
Some people fear that DevOps capabilities such as continuous delivery are incompatible with the checks and processes prescribed by the Information Technology Infrastructure Library (ITIL), a set of documented best practices for IT service management. In reality, ITIL’s life-cycle model is compatible with DevOps. Most of the principles defined by ITIL align very well with DevOps principles. ITIL has, however, received a bad reputation in some organizations due to being implemented predominately with slow, waterfall processes that didn’t allow for rapid changes and improvement. Aligning such practices between development and operations is the essence of DevOps.
DevOps Isn’t for Regulated Industries
Regulated industries have an overarching need for checks and balances and for approvals from stakeholders who ensure compliance and auditability. Adopting DevOps actually improves compliance, if it’s done properly. Automating process flows and using tools that have built-in capability to capture audit trails can help. Organizations in regulated industries will always have manual checkpoints or gates, but these elements aren’t incompatible with DevOps.
DevOps Isn’t for Outsourced Development
Outsourced teams should be viewed as suppliers or capability providers in the DevOps delivery pipeline. Organizations should ensure, however, that the practices and processes of the supplier teams are compatible with those of their internal project teams. Using common release planning, work-item management, and asset repository tools significantly improves communication and collaboration between lines of business and supplier and project teams, enabling DevOps practices. Using application release management tools can greatly improve an organization’s ability to define and coordinate the entire release process across all participants.
No Cloud Means No DevOps
When you think of DevOps, you often think of cloud because of its ability to dynamically provision infrastructure resources for developers and testers to rapidly obtain test environments without waiting days/weeks for a manual request to be fulfilled. However, cloud isn’t necessary to adopt DevOps
DevOps Isn’t for Large, Complex Systems
Complex systems require the discipline and collaboration that DevOps provides. Such systems typically have multiple software and/or hardware components, each of which has its own delivery cycles and timelines. DevOps facilitates coordination of these delivery cycles and system-level release planning.
DevOps Is Only about Communication
There is a misconception that communication and collaboration solve all problems. DevOps depends on communication, but better communication coupled with wasteful processes doesn’t lead to better deployments.
DevOps Means Continuous Change Deployment This misconception comes from organizations that deploy only web applications. The concept here is about being ready to deploy when the business thinks it is the right time and not when the code is ready.