This article is based on reporting originally published by The Register, covering GitLab’s Commit London event in October 2019. Quotes are sourced from that reporting.
The Core Pitch: One Platform to Rule the DevOps Toolchain
At its Commit London event in October 2019, GitLab made a bold and deliberately provocative claim: that the fragmented DevOps toolchain is itself the enemy of software delivery speed — and that GitLab is the solution.
“Toolchain complexity slows down delivery,” read one slide displayed at the event. GitLab’s director of product, Eric Brinkman, went further: “We want GitLab monitoring to be a complete replacement for DataDog.” That sentiment extended across an entire category of tools the company has publicly targeted for replacement.
CEO and co-founder Sid Sijbrandij framed the company’s mission in equally direct terms: “The hardest thing to get across is that GitLab is more than just version control and CI. What we’re doing is a DevOps platform delivered as a single application.”
Around 300 developers attended the day-long event, held at an 18th-century brewery in the City of London.
Which Tools Is GitLab Targeting?
GitLab’s stated ambition covers a wide range of specialist DevOps and SecOps tools. Based on the Commit London event and the company’s own published comparison pages, the targeted categories include:
- Configuration management: Chef, Puppet, Ansible
- CI/CD: Jenkins, Spinnaker
- Project management: Jira, Collabnet
- Monitoring and observability: Splunk, Datadog
- Security scanning: Snyk
GitLab itself is careful to include a disclaimer on its comparison pages: “GitLab does not claim to contain all the functionality of the tools listed here.” That caveat matters — it is an honest acknowledgement that breadth and depth are different things. Nevertheless, the strategy is clear and deliberately aggressive.
The Case for a Unified Platform
The argument for consolidation is not without merit. Engineering teams that maintain integrations between ten or fifteen specialist tools incur real costs: integration maintenance, context-switching, credential and access management, and the cognitive overhead of moving work through multiple systems. When a pipeline breaks at the seam between two tools, diagnosing the failure is slower than if all stages lived in one system.
GitLab’s pitch is that a single application — with a unified data model, a single authentication layer, and consistent UI across source control, CI/CD, security scanning, monitoring, and issue tracking — reduces that friction meaningfully.
RedMonk analyst James Governor described the company as “hyper-aggressive. It plans to provide literally everything you need for application development, from source code management, to CI/CD, to monitoring and observability, to security ops, to docs.” He speculated that future development could push GitLab toward PaaS-like capabilities, potentially overlapping with offerings like Google Cloud Run.
The Risks of Competing With Everyone
The strategy carries significant risks. When a single vendor positions itself as a replacement for best-of-breed tools across every DevOps discipline, it faces two structural problems:
- Partnership erosion: Vendors whose products GitLab is trying to replace are unlikely to become integration partners. The DevOps ecosystem runs substantially on partnership and marketplace ecosystems; competing with everyone limits those opportunities.
- Depth versus breadth: Specialist tools like Snyk (developer-focused security) or Datadog (observability) have years of domain-specific investment behind them. A platform that covers every category risks being shallower in each one than dedicated alternatives.
The fundamental question teams must answer is whether the workflow integration benefits of a single platform outweigh the loss of depth compared to best-of-breed specialists. The answer will vary by organisation size, team maturity, and the specific tools being considered.
Cloud Infrastructure and Kubernetes Integration
One concrete announcement at Commit London was GitLab’s integration with AWS Elastic Kubernetes Service (EKS). Sijbrandij described the direction as: “What we’re going towards is something in GitLab where you can say: ‘Just spin up a new Kubernetes cluster on AWS’.”
At the time of the event, equivalent integration already existed for Google Cloud Platform. Sijbrandij stated an intention to extend the same capability to Azure Kubernetes Service.
GitLab had previously migrated its own cloud infrastructure from Azure to GCP, a move Sijbrandij said was planned before the Microsoft-GitHub acquisition and motivated in part by the “technical performance of the Google cloud.”
On progressive delivery — the practice of rolling out features to a subset of users before full deployment — Sijbrandij said: “We’ve got support for progressive rollouts with canaries, using Kubernetes. It reduces the impact of any errors.”
Self-Managed vs. Cloud: Where Customers Live
A notable data point from Sijbrandij: the majority of GitLab’s revenue at the time came from self-managed deployments rather than its cloud-hosted offering. “It’s more than 80 per cent of our revenue,” he said, while acknowledging that cloud adoption was growing.
This is a meaningful contrast with some competitors and reflects the reality that many enterprises — particularly those with regulatory constraints or existing on-premises infrastructure — prefer to run GitLab on their own hardware or private cloud.
Workflow Portability as a Competitive Differentiator
Sijbrandij made an interesting distinction on the topic of multi-cloud strategy. He argued that for most organisations, multi-cloud is not primarily about making existing applications portable between clouds — “that’s super costly” — but about retaining the freedom to deploy new applications on whichever cloud makes sense in the future.
“Our customers want workflow portability, no matter what cloud that application is deployed on,” he said. The implication is that a cloud-neutral DevOps platform is a hedge against vendor lock-in at the tooling layer, even if application-level portability remains difficult.
This position also helps GitLab differentiate from cloud-native DevOps tooling offered by AWS, Azure, and GCP. “We see that our customers want workflow portability,” Sijbrandij said, “so they’re less likely to use DevOps tools supplied by a cloud vendor. They want an independent company to provide them.”
IPO Ambitions and a Remote-First Culture
At the time of Commit London, GitLab had approximately 900 employees across 59 countries — all working remotely. Sijbrandij stated an ambition to take the company public by 2020, saying the company was “ahead of revenue expectations” and had “a good shot at it.”
“We will continue being a remote company. We will be the first public remote company as far as I know.”
Sid Sijbrandij, GitLab CEO, at Commit London 2019
Sijbrandij described the remote model as beneficial for both employees — more flexibility, less commuting — and for the company, which can hire globally and avoid the cost of office space. Internal collaboration tools at the time included Slack, Zoom, Google Docs, and GitLab Issues.
The company’s motivation for pursuing an IPO rather than acquisition was also revealing. “We have unique values, and if we get acquired those are more at risk than if we become a public company,” Sijbrandij said. GitLab had participated in Y Combinator in 2015 and raised external investment that necessitated a liquidity event.
GitHub’s Shadow and the Microsoft Factor
GitLab benefited significantly from the perception of independence following Microsoft’s acquisition of GitHub in June 2018. Sijbrandij cited the company’s share of media coverage during that period as a measure of the benefit: “In that press cycle we got 23 per cent share of voice. The next competitor got 3 per cent.”
GitHub remains GitLab’s most direct competitor for source control and CI/CD mindshare. While GitHub continued to grow after the acquisition, some users migrated to GitLab precisely because it was not owned by a major cloud vendor — the same independence argument GitLab uses against AWS- and GCP-native DevOps tooling.
The Central Question
GitLab’s strategy rests on two claims that teams evaluating the platform must assess for themselves:
- Is toolchain complexity genuinely slowing your delivery? If your team maintains a complex, fragile integration between many specialist tools, consolidation may offer real gains in developer experience and pipeline reliability.
- Can GitLab’s coverage match the depth of specialist tools in the categories that matter most to you? For teams with advanced observability, security, or configuration management requirements, the answer may still favour best-of-breed.
GitLab is transparent about its roadmap — the company publishes it publicly — which makes it possible to evaluate whether planned capabilities will close gaps that exist today. That openness is itself a differentiator in an industry that often obscures product direction.
Whether a single-platform strategy can deliver sufficient depth across every DevOps discipline, or whether it inevitably sacrifices quality for coverage, remains the defining question for GitLab’s long-term competitive position.