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:

1. 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.
2. 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.

The Problem GitLab Wanted to Solve

In the broader software industry circa 2017, development and operations teams typically relied on separate, specialised toolchains. Integrating those tools required custom glue code, ongoing maintenance, and constant context-switching — all of which slowed delivery and introduced coordination overhead. GitLab’s leadership argued that forcing teams to stitch together disparate tools created friction, degraded code quality, and undermined the core promise of DevOps: fast, reliable software delivery.

What GitLab Meant by “Complete DevOps”

GitLab defined Complete DevOps as a single, end-to-end platform that covers every phase of the software development lifecycle — from planning and coding through testing, deployment, monitoring, and operations — all within one user interface. The company articulated three core requirements for a Complete DevOps solution:

• A unified UI shared by both development and operations teams.
• Native integration across all DevOps phases, eliminating the need to manually connect third-party tools.
• Reduced friction between Dev and Ops, enabling genuine collaboration rather than hand-offs.

As GitLab put it at the time: “We want to close the loop between Dev and Ops, automating processes and reducing complexity so that you can focus on a great customer experience.”

Series C Funding to Back the Vision

To accelerate this roadmap, GitLab announced a $20 million Series C funding round. The company stated that the capital would be directed toward reimagining and restructuring its DevOps tooling to deliver the Complete DevOps experience — reducing friction, increasing cross-team collaboration, and giving organisations a competitive advantage through faster, higher-quality software delivery.

Key Pillars of the Complete DevOps Roadmap

GitLab’s Head of Product, Mark Pundsack, detailed the strategy in a blog post. The major capability areas announced were:

Dual Monitoring Dashboards

GitLab already provided a developer-centric monitoring dashboard. The roadmap called for a second, operations-focused dashboard showing an aggregated view of all projects in production. By giving both personas access to production status within the same tool, GitLab aimed to eliminate the need for separate observability platforms and keep Dev and Ops looking at a shared source of truth.

Automated Merge Requests

Rather than relying on manual notifications and manual code changes, GitLab planned to introduce the ability to automatically create and apply merge requests. The goal was to free developers from routine change management tasks and allow them to focus on feature work and problem-solving.

Cloud-Native Development

GitLab’s vision included a cloud-based development workflow that removes the need for developers to manage local language runtimes and dependency chains. Developers would make changes, push them to the platform, and commit to the repository — with the cloud handling environment consistency.

GitLab PaaS Built on Kubernetes

GitLab described a platform-as-a-service layer built on Kubernetes that would allow operations teams to manage their entire environment through GitLab’s own tooling — without developers ever needing to interact directly with the Kubernetes dashboard or CLI. This abstraction was central to reducing operational complexity for development teams.

Feature Flags

Feature flags let developers merge and deploy code without immediately exposing it to end users. This decouples deployment from release, enabling teams to:

• Merge smaller, more frequent changesets without user impact.
• Progressively roll out features to a controlled percentage of users.
• Roll back or disable a feature instantly if a defect is discovered, limiting blast radius.

Auto DevOps

Auto DevOps was positioned as a way to automatically detect a project’s programming language, build the application, and deploy it — reducing the pipeline configuration burden. GitLab noted that Kubernetes users could trigger Auto Build and Auto Deploy with a single click, lowering the barrier to a production-ready CI/CD pipeline.

Additional Roadmap Items

The broader DevOps strategy also referenced:

• Artifact management — centralised storage and versioning of build outputs.
• SLO tracking and auto-revert — automatically rolling back deployments that breach defined service-level objectives.
• Onboarding and adoption tooling — making it easier for new teams to adopt GitLab’s full feature set.
• Pipeline environment views — visualising the state of all environments directly within the pipeline interface.

The Underlying Philosophy

Central to GitLab’s Complete DevOps vision was a belief that all creative work should shift from read-only access to read-write participation — meaning every stakeholder, not just code authors, should be able to contribute meaningfully. By giving both developers and operators a shared platform with overlapping visibility into production, GitLab argued that organisations could break down the silos that traditionally slowed software delivery and compromised quality.

Why This Mattered in 2017 (and Still Does)

The announcement reflected a competitive positioning shift: GitLab was moving beyond source control and CI to directly challenge broader DevOps platform vendors. The Complete DevOps concept foreshadowed what would become a major industry trend — platform engineering and the consolidation of fragmented toolchains into unified internal developer platforms (IDPs). GitLab’s continued investment in features like Auto DevOps, Kubernetes integration, and feature flags has kept this vision central to its product strategy in the years since.