Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Section Vision - Ops

Ops Overview

Ops Section Overview

The Ops Section comprises the Configure and Monitor stages of the DevOps lifecycle. Market analysts (internal - i) often describe these stages as IT automation and configuration management (ITACM, analogous to Configure) and IT operations management (ITOM, partially analogous to Monitor).

The total addressable market (TAM) for DevOps tools targeting these stages (i) is $2.2B today and expected to grow to $5.3B in 2023 (18.8% CAGR). This is a deep value pool and represents a significant portion of GitLab's expanding addressable market. The market is well established (i) with players such as Splunk, New Relic and Datadog dominating market share in the Monitor stage and IBM (+RedHat), Hashicorp, Puppet and Chef splitting a large chunk of the fragmented market in the Configure stage.

With so many existing strong players, GitLab's market share in these stages is effectively zero. Our customers do utilize Configure and Monitor capabilities today. Primarily they:

Our current R&D investment in Configure and Monitor stages is 40 team members (on a plan to grow 205% Y/Y in 2019). The Configure stage is considered in Year 3 maturity and the Monitor stage is considered in Year 1 maturity.


Despite significant growth in our R&D investment in 2019, we are constrained relative to our competition in our investment amount in the Ops section. This constraint coupled with our lack of brand identification with Enterprise Ops section buyers means we need to be very strategic in building our product capabilities.

While the market for the Configure stage has many strong incumbent players, it is splintered across many traditional IT management tools (Ansible, Chef, Puppet). There are emerging trends (i) showing a consolidation on containers (i) and specifically Kubernetes (i) for cloud-native application development. This will have the effect of stymying commercial players from locking in market share based on proprietary tools. So while there are strong players, the current market dynamics means there is upside for us.

The market for the Monitor stage is aligned around key players New Relic, Splunk, ServiceNow and Datadog. Datadog, New Relic and Splunk are all headed towards integrated observability platforms based on logging and metrics. ServiceNow (i) is considered a standard for help-desk and Incident Management workflows. Strong existing players with large sustained R&D investment will make it difficult for GitLab to compete head-to-head for Monitor stage market share.

Beyond the key players, there is also rapid innovation in new technologies making for a market where there is both proliferation of new technology, and consolidation of the winning technologies into comprehensive platform players. Ease of deployment for operational tools has aided this expansion. Developers, and operations teams can easily instrument and utilize new technologies alongside their applications with less risk, and in quicker time frames than under previous models where it required dilligent planning and months of installation and configuration.

Competing tools are marketed as stand-alone point solutions while GitLab's Ops section capabilities will require customers to be using other stages of GitLab. This creates a narrow funnel for adoption with potential users coming only from the segment of the market already using, or willing to use, other stages of GitLab rather than broad-based market fit. This smaller adoption funnel will also affect the rate of learning.

Few companies are able to successfull bridge between Developer and Operator personas. Building tools that satisfy both personas is difficult. Without deeply understanding new personas, market entrants end up with a checklist of modules that doesn't represent a cohesive and improved experience for users.

Outside of market challenges we have some internal ones as well. In general, we are not dogfooding the Ops section features sufficiently. This has the effect of slowing our rate of learning, and putting us in the position of not having immediate real world validation of our product initiatives.


As noted above, given strong existing players, and our relatively low R&D investment, product maturity and brand awareness compared to the competition, GitLab must be targeted in our investment. Here are some key opportunities we must take advantage of:

Vision Themes

Our vision for Ops is to enable today's modern best-practices in operations without the burden of specialized teams, multiple tools and heavy workflows that are the largest barriers to adoption in these stages of the DevOps lifecycle. Our goal is to empower DevOps teams to own their code in production and have the tools to contribute not just to application feature development but to the characteristics of their applications as experienced by their end-users.

Theme: Infrastructure and Observability as Code

There have been two major trends impacting operations; these are essential to seeding the DevOps transformation within teams. They are Infrastructure as Code (IAC) and Observability as Code (OAC).

Infrastructure as Code

IAC provides DevOps teams with a method to maintain consistency with the infrastructure their applications run on. The best practices defined in IAC prevent configuration drift and allow teams to maintain consistent performance and security characteristics without the need for ongoing manual intervention.

IAC was made possible by the availability of rapidly deployed cloud infrastructure (IaaS platforms) and the corresponding build up of tools to enable generic usage and consistent deployment to that infrastructure (Container Management Platforms).

With our roots as a source code management system, we will build on our existing workflows for code management and extend our ability to define and manage infrastructure configuration in your project repositories so you can achieve reliability and consistency in your application.

As examples, GitLab will:

Observability and Operations as Code

Observability is a measure of your application which defines how well you can understand the state of your production system from its external outputs. The more observable your application is the more reliably you can operate it, both manually and through automation. Our vision is to allow you to define your observability and operational automation in code, alongside your application code. Whether that is the configuration of dashboards, metrics, alerts, runbooks, automation scripts or incident issues - GitLab will source-control those configurations and ensure they are reliably deployed to your production systems.

As examples, GitLab will:

Theme: Smart Feedback Loop

Defining your infrastructure, observability, and operations as code is just the first step. The real magic happens when you rapidly iterate on those definitions. As a single-application for the entire DevOps lifecycle GitLab completes what is commonly a major gap in the DevOps loop - the feedback from ops back into planning.

Our vision is to provide not just an easy ability to identify, suggest, complete, and deploy changes to your production system but also enable new insights that other tools can't. During incident response, GitLab can quickly identify the last deployed commit, lines of code changed, and author to guide the response to the right place. During deployment, GitLab can quickly tell you if your production system is already out-of-bounds from defined service-level indicator (SLI) metrics and roll back. During post-mortems, GitLab can suggest runbook or alert changes. We are very excited about enabling DevOps teams with these smart additions.

As examples, GitLab will:

Theme: Operations for All

Truly integrated DevOps teams are difficult to create. While large organizations have the budget to staff dedicated teams with roles like "Cost Optimization Engineer" and "Site Reliability Engineer" smaller teams require "Jack of All Trades" engineers.

Our vision at GitLab is that everyone can contribute, and that small teams, without specialization can leverage and adopt the same tools as those in larger organizations. By building on our preference for convention over configuration we can take the guess work out of operations. We will enable you and your team to quickly build a production application and iterate on it. We'll make it easy for teams to start from modern operations practices where you avoid alert fatigue by detecting real user events and are able to resolve like a pro. Not just on its features, but on the overall experience delivered to your users. Rapidly.

As examples, GitLab will:

Theme: No-Ops

While many teams will continue to employ operations best practices, there is a growing movement to use stricter conventions to reduce the need for operations tasks almost entirely. We'll continue to support this pattern via our investment in Auto DevOps, Serverless and PaaS iniatives.

At GitLab we believe more and more organizations will adopt centralized platform teams to manage and provide infrastructure to their development teams. By providing useful tools for those platform teams to function, we can assist them in reducing the operational burden on their development teams.

As examples, GitLab will:

3 Year Strategy

In three years the Ops Section market will:

As a result, in three years, Gitlab will:

What's Next for Ops

In the next 12 months the Ops Section must focus on:

In doing so, over the next 12 months we will choose NOT to:

12.6 (2019-12-22)



12.7 (2020-01-22)



12.8 (2020-02-22)


13.0 (2020-05-22)