18 ene 2018

Technologies

5 bad DevOps habits to break

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 5 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.”

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.”

Ver fuente