alphaspirit - Fotolia
Build a DevOps toolchain that's efficient and effective
Is it possible to create a DevOps toolchain that meets the needs of developers, IT operations teams and business staffers? Here's how to devise a strategy.
Organizations that want to build a DevOps toolchain have an unprecedented number of products to evaluate. This process can be daunting for a business that wants to build a toolchain that is both comprehensive and efficient.
Capabilities sought in a DevOps toolchain can include integrated development environments, repositories, CI/CD, code review, release orchestration, log management, containers, configuration management and automation tooling. What complicates toolchain planning is that many products are able fulfill more than one need.
"Most organizations are now faced with their own hairball of legacy DevOps tools, and many of them are overlapping in terms of functionality," said Torsten Volk, managing research director at Enterprise Management Associates.
IT teams typically have little visibility into the individual tool silos. Plus, developers are often poorly connected with the operational monitoring tools that could show the effects their code has on users and operations.
A good starting point is to focus on how a DevOps toolchain can help monitor and enforce centralized policies designed to prevent projects from going off the rails. One area of emphasis, Volk suggested, should be to find tools for the parts of the software lifecycle that require the kind of manual labor that holds back developer productivity. Test automation is one key area that organizations try to address with too many manual tasks on the one hand and a lack of test coverage on the other. There is also a big push toward establishing a unified set of metrics in terms of process efficiency, customer alignment and product quality.
Complete the loop
"It's important to make it very simple for each developer to observe the customer and operational impact of their code," Volk said.
Throughout his career in software development, Volk saw how even the most elegant, innovative code will go unused if it comes with seemingly trivial hurdles that frustrate business users.
"It can be overwhelming for organizations looking to improve and modernize capabilities in this area," said Joe Mongiat, senior technical architect at West Monroe Partners, a technology consulting firm. In order to focus time and effort, it's important to combine a measured, iterative approach, executive support and dedicated team members to help drive the vision, selection and decision-making around your end-to-end DevOps strategy.
To start, Mongiat said, consider the stakeholder groups in your organization and how they would use these tools. This should include developers, IT and security operations teams, IT leadership and any other business stakeholder groups. Document how their needs drive priority and consider surveying them for ideas and input.
It's important to first gain executive support in order to ease the burden these new tools will bring into the organization. Without this support and a broad understanding of their needs, you risk over-engineering for one set of users, having low utilization and buy-in on the tools that are selected or having significant gaps in features, Mongiat said.
In one recent project, Mongiat's team helped a financial services company move from an on-premises environment to the cloud with a supporting DevOps toolchain. It didn't require a lot of time or effort to configure and set up the tools. The bigger challenge, Mongiat said, was to gain buy-in from stakeholders and figure out how the IT organization's existing processes and skills could be used to support this new environment.
Evaluate the full value proposition
It's important to consider the full value proposition of a DevOps toolchain in order to create the most value.
"Most organizations that think about toolchains from a cost-effective standpoint are thinking of CI/CD and infrastructure as code, but there are many more pieces to the puzzle," said Justin Rodenbostel, vice president at SPR, a digital transformation consultancy.
Many toolchains support different aspects of an engineering team while still meeting the needs of the customer and business.
Rodenbostel sees a parallel to building a house. All of the workers will have some tools in common, but other tools will be specific to that person's role, be it plumber, electrician or carpenter. Engineering teams operate the same way, he said. Workers will use specialized tools for disciplines such as security, software engineering, build and deploy, provisioning or configuration management.
As a starting point for tool selection, Rodenbostel recommended IT decision-makers look at vendor use cases. "The DevOps success stories we typically hear have to do with a company's DevOps evolution, rather than how its leaders built a process and selected tools that could support web-scale traffic on the first day they were in production," Rodenbostel said.
Even after you've selected tools that get the job done, continue to look for ways to improve your processes as the organization's needs evolve.
Start with a carrot
It's probably better to get traction from developers so that they can drive adoption of new DevOps tooling.
"I recommend taking an enable, don't force approach to building a DevOps toolchain," said Tim Curless, a DevOps solutions principal at Ahead, a service delivery consultancy.
Organizations should start with a workshop with all stakeholders. This will identify the key use cases and success factors. Also, this is the best time to compile a list of all the tools already in use.
From there, a team should be built to own the reference toolchain and maintain the toolchain as if it were a product. This team should be responsible for training and be ready to respond to requests for amendments or additional tools.
The product as a whole should be versioned with updates released on a regular basis. While the toolchain product is the recommended toolchain, it is not forced throughout the organization, Curless said. If users decide to go it alone, they won't have access to the toolchain team for training and support.
It's important to incorporate security into this process.
"Providing a means for experimentation is important, but security in the environment is critical," Curless said. For example, a team may use an open source tool that doesn't comply with copyright or legal guidelines or could potentially have a vulnerability that would put the organization at risk. These scenarios can only be mitigated through proper security.
Filling the gaps
To narrow the number of tools you might use, consider the creation of a reference architecture for each category in your toolchain. Next, teams should populate the reference architecture with tools the organization already owns or uses. This will illustrate where gaps lie and highlight possible overlaps, Curless said. The boxes that aren't populated represent areas to add tools.
These gaps can be filled using simple tools and open source or enterprise-grade software.
For significant purchases, it's helpful to use a scorecard approach to rationalize two to three options, Curless said. For example, he had seen this method prove useful when evaluating configuration management tools from Puppet, Chef and Red Hat.
