Data Centers

10 bad habits DevOps admins must break

DevOps practitioners tend to fall into a few common traps. Here's what they need to avoid to find success with the workflow.

As DevOps is gaining traction in many organizations, including Adobe, Amazon, and Target, DevOps administrators must work to integrate development, operations, support, and management for better productivity and a smoother overall workflow.

Lucrative careers in the field are growing rapidly: DevOps engineers came in no. 2 on Glassdoor's list of best tech jobs in America for 2018.

Special Report

Riding the DevOps revolution

You can download all of the articles in this special report in one PDF (free registration required).

"Generally, companies have at least a cursory understanding of what DevOps is," Justin Rodenbostel, vice president of open source application development at SPR. "That said, many of these same organizations are still struggling with finding the right path to adoption, understanding how to start to adopt and understanding whether they have capabilities mature enough to get started and be successful."

Many companies are still trying to figure out what DevOps means within small pockets of their organization, said Matthew Perry, director of IT operations at WWT Asynchrony Labs. "They have early adopters using DevOps methodologies as they continue to look for patterns that they can apply throughout their organization," he added.

SEE: IT leader's guide to making DevOps work (Tech Pro Research)

Here are 10 mistakes for DevOps admins to avoid in their implementation journey.

1. Fearing failure

DevOps admins must avoid thinking their environment is perfect, said Jim Halpin, team lead of LaSalle Network's technology recruiting practice. "Be willing to fail," Halpin said. "Sometimes you will make decisions or implement a tool that is not the best choice for the environment. Failures can lead to innovation."

While developers may want to see the fruits of their labor, that's not always the case, said IBM distinguished engineer Michael Elder. "Adopt an NCIS (No Code Is Sacred) experiment-driven practice that insists on self-editing and accepts the 'don't be afraid to fail' mentality," Elder said. "This will allow teams to form questions, quickly implement a means to gather data and try alternatives, and then use real user behavior and feedback to make a final decision."

SEE: How to become a DevOps engineer: A cheat sheet (TechRepublic)

2. Lacking trust

In the pre-DevOps world, there was a clear line between developers and operators, according to Roi Rav-Hon, DevOps team lead at Logz.io: Operations engineers did not trust the developers with production access, and developers did not trust the operators with their code.

"When DevOps came into the picture and broke this barrier, it became important to change the state of mind of the entire R&D organization," Rav-Hon said. "Operators are perfectly capable of touching and modifying the code to suit the production environment, and developers are perfectly capable of understanding, fixing and maintaining the production environment. Everyone wins in this scenario, and it is important to give both sides the proper tooling to handle the other territory as well."

3. Implementing DevOps for the sake of DevOps

"Many organizations decide to do DevOps for the sake of doing DevOps without doing any of the prep work required to really be successful," said TJ Randall, vice president of customer success at XebiaLabs. Before beginning any DevOps initiative, admins should consider their process and their goals, and what they mean for the organization, Randall said. At the start, organizations should pick one to three applications to move through the new DevOps process, to demonstrate the workflow and show to other teams as success stories, he added.

SEE: Job description: DevOps engineer (Tech Pro Research)

4. Allowing organizational silos

Silos are a major issue that arise with many DevOps implementations. "While working within the same network, different elements within the DevOps teams tend to take a very siloed approach, working as closed units," said Dror Mann, co-founder and vice president of product for Loom Systems. "Hyper-focusing on specific tasks and lack of interaction between different teams can lead to a breakdown in the overall IT framework."

DevOps teams need to find ways to act as one integrated, synchronized unit, Mann said. "Breaking out of the silos and increasing interaction can immensely improve working processes between teams and have a drastic effect on the overall performance, driving the business forward."

5. Not standardizing

Standardizing the delivery process is key for DevOps success, Randall said. "By doing the prep work—bringing everyone together, defining your releases and establishing goals—you are equipping yourself to move away from a trial and error approach to a more repeatable, scientific one," Randall said. "Standardization positions you to set goals and then collect and analyze data that allows you to see if you're meeting them."

The important step here is to assign metrics/KPIs to those goals and track them over time to see how successful you are or where you need to improve, he added.

6. Failing to integrate Agile

DevOps assumes Agile collaboration, so to successfully adopt the workflow, Agile must be ingrained in the organization, said Jasper van der Hoek, an enterprise architect at Mendix. "One recommendation to avoid this potential pitfall is to setup a bimodal organization and enable your Mode 2 team to fully adopt the Agile mindset prior to adopting DevOps," van der Hoek said. "DevOps is an evolution of Agile, and to support a successful transition, everybody involved with the DevOps team should support the Agile mindset, from the team members all the way up to the executive level."

7. Starting too big

Attempting to make all of the DevOps workflow changes at once will lead team members to struggle with finding the right balance and tools, and may lead to resistance to change, van der Hoek said. "Select one or two new DevOps teams that start a new initiative, work through challenges, build on successes, and slowly scale this through your organization," he added.

IT leaders will have more success when starting small and focusing on a single function with specific requirements and goals, according to Mike Fuhrman, chief product officer at Flexential. "Approaching the challenge with too broad of a focus frequently leads to the implemented strategy creating a lot of headaches for the business," Fuhrman added. "If DevOps is new to the company, find a trusted advisor to help you ensure successful execution across one or two business functions, then look to incorporate lessons learned as you scale out across the rest of the company."

SEE: Quick glossary: DevOps (Tech Pro Research)

8. Ignoring security

DevOps admins tend to fall into some extremely bad habits when it comes to security, according to Pete Cheslock, senior director of Threat Stack. "Our research indicates that the majority of companies admit to cutting back on security measures in order to meet a business deadline or objective, in essence sacrificing security for speed," Cheslock said. "And while the vast majority (85%) have identified practicing SecOps as a goal, only 35% are actually doing it."

DevOps and security teams tend to operate in silos, Cheslock said, and DevOps admins need to encourage greater collaboration between Dev, Sec, and Ops to close security gaps.

"Security is a huge part of DevOps and, oftentimes, I won't see security team members pulled into this process," said Tim Curless, a senior technical architect at AHEAD. "Bringing these teams together as an afterthought is the antithesis of DevOps. It's critical to have everyone at the table for a project launch in order to achieve success with the methodology."

9. Failing to work with the business

"Most DevOps professionals still speak in technical terms, even though they're often sitting at the intersection between IT and the C-suite," Curless said. "DevOps professionals need to speak in terms of business outcomes such as faster release times, attracting new customers and creating fewer unplanned outages."

DevOps administrators need to remember the "why" when getting buy-in for DevOps adoption, Curless added. For example, if the CIO is concerned about the cost of application delivery, admins should calculate the cost of an application by estimating staffing costs, labor hours, deployments/releases and the potential of production failure—and how practicing DevOps would reduce that costly downtime, he added.

DevOps admins tend to underinvest in the initial workflow planning sessions, according to Chris Wood, vice president of business acquisition, strategy and engineering at Solutions By Design.

"Many times there is a 'just get it done' mentality," Wood said. "In doing so, you send people forth to deliver without always knowing the shared vision between business and IT. By sitting down with the business, agreeing upon a repeatable delivery process, ensuring that the backlog reflects the priorities of the business and then engaging the business routinely throughout the process, DevOps administrators can allow for course corrections and natural changes throughout the process. It also promotes a healthy line of communication."

Admins also tend to fail to develop a design for what the toolchains should look like before implementing a solution, said Todd Palino, senior staff engineer for site reliability at LinkedIn. "We look to solve one pain point, say deploying applications to hosts, without an understanding of how that component should fit into an overall workflow," Palino said. "As we incrementally solve one solution after another we end up stitching the solutions together with inelegant hacks, which are often human-shaped. Time spent planning up front allows us to instead consider each solution as a piece of a whole, leading to less fragile infrastructure."

10. Focusing only on tools

Many companies still equate DevOps to tools, Perry said. "They might consider that since they're using Jenkins, Ansible and Kubernetes that they must be practicing DevOps," he added. "However, when you look at companies effectively practicing DevOps, they have changed how work gets done, as well using tools that facilitate getting work done in a collaborative fashion."

Some admins get overwhelmed by DevOps tool selection, said Dan Juengst, principal technology evangelist at OutSystems. These chains are often very complex, with hundreds of vendors in the space. "Don't get stuck in the quagmire of tool choices and building the perfect pipeline," Juengst said. "Instead focus on the three to four key areas you can automate to add major business value."

Organizations should first take the time to figure out how they will most efficiently work together, and then select the tools that will support that work, Rodenbostel said.

"DevOps isn't technology, process or even people—it's an attitude of cooperation and change," said Patrick Hubbard, head geek at SolarWinds. "And while there are new demands placed on all three components, 'DevOps' is more a state arrived at, rather than an initiate driven toward following prescription."

Also see

istock-872677410.jpg
Image: iStockphoto/chombosan

About Alison DeNisco Rayome

Alison DeNisco Rayome is a Senior Editor for TechRepublic. She covers CXO, cybersecurity, and the convergence of tech and the workplace.

Editor's Picks

Free Newsletters, In your Inbox