Open Source is for Operations, Too

Show of hands - who reading this is running OpenStack in their production environment? Prometheus? Perhaps you're generating Grafana dashboards? GitHub. GitLab. Nagios. Jenkins. Ansible. Puppet Enterprise?

Go ahead, put your hands down. Seriously, I can't see them anyway, you know. 

The point of this incomplete list is that there are likely a dozen or more open source solutions responsible for deploying, managing, and monitoring the applications in your production environment.

In the most popular open source projects in 2017 the category of IT operations was in the top three - behind data & analytics and DevOps-enabling tools. Trending in 2018 amongst powerhouse open source software targeting ML, AI, and responsive apps? Software designed to automate: Ansible (#3), manage security: Vault (#7), and scale/route applications at runtime: Kubernetes (#9). Operationally focused software.

Part of the reason for the growing popularity of open source operations is, of course, the influence from DevOps and the adoption of cloud-native architectures. The latter requires the coupling of infrastructure and applications in order to produce a fully operational, scalable application. The former demands adoption as a means to seamlessly integrate continuous delivery with continuous deployment to realize the time to value expected by business of its growing portfolio of application capital.

Take, for example, NGINX Ingress Controller. Literally, it's free and open source. Yes, it's part of a cloud-native application and yet its purpose is to route application requests; typically, an operational function in most enterprise network architectures. In fact, if you look at the last results of the bi-annual CNCF survey, you'll see that NGINX is the top ingress controller (64%) used by a respondent base that includes 36% in an operations role.

But that's infrastructure operations, right? What about network operations? Well, they're "operations" and open source users, too. Take, for example, Ansible - again, literally - as pipeline-executing, operational software that automates the deployment of app infrastructure and app services. According to our own State of Application Services research, use of Ansible for automation by every role - including NetOps - grew from 20% in 2018 to 23% in 2019. That's alongside competing open source solutions like Chef, Puppet, and OpenStack.

The reality is that open source software is eating the software that's eating IT. And IT includes operations.

A significant impact of this movement toward open source is not just the software used to operate IT on a daily basis. It's also the cultural impact of community in which ideation and solutions are shared, collaborated over, and ultimately consumed by peers. This is evident in the growth of open repositories housing templates, configurations, and scripts designed and refined by open-minded communities that are interested in helping others thrive.

The collaboration in communities on the deployment artifacts necessary to speed and scale application delivery is as much as an extension of DevOps into the enterprise as methodologies associated with the approach (e.g. Agile). That collaboration will ultimately result in organically developed best practices and de facto standards for deploying entire architectures that encompass security, performance, and availability of applications.

Given the overwhelming complexity of today's operational environments, this kind of collaboration and support is critical for operations to achieve its goals of faster, safer application deployments.

Operations are - and should be - embracing open source solutions. To fully realize the benefits, however, operations should also actively participate in and contribute to the communities creating the configurations, templates, and best practices around its implementation.

Open source isn't just about creating code anymore; it's also about how that code is packaged, deployed, and operated as it's delivered to customers.

Open source is absolutely for operations, too.