5 Myths about Puppet
As a Puppet educator, I want to share with you some of the myths about Puppet that I encounter when I’m teaching classes, reading Reddit posts or even trying to explain my job to people who are in software but don’t entirely understand what I do.
I also want to share one that I personally subscribed to until a couple of weeks ago, despite working at Puppet for almost two years. It’s the bonus myth at the end of the article, if you’re curious.
Myth No. 1: I Need to Know Ruby to Use Puppet.
You don’t! The Puppet language is its own full-featured programming language.
Most of the Puppet code that you will write will be in the form of descriptive blocks of attributes that say what state a given service or user or other resource should be in. These descriptive blocks are easy to read, with statements like ensure => installed. Your infrastructure code can and should serve as its own documentation.
What’s more, Puppet supports running tasks written in any scripting language that the target node supports with an interpreter. You can use the classics like Bash and PowerShell, or Ruby, Python, JavaScript and even good old Perl.
Myth No. 2: Puppet Is too Complicated.
Puppet is only as complex as you need it to be. If you only need a little bit of infrastructure management, your Puppet code doesn’t need to be very complex at all.
Most infrastructure will be handled by the descriptive blocks of Puppet code mentioned above. This usually comprises most of your Puppet codebase. In some cases, Puppet users will want to become full practitioners so that they can take greater control of their infrastructure management.
Puppet users who want to become advanced practitioners will find everything they expect from a full-featured programming language. Puppet language features include the usual conditionals, case statements and ternary operators, but also features like file templating, strong static typing for variables and secure data abstraction with Hiera to keep your configurations both adaptable and private.
Only write code for what you care about and let Puppet handle the rest.
Myth No. 3: Puppet Is Only for On-Premises Applications.
This is one of the most pervasive misconceptions about Puppet, especially Puppet Enterprise.
Puppet is a tool for infrastructure automation and compliance enforcement. That means Puppet not only gets your infrastructure up and running, it also enforces compliance over time. That means easier configuration, improved uptime and an infrastructure that knows how to correct misconfigurations.
Although Puppet works well for maintaining on-premises infrastructure, it can be used anywhere you care about maintaining compliance and improving uptime, even in the cloud.
Much of our cloud infrastructure today is ephemeral — if a server starts acting funny, you can just delete it and replace it. But just think about how many mission-critical servers and services you just can’t do without: load balancers to route customers to the appropriate service instance; data storage solutions like databases, key stores and file hosts; firewall and network address translation (NAT) routing servers; build servers that not only test and deploy your code, but also automate so many tasks it’s easy to lose count; and even the machines that run fleets of containers, like Kubernetes or Docker Swarm hosts.
Puppet manages any piece of infrastructure that you just can’t do without.
Myth No. 4: The Codebases Are too Unwieldy to Maintain.
They don’t have to be.
Puppet Education teaches you how to use the Roles and Profiles design pattern to keep your codebase modular, extensible and maintainable over time. It’s an easy framework to learn with just a little practice.
Roles handle abstract business functions and load up profiles. Profiles handle direct technological implementation and configuration.
With this design pattern, you can maintain the role of a given node while easily swapping out the technological stack that provides the services. This makes it easy for you to grow and change your infrastructure to keep pace with your ever-evolving business needs.
Myth No. 5: Puppet Is Expensive.
For starters, Open Source Puppet (OSP), the language and agent combination which powers Puppet Enterprise (PE), is free. That’s free both as in libre (free to use and modify) and gratis (free samples, take one).
Many Puppet Enterprise subscribers start out building their infrastructure with OSP, and then move up to Puppet Enterprise as their needs change. Puppet Enterprise adds a lot of preconfigured infrastructure automation and a central server to maintain it from. This includes the ability to automate more complex workflows, identify drift, and even generate a value report right from the dashboard so that you can tell your leadership team exactly how much time and money you’ve saved by automating your infrastructure management.
A paid Puppet Enterprise license also gives you access to educational resources like live and on-demand classes, plus 24/7 access to enterprise-level technical support. No more Googling for “How do I configure ______ in Puppet?”
Bonus: Puppet Is Only for Large Infrastructures.
As it turns out, Puppet can be used for both large- and small-scale deployments.
It is true that many Puppet adopters start small by only managing a few services and a small number of nodes with Open Source Puppet, and then move on to Puppet Enterprise as their installation increases in either scale or complexity. However, with built-in services to monitor and manage infrastructure of any size, you can tailor Puppet Enterprise to your needs and scale it up whenever you like.
Maybe you only want to manage a few mission-critical pieces of infrastructure — say, a build server, a load balancer, a production database and a dedicated database and server for your testing and staging environments. You can do it with Puppet!
If you’ve ever been curious about Puppet and want more information, Puppet Education now offers free, on-demand introductory classes — three full days of educational instruction that take you from conceptual introduction to hands-on lessons and deploying your own code. Learn more here.
