The Enablement section is responsible for the features and tools our customers use to operate GitLab at all scales. Enablement supports customers from initial deployment of GitLab to ongoing operation, as well as integration of other services in use by an organization.
The Enablement section is made up of one eponymous non-DevOps stage, Enablement, and seven groups:
Provide users with a consistently great experience and achieve customer business requirements by making GitLab easy to deploy, operate, scale, and integrate.
GitLab delivers value by enabling organizations to build better software, faster. The most important persona for the Enablement group is therefore the broader userbase of GitLab, rather than its administrators. We need to provide the software necessary to make it easy for an administrator to provide a delightful and productive GitLab experience to their users.
There is no traditional addressable market for Enablement due to its foundational, GitLab-specific nature. Every GitLab user is directly impacted, however, by the work Enablement delivers.
In light of this, we think of Enablement's addressable market as that of GitLab's larger addressable market. By working to ensure we can meet the operational, compliance, and integration requirements of GitLab's enterprise customers, we can capture increasingly larger percentages of GitLab's total addressable market opportunity. While we presently don't capture reasons for loss with sufficient granularity to determine when an Enablement related concern was the primary driver, making the determination of the precise missed opportunity challenging, these improvements will have a positive impact on our ability to attract and retain customers in the enterprise segment.
There are two primary segments within the broader "GitLab" market: organizations that would like to operate their own GitLab instances (self-managed) and those who prefer to utilize a SaaS service (GitLab.com). It is estimated that SaaS is the larger segment, with growth continuing to outpace self-managed.
It is important to note that GitLab.com utilizes the same code base and release artifacts as our other customers, and we document any non-default configurations, as opposed to other products in the market.
Today, we are able to capture most of the self-managed segment with our mature linux packages and more recently our Kubernetes Helm chart. A proof point is GitLab's two-thirds market share in the self-managed Git market. While this speaks to the competitiveness of GitLab's overall product, a critical enabling factor is the high-quality, flexible, and scalable software and operational tools.
While we are able to meet the requirements of most organizations, there are some occasional unmet needs:
GitLab's market share in the SaaS segment is significantly smaller than self-managed at approximately 8%. While some of the disparity is due to the network effects of GitHub.com's strong open-source community, Bitbucket's 30% market share illustrates the significant upside present in this segment for us.
There are a larger number of unmet needs on GitLab.com than self-managed, which primarily fall into two buckets:
From an Enablement perspective, much of our work is on improving the performance and reliability of GitLab.com, although there are some feature gaps we are working to address, like enablement of Advanced Global Search.
The existing team members and open vacancies for the Enablment section can be found in the links below:
Historical staffing levels for Enablement can be found in our hiring charts.
Due to the GitLab-specific nature of Enablement, adoption is primarily meaningful when seen as a percentage of GitLab instances.
Note: Links are to internal Periscope dashboards. Additional details can be found on internal Enablement topic.
/install/) and container image represent about 90% of all instances, with Source making up 8% and the cloud-native Kubernetes Helm chart 1%.
It is important to note that these statistics include the whole installed base, rather than incremental changes, which would be more sensitive to leading indicators.
As noted above, GitLab's competitive position is a tale of two cities. We are the leading self-managed Git solution but are a distant third in SaaS. Our success in self-managed has driven the majority of the company's growth, however it is at risk of being disrupted by growing trends in the market.
The IDC DevOps 2019 report is illustrative of this challenge, with the top two preferences for new IT infrastructure projects being community-supported open source software (OSS) and SaaS, respectively. Commercially supported OSS is fourth with under 15% share. While we have been successfully managing the open-core nature of GitLab, we are at risk of being disrupted from below by other OSS projects; for example, ones that may be lighter-weight and more focused in specific stages. GitLab.com, our SaaS service, represents both our biggest opportunity and risk depending on our execution.
We need to achieve what could be considered opposing goals: making GitLab efficient and easy to run at small scales and improving the scalability and reliability at web-scale.
In three years we expect:
As a result, in three years, GitLab will:
Deploying and maintaining GitLab should be as frictionless as possible for organizations of all sizes. This is critical for GitLab at multiple points in the customer journey.
GitLab starts as a personal or side project at many organizations, representing an important driver of initial adoption and awareness. Delighting future champions by providing a thoughtfully designed out-of-the-box experience that runs well on hardware they have lying around pays dividends in future growth.
Once a company is ready to adopt GitLab enterprise wide, it is similarly important to ensure the GitLab instance is set up for success with minimal effort. Consider our 5,000-user reference architecture which recommends setting up at minimum 27 different instances, and that our GitLab configuration file is over 2,000 lines long. This is a significant upfront investment to ask a company to make, prior to seeing value returned. It can also be error prone given the complexity, with the only practical solution to ongoing management being infrastructure as code, which requires further investment.
Day 2 operations like backups, scaling, and upgrades are equally important. GitLab is a business critical application, so events like upgrades need to be routine and seamless. The easier we make it for our customers to upgrade, the faster our users will be able to leverage our new features and provide feedback. Currently it takes 3 months after release for half of our users to feel the impact of our work.
By reducing the deployment/operating costs and packaging best practices, we will see the following benefits:
As customers roll out and adopt additional stages of GitLab to realize the benefits of a single application, the service availability and performance requirements increase as well. Additional departments within the business utilize the service on a daily basis to accomplish their jobs, such as design, security, and operations teams. People around the world collaborate together. Work that may have been done manually is now automated using CI/CD, including delivering the latest update or bug fix to their customer facing application/website. For these reasons, GitLab is increasingly being identified as a business-critical application with attendant requirements. It is therefore important for GitLab to be a consistently reliable, performant service for all users to fulfill its potential.
By providing market-leading reliability and performance, we will see the following benefits:
Organizations in regulated industries, the public sector, and large enterprises often have a variety of standards and processes that they must adhere to.
In the public sector, there are standards like NIST 800-53 and FedRAMP. For companies handling credit card transactions, there is PCI DSS. These are just two examples. While some of these standards are not directly aimed at services like GitLab, they have a broad reach, and the requirements generally cannot be waived, as the penalties for non-compliance can be severe. Many enterprises have also developed their own internally driven processes and policies that can be important to support, rather than requiring changes prior to the adoption of GitLab.
For published standards, it is important that GitLab offers the required features and configuration to enable our customers to be in compliance. This includes changes to our code base; for example, fully encrypting all traffic between GitLab nodes, selection of specific cryptographic modules, availability via our Reference Architectures, and disaster recovery, among others. Additionally, some standards like FedRAMP can also impact the operational and governance processes of GitLab.com. The more that we can do to be compliant out of the box or provide documentation on recommended settings, the less work our customers will be required to do during evaluation and implementation.
By enabling our customers to meet their compliance requirements and reducing the required effort, we will see the following benefits:
Over the next 12 months, each group in the Enablement section will play an integral part in this strategy.
Please see the categories page for a more detailed look at Enablements's plan by exploring
Strategy links in areas of interest.
In 2020, the Distribution team will focus on several main themes:
You can learn more about Distribution group plans on the Distribution Direction page.
You can read complete the Geo group plan on the Geo Direction page.
In 2020, the Geo Group will focus on making substantial improvements to the Disaster Recovery Category. Currently, a planned failover requires around 10 preflight actions plus 6-8 additional steps, which each contain several more commands and we aim to reduce the number of steps significantly, ideally to under five steps (we still need to do some more exploration to see what is possible). Consequently, we are working on making it easier to perform a planned failover; for example, by exploring a read-only maintenance mode, working on making it easier to pause and resume replication, and by streamlining the failover process. We are also working to enable Geo on GitLab.com to ensure the product functions at scale. This also gives us an opportunity to highlight any shortcomings long before those changes are made available in the self-managed release.
Another challenge is that many new GitLab features are initially shipped without Geo support, which means they are initially not part of Geo's Disaster Recovery plan, nor can developers benefit from geo replication. Many of our customers have a reasonable expectation that Geo works "out of the box". In order to address this problem, we are working to accelerate how new data types are added to Geo by building a scalable, self-service geo replication and verification framework. This should make it easier for developers at GitLab and the wider GitLab community to contribute and significantly reduce the current limitations on replication and verification. We also plan to make Geo easier to install and use. At this moment, installing Geo requires more than 70 individual steps to be setup, which is cumbersome, time consuming and error prone. For this reason, we are aiming to significantly simplify the installation experience, ideally reducing the required steps to below 10 (we know this is ambitious). We also aim to improve the Geo Administrator Panel so that systems administrators can manage Geo with ease and perform the tasks they need on the UI. For Geo-replication use cases, we will explore how we can improve the overall user experience. Our goal for Geo-replication is to offer the same experience to users, regardless of their location. In the future, we want our users to be able to configure Geo within minutes - not hours. We envision Geo-replication to be fully transparent to users.
Finally, the Geo group is now also responsible for backups and restore and we are going to analyze the requirements needed to improve the current backup system with a likely focus on completeness and performance.
You can read the Global Search group plan on the Global Search Direction page.
In 2020, the Global Search group is focused on three primary priorities: optimizing the cost and load of our Elasticsearch implementation, enabling Advanced Search (powered by Elasticsearch) for paid groups on GitLab.com, and improving the user experience.
Optimizing the infrastructure utilization is important for Global Search, as Elasticsearch can become quite costly to operate in both storage and compute. Reducing the requirements will be appreciated by our customers, but it is also critical enabling work to delivering Search on GitLab.com at scale. We believe we can make a number of optimizations, reducing the impact indexing has on the GitLab server itself, as well as reducing overall index size on Elasticsearch.
Enabling Advanced Search on GitLab.com brings two primary benefits. First, users of GitLab.com will benefit by being able to perform group-wide searches with lower latency, and higher quality results. Second, we will be able to dogfood our own feature, which we have found to be hugely beneficial in improving its quality and value for all customers.
Once we have Advanced Search running well on GitLab.com, we'd like to improve the relevancy of returned results and improve the user interface. There is a lot of we can do here, for example leveraging our knowledge of the code base, to prioritize function definitions themselves over the potentially hundreds of places it is called throughout the code base.
The Memory group is focused on improving performance and reducing the memory consumption of GitLab.
The focus of the team will be threefold: foundational improvements like Puma to significantly reduce memory usage, assisting in addressing memory and performance bottlenecks that are affecting customers, as well as driving organization-wide changes to ensure net-new code is performant.
The Database group is focused on improving the scalability, performance, and resilience of the relational database as well as instituting best practices across the wider development organization.
The primary focus of the team in 2020 is to improve the performance and scalability of the Postgres database. Upgrading to PosgreSQL 11 from our current supported version of 9.6 will allow us to take advantage of newer features such as declarative partitioning while also realizing the performance gains included in PostgreSQL 11. As a first iteration, we will implement partitioning for problematic tables, providing additional headroom and performance. Later, we will leverage the partitioning work and roll out sharding of the Postgres instances themselves, to improve isolation and reduce the impact of noisy neighbor situations.
The Infrastructure group has two primary goals in 2020:
A few of the key frameworks and guidance to drive in the short term are:
Choosing to invest in these areas in 2020 means we will choose not to:
Global Search is made up of two primary experiences, Basic Search and Advanced Search.
Basic Search is the default search experience for self-managed users as well as Free users of GitLab.com. It provides a way to search across the DevOps platform. Basic search includes Code Search for one project.
Advanced Search in GitLab paid tiers, is a powerful search service that saves time when collaborating. Instead of creating potentially duplicate code, users can now search for code across multiple projects that they can re-use. GitLab leverages the search capabilities of Elasticsearch. This category is at the "viable" level of maturity.
Install a self-managed instance of GitLab using the Omnibus package. This category is at the "lovable" level of maturity.
Install GitLab in a cloud native environment using Helm. This category is at the "viable" level of maturity.
Geo-replication provides an easily configurable, read-only mirror (we call it a Geo node) of a GitLab installation that is complete, accurate, verifiable and efficient. This category is at the "viable" level of maturity.
Disaster Recovery (DR) helps our customers fulfill their business continuity plans by creating processes that allow the recovery of GitLab following a natural or human-created disaster. This category is at the "minimal" level of maturity.