Alessandro Franceschi: Interview with the Author of “Extending Puppet”

Alessandro Franceschi is a freelance consultant and longtime Puppet user, active in many Puppet-related projects. He has just published Extending Puppet with Packt Publishing. Nigel Kersten, CIO at Puppet Labs, interviewed Alessandro about the experience of writing his book.

Nigel: For our readers, tell me a bit about yourself and your history with Puppet.

Alessandro: I'm a seriously addicted computer freak. I started with a Commodore 64 more than 30 years ago (tempus fugit), and since then I don't think I've passed more than a week without touching a keyboard.

After I graduated in Natural Sciences, in 1995, I opened a local internet service provider, then, some years later, I decided to become a freelance consultant. I've always preferred to work on what I like, rather that what is financially more rewarding, and I definitely prefer technical activities rather than managerial ones.

While working as system administrator in Banca d'Italia in 2007, a colleague (thanks Francesco!) proposed a tool that could help us in managing the multitude of our systems.

It was Puppet, of course, and it was love at first sight.

Just like every system administrator, I liked to automate activities, but Puppet was really bringing automation to the next level.

Since then, I have never considered the option of managing any system in a different way, it was so clear that such a tool had to change operations forever. And it did.

Nigel: What’s the goal with this book? Who is it aimed at?

Alessandro: I like to think that “Extending Puppet” is the book I'd have liked to read but nobody had ever written, so I wrote it myself. Boastings aside, I've tried to pour into its pages all the knowledge and experience I've gathered about Puppet over the years, trying to add information that is not easy to find in the available documentation and books (most of the existing ones are of great quality), or to present it in a different way.

It's not a book for absolute beginners; its ideal target is a more or less experienced Puppet user. One feedback I received about it was from a Puppet trainer who really appreciated the contents. This made me particularly proud of the result.

Nigel: One of the things I really loved about this book was how pragmatic it was. You’ll introduce a concept like run stages, and not only talk about how they’re meant to be used, but also be completely honest about the fact that there are limitations. Can you talk about how you tread that line between useful advice and not scaring off your readers? Were there any choices like this that were especially difficult?

Alessandro: To be honest these weren't difficult choices — once you decide that your main purpose is to provide useful information for real-world scenarios, the rest comes by itself. I did have some difficulties in trying to separate what were my own opinions on how to do things with Puppet from common and accepted patterns and best practices. I tried to keep it clear when I was expressing personal opinions, but that's not always easy. The extreme flexibility that Puppet offers is prone to all kinds of use, and abuse, and in some cases it's not clear what's the right way to do things.

The real best practice is what works best for you and your infrastructure, so one of my intentions has been also to show the available and more common alternatives, in order to give readers the choice of what best fits their needs.

Nigel: I often find that, no matter how expert I feel on a technical topic, when I’m writing or presenting on it, the act of writing forces me to fill in some gaps in my own knowledge or mental model of how something works. Did you find that with this book, Alessandro? If so, what were those gaps?

Alessandro: Definitively. I've learnt a lot of things about Puppet while writing this book. In some sections, like the one about Puppet's internals, the help of Brice Figureau, who was one of the book's technical reviewers, was crucial. Without his support, that whole part would have been largely incorrect, or plain wrong. For other topics, like the one about how to use Puppet to manage network devices, I had no direct experience and no possibility to test any code, so I studied the available documentation (in some cases really scarce) and tried to summarize the most important concepts and guess the possible usage patterns.

The last chapter, about the future of Puppet, involved long reading sessions on Henrik Lindberg's blog, other online resources and direct queries in order to understand the direction you guys are taking.

Nigel: You’ve got a great historical perspective on the evolution of Puppet and the surrounding ecosystem. Were there any parts of the book where you realized just how far we’ve come and how much we’ve accomplished since the early days?

Alessandro: Puppet is expanding its horizons; that's clear and inevitable. We are no longer talking only about the automation of the setup of a system's resources — we are talking about the automation of entire infrastructures, which are more and more fluid, complex, and elastic. We started from a catalog of resources to apply to a single system and we are finding ourselves dealing with interconnected services, whose configuration has to adapt according to the infrastructure topology, and with the whole paraphernalia that defines a data center, be that physical or virtual: network devices, storage devices and virtualization layers.

We have seen great products being developed, like PuppetDB, and we are seeing how Puppet Labs is collaborating closely with the vendors that provide the equipment and the solutions that are used in current IT infrastructures.

When I hear more or less marketing-oriented terms like “software-defined data center” or “infrastructure as data,” I can clearly see how Puppet can fit in the whole picture and play its role.

I think that PuppetDB, also thanks to Erik Dalen’s puppetdbquery module, can play a huge role in how we’ll write modules that are infrastructure-aware. The future parser and the new type system will encourage more and more the definition of our infrastructures with pure data, which can be manipulated and used in more powerful ways.

Nigel: Conversely, did writing any parts of the book make future challenges that we need to address more obvious?

Alessandro: You know, one of the great things of the Puppet ecosystem is its community: Luke, at the beginning, and then your whole company, have cultivated it and have grown with it.

One of the approaches that has been followed over the years concerning the solutions and methods for solving problems has been somehow based on Darwinian principles: Let's leave people full freedom on how to implement solutions, and the best ones will emerge and prosper, eventually being integrated or supported in Puppet. It worked with Hiera and with some design patterns, but in my opinion it hasn't worked as well with modules. Or, more precisely, it hasn't worked well with modules' interoperability.

We have many good modules around now, and we can consider them fitting for different use cases, but often it is a real mess to make modules from different authors work together. This often forces many people to make local fixes and forks, fragmenting the module ecosystem even more.

Also, I think that the distinction between component application modules and higher abstraction modules should be more clear. Component application modules, IMHO, should be considered as libraries that offer interfaces to the management of the relevant application in the most neutral and reusable way. Higher abstraction modules can be more opinionated and use different component modules to provide a full application stack, deployed on one or more different nodes.

So, for what is related to modules, I think that better interoperability and more coherency are challenges that are still open, as is whatever is related to higher abstraction modules, which up to now have not been really developed with reusability principles.

Also, more generally, I think that Puppet still lacks a solid and official way to manage interdependencies among resources on different nodes and triggers that make Puppet run on demand on related nodes.

We can achieve these things with some tweaks, like custom reports, custom facts or queries to PuppetDB, but I feel this should be something that Puppet can implement in a more integrated and better way.

Finally, a part where there have been great improvements, but which always needs work, is performance. Puppet agent runs should run as quickly as possible, starting from catalog’s compilation to how quickly resources are applied to the system, and how the Puppet-generated data is reported and managed. These concerns are quite clear to Puppet developers, and I’m confident they know how to deal with them.

Nigel Kersten is CIO and vice president of operations at Puppet Labs.

##Learn More

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.