DevOps automation tools are a multibillion dollar industry increasingly adopted by enterprises looking to achieve agile goals and streamline deployment. According to the latest Version One “State of Agile” report, enterprises are not only quicker to adopt automation methodologies, but are integrating them more broadly and deeply into their organizations.
Automation triggers productivity. DevOps employ automation methodologies as a lean practice aimed at reducing manual labor, eliminating communication delays between development teams and across departments, and as a way to effectively tackle issues as these come up throughout the SDLC (software development life cycle).
But automating DevOps is not a simple case of the more the merrier and the amount and placement of automation tools in the development phase, the testing phase and the post-deployment stage is paramount to determining its effectiveness.
If you’re at the point where you’re considering introducing or increasing your company’s dependency on automation, the following is a three step thought process to automate your mindset:
Look at the current state of your DevOps, how often do you release software updates? How fast are you receiving feedback during the production lifecycle? How effective are you at remediation? Do your developers often cause delay by checking in bad quality code and breaking the build? How often do you produce status reports and how transparent are they to your entire organization?
Once you have these answers locked down, it is time to take a long hard look at how long these processes are taking you, how accurate their results are, and if they can be effectively implemented at scale. Chances are that if these processes are being handled manually, you are wasting valuable development and security resources on processes that should be automated.
CTOs are often tasked with making DevOps ROI calculations. To do this they turn to certain quantifiable metrics such as increased agility, product quality, reduced outages and improved innovation, which have a compounding effect on bottom lines.
A recent BCG article describes how a said company in the financial services space saw a 70% decrease in system downtime and a 50% increase in code quality as a result of a carefully planned out DevOps automation strategy. This is not a one-of example. A 2017 Puppet Labs study indicates that organizations using some level of automated DevOps experience 60 times fewer failures and recover from failure 168 times faster than their non-automating peers. Similarly, a 2016 Puppet annual study about the state of DevOps suggests that automation driven organizations are deploying code 30 times more frequently than their non-automating counterparts, with 50% fewer failures than organizations that manage production manually.
To the extent that time is money, automation promises speed. By continuously monitoring your code, automation tools offer “shift left” capabilities, shoring up bugs early in the product life cycle making them easier, faster and cheaper to fix. IBM and the Ponemon institute research has reported that the cost to fix an vulnerability found after product release was 30 times higher than the same vulnerability uncovered during development, and up to 100 times more expensive than one identified in the requirement phase.
While automation is king, the key to getting your money’s worth out of it is to go slow. Indeed, slow and steady wins the race. Don’t over automate. This will result in a onslaught of updates and alerts from multiple tools which will drown programmers in a workload, hindering rather than expediting their response rate.
Rather, determine the critical functions that could benefit from automation and start with those. Consider that there are levels of automation.
Continuous integration is the basic level of automation which monitors code throughout all stages of the production pipeline, from before a component enters the build, through development and post deployment. These types of CI servers are sophisticated in their ability to integrate with all common programming languages and across all development environments.
Continuous deployment is the next level of DevOps automation on the path towards continuous delivery. If continuous delivery is the goal, continuous deployment is the means by which code is automatically sent to production after the development and testing stage. The ongoing process of deploying to production cuts through the backlog that awaits in staging environments, thereby offering a faster, bottleneck free, development process.
Finally, we must mention the DevSecOps revolution. If continuous deployment is to achieve its fullest capabilities, it must apply to security concerns as well. This is where DevOps converges with security, breeding automated testing tools for security and quality purposes.
Alongside these, automated remediation is a new frontier which software development companies all wish to one day achieve. This is the process of not only identifying problems but fixing them automatically, taking the hefty burden of remediation away from production teams and placing it in the hands of a machine.
While this sounds like a dream, such groundbreaking processes are not without their difficulties. Namely that of letting an outsider, a machine, enter your code. The level of precision needed to ensure that automated remediation be done to the level it would have been done manually by a programmer intimately familiar with the code is astronomical. Technology is working its way there but we are not free and clear yet. Think about automatic translation tools or voice over IP, or even virtual assistants like Apple’s Siri. For all these tools inaccuracies still abound and flawless results are a ways off.
Ultimately the extent to which DevOps automation is implemented in your organization will have to do with how well you are able to sync up multiple automation tooling so that the agility, speed, transparency and traceability they offer can be felt.
The goal is responsible, effective, use of automation tools. This does not necessarily mean an end-to-end automated DevOps solution right off the bat. What it means is that automation tools should be chosen per function after determining the particular benefits of foregoing manual labor.
Automation is the process of allowing technology to step in in a way that makes manual labor inherently repeatable, consistent and much faster. But as much as automation is about the shift from manual to machine-based, DevOps automation is ultimately a process that requires structural change. According to Gartner’s 2015 “The Science of DevOps” report, 50% of the companies surveyed claimed that people were their biggest challenge when implementing automated solutions.
Cross-functioning teams, iterative development, and a continuous feedback cycle are powerful technological benefits. But the human factor at work in the way these technologies get implemented needs to be taken into account when striking a balance between manual and automated. How much is too much is not only a question of a company’s ability to align all its automation tools so that they work together in synchrony, but also a question of how development, security and testing teams take to the conceptual shift.
Organizations that over-automate tend to focus on automation tools more so than on development processes and the people who execute them. They end up with too many tools and must then adjust their DevOps processes to accommodate those tools, not the other way around.
More than a tools-focused initiative DevOps automation is about the human factor that runs it. From the executives that recognize its need to the CTO’s that drive its adoption, all the way to the “people on the ground” including developers, security and QA teams, DevOps automation is a people driven process aimed at faster delivery and improved quality.