The Core Argument: Best-of-Breed Over All-in-One

At its annual Puppetize PDX conference in Portland in October 2019, DevOps automation company Puppet made a pointed argument to roughly 400 attendees: a one-size-fits-all DevOps platform ends up fitting nobody particularly well. The message put Puppet in direct philosophical opposition to platforms like GitLab, which at the time was publicly listing competing tools — including Puppet — as targets in its push to deliver a single, unified DevOps application.

Puppet’s position is that real-world application and infrastructure delivery is too varied and complex for any single platform to handle optimally across every customer’s needs. Instead, Puppet advocates picking the best tool for each stage of the DevOps chain and integrating those tools through automation.

A Strategic Pivot: From CI to CD

CEO Yvonne Wassenaar, who joined Puppet at the start of 2019, described a strategic rebalancing she initiated shortly after taking the role. When she arrived, she said, the company was more focused on the CI (Continuous Integration) side of the CI/CD pipeline — territory that put it in direct competition with tools like Jenkins, without enough differentiation.

Her response was to shift the company’s focus toward the CD (Continuous Delivery) side, which she described as “a rebalancing back to what really matters to our customers today.” The goal was to position Puppet more distinctively around infrastructure automation, configuration management, and deployment rather than competing head-on with CI-focused tooling.

Under the Hood: Puppet’s Technical Stack

CTO Deepak Giridharagopal — a Puppet veteran who described his own transition from engineer to executive as “hard” — provided a candid look at the company’s technical foundations:

• The core open-source Puppet project is written in Ruby.
• PuppetDB and much of the enterprise commercial stack run on the Java Virtual Machine (JVM).
• Giridharagopal’s personal tools of choice at the time were Rust and Go, reflecting broader industry trends toward performance-oriented, compiled languages.

Containerisation: The Pupperware Project

A significant focus at Puppetize PDX 2019 was the ongoing effort to containerise the Puppet stack. Giridharagopal highlighted Pupperware — an open-source project on GitHub — as the community’s effort to run Puppet infrastructure inside containers.

The commercial product was also being containerised in parallel. Giridharagopal was candid about the challenges involved, describing it as “a very educational case study in the complexity of just how hard it is to make something run in that kind of environment.” The dream of simply dropping a mature, cross-platform application into containers and shipping it, he noted, runs into practical obstacles fast — including filesystem behaviour differences between macOS, Linux, and Windows.

His framing of containerisation was pragmatic: he viewed it as “just a different delivery vehicle” rather than an architectural overhaul, with backward compatibility remaining a priority for Puppet’s existing user base.

40,000 Organisations and the Complexity That Comes With Scale

Field CTO Nigel Kersten, who works directly with Puppet’s customer base, explained why adoption at scale creates inherent complexity. Because Puppet typically operates at the infrastructure layer — beneath most of an organisation’s other tooling — integrating it across an enterprise environment involves layered dependencies and process interlocks that take meaningful effort to untangle.

Puppet’s response has been to offer professional services to help customers through complex integrations. However, both Kersten and Wassenaar were careful to frame the company as product-first. Wassenaar stated that in her experience, services revenue should not exceed roughly 20 percent of a software company’s overall business — and Puppet aims to stay well within that boundary.

Kersten drew a distinction between tactical, billable services work and higher-value strategic consulting that enables partners and the broader ecosystem — comparing the latter favourably to the kind of ecosystem investment Amazon has made in its partner network.

The Road Ahead: Security, Innovation, and Competition

Looking forward, Wassenaar identified vulnerability detection and remediation — internally framed as “Find It, Fix It” — as a key growth area for Puppet. The idea is to extend Puppet’s infrastructure automation capabilities into security use cases, helping organisations not just configure systems but identify and remediate vulnerabilities at scale.

On the competitive landscape, Wassenaar acknowledged that rivals like Ansible had moved further ahead in certain areas — specifically network automation content. Her response was that Puppet was “just at the beginning of that race,” signalling intent to compete rather than concede that ground.

The Bigger Debate: Integrated Platforms vs. Best-of-Breed Toolchains

Puppet’s conference messaging crystallised a debate that continues to run through the DevOps industry: should organisations consolidate onto a single integrated DevOps platform, or build a best-of-breed toolchain by integrating specialised tools for each function?

Puppet’s bet is that organisations will resist vendor lock-in and prefer to use Puppet Enterprise as an automation layer that integrates with a broader toolchain — rather than replacing it. GitLab’s counter-bet, at the time, was that the operational overhead of managing many tools would push teams toward a single, coherent platform.

Both arguments have merit, and in practice most organisations land somewhere in the middle: consolidating where it reduces friction and complexity, while retaining specialist tools where the functional gaps in integrated platforms are too large to ignore.

Key Takeaways for DevOps Teams

• No universal answer: The right DevOps toolchain depends on your organisation’s specific infrastructure, team structure, and delivery requirements.
• CD over CI: Puppet was explicitly repositioning around Continuous Delivery and infrastructure automation rather than pipeline build tooling.
• Containerisation is hard: Even mature, widely-deployed tools face real challenges when being adapted for container-native deployment — cross-platform filesystem behaviour being one concrete example.
• Services as an enabler, not a business model: Puppet’s leadership viewed professional services as a means to drive product adoption, not as a revenue line to maximise.
• Security automation is emerging: Vulnerability detection and remediation via infrastructure automation was flagged as a meaningful growth frontier.

Feedback Is the Core of DevOps

A feedback loop is essential to every part of the modern DevOps environment. From continuous integration and continuous deployment (CI/CD) to application development, infrastructure monitoring, and team collaboration, feedback is arguably the single most important element of a functioning DevOps practice.

But feedback only has value when it arrives in time to act on it. In the context of modern software delivery, that means instant — or as close to instant as technically achievable.

How Feedback Has Changed Over Time

Before web and mobile development became the norm, feedback was a relatively simple, closed loop between a developer and the application they were building. Compilers, static analysis tools, and unit tests caught issues early. Desktop developers could investigate and fix problems without end users ever being exposed to flaws, because there were no live deployments in the modern sense — distributing software meant shipping a new version on physical media.

The shift to web-based and mobile software changed everything. New components entered the picture:

• Cloud infrastructure with elastic, distributed resources
• Containers abstracting application environments
• Test-driven development (TDD) as a standard practice
• Continuous, iterative deployment cycles pushing changes to production multiple times per day

Each of these introduced new failure modes and new surfaces to monitor. The single-machine feedback loop of the desktop era was no longer sufficient.

What Feedback Actually Means in a Modern Pipeline

When multiple, distributed systems are running simultaneously — a CI/CD server, containerised application services, separate database containers, load balancers — all of them generate streams of information. Without an analytical layer to process that information, what you have is raw data.

Raw data has limited utility on its own. Engineers working directly with logs or metrics can extract meaning, but the wider organisation — including product managers, business stakeholders, and operations leads — needs processed, contextual information. The role of the analytics layer is to convert raw data into meaningful feedback.

Equally important is routing the right information to the right people. A sales team has no use for a CPU utilisation graph; an infrastructure engineer has no need to review marketing burn-rate dashboards. Well-designed analytics surfaces relevant signals to the teams that can act on them.

Why Instant Feedback Matters for Deployments

Modern application teams aim to deploy consistently, securely, and with high stability. When a release goes out, the team immediately needs to know:

• Did the deployment complete successfully?
• Were any errors thrown during or after the release?
• How are resource utilisation and response times trending compared to before the deploy?
• Are end users experiencing any degradation?

Even a few minutes of delay in answering these questions can have real business consequences. The industry expectation of high availability and zero-downtime deployments means that issues must be caught and addressed before they escalate. A minor anomaly that goes unnoticed for five minutes can become a cascading failure that impacts thousands of users.

Instant feedback gives teams a window to intervene — rolling back a bad release, scaling resources, or triggering an automated remediation — before a small problem becomes a major incident.

How Analytics Dashboards Enable Real-Time Feedback

Analytical dashboards serve as the translation layer between raw system telemetry and actionable feedback. When configured correctly, they:

• Aggregate metrics from CI/CD pipelines, application performance monitoring (APM) tools, infrastructure agents, and log aggregators
• Surface anomalies and threshold violations as alerts in near real time
• Present trends visually so engineers can quickly distinguish normal variance from genuine problems
• Enable correlation between a deployment event and a downstream change in error rate or latency

This continuous, processed feedback loop allows DevOps teams to streamline their processes, reduce mean time to detection (MTTD), and consistently deliver a more reliable product to end users.

The Role of Feedback Will Only Grow

As deployment frequency increases and systems grow more distributed, the demand for fast, accurate, well-routed feedback will only intensify. Teams that invest in robust analytics pipelines — ensuring the right data reaches the right people at the right time — will be better positioned to maintain reliability while continuing to ship at speed.

The tools and platforms that power instant feedback will need to keep pace: ingesting higher volumes of telemetry, reducing latency from event to alert, and presenting information with enough context for engineers to act decisively. In a world of continuous delivery, instant feedback is not a luxury — it is a fundamental operational requirement.

GitLab Becomes a Unicorn With $100 Million Series D

GitLab crossed the $1 billion valuation threshold in September 2018 after closing a $100 million Series D funding round. The round was led by ICONIQ Capital, with participation from Khosla Ventures and Google Ventures. The fresh capital is earmarked to deepen GitLab’s position across the full DevOps lifecycle — from project planning through production monitoring — all within a single application.

Who Invested and Why

ICONIQ Capital general partner Matthew Jacobson highlighted GitLab’s development velocity as a key differentiator:

“GitLab is emerging as a leader across the entire software development ecosystem by releasing software at an exceptional velocity. They’re taking the broad software development market head-on by developing an application that allows organizations to ship software at an accelerated rate with major increases in efficiency.”

Matthew Jacobson, General Partner, ICONIQ Capital

The involvement of Google Ventures is notable given GitLab’s emphasis on Kubernetes integration and cloud-native workflows, areas that align closely with Google’s own infrastructure priorities.

The Problem GitLab Is Solving: Toolchain Sprawl

GitLab’s funding thesis rests on a specific pain point it calls the “tool chain crisis.” A typical enterprise DevOps pipeline is assembled from a large number of point solutions — tools such as VersionOne, Jira, GitHub, Jenkins, Artifactory, Electric Cloud, Puppet, New Relic, and Black Duck, among others. Each tool solves one stage of the software delivery process but introduces its own integration overhead, access controls, and data silos.

The practical consequences of this fragmentation include:

• Longer cycle times caused by hand-offs and integration failures between tools.
• Poor end-to-end visibility, making it difficult to trace a feature from idea to production incident.
• Increased cognitive load for developers who must context-switch across multiple UIs and authentication systems.
• Higher operational cost to maintain, license, and upgrade each tool independently.

GitLab’s Concurrent DevOps Vision

GitLab’s answer to toolchain sprawl is what it calls Concurrent DevOps — the idea that every stage of the software development lifecycle should be addressable inside one application rather than stitched together from best-of-breed point products. The stages GitLab targets include:

• Manage — project management, access controls, and analytics
• Plan — issue tracking, roadmaps, and agile boards
• Create — source control, code review, and the web IDE
• Verify — CI pipelines and code quality checks
• Package — container and artifact registries
• Release — continuous delivery and feature flags
• Configure — Kubernetes and infrastructure configuration
• Monitor — performance monitoring and alerting
• Secure — SAST, DAST, dependency scanning, and license compliance

The goal is a single data model and a single interface across all of these stages, eliminating the integration tax that multi-tool environments impose.

Industry Analyst Perspective

Stephen O’Grady, principal analyst at developer-focused research firm RedMonk, framed GitLab’s approach in the context of broader trends:

“Two of the defining characteristics of modern application development are an open, collaborative process and toolchains that transcend individual product categories from planning out to operations. By marrying an open source development process to a comprehensive set of functional capabilities, GitLab aims to leverage those precise qualities in a single application that meets enterprises’ DevOps needs.”

Stephen O’Grady, Principal Analyst, RedMonk

Recent Product Investments

At the time of the funding announcement, GitLab had already shipped several features aligned with its Concurrent DevOps roadmap:

• Auto DevOps — a set of pre-configured CI/CD templates that automatically detect, build, test, deploy, and monitor applications with minimal configuration.
• Kubernetes integrations — native cluster management within the GitLab UI, enabling teams to deploy and monitor workloads without leaving the platform.
• Web IDE enhancements — a browser-based editor allowing developers to make and commit changes without a local environment.

CEO Commentary on the Milestone

GitLab CEO Sid Sijbrandij connected the funding directly to the company’s delivery track record since its Series C:

“Since raising a Series C round last year, we’ve delivered on our commitment to bring a single application for the entire DevOps lifecycle to market, and as a result have been able to reach over $1 billion in valuation. With this latest funding round, we will continue to build out our management, planning, packaging, deployment, configuration, monitoring and security features for a more robust DevOps application.”

Sid Sijbrandij, CEO, GitLab

What This Means for DevOps Teams

For engineering and platform teams evaluating their toolchain strategy, GitLab’s trajectory at this point signalled a credible consolidation option. Rather than maintaining complex integrations between a dozen vendor products, organisations could begin adopting GitLab as a progressive replacement — starting with source control and CI/CD, then expanding into security scanning, monitoring, and release management over time.

The unicorn valuation and blue-chip investor backing also provided a degree of enterprise confidence that the platform would continue to mature and receive long-term support — an important consideration when consolidating critical delivery infrastructure onto a single vendor.