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).
In some contexts, "ops" refers to operators. Operators were the counterparts to Developers represented in the original coining of the term DevOps - meant to signify the rift between the two groups and a need for collaboration. At Gitlab, we use "ops" to mean operations. Our developer first perspective means our use of the word ops is focused on enabling developers to perform operations tasks.
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:
In three years the Ops Section market will:
As a result, in three years, Gitlab will:
Our direction 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.
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).
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 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:
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:
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:
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:
Below are some additional resources to learn more about 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:
As a key part of our investment in expanding the breadth of GitLab, the stages and categories in the Ops section have a higher appetite for acquisition. Over the next year, GitLab is interested in acquisitions that fill gaps in our current set of new and minimal categories in the Configure and Monitor stages. There are also some other un-named categories which fulfill our themes above that we would consider acquisitions in. Those include:
The Ops section is composed of two stages, each of which contains several categories. Each stage has an overall strategy statement below, aligned to the themes for Ops, and each category within each stage has a dedicated vision page (plus optional documentation, marketing pages, and other materials linked below.)
The Configure stage is made up of several categories:
Commit your code and GitLab does the rest to build, test, deploy, and monitor automatically. Eliminate the complexities of getting going with automated software delivery by automatically setting up the pipeline and necessary integrations, freeing up your teams to focus on the culture part. This category is at the "viable" level of maturity.
Create and manage Kubernetes clusters with a few clicks. Install applications with a single click. This category is at the "viable" level of maturity.
Tight integrations with Slack and Mattermost make it easy to manage and automate software development and delivery right from your chat app. This category is at the "minimal" level of maturity.
Runbooks are a collection of documented procedures that explain how to carry out a particular process, be it starting, stopping, debugging, or troubleshooting a particular system. Executable runbooks allow operators to execute pre-written code blocks or database queries against a given environment. This category is at the "minimal" level of maturity.
Run cloud-agnostic serverless workloads on Kubernetes, deployed via GitLab CI/CD. This category is at the "minimal" level of maturity.
Manage your infrastructure effectively to create, configure, and manage a complete software development environment. This category is at the "minimal" level of maturity.
This category is at the "minimal" level of maturity.
This category is planned, but not yet available.
The Monitor stage is made up of several categories:
GitLab collects and displays performance metrics for deployed apps, leveraging Prometheus. Developers can determine the impact of a merge and keep an eye on their production systems, without leaving GitLab. This category is at the "viable" level of maturity.
Out-of-the-box Kubernetes cluster monitoring let you know the health of your deployment environments with traceability back to every issue and code change as part of a single application for end-to-end DevOps. This category is at the "viable" level of maturity.
Track incidents within GitLab, providing a consolidated location to understand the who, what, when, and where of the incident. Define service level objectives and error budgets, to achieve the desired balance of velocity and stability. This category is at the "viable" level of maturity.
GitLab makes it easy to view the logs of running pods in connected Kubernetes clusters. By displaying the logs directly in GitLab, developers can avoid having to manage console tools or jump to a different interface. This category is at the "viable" level of maturity.
Tracing provides insight into the performance and health of a deployed application, tracking each function or microservice which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system. This category is at the "minimal" level of maturity.
Self-managed GitLab instances come out of the box with great observability tools, reducing the time and effort required to maintain a GitLab instance.
Error tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased. This category is at the "minimal" level of maturity.
Simulate user activity within your application, to detect problems in end-to-end workflows and understand real-world performance. This category is planned, but not yet available.
Easily communicate the status of your services to users and customers. This category is planned, but not yet available.
It's important to call out that the below plan can change any moment and should not be taken as a hard commitment, though we do try to keep things generally stable. In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.
sidekiq-clusterscript to Core