The top 5 DevOps myths debunked

Source:- techbeacon.com

Business executives today are under pressure to accelerate speed to market while ensuring high quality, so it’s not surprising that they are turning to DevOps practices to ensure high-quality software and an exceptional experience for the customer.

To be effective, they you a clear understanding of DevOps and a road map for implementing these practices, but there are many misconceptions and myths that can mislead you. While DevOps is no longer the road less traveled, many people still encounter bumps and unnecessary detours along the way.

Before any road trip, it’s wise to know your path. Traditionally, software development was depicted as a linear process similar to an assembly line. But the DevOps movement urges you to view it as a circle or infinity loop, indicating that software development is iterative and ongoing. Each stage in the development lifecycle depends on the prior stages and flows into the next ones.

By embracing the entire lifecycle, from planning and development to operation in production, DevOps promotes collaboration across teams to maximize the entire value chain or flow of work to end users. Importantly, DevOps emphasizes the reverse flow of information about adoption and effectiveness from users back to planners.

Here are the top five myths, just waiting to be debunked.

1. DevOps is horizontal

Debunked: The union of dev and ops speaks to breaking down silos between IT departments in favor of a holistic view of how to maximize both velocity and quality. But the concept extends to the importance of breaking down silos between IT and business, and between the business and customers. DevOps is a revolution that is rooted in IT departments, but it encompasses deep concern for the business and customer.

It’s counterproductive for the dev team to prioritize speed if that leads to quality issues for the operations teams. In a similar way, it’s counterproductive to focus on development without assessing adoption to ensure you’re building what users really need. This feedback loop, where each stage of development is informed by other stages, is why effective development can’t be seen as linear.

2. You have to get to CI/CD right away

Debunked: Getting to continuous integration/continuous delivery (CI/CD) is a strategic journey with several milestones of maturity in between. Not everyone starts at the same place, and it’s important to know where you’re starting and where you want to go. You should envision your future state, while focusing on the improvements that are most relevant today.

Most companies begin by establishing version control as the source of truth for their development process and defining their release pipeline. To gain competitive advantage in the market, they then look to intelligent automation of their processes, especially testing and verification of new code. Don’t make the mistake of thinking DevOps is just about the tools. You have to define and fix your processes first. Automating a broken process will just fail faster.

3. DevOps is a technology

Debunked: DevOps was defined by Jez Humble as a “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” Thus it involves a company’s culture, teams, practices, and technology in increasing an organization’s ability to build and deliver innovation at a rapid pace with higher quality.

While every IT department is transitioning to agile and more collaborative delivery processes, different industries still have different requirements. Highly regulated industries such as banking, insurance, healthcare, and the public sector are more focused on trust and stability, while other industries focus primarily on speed and velocity. Every company needs to map out its balance of innovation velocity versus stability KPIs to identify the optimal trajectory for its DevOps journey.

4. Developers should build their own DevOps tools

Debunked: The earliest tools for automating parts of the development process were homegrown scripts. And there’s still room for teams to automate those aspects of their workflow that are truly unique. But as with business processes such as manufacturing, selling, and customer support, there are extremely well-defined practices and well-established tools to help with the development lifecycle.

Every business process that has been automated over the last 20 years started with teams custom building their own tooling and eventually evolved to enterprise packaged solutions that proved more cost-effective over time, with a faster pace of innovation, less expensive maintenance, and greater economies of scale than homegrown options. Today, as every company is transforming its business to compete in a digital economy, IT departments can no longer risk building DevOps on their own.

To be effective, DevOps tools must be tightly integrated with the development and deployment platforms they serve. Dev teams that invest in entirely custom solutions can waste huge amounts of time reinventing the wheel. Custom-built developer tools require devs to have deep platform expertise and keep up with all of the new APIs and features across all their platforms instead of building innovative solutions that solve real customer problems and differentiate the company. The true cost of ownership for internally developed solutions is extremely high over the long run compared to pre-built, platform-specific solutions.

As the 2019 State of DevOps Report states, “The strongest concentration of fully proprietary software is seen in low performers, while the lowest concentration is seen among high and elite performers. Proprietary software may be valuable, but it comes at great cost to maintain and support. It’s no surprise that the highest performers have moved away from this model.”

5. DevOps relies mostly on open-source tools

Debunked: Only 22% of DevOps teams rely primarily on open-source tools, whereas 70% use commercial tools for at least some parts of their process (source: 2019 State of DevOps Report). Developers who are building a process on their own are most likely to rely heavily on open-source tools, since those tools don’t require funding approval. But when designing a process for your team, it’s critical that teams identify the most effective tools for the job, and recognize that many commercial tools bring a very high return on investment. Different technologies and platforms also demand different approaches. Research shows that teams that have autonomy to choose the best tools for their platform outperform teams that are required to use corporate-mandated tools (source: 2017 State of DevOps Report).

The best tools for your DevOps workflow may vary depending on the type of application or the platform to which you’re deploying. A DevOps stack for building mobile applications may look quite different from one used to build, test, and deploy to an infrastructure-as-a-service (IaaS) provider. Software-as-a-service (SaaS) applications are becoming far more sophisticated and increasingly demand their own DevOps lifecycle.

Needless to say, the tools for deploying SaaS applications must be carefully designed for the platform they are serving. Generic DevOps tools will require extensive scripting and customization to work on most SaaS systems, making platform-specific tools are far more attractive option.

A clear understanding of DevOps will guide you on the path to greater velocity and quality. DevOps has been summarized by Jonathan Smart as “better value, sooner, safer, happier.” In his statement, “better” implies continuous improvement, always striving to improve the quality not only of our work but also of our processes. “Value” means using agile development and design thinking to address and adapt to the needs of end users. “Sooner” means using techniques such as continuous delivery to release more quickly. “Safer” means integrating automated quality and security scanning into the development workflow. And “happier” refers to continuously improving both the development experience and the customer experience of users.