This article is based on reporting originally published by The Register from Puppetize PDX 2019 in Portland, Oregon.
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.