The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last reviewed: 2020-12-22
No news for this month.
Upcoming features can always be found on the Enablement kick off page. Highlights include:
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 cross-stage end user features.
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 use.
GitLab delivers value by enabling organizations to build better software, faster. The most important persona for the Enablement group is therefore the broader user base 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. Within the single platform, users also need a set of common cross-stage features to make the broad array of features easily consumable.
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 usability requirements of GitLab's enterprise customers, we can capture increasingly larger percentages of GitLab's total addressable market opportunity.
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). SaaS revenue within the DevOps space is predicted to overtake self-managed by 2022, with our key competitors already capitalizing on this shift. This is confirmed by analysts reports (GitLab confidential) as well as others in the DevOps space.
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 unmet needs:
Today, GitLab is underperforming compared to our peers in the SaaS segment. While GitLab's SaaS revenue is accelerating faster than self-managed, it represents less than 20% of our revenue (GitLab confidential). IDC predicts SaaS represents 38% of the DevOps market today, growing to 62% by 2022. This represents both a significant growth opportunity if we can better serve this segment, or significant risk if we fail to execute.
There are a larger number of unmet needs on GitLab.com than self-managed, which primarily fall into two buckets:
For GitLab's FY22, a key theme is SaaS First, to drive the closure of these gaps. From an Enablement perspective, much of our work is on improving the performance, reliability, and efficiency of GitLab.com. The GitLab.com infrastructure strategy is available here.
The existing team members and open vacancies for the Enablement section can be found in the links below:
All Enablement section metrics can be found on the Enablement Performance Indicator page.
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 internet-scale.
In three years we expect:
As a result, in three years, GitLab will:
Woven throughout all of the below themes is a focus on improving our competitiveness in the SaaS segment. As this is critical outcome for the company, it is worth highlighting individually our efforts to contribute.
Most important, is improving the service levels and efficiency of GitLab.com, our multi-tenant SaaS service. A multi-tenant cloud service is the best solution for most customers, combining low cost of ownership and fast time to value. Enablement is specifically focused on a few key outcomes:
In addition, we are exploring a single-tenant SaaS offering to serve segments of the market that desire a SaaS service, but have compliance requirements which prohibit a multi-tenant service.
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 over 3 months after release for a majority 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
Direction page links in areas of interest.
In FY22 (CY 2021), 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 the Geo group plan on the Global Search Direction page.
For the first part of the year, the Geo group is primarily focused on the work required to reach [complete maturity for Complete maturity for Disaster Recovery.
Once complete, Geo plans to improve our Geo Replication, another key feature for large enterprises with multiple offices, or the growing number of businesses embracing remote work. Geo-replication enables organizations to set up additional GitLab nodes throughout the world, enabling these users to work efficiently, by reducing the latency and time it takes to perform common tasks like cloning or pulling container images.
Disaster Recovery is a common, must-have, requirement for large enterprises, allowing them to feel comfortable that GitLab can remain available for their developers to be productive throughout a variety of disaster scenarios. It is a significant driver of our Premium tier.
The remaining work to achieve Complete falls into the following categories:
As part of a planned failover process, it is required to fully synchronize a primary Geo site and a secondary site so that no data is lost. We are working on a maintenance mode that blocks any write operations on the primary site thereby allowing both sites to fully get in sync. Additionally, a maintenance period may be useful in other situations e.g. during upgrades or other infrastructure changes.
As of December 2020, Geo replicates 80% of all data; however, not all data is automatically verified. We've created a self-service framework that supports replication strategies for Git repositories and blobs (files). We are adding blob verification support to the framework, with package files being supported first.
The Geo Primary site supports high-availability configuration of PostgreSQL using Patroni; however, Geo secondary sites have only experimental support for a similar configuration. This is problematic because it means that a failover to a designated secondary site can't utilize a high-availability configuration immediately. Exactly mirroring the architecture on the primary and secondary site is not yet possible. We are working on making PostgreSQL clusters generally available.
Geo Replication is less commonly utilized than Disaster Recovery, but for organizations with users distributed across the globe, it is critical to ensure these developers are productive and have a good user experience.
We need to understand better how software developers interact with secondary sites. As a next step, we are going to track Git operations performed on secondary sites. This data will help us understand usage patterns and how we can improve the overall user experience.
Using a Geo site to overcome UX issues (e.g. latency) requires additional configuration for software developers, which is cumbersome. Using the secondary Web interface is a worse user experience than using the primary. A software developer needs to switch between a primary and secondary frequently, which can be highly confusing and frustrating.
We plan to automatically choose the best Geo node. This means that Geo will forward any requests from a secondary to a primary unless the user experience can be significantly improved by using the secondary. This will likely result in the deprecation of the read-only web interface because requests will be proxied from a secondary to a primary.
For Geo-replication only a subset of data may need to be replicated but Geo sites require spinning up the entire GitLab stack, less may be sufficient. Additionally, systems administrators can select a subset via selective sync, but they may be wrong.
We are investigating an advanced caching mode with the following properties:
You can read the Global Search group plan on the Global Search Direction page.
For FY22 - the Global Search team is working on delivering a modern search user interface that will allow users to navigate through their search to filter down to what they are looking for. Offering comprehensive filter options will allow users to search with vague context, decide what applies to what they are looking for, and filter out everything else. Making these filters dynamic based on the information returned from the initial query will encourage users to explore the information in GitLab easier.
The two key areas Global Search is working on this year is:
Our old user interface was designed to provide a minimal amount of complexity as we focused on building and scaling the backend components. We have started adding richer features to help users more easily find what they are looking for, and discover content that is related. Once we have a core modern search experience, we on improving the design that better utilizes these features for a more complete User Flow. Our customers have told us that having a single tab for all results with filtering to specific scopes would be a better approach to help find content types across the repo. We are also going to start using horizontal space better by adding filtering to the left-hand side of the search page. This will allow us to expand the results list as well as move more results above the fold.
While a good search interface can help users filter and narrow down their searches to better find what they are looking for, we also want to improve our ranking functionality to reduce the need to filter in the first place. Improving ranking is critical to making finding information less intensive, by providing the most relevant results across the platform first.
For FY22, the group is purely focused on reducing the Memory consumption of GitLab, to ensure it runs well on low end devices. This is primarily a long term bet to prevent disruption from below, but to a lesser extent general efficiency for larger deployments as well.
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.
For FY22, the group is working on the following key themes:
See the 1 year GitLab.com infrastructure strategy
Choosing to invest in these areas in 2020 means we will choose not to:
The Enablement pricing strategy's aim is to ensure that the widest possible audience can benefit from GitLab through our free tier, and that we can meet the unqiue needs of large organizations through our paid tiers.
At the free tier, we want to provide an open-core product for everyone. To achieve this GitLab needs to be incredibly easy to try and adopt, for a wide variety of deployment methods. Today we support SaaS with GitLab.com, and self-managed on all major cloud providers as well as on-prem. This model helps keep our open core flywheel spinning, and is a key factor in our organic growth by being a go-to DevOps application with a low time and effort investment required to see value.
As adoption across an organization grows, additional business and scale requirements may need to be met, these are particularly common for large enterprise and regulated industries. We aim to meet these more complex operational needs with features in our paid tiers, so that these organizations can adopt GitLab at scale.
From an operational standpoint, we believe GitLab should be easy to deploy and operate, and that all users should have a great user experience. To achieve this, we invest significantly in automating as much of the deployment and day 2 operations as we can, and embedding as many best practices into the product as possible. We want to set up administrators for success, so they can delight their users. We don't believe application performance, or ease of use, should be a paid-for feature. This helps to ensure that GitLab is easy to try, and that when deployed, provides a good user experience.
For the user-facing features that we build, we align with our overall pricing strategy, focusing Core/Free on individual developers. Presently this includes basic search, which provides a search experience across projects and groups.
We do not introduce any new operational features at the Starter level, as Manager-level needs are well served by our Core/Free features, usually by simply vertically scaling their existing instance to accommodate a growing team.
Operationally, this tier is where the majority of paid features are located, as Director-level buyers are typically more concerned about meeting wider business, compliance, and scale requirements. We focus features that relate to meeting these needs, typically found in larger enterprises or regulated industries, in this tier. Examples include meeting business continuity needs with disaster recovery and horizontally-scaled instances, as well as multi-region performance requirements with geo-replication.
Currently there are no Enablement features in this tier. We would introduce new features in this tier that target highly specialized requirements typically seen at the executive level. For example companies who may operate multiple independent businesses, but still want to provide a unified experience across the organization through some type of federation.
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.
Infrastructure provides operational capabilities (including availability, reliability, performance, and scalability) for GitLab's multi-tenant SaaS offering.