5 DevOps Pitfalls to Watch Out for – InApps 2022

DevOps has evolved from a way to remove bottlenecks to a reliable accelerated deployment strategy. However, the State of DevOps Report noticed an intriguing stat about the best industry players when they compare them to the low performers in the industry:

• Their code was deployed 100 times faster
• Their code failed three times less
• When it did fail, they recovered 24 times faster.

On one side, DevOps adoption is advocated globally. On the other side, there is a huge gap between the best and worst performers of DevOps.

This signals that while companies in many cases realize the advantages of DevOps, they are failing in its implementation.

Mistakes to Avoid on Your DevOps Journey

The roots of DevOps lie in a culture of collaboration. It’s impossible to get everything working perfectly from the first day.

As companies struggle to solve the puzzle of DevOps, success comes along as lessons on the long road to achieving a state of continuous integration and delivery.

What are the mistakes that your organization can avoid on this journey from siloed deployment processes to a well-integrated deployment continuum?

1. Deciding to Automate Wrong Processes

Often in trying to make the best use of DevOps resources, teams take DevOps too far and end up over-automating processes that don’t need automation. They try to replicate what giants like Facebook or Netflix did with their configuration management tools.

Then there are cases where essential processes are left out of the automation workflow. When teams start automating without the big picture of how all processes and subprocesses tie together, it’s hard to find processes that need automation.

Instead of applying automation verbatim on every process, first, break down each process into constituent subprocesses. Then examine each process to see if the process is working as expected. The simplest way to do this is to compare standard inputs and expected outputs against their current values to check. This will highlight the deviations in the current process and their causes so you can devise an approach to fixing them.

This process aids DevOps teams in two ways:

• It provides a complete picture of each process and ensures that no process is ignored
• It forces a thorough analysis of all processes so that no process is wrongly automated

DevOps architects, who possess cross-functional and leadership skills, can also help you navigate the deep, uncertain waters of DevOps automation.

2. Using Application Release Automation (ARA) Tools Instead of Configuration Management (CM) Tools

Configuration Management (CM) and Application Release Automation (ARA) are types of automation tools. However, both types of tools are meant for different purposes.

CM tools are best suited for stateless apps that run on a server-agnostic model. Therefore, cloud native applications can be easily managed with the help of CM tools that treat the app and the servers in the same way.

They obtain the desired state of servers from one or more configuration files stored using a source control system like GitHub or SVN.

ARA tools are meant for more complicated applications where the server has tightly-coupled dependencies and therefore they need coordination tasks.

If your application release process involves a majority of configuration tasks on a homogeneous application stack, then ARA tools are not suitable for such a setup. Using ARA tools here would be like serving toast with butter to a person who likes toast with jam, the person being your application and the server CM tools being the jam in this analogy.

From a practical perspective, you would have to write a lot of little scripts to automate server configurations with an ARA tool. Programming static values such as a change in heap size or application pool size would require coding effort. This is because these tools are not built for automating server configuration; they automate coordination and handoff processes.

With a tool specifically built for server CM, any configuration change as simple as changing some value in a few files. Therefore, it’s easy to rollback configurations and manage configurations on an ongoing basis.

3. Using Continuous Integration (CI) or Continuous Delivery (CD) Tools Instead of CM Tools

CI/CD tools are meant for development and testing teams, and they are extremely useful for them. Open source tools like Jenkins save costs and provide instant feedback which they can work into it.

Deployment tools are responsible for long term maintenance of the infrastructure needs of the application. They manage the app’s release to production and the ongoing configuration management long after UAT ends.

CI/CD tools are not directly beneficial to deployment teams because these tools don’t give them direct visibility and coordination capabilities for release and post-release phases. These capabilities can only be provided by modern tools for server configuration management.

4. Selecting the Wrong Metrics to Measure Project Success

While DevOps promises an accelerated rate of delivery, teams must be vigilant or the speed may negatively affect the application quality. A clearly defined, objectified set of DevOps metrics can help track the progress and quality of the project.

DevOps is extremely flexible in terms of customization for each organization. There is no formal framework to use for orienting your metrics selection process.

Therefore, start by defining what problems you want to solve with DevOps and how your company’s DevOps transformation would look like. After that, identify your organization’s potential challenges with DevOps and use them to orient your metrics. The right DevOps metrics will help you understand your success.

Apart from the technical metrics, you also need to select business metrics of DevOps so you can communicate the ROI of your efforts to major stakeholders. For this, you need to ensure that the metrics you select are outcome-based and aligned to business priorities. For example, if a major business objective with DevOps is bringing about efficiency in your processes, metrics focused on cost would be more suitable.

5. Not Considering Security Important Enough for DevOps

In the US, healthcare security breaches are handled against the most stringent rules under HIPAA and HITECH laws. Non-healthcare breaches don’t stay contained either. Millions of dollars have already been spent on fines and fixing the subsequent PR disasters.

High performing DevOps developers define security priorities early on and are able to incorporate them rightly into their DevOps plan.

DevSecOps, a security-oriented flavor of DevOps, binds security and compliance testing to individual DevOps phases instead of conducting them collectively at once. These crucial processes happen early in the cycle (the “shift left” of security and compliance checks) and are woven into your DevOps process.

This has at least a few advantages:

• The development team does not have to dedicate a major chunk of their time fixing security and compliance issues. The systems in place progressively detect and report these errors as they are found. These issues become a part of the regular feedback loop for the development team and therefore can be immediately fixed.
• The overall development time also gets expedited as teams are no longer rely on an independent phase to strengthen the security of their application.
• The security of your applications goes up manifold and you protect your organization against future breaches.

Final Words

Organizations that use DevOps as competitive leverage end up over-automating their processes, thereby affecting crucial DevOps metrics. Tools that are selected without due diligence (or not suitable for your specific process) can also slow down your DevOps progress. Often, a lax approach to security in DevOps can lead to breaches and subsequent fines.

Fixing these mistakes will need you to plan and take all major stakeholders in confidence to plan and communicate the countermeasures.

Feature image via Pixabay.