10 bad DevOps habits to break

Source – enterprisersproject.com

In 2017, more companies than ever before decided to start their DevOps journey. As with anything new, there’s a learning curve: The trick is identifying missteps before they become bad habits, because habits can be hard to break.

As you refine your DevOps strategies for the new year, it’s important to take a critical look back and seek out these troublemakers. These issues may not be obvious – so we asked business leaders and DevOps practitioners to help, by sharing their wisdom on the worst DevOps behaviors standing in the way of success.

Read on for the top 10 offenders. If you’re guilty of any of these, now is the time to kick these bad habits to the curb and maximize DevOps success in 2018.

1. Trying to be Netflix
Vinayak Joglekar, CTO and co-founder, Synerzip: “DevOps professionals need to kick the habit of trying every fad, tool, and trick to deploy several times a day like Netflix and Amazon are famous for doing. There is no business value in continuous deployment if your company doesn’t observe the impact of each small change on the way end users behave. In fact, continuous deployment can have negative business value if end users haven’t yet formed a behavioral pattern that companies can measure and track as they make changes to the code base to measure real end-user value. Ultimately, DevOps has to move away from being ‘cool’ to being ‘relevant.’”

2. Making speed your only goal
Ian Buchanan, developer advocate, Atlassian: “One DevOps habit to drop in 2018 is the constant focus on releasing faster, without improving quality. For example, you should not drive deployment automation without any automated tests. It’s a sign that everyone understands the automation aspect of DevOps, but often misses the necessary cultural groundwork, like having developers, testers, and operations teams building automation collaboratively.”

3. Ignoring security early in the development cycle
John Martinez, VP of customer solutions, Evident.io: “There’s a tendency among many product organizations to be myopic about how they approach DevOps; the emphasis is on pushing product fast, but that comes at the cost of ignoring security throughout the development lifecycle and into production. The result is that there are security vulnerabilities in the product and the underlying infrastructure that were missed by the DevOps team. That leaves the company and product exposed, or worse, they could get bitten by a breach which requires the team to go back and apply fixes. In other words, they’re constantly playing catch-up. The better way requires both a cultural and technical mind shift; DevOps and SecOps should cross-pollinate and sprinkle their expertise throughout, which would result in an improved approach: DevSecOps. This mindset will need to affect both hiring practices and processes for companies and it will fundamentally change what a security engineer looks like.” (See our related article, Why DevSecOps matters to IT leaders.)

4. Allowing siloed development teams
TJ Randall, VP of customer success, XebiaLabs: “The most common roadblock I’ve seen in working with Fortune 2000 organizations is that development isn’t just one team but many. This means the agile or continuous delivery/integration changes that do occur across the organization occur within individual silos, with each team focusing only on what they need. Everyone is solving their own problems within their own silo, so operations struggles to unify the activity into a consistent, repeatable process. It’s tough to figure out how to get different silos to agree to look at what the others are doing and to explain to them why it’s worth their time to do so.”

5. Creating too many tool standards
Matthew Perry, director of IT operations, WWT Asynchrony Labs: “Over the past year, I have seen some trying to adopt DevOps practices using themes that limit their success. This often occurs when teams lack a clear understanding of lean principles. When you start to apply lean, you should focus on creating customer value by enabling flow through the value stream. You then work to eliminate bottlenecks and rework in your delivery pipeline and enhance team productivity, all of which are crucial for DevOps. The other limiting factor is not giving teams the proper amount of autonomy. Specifically, creating too many standards around tools and not letting teams experiment with their own tools. You should set some guardrails around architecture and how infrastructure is configured, but allow teams to choose technologies that will be the most effective for their particular needs.”

6. Counting too much on one DevOps tool
Justin Rodenbostel, executive director, open source application development, SPR: “One of the worst habits to keep a company from succeeding at DevOps is when they think a tool is their ‘DevOps solution.’ It’s not a tool. Instead, DevOps is a continuation/maturation or illustration of an evolved, iterative development methodology. Modernized operationss teams that take advantage of automation are great, as are the automation tools commonly used by successful DevOps. However, the tools alone do not make DevOps. DevOps is a mix of culture, process, and tools – with the tools acting as support for both culture and process.”

7. Failing to automate security
Gordon Haff, technology evangelist, Red Hat: “Security’s still too much of a silo in DevOps; some of us use the DevSecOps term to remind people of this. You can do something about it though. Invite your security people to tell DevOps teams about their concerns. Involve them early on when developing new applications or implementing new tooling. Automate security processes as much as possible – shifting them ‘left’ (earlier) in the development pipeline. And work to create a security mindset in your developers. Most will never become true experts in security but, by involving them in security exercises, you can help to encourage an environment where security is everyone’s job.”

8. Making DevOps one person or team’s job
Ofer Karp, senior VP of engineering, Perfecto: “The leading derailment factor is assigning DevOps responsibility to one person or team. For me, Agile and DevOps is about improving team productivity to deliver more. In order for DevOps transformation to truly succeed, everyone should be involved and engaged. Teams will gradually change how software is built and maintained. This changes how you plan, evolve the architecture, and alter development and testing. In addition, you will also be changing how you deploy, monitor, and support your customers. This is why DevOps needs a full organization transformation – not just for individuals or team assignments. To kick this habit in the new year, assess the responsibilities of developers. Expand their role to also include streamlining deployment, monitoring and customer escalation issues. Redefine success from feature shipped to satisfied customer.” (For more perspectives on this topic, which still stirs debate in the DevOps community, see our earlier article, DevOps Lessons Learned. )

9. Not following through
Thomas Varghese, DevOps manager, Day Translations: “We accumulated some bad DevOps habits in our quest to develop new products and roll out projects faster. Our worst ones are not defining requirements to the core, not following sprints, and not understanding delays in the dev cycle. In 2018, we’ll be following an agile process and assigning a time for feedback and suggestions from the right parties at the right stage in the project.”

10. Failing to secure the entire DevOps pipeline
William Henry, Opensource, DevOps, and cloud strategist, Red Hat: “Regarding security, secure the supply chain too. It’s not just about worrying that your product/application in production is secure from attack, but that the supply chain of third party components and tools in the DevOps pipeline are also secure and deployed and maintained securely. Also for 2018 the idea of anti-fragility will gain greater awareness. The idea here is not about deploying systems/applications that are incapable of breaking/crashing but instead to assume they will, and even purposefully make them fail, so as to see how the system responds and self-heals. Think of Kubernetes autoscaling or auto relaunching failed pods.”