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.
[ Are you a DevOps job seeker or a hiring manager? Get our free ebook: The Ultimate DevOps Hiring Guide. ]
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.’”
[ For more on doing DevOps without continuous delivery, see our related article, Dear CIOs: Stop beating yourselves up for being behind on transformation. ]
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.”
Comments
Great article! I've been reading a lot recently about what part the database should play in effective DevOps execution, so I would add that to this list. Seems to be overlooked quite often, but pretty critical. Here's a recent article I read on the subject: http://www.computerweekly.com/blog/Ahead-in-the-Clouds/Unblocking-the-database-bottleneck-in-enterprise-DevOps-deployments .
For example, Ian Buchanan, developer advocate, Atlassian: states some good points, but without context, they're meaningless -- he's at a company that produces PMO-based software (which I've used for almost 15 years -- and, they have a nice building in SF). For example, business people need reliability. Software developers do need to keep trying new software daily -- we're always improving on our processes. Context is very important -- I get his point, but its vague as stated for a CTO/CIO.
"constant focus on releasing faster, without improving quality"
This is very common when management adopts Agile without understanding it.
They treat Agile as a continued iteration of small waterfalls in hopes to increase development speed of their product. Skipping any refactoring iteration in the process. Ending with burnout developers and a software full of bugs and security issues.
Agile is like building a wall with rocks.
You take your time to shape the rocks the right way. You fix any rock that is in the wrong place.
If you do things right, you end building a wall that you don't need to go back all the time to fix it. That's is the power of Agile. You make things in such way so you can move forwards without having to look back over and over again. If you don't follow this approach you will end with a wall that any wind can push down.