Open Source in the enterprise: Perspectives for CIOs

A myriad of point-tools are involved in every organisations’ 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 organisations today, these tools are comprised of a mix of commercial and Open Source (OSS) technologies.

Existing Open Source tools can be found throughout your software Dev and Ops 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.

OSS is everywhere

The proliferation of OSS technologies, libraries, and frameworks in recent years has greatly contributed to the advancement of software development, increased developer productivity, and to the flexibility and customisation 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 OSS as part of the software development and release process, and how you can address them when adopting OSS, 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 OSS 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, analysed, 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 organisation. 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 optimise the whole process across many teams and projects throughout the organisation.

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 centralised 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-organisation 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 OSS components and libraries, or rely on OSS 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 per cent Open Source code. As OSS use increases, so are the potential security vulnerabilities and breeches (think Heartbleed, Shellshock, and POODLE).

Commercial software is just as likely to include security bugs as OSS 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 Dev and Ops, 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 organisations and steering digital transformation in the enterprise, technology leaders need to support proper use of both OSS 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 OSS 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 optimising, you have to know exactly what your application lifecycle looks like. This holistic process is sometimes hard to encapsulate in large and complex organisations.

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 OSS 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 centralised platform.

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

Anders Wallgren at Electric Cloud