This article is based on a Q&A interview originally published by DevOps Online (devopsonline.co.uk) with Puppet in October 2019, covering Project Nebula and Puppet’s broader strategy for automation, compliance, and multi-cloud infrastructure.
Background: Puppet’s Mission to Automate the Grind
Puppet was founded in 2005 with a stated purpose: eliminate soul-crushing work from IT. More than a decade later, that mission still shapes the company’s product direction. With tens of thousands of organisations relying on Puppet to manage infrastructure configuration and software delivery, the company has continued to expand its scope—from server configuration management into multi-cloud orchestration, continuous compliance, and cloud-native deployment automation.
In late 2019, Puppet announced two significant developments: Project Nebula, a new platform for cloud-native continuous deployment, and a sharpened focus on continuous compliance, continuous deployment pipelines, and automated incident remediation.
What Is Project Nebula?
Project Nebula is Puppet’s answer to the fragmentation problem in cloud-native delivery pipelines. It provides a common workflow for DevOps teams to build, provision, and deploy cloud-native applications across dev, test, and production environments—with the goal of enabling rapid, low-risk deployments.
The core design principle is familiar to anyone who has used Puppet’s configuration management tools: declarative, reusable workflows that abstract away underlying complexity. Teams define what the end state should look like; Nebula handles the orchestration required to get there.
Why Puppet Built It
During an initial private beta, Puppet identified two recurring pain points that were blocking organisations from achieving true continuous deployment with cloud-native applications:
- Toolchain fragmentation: Teams lacked a single tool capable of automatically composing multiple cloud-native utilities—covering infrastructure provisioning, application deployment, and notifications—into a coherent, end-to-end deployment workflow.
- No shared platform for teams: Individual teams were building deployment workflows in isolation, with no consistent way to share those workflows or propagate best practices across the organisation.
Puppet’s response was to apply the same declarative principles that made configuration management automation tractable to the cloud-native continuous deployment problem. Teams already practising infrastructure as code can bring those same mental models—desired state, idempotency, reusable modules—into their Kubernetes and serverless workflows.
What Nebula Means for IT Teams in Practice
Project Nebula allows DevOps platform teams to create reusable workflow templates that application developers and infrastructure administrators can consume on demand. The intended outcome is a self-service delivery model where developers can spin up environments for dev, test, or production use cases without depending on specialist infrastructure knowledge every time.
For organisations still running traditional workloads alongside cloud-native services, Nebula is designed to sit alongside existing Puppet tooling rather than replace it—providing continuity as teams modernise incrementally.
The Real Challenges of Cloud-Native Adoption at Scale
Puppet’s perspective on cloud-native adoption is notably clear-eyed. While the promise of containers and serverless architectures is that they simplify operations, the company argues the opposite is true in production at scale.
Getting started with cloud-native technologies is relatively straightforward. Scaling those technologies across multiple teams, while maintaining security and compliance, is where organisations consistently run into trouble. The reasons include:
- Steep learning curves: New workflows and toolchains require significant re-skilling, and mistakes are costly in production.
- Misplaced expectations: There is a common misconception that cloud-native architectures eliminate the need for dedicated infrastructure and operations expertise. In reality, responsibilities such as security patching, compliance reporting, credential rotation, and monitoring configuration do not disappear—they simply need to be automated.
- Operational complexity at scale: Multi-cloud and hybrid environments introduce more moving parts, not fewer. Organisations that underinvest in infrastructure engineering early tend to encounter compounding reliability and security problems as workloads grow.
Puppet’s recommended response is to invest deliberately in infrastructure developers—engineers who specialise in building and managing the automation layer that supports everything else—and to treat automation as a first-class requirement rather than a future optimisation.
Continuous Compliance: Moving Beyond Point-in-Time Audits
Compliance is one area where Puppet sees significant room for automation to eliminate manual, repetitive work. The company’s vision for continuous compliance involves embedding policy checks throughout the delivery pipeline rather than treating compliance as an end-of-cycle gate.
A mature continuous compliance pipeline, as described by Puppet, would work as follows:
- Source code scanning: Static analysis and policy checks at the point of code commit, catching compliance violations before they reach a running environment.
- Pipeline integration: A continuous verification step integrated into the test and deployment phases, validating infrastructure and application configuration against defined compliance policies (for example, PCI DSS controls for payment card environments).
- Runtime scanning: Ongoing scanning of running applications and infrastructure to detect drift or new violations.
- Automated remediation: When a violation is detected in a running environment, the pipeline automatically triggers a new deployment that incorporates the required fixes, returning the environment to a known-good compliant state without manual intervention.
Achieving this level of automation also requires organisational change. Teams need to redesign processes around automated compliance verification and develop sufficient confidence in their policy-as-code definitions to reduce—or in some cases eliminate—manual pre-deployment approval gates.
Puppet’s Broader Modernisation Strategy
Puppet positions infrastructure automation as the foundation on which application modernisation depends. The company’s argument is straightforward: if your infrastructure cannot be placed reliably into a known, desired state on demand, everything built on top of it becomes harder to deliver, secure, and scale.
The company’s strategy for helping organisations modernise has two layers:
- Infrastructure abstraction: Giving teams tools to describe desired infrastructure state declaratively, making applications more portable and infrastructure more auditable—regardless of whether workloads run on bare metal, virtual machines, or cloud-native platforms.
- Multi-cloud continuity: Allowing teams to reuse workflows, content, and automation logic across traditional and cloud-native environments, so organisations are not forced to start from scratch as they migrate workloads or adopt new platforms.
Project Nebula is the most visible expression of this strategy in the cloud-native space, applying concepts that Puppet refined in server configuration management to Kubernetes-based and serverless deployment workflows.
Key Takeaways for DevOps Teams
- Cloud-native adoption does not reduce operational complexity—it shifts and redistributes it. Plan your team structure and tooling accordingly.
- Declarative, infrastructure-as-code principles that work for server configuration can be extended to cloud-native deployment pipelines. Nebula is Puppet’s implementation of that idea.
- Continuous compliance requires embedding policy checks at every stage of the pipeline, not just at release time. Automated remediation closes the loop without manual intervention.
- Automation is no longer optional in multi-cloud environments. Organisations that treat it as a future nice-to-have will encounter security and reliability problems at scale.
- Self-service delivery models depend on reusable, well-documented workflow templates that platform teams build and maintain for the broader organisation.
Original interview source: DevOps Online (devopsonline.co.uk), October 2019.