Published on 8 August 2018 by

In this final part of the blog series we are going to review some of the more abstract ideas that exist around DevOps and how they relate to Puppet. This final blog post will make more sense if you have read part 1 which covers some of the preparation and part 2 which covers topics during the evaluation.

Things to keep in mind

Automation is a spectrum

Model-driven automation helps you achieve both scale and complexity while still giving you a simple, composable and human readable way to describe your infrastructure. With Puppet’s platform you are able to access multiple aspects of automation right out of the box, such as job orchestration, reporting, and simulations. By default, Puppet is able to simulate runs, compare resources to make sure different teams are not managing the same resource different ways, conduct orchestration jobs, run ad hoc task execution, and provide robust reporting and dashboards. You can test, simulate, and enforce differences and similarities across disparate systems with a simple declarative statement. For example “user {‘sam’: ensure => present,}” tells you if a user named Sam exists, logs the state of this resource every time Puppet runs, creates the user if it does not exist, and notifies you if any other part of your code is also trying to manage a user named Sam — all by default.

Aside from model-driven automation, you also need a way to execute ad hoc tasks, such as stopping a service temporarily, or running a database schema upgrade script. Ansible is a common tool for running ad hoc tasks. With Puppet Bolt now available, you can take advantage of simple task execution and model-driven management with a single tool which allows you to run scripts in any language using SSH or WinRM. Running that script on a set of nodes means you've automated your job, right? Sort of. You’ve just entered the spectrum of automation. You have automated a task, making future runs of that specific task easier and repeatable. But what about the feedback, testing, or maintenance required once that configuration is in place? How do you make those critical pieces continuous? These higher orders of automation automate the feedback loop and tell you how the task relates to the rest of the system. These additional capabilities add scale and feedback that allow an organization to quickly consume, optimize, and expand their automation — thus expanding their spectrum of automation.

Takeaway: The Puppet approach of automation allows to you define the end state, and uses that model for both enforcement, testing, and validation — giving you a spectrum of automation with the tooling for feedback, testing, and scale all in one platform and out of the box. This is what we call the shift to pervasive automation.


Culture is complex in every organization. To succeed with a platform like Puppet Enterprise and realize the benefits described in the State of the DevOps Report, change is required across people, processes, and technology.

Recognizing that adopting automation will drive changes to more than just the software stack is critical to building a business case and helping team members overcome the fear, uncertainty, and doubt that change often brings. This blog post will help you identify some of the changes you can expect. Teaming up with or involving other staff from different departments can be an excellent way to get a more holistic view of the DevOps approach and how it can benefit your organization. Involving others in a cross-functional team not only provides an internal model for the rest of the company, but also gets you halfway to “doing the DevOps.”

Takeaway: Recognize where your organization might need changes during this time. Make note of who these changes will affect so you can start conversations with them.

Workflows and toolchains

DevOps is not a single product, piece of software, or just rebranding of existing titles. There are different pieces that, when planned and implemented correctly, truly become more than the sum of their parts. Part of this is why I suggest evaluating Puppet Enterprise with Code Manager connected to a version control server — so when you do want to connect CI/CD tools like Puppet Pipelines or use Puppet’s Jenkins Integration it will be a small step. This can be more difficult for smaller organizations, where you may be trying to minimize the number of software installs or tools you use, and thus see this as more work. The work and investment to set up the evaluation correctly and understand where future integrations can be implemented is well worth the time. The view from the top of the mountain is always worth the effort.

Takeaway: You have a toolchain now; every company does. How automated is that toolchain? How can Puppet ease that pain and what is the effort involved to restructure how you're currently doing things? An evaluation is a great time to re-evaluate not just a solution, but your existing processes and toolchain.


While you might think integrations would fall under the technical aspects, I want to take a non-technical perspective for a minute. Know which integrations are important, how those integrations should work for your organization, and evaluate them once you have a basic familiarity and trust with the Puppet platform. In some cases, handoffs between applications may work better than native integrations. For example, using Terraform to provision resources and an OS, then using Puppet to configure and maintain it over time might be the right workflow for you.

It may be easier to see a demo or example of an integration, such as our VMware vRA integration, to satisfy an early requirement. For example, if a customer requires hands-on evaluations of our VMware vRA integration, we would need access to a non-production instance of vRA, which could be a significant amount of work to stand up. If seeing the integration in action in a lab is enough, that time and effort could be better spent on professional services or training classes. Over the years, I have been involved with many projects where someone in charge said, “We need to see software X and Y work together on our equipment before proceeding.” Occasionally this can make evaluations take months because we had to set up additional infrastructure. In my experience, companies are more similar than they are different and what works for one will generally work for most.

Takeaway: Sometimes demoing or test driving an existing implementation of an integration is enough in the beginning. Knowing how you require the tools to integrate is important while evaluating.


To wrap up I wanted to repeat the TL;DR that I wrote in the first post, as you may have some different perspective now. Thanks for reading and please comment if you have some input or experience. I hope this helps you undertake an evaluation of Puppet Enterprise, and hopefully saves you time and frustration!


  1. When evaluating solutions, consider your future growth and future use cases. You may only need some capabilities of the platform today, but down the road you will likely have a whole new set of challenges — and bending a tool to do things it wasn’t meant to do often leads to extra work, downtime, and frustration. You want a solution that allows you to start small and can scale with you.
  2. Often the errors and frustrations I encounter are not errors with Puppet, but with not starting with a clear understanding of how the existing systems we are working on — networking, firewalls, non-default Linux images, etc. — are configured. Using sandboxes or labs to evaluate Puppet provides a clean slate, which will minimize configuration-related issues so you can get down to business. It is very easy to take network, DNS, and firewall configurations for granted.
  3. Start simple. Want to automate that important new app? You will get there. Start by automating things you are familiar with, such as the prerequisites for your existing software or dev/test/qa/prod baselines, and build from there. The formula for success that we see with our customers is to start small, show success, automate more.
  4. Pervasive automation is the future. Changes in culture, process, and technology are key to making this shift. Change doesn’t happen overnight, and it shouldn’t. Just be open to it in various forms.

Mike Smith is a sales engineer at Puppet.

Share via:
Posted in:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.