Two key challenges of using open source in the enterprise

A myriad point-tools are involved in every organization's software production. Some of our enterprise customers report using over 50 tools along their pipeline, from code development all the way to releasing into production. For the majority of development organizations today, these tools are comprised of a mix of commercial and open source technologies.

Existing open source tools can be found throughout your software development and operations teams -- from programming languages, infrastructure and technology stacks, development and test tools, project management and bug tracking, source control management, CI, configuration management, and more.

Open Source Is Everywhere

The proliferation of open source technologies, libraries, and frameworks in recent years has greatly contributed to the advancement of software development, increased developer productivity, and to the flexibility and customization of the tools landscape to support different use cases and developers’ preferences.

To increase productivity and encourage a culture of autonomy and shared ownership you want to enable teams to use their tool(s) of choice. That being said, since the advent of agile development, we see large enterprises wrestle with striking a balance to allow this choice while also retaining a level of management, visibility, and governance over all the technologies used in the software delivery lifecycle. And this problem gets harder over time, because with every passing day new tools are being created and adopted to solve increasingly fine-grained problems in a unique and valuable way.

I’d like to address two of the key challenges software executives face with regards to the use of open source as part of the software development and release process, and how you can address them when adopting open source, while mitigating possible risks.

Enabling Developers While Ensuring System-Level Management

The realities of software production in large enterprises involve a complex matrix of hundreds or thousands of inter-connected projects, applications, teams and infrastructure nodes -- all of them using different open source tools and work processes, creating management, visibility, scalability, and interoperability challenges.

The multitude of point-tools involved also creates a problem of silos of automation. In this situation, each part of the work along the pipeline is carried out by a different tool, and the output of this work has to be exported, analyzed, and handed-off to a different team and tool(s) for the next stage in the pipeline. These manual, error-prone handoffs are one of the biggest impediments to enterprise DevOps productivity. They not only slow down your process, but they also introduce risk and increase management overhead.

The fact that your process involves a lot of "best for the task" tools is pretty much a fact of life by now -- and with (mostly) good reason. But these silos of automation do not have to be.

Enterprise DevOps initiatives require a unifying approach that coordinates, automates, and manages a disparate set of dozens of tools and processes across the organization. While you want to allow your developers to use the tools they’re used to, you also want to be able to manage the entire end-to-end process of software delivery, maintain the flexibility to include new tools as they are needed, and optimize the whole process across many teams and projects throughout the organization.

This is why enterprises today are opting to integrate their toolchains into an end-to-end DevOps Release Automation platform. To accelerate your pipeline and support better manageability of the entire process, you want a platform that can serve as a layer above (or below) any infrastructure or specific tools/technology and enable centralized management and orchestration of all your tools, environments, and apps. This allows for the flexibility to manage the unique tool set of each team has today (or adopts tomorrow), while also tying all the tools together to eliminate silos of automation and provide cross-organization visibility, compliance, and control.

Security Risks and Open Source

Open Source is not only prevalent in your toolchain, it’s also in your code and in your infrastructure. Many applications today incorporate open source components and libraries, or rely on open source technology stacks. Some estimate that more than a third of software code uses open source components, with some applications relying on as much as 70 percent open source code. As open source use increases, so does the potential for security vulnerabilities and breaches (think Heartbleed, Shellshock, and POODLE).

Commercial software is just as likely to include security bugs as open source code. To mitigate these risks, you need to ensure you have the infrastructure in place to react and fix things quickly to resolve or patch any vulnerability that might come up.

By orchestrating all the tools and automating your end-to-end processes across development and operations, a DevOps Release Automation platform also accelerates your lead time in these cases, so that you can develop, test, and deploy your update more quickly.

Putting the Right Support in Place

When managing IT organizations and steering digital transformation in the enterprise, technology leaders need to support proper use of both open source and commercial technologies as part of their toolchain, while putting the right systems in place to enable enterprise-scale governance and security.

How do you know where open source technologies are being used in your process, and if there are any inherent risks or major inefficiencies that need to be addressed as a result? Before you can start optimizing, you have to know exactly what your application lifecycle looks like. This holistic process is sometimes hard to encapsulate in large and complex organizations.

CIOs need to work with their teams to capture the end-to-end pipeline and toolchain, from code-commit all the way to production. This mapping is critical to finding the bottlenecks, breakages, and inefficiencies that need to be addresses.

Then work with your teams to pick the tools (whether they be open source or not) that work best for the problem that you are trying to solve. Consider how you can orchestrate all these tools as part of a centralized platform.

Along with cultural change, breaking the "silos of automation" goes a long way towards effectively breaking the silos between development and operations, and unifying your processes towards one -- shared -- business goal: the faster delivery of valuable software to your end users.

Anders Wallgren at Electric Cloud.

Published under license from ITProPortal.com, a Net Communities Ltd Publication. All rights reserved.

Photo Credit: rvlsoft/Shutterstock