GitLab - Huge Potential Value Generator - Part 1
Enterprises have gone through the cloud evolution, and are going through the DevOps evolution, but now they have fragmented DevOps tooling siloes.
GitLab offers enterprises cutting-edge DevOps tools all within a single platform - with incredible feature breadth.
If the agility and scalability provided by hyperscalers were the key value generators of the 2010s, .
We think the software management capabilities of leading DevOps names could be the biggest value generators of the 2020s.
Part 1 covers: rise of DevOps, the problems created, & GitLab's product and business model. Part 2 covers: the value, the future, the comp, and valuation.
The Rise of DevOps
The concept of DevOps emerged as early as the late 2000s, in tandem with the adoption of cloud computing. Before DevOps, the predominant approaches for delivering software were the Waterfall and Agile methods.
The Waterfall approach is now considered a legacy approach for software development. It entails doing each phase and step - from idea, to coding, to testing, through to deployment - in a linear, sequential manner. It was a suitable approach for monolithic applications in simpler times, but as the mobile era forced the need for greater software velocity and complexity, it proved to be highly inefficient.
Monolithic applications and their dependencies are tightly integrated. This means a single code update leads to an exponential number of other changes that need addressing, thus rendering the Waterfall approach, predicated on linearity, a major mismatch as velocity and complexity increased. As a consequence, teams using the Waterfall approach tend to avoid small and frequent changes, and instead carefully plan for larger, periodical changes.
Figure 1: Waterfall Chart for Software Development
In the early 2000s, developer communities came to focus on the Agile approach. The principles of Agile was centred around developer and product manager collaboration and iterative changes, to break down the rigidity of linear workflows. Typically, the goal is to release incremental software updates or MVPs (Minimum Viable Product) every 2-4 weeks, rather than focusing on big changes at the year-end, like is what is often done with the Waterfall approach. This reduces risk, quickens response times to end user feedback, and hence supports orgs to adapt faster to market changes.
Figure 2: Risks and Timeline Comparison – Agile vs Waterfal
Agile is an improvement on Waterfall, however, the principles don’t explicitly encompass the work of IT operations – the people needed to deliver and maintain the applications in production. In slower-moving times (i.e., pre-cloud, pre-smartphone), it was manageable to have developers take a project from idea to code completion, and then hand it off to operations. But differences in priorities between devs and ops became more problematic in the advent of cloud computing.
In the cloud, SaaS, and mobile era, devs are conditioned to release new features at a quick cadence in attempt to keep their company relevant. On the other hand, the agenda of ops teams is to maintain application stability and performance, which is difficult to do when there are devs pushing through frequent updates. In short, the cloud empowered devs to increase the speed of innovation but ops essentially became a bottleneck. This gave birth to the philosophy of DevOps, which is essentially an extension of Agile that brings close collaboration between devs and ops.
A major component of DevOps is CI/CD, or Continuous Integration and Continuous Deployment. Agile covered the CI component, which entails continuously integrating new code to deliver updates and new features. DevOps brings the CI and CD, creating a pipeline for coordinating the end-to-end lifecycle of an application. The CD component involves the testing and then putting the application into production whereby it is live in the market. The continuous nature of CI/CD is key because rather than a project being handed off from one team to the other, it brings devs and ops into continual close collaboration. As a result, it also closes the feedback loop between end users, ops, and devs, enabling more nimble reactions to the market. Respectively, the CI and CD kind of pairs up with the Dev and Ops, as depicted in the infinity symbol below. If implemented effectively, DevOps can result in numerous software updates per day – a big improvement over Agile on its own.
Figure 3: The DevOps, aka CI/CD, Infinity Symbol
The other major aspect of DevOps is the separation of environments – development, testing, and production. The virtualization and on-demand nature of public cloud infrastructure, makes it easy to spin up and manage different environments. This creates parallel, rather than linear, workflows between devs and ops. Devs can speedily work to create new features in a separate environment that doesn’t impact a live application. Then, devs can use the CI/CD pipeline to seamlessly merge the code changes into testing and then production, with oversight from ops.
DevOps is Great but there are Some Problems
As orgs have shifted from on-prem to cloud infrastructure, and shifted from monolithic to microservices-based applications, the complexity of managing DevOps itself has increased. A microservices-based application consists of an application being broken up into smaller components, each of which is connected to a number of services. This modern architecture is distributed across cloud environments, thus making the application highly available and resilient to outages and network congestions. It also enables the application components to be independently updated, thus leading to less complexity and overall faster product evolution.
DevOps practices have been instrumental in empowering the faster software cycles, but the modern-day application architecture has led to a proliferation of different DevOps tools. Each application component is being developed with its own set of DevOps tools, in most part because different devs and ops personnel have preferences for different tools. This results in a CI/CD pipeline, that is supposed to be seamless and transparent, is actually suffering from siloes and fragmentation. To cobble the disparate tooling together in order to form the CI/CD, many DevOps orgs are trying a DIY approach. Though, this entails substantial costs in recruitment, training, and overheads, and is unwieldy to manage.
The evolution has somewhat exchanged excessively complicated code changes inherent in monolithic applications, for excessively complicated DevOps tooling inherent in microservices-based applications. Vendors like GitLab, specialise in making DevOps easier for orgs by providing an all-in-one platform. With GitLab, DevOps teams can deliver software in a simpler and cost-effective way, with high-efficiency, high-quality, and high-security standards.
Brief History of GitLab
GitLab began as an open-source project back in October 2011. Co-founder, Dmitriy Zaporozhets, was working as a developer in Ukraine, and was frustrated with the lack of high-quality developer collaboration tools available in the market. So, he decided to begin an open-source project on GitHub to build software for developers to collaborate on source code. He received regular feedback and contributions from the dev community, and continued to improve the software himself.
In 2012, Sid Sijbrandij, joined Zaporozhets on the GitLab open-source software (OSS) project. Then in 2014, the two cofounded GitLab Inc., which is a business based on an open-core model, whereby the GitLab OSS features are provided for free and additional proprietary services/features are provided to paid users. (GitLab Inc. also decides to regularly contribute proprietary services to the OSS community).
Figure 4: Origins of GitLab In
In 2015, GitLab Inc. was part of the Y Combinator Seed Accelerator Program, and in the same year raised $4m from its Series A funding round. From thereon, every year GitLab moved onto the next funding round. In 2019, the company raised $268m in its Series E, led by Goldman Sachs and ICONIQ, pushing its valuation to $2.7bn. This was the last funding round before the IPO in October 2021.
GitLab received a lot of media attention during COVID-19 because since its inception it has been an all-remote company. The company has c. 1,800 employees across ~ 70 countries and has never had a single office. During the lockdowns, they actually released their Guide to All-Remote and even published a Coursera course on remote management.
Despite its successes, GitLab Inc. remains popular in the open-source communities, as it provides lots of free features and services and even open-sources entirely new products. And the contributions back to OSS are not just in the form of source code, they also include documentation, tutorials, workshops, and packaging and release distributions.
GitLab Inc. has great appeal with the OSS community, though its TTM revenue of $333m and 74% YoY growth is generated via paid and enterprise-grade offerings. OSS has lots of benefits but many parts lack clear documentation, require excessive tinkering, and lack technical support. Fundamentally, this is why the open-core model has proven to be so successful; the premium and enterprise-grade offerings fill many gaps that frustrate devs, and are truly worth paying for. On the flipside, the open-core model could be considered central to the success of OSS projects too. Many other projects that don't have a commercial entity behind them have ended up with significantly less enterprise adoption, and this then leads to little-to-none support from code contributors.
GitLab Inc. is leveraging the contributions from the OSS community to continually improve its DevOps platform. Since Zaporozhets created the GitLab OSS project in 2011, every single month there has been a new version released consisting of numerous improvements and new features. Some of these improvements/features come from OSS community contributions, and some come from GitLab Inc. The loop of feedback and swift implementation has created a flywheel effect: R&D + contributions > more features > more users > more R&D + contributions.
The benefits of this continuous cycle manifests in the number of stars GitLab projects have received on both GitHub and GitLab. Stars are awarded for various positive contributions including the quality of the OSS project, documentation, community interaction, responding to questions, etc. As can be seen in the following chart, GitLab has accrued almost 30k stars, which is among the most elite names in the OSS world.
Figure 5: GitLab’s Flywhee
To get an understanding of what a new monthly release entails, we recommend subscribers to take a look at the 15.4 release for September 2022. As shown below, in the intro we’ve copied and pasted, version 15.4 includes over 60 improvements. Some of these improvements will have come from the 186 contributions from the open-source community, and others will have been developed internally at GitLab Inc.
Figure 6: Intro to 15.4 Version of GitLab (September 2022)
The 60+ improvements in September were user-facing; there will have also been numerous more backend updates that end users won’t be aware of. And to do this amount of work every month, along with reviewing the number of OS contributions, indicates GitLab Inc. has an extremely efficient and organised operation. In essence, GitLab Inc. is the epitome of DevOps itself. And this ability to source, organise, and implement the best ideas from large pools of contributors is a key component of GitLab's moat and will only deepen as time goes by.
Originally, GitLab Inc. consisted of two collaboration applications: one for SCM (Source Code Management), and one for CI (Continuous Integration). Then, the vision emerged to be an all-in-one application that seamlessly connects all the phases of DevOps. Over time, as depicted in GitLab’s version of the DevOps infinity symbol, GitLab Inc. now provides:
Planning: some similarities to Asana and monday.com, whereby users can organise, align, and track projects to make sure people are working on the right tasks at the right time.
Code Creation/Build: GitLab’s original offering (SCM), whereby devs can connect to a repository (codebase), write code, submit for review, then merge new code to the main branch. Generally collaborate with other devs and manage the source code with version control.
Verify/Testing: includes code quality analysis and security testing, with a high degree of automation built in. The emphasis is on frequent testing and quick feedback so devs can quickly improve their code.
Packaging: GitLab enables teams to package together the application, its container, its dependencies, and all of its artifacts, into a single location within the GitLab platform. The package registry works with all common languages and binary formats, and the container registry seamlessly allows the creation, storage, and retrieval of container images (everything an application needs to run of a machine).
Release/Delivery: similar to Palantir’s Apollo, GitLab can automatically deliver software to run in any environment (development, staging/testing, production) and across any infrastructure (AWS, GCP, Azure, on-prem), with zero-touch provisioning (after having initially setup the IaC configurations). This is the first phase of the CD component of DevOps.
Configuration: having a tight integration with Kubernetes, makes GitLab valuable for orchestrating containers and configuring their infrastructure environments. This ensures applications run smoothly with high availability and resiliency.
Monitoring/Observability: this is a nascent area for GitLab Inc. Essentially, it is about observing metrics across the network, infrastructure, and application layers, in order to fine-tune performance. It also incorporates services for incident triage and troubleshooting so DevOps teams can respond to issues promptly and appropriately.
Figure 7: GitLab’s Version of the DevOps Infinity Symbol
As included in the diagram, GitLab infuses best practice security measures and standards throughout its CI/CD processes. And governance and management capabilities (a core selling point for the enterprise edition) are also wrapped around the DevOps framework. If you were to assume that GitLab Inc. appears to be a useful tool to assist orgs in being compliant, then you would be absolutely spot on. The platform’s transparency, coordination tools, shift-left security practices, and governance capabilities, along with regulatory guidance, makes GitLab very valuable for compliance requirements.
The next slide illustrates GitLab’s comprehensive platform via a different lens. It shows that GitLab’s bread-and-butter is the Create and Verify phases, as its origins are in SCM, CI, testing, and code quality analysis. The current expansion efforts are in the Packaging and Release phases, and the future expansion plans include the Configuration and Monitoring phases. In this particular slide, they’ve also added in Protect, which is the shift-left security for infrastructure, whereas the Verify phase includes shift-left for application code writing.
Figure 8: Expansion Plans
On the whole, the present and the future looks promising for GitLab. It already has an end-to-end platform for DevOps, and there isn’t much head-to-head competition, as we’ll discuss in more detail shortly. But at the same time, at the CD end of the DevOps framework, GitLab has ample opportunity for more land-and-expand and new logo business.
Kubernetes, cluster cost management, IaC (Infrastructure as Code), serverless, automation, and container security are significant growth areas that GitLab is targeting in its future expansion plans. More generally, however, as code is pretty much the innovation driver behind everything, there is almost an infinite possibility for expansion.
According Gartner, by 2024, 60% of orgs (up from 20% in 2021) will have switched from multiple point DevOps vendors to an all-encompassing DevOps platform, which they have dubbed the Value Stream Delivery Platform. On the whole, the way GitLab is evolving with the outlook of the market is very promising for durable growth.
Figure 9: Gartner’s Prediction – the Value Stream Delivery Platfor
As previously mentioned, GitLab Inc. is an open-core business. As we mentioned earlier and in previous reports, vendors that have built their product on OSS are at an advantage when it comes to staying in tune with the market. There are thousands of devs continually reviewing the source code, identifying bugs, examining potential vulnerabilities, or finding areas for functional improvement – and vendors like GitLab benefit directly from that.
Additionally, open-core vendors like GitLab invite devs to suggest code improvements to GitLab’s proprietarily created software. Devs can submit change proposals ranging from source code, to documentation, to the UX/UI of the GitLab platform.
In essence, one can view GitLab’s OSS engagement as the source of R&D and product inspiration, making sure the company stays on track with regards its value proposition.
The other key component of the open-core business model, is of course, delivering services and functionality to paid users and enterprises. Drawbacks of OSS include poor user experience, poor documentation, excessive workarounds, and poor security, which collectively result in lower developer productivity. And this is because there is no SLA (Service Level Agreement), and in essence no one accountable. GitLab’s paid tiers – Premium and Ultimate – are aimed at overcoming these pain points by improving the dev experience, the overall software productivity, and also providing greater scale and security.
Figure 10: GitLab’s Subscription Tiers
A dual bottom-up and top-down GTM approach fits in nicely with GitLab’s open-core model. Bottom-up adoption occurs via OSS communities, public cloud marketplaces, or directly with GitLab.com. Top-down sales are achieved via a large sales force and a variety of channel partners. Many large deals come to fruition as devs in an enterprise are struggling to scale on the Free or Premium tier, and a call from the sales team hence leads to a large Ultimate deal where they get scalability and support.
Figure 11: GitLab’s Partner Ecosystem
The strategy is certainly working out well, despite the economic headwinds. 2Q23 revenue grew 74% to a TTM of $333m. Additionally, in 2Q23, the number of base customers (those with ARR spend above $5k) and >$100k customers, grew 61% and 55%, respectively. In total, GitLab has an estimated ~ 30 million registered users and 1 million active license users.
Figure 12: Customer Count Growth
In Part 2 we'll cover the value of DevOps and GitLab, the future of DevOps, GitLab's competition, its financials, and the valuation considerations.