This week I took on the role of CTO at Puppet Labs, and started reflecting on the awesome journey that led me here.

It was 2006, and I was scrambling to make it onto the last bus back to San Francisco from the Apple WWDC Beer Bash down in Cupertino. I’d been to quite a few Beer Bashes and knew the drill: forget the lineup for the campus store, just concentrate on finding beer and the few Apple employees who could fix the OpenDirectory bugs that were making my life hell. Both objectives were completed, leaving me only minutes to avoid having to spend way too much money getting a taxi back up to the city.

Fatefully, I found a seat next to this intensely opinionated sysadmin, Jeff McCune (later to become one of the first pro services guys at Puppet Labs, and now one of our core developers). He recognized me from my WWDC presentation that year and started grilling me about how I ran my university campus, particularly the file-based configuration management system I used, Radmind, and the hacked up framework I’d put in place to try to manage higher level objects than mere files.

He’d been to a talk by Luke Kanies (now the CEO of Puppet Labs) at LISA and was very excited about this guy who had built a tool that worked the way sysadmins actually needed to work with a pragmatic, model-based approach. Even more importantly though, Luke was serious about fostering adoption, and had helped Jeff write some useful extensions for Puppet. Jeff had already gotten religion about idempotent, declarative approaches for sysadmins, and spent pretty much all of the bus ride bending my ear about this new project called “Puppet” and how it was going to change the world of operations.

After WWDC, I flew back to Australia, fully intending to try out this magical Puppet project, but got distracted by the day to day life of running campus IT operations on a shoestring budget for users who were academics and artists.

I was even more distracted a few months later when one of the MacEnterprise community members came out of lurking and told me I should apply for a role at Google in Mountain View. Several of the toughest interviews of my life followed, and within a couple of months, I was moving my young family to the other side of the world to run Mac Operations at Google HQ.

It was clear that tools like Radmind simply weren’t going to work at Google for the many thousands of corporate Macs. Opinionated engineers who demanded a high degree of customization, immense growth, globally distributed offices and a very small team meant that it was completely insane to even think about trying the old methods of file-based config management of the entire system.

We needed a better and more sustainable way, a solution that gave us higher levels of abstraction with meaningful entities such as users, groups, services and packages, and that didn’t require you manage the entire machine.

Jeff and I had kept in contact, and he was presenting on Puppet at WWDC that year. I popped up to San Francisco with some of my coworkers, and made sure we turned up to his talk.

10 minutes into his presentation we were getting pretty excited, and we started experimenting over VPN. By the time Jeff finished his talk, we had a working Puppet master back at Google managing the contents and permissions of a few critical files in /etc, and knew we had a great match.

As it turned out, the Mac deployment was such a rapid success that one of the Linux Ops team started a skunkworks project to manage the internal Linux distro with Puppet, as there had been a few failed CFEngine attempts. This worked so well that Puppet eventually managed all the Google corporate Mac and Linux desktops, laptops and servers.

Puppet was a much younger project in those days. We were building a lot of custom Puppet extensions for Mac OS X that went back into the core, and were having to scale Puppet to manage tens of thousands of nodes, so I spent a lot of time on the mailing lists and IRC channels brainstorming with Luke and the community. I quickly fell in love with the community. It was full of thoughtful sysadmins, people who were frustrated with the unreliable state of operations tools, and knew there was a better way out there than continually reinventing arcane bash/ssh frameworks.

We have some great technology with Puppet, but one of our greatest strengths is our outstanding community.

I ended up at the first ever Puppet Camp, San Francisco, 2009. It was small, but was one of the most exhilarating conferences I’ve ever been to. I love looking back at those photos and seeing how many of that group are now part of the Puppet Labs team. Dan Bode, James Turnbull, Ben Hughes, Gary Larizza, Michael Stahnke, Carl Caum, Deepak Giridharagopal (Little known fact: his last name is actually Tamil for “Grid Computing”).

That’s an awesome group of people to end up working with, let alone all the other great people we have here at Puppet Labs.

I had an amazing couple of years at Google, surrounded by super sharp minds and working on truly interesting operations problems at a scale greater than anything I’d ever touched before, but I was starting to look enviously at friends who left for early stage startups and the breadth of knowledge they were acquiring. Luke had poked me a couple of times about coming to work for him, but I didn’t seriously consider it until late 2010 when he, Teyo and James made a much more concerted effort.

“You’re opinionated about Puppet. Want to put your money where your mouth is?”

One visit to Portland and I knew I wanted to live in this awesome food, beer, and cycling-obsessed city full of people following obscure passions. I jumped ship from Google and we moved north, where I dived headfirst into being responsible for Product at a very quickly growing startup.

It’s been an immense 18 months. We started with our first commercial release, Puppet Enterprise 1.0, and followed that up with several great releases, all solving real problems for real users. We’ve brought on the open source MCollective and Hiera projects from the incomparable RI Pienaar, released Puppet 2.7.0, and grown at an amazing pace. We’ve grown from 2 events a year to 15, including the incredibly successful PuppetConf `11 and are building up to an even bigger PuppetConf this year. Nothing like startup speed to quicken the blood.

From the original 20 odd folks I started with in the tiny office in the seedy and urine-drenched Old Town to our shiny digs in the Pearl, with over 80 employees. From a distinct lack of in-house beverages to decent espresso and delicious local beer. From a company that knew the user experience was critical, to one with a growing UX/Design department headed up by Randall of the impenetrable Gandalf gaze.

I love this company. I love what we’ve done already to change the face of operations, I love the ambition we have to change it even more, and I especially love the people I get to do it with.

I’m thrilled to take on the role of CTO, and to concentrate on fostering our culture of technical innovation so that we continue to build applications and platforms that truly advance the state of IT infrastructure. The world of operations is undergoing radical change right now. The cloud, pervasive virtualization, corporate adoption of FOSS, BYOD, IaaS, PaaS and SaaS are all forcing sysadmins to be truly agile and adaptive. Some of the brightest people in our industry work in operations, and it’s going to be incredible to see what they come up with when IT automation gives them space to concentrate on genuinely important matters.

Puppet Labs has been on a roll…and this time it is not our user community, but the physical one we live in that is giving rave reviews! The City of Portland’s Sustainability at Work Program recently announced Puppet Labs as a Gold Certification winner!

It all began with the culture here…they care about their community and take immense pride in doing their bit for the environment. Most of the Puppet Labs employees (80% to be precise) come to work on bikes, public transport, or on foot. They even have an in-house bike rack in their dining/meeting area!

The company is housed in a LEED Gold building, and the employees adopt energy efficient measures in their daily lives. “Daily life” includes bringing dogs to work, eating cupcakes and drinking from the kegorator at weekly meetings, and recycling most of what they throw into the bins. Even the copious coffee habit comes with a green benefit, with buckets of grounds being saved for employees’ gardens. In keeping with the relaxed yet results-driven work environment, I saw people coming up with ways to make the company greener—not because they were looking for an award, but because caring about the environment comes naturally to them.

I should introduce myself: I’m an MBA student from the University of Oregon, and I helped document all the environmentally friendly activities going on at Puppet Labs. I reported the activities to Sustainability at Work in the areas of Energy (e.g. the T8 lighting, the energy star equipment), Water (e.g. we have tap water not bottled water, we have water-saving faucets), Materials and Waste (we do cardboard, glass recycling, we avoid printing out documents) and Transportation. Beyond activities in these four areas, there’s also an internal portal with postings about various volunteering opportunities, sustainable transportation options, green living etc. Once I gathered all the information, we used the Sustainability at Work calculator to report our work to City of Portland. There was another round of reporting where we filled in another checklist of actions. The final round had a City of Portland expert come over for an on-site verification process. Finally, Puppet Labs received the highest possible certification, GOLD!

Puppet Labs is one of the 7 businesses in Portland to be gold certified, and the only software company. This certification holds good for the next three years. The City of Portland’s website has already featured Puppet Labs as a Gold Winner. Mayor Sam Adams (those of you who visited Portland for PuppetConf last year may remember him speaking) had the following statement:

“Congratulations to Puppet Labs, Inc. on becoming Sustainability at Work Gold Certified. We appreciate Puppet Labs, Inc.’s leadership in taking concrete actions to make Portland a better place to live and work. We hope that Puppet Labs, Inc.’s achievement inspires other businesses to make innovative changes that improve profitability and sustainability.”

This is a great achievement for Puppet Labs, and we feel proud to be recognized as a responsible environmental and community steward.

I’m proud to announce the release of Puppet Enterprise 2.5, downloadable right now and free to use on up to 10 nodes.

Just over a year ago, in February of 2011, Puppet Labs released our first commercial product, Puppet Enterprise. We were about 25 people at the time, and our revenue up until then consisted of training, services, and support for our open source Puppet project. That release taught us a lot, and it was our first major step in moving us to a product company.

In the intervening year, a lot has happened. We’ve put out a minor (1.2) and major (2.0) release of Puppet Enterprise and announced another round of funding, led by Kleiner Perkins and including new investors VMware, Google Ventures, and Cisco. Along with others, we’ve continued to push DevOps and its transformation of IT operations from a cost center to a source of competitive advantage. In addition, we’ve grown from 25 to 75 people. It’s been a crazy year, but it’s been a great year.

It looks like this quarter is going to be a pivotal turning point at Puppet Labs, so I’m proud to have a release close the quarter for us. As of this morning, you can download Puppet Enterprise 2.5, an update to our major release last fall with some great new capabilities.

The first major new capability is support for Windows. With this addition, Puppet Enterprise and Puppet provide the widest platform support of any IT automation product. We have commercial support for the major Linuxes like RHEL, SuSE, and Debian, plus Solaris, and now Windows, and Puppet runs great on OS X, FreeBSD, AIX, HP-UX, and basically every Linux distribution, such as Gentoo and Arch.

The big benefit to this support is that system administrators can now use a single configuration language and platform across their entire infrastructure. With our support for Cisco and F5 devices, you can even get to the network layer for some problems. You can also build Puppet configuration modules that will work identically across both Linux and Windows machines.

Speaking of modules, the next major update is that Puppet Enterprise 2.5 includes completely revamped support for the Puppet Forge, our online configuration module marketplace. The Puppet Module Tool (PMT) user interface has been thoroughly redone, and it now also has support for dependencies. Just by installing PE you can find, download, install, and manage configuration modules from the Puppet Forge.

They have a saying in science that a couple of months in the laboratory can often save a couple of hours in the library, and this support should hopefully push people to spend a couple of hours on the Puppet Forge to save months of individual development. And with over 300 freely downloadable configurations spanning everything from MySQL and Apache to Hadoop and OpenStack, Puppet Forge has something for everyone. This dramatically shortens the amount of time you need to really solve an automation or deployment problem. In addition, you benefit from community-driven best practices, with all that shared code out there, rather than having to just rely on what standards you’ve developed internally.

Look for much more development on the Puppet Forge this year, and this is a great first step to demonstrating how we’ll be investing in it. We’re especially proud of the amount of design effort that went into PMT’s new interface. As I said at PuppetConf in 2011, we’ve become a design-driven company, and this new work is starting to show how that shift will affect the non-GUI aspects of our products.

The next Puppet Enterprise 2.5 capability is not all that large, but is very important. Puppet Enterprise is now shipping with role-based access control (RBAC). This has been asked for by nearly all of our customers, and we had to spend a lot of time simplifying and consolidating our GUI platform in order to make it possible. There is still a lot of work to do simplifying Puppet’s whole security model, and the RBAC we’ve shipped is about as simple as we could make it, but you’ll find this to be very easy to use and, frankly, a bit attractive.

The last major piece of Puppet Enterprise 2.5 is built to take a lot of the capabilities and benefits of big data and allow our users to apply it to their infrastructure. And Puppet itself is a big source of data, producing for some customers more than 750 GB of information every day about status and change in their infrastructure. All this data can be great sources of additional insight and further automation.

We’ve wrapped everything in Puppet that has to do with data into what we’re calling the Puppet Data Library (PDL). This includes all of the data types in Puppet: The software and hardware inventory data, which tells you every host you’re managing and every package, service, user, or whatever that you’re managing on them; the run reports, whether enforcement mode where you’re actually changing machines or simulation mode where you’re just seeing what a configuration would do without modifying the system at all; and the configuration graph, which includes all of the software inventory, plus all of the dependencies between them.

In addition to the data types themselves, the PDL includes completely open formats. These are primarily JSON, with some YAML, and the configuration graph can easily be converted to ‘dot’ format that is readable by graph applications like OmniGraffle, GraphViz, and Visio. This allows you to inspect your configurations, confirm they are built as you expected, and make simple optimizations that without this visualization might be impossible.

Beyond the data and formats, the Puppet Data Library includes our open RESTful APIs. These are the exact same APIs that we build our own applications on, so we’re confident they’re sufficient to build great applications.

The PDL’s combination of open data, open formats, and open APIs is very powerful. Our users are already doing interesting things with it, like building automated reports that take serial numbers from the hardware inventory and query the hardware vendor’s API to determine whether any warranties have run out. We’re also building all of our commercial applications on the PDL; the best example is Puppet Enterprise’s compliance application, which we shipped in Puppet Enterprise 1.2. It uses standard types and interfaces from the PDL, and builds a new workflow and interface with a focus on auditing rather than on management.

While Puppet Enterprise 2.5 is a minor release, it’s a very big release for us, and it’s one we’re very proud of. It also does a great job of laying the groundwork for our upcoming releases. You should be able to almost predict our direction based on where we’ve spent time here, and we hope you’re pleased with the effort.

- Luke

Learn More

• Download Puppet Enterprise 2.5 – it’s free for use up to 10 nodes
• Sign-up for a Puppet Enterprise 2.5 LIVE technical webinar & demo
• Join our Puppet Enterprise 2.5 LIVE technical Q&A on Twitter #puppetize on Wednesday, April 4th, 11am PT
• Check-out the Puppet Enterprise 2.5 docs

This week we’re going to cover the puppetlabs/stdlib module. This module is packed with lots of Puppet goodness, including custom Puppet functions for validating manifest data, a resource type for managing individual lines in files, extensions to facter, and more. Clearly, this is one bad-ass Puppet module!

Since the puppetlabs/stdlib module has so much utility, it’s required by many of the modules built by the crew here at Puppet Labs. My goal this week is to show you how to harness these features in your own modules. To ensure we cover this module properly we’re going to break the coverage into four posts.

We’ll kick things off with the file_line resource which allows you to manage individual lines in a file. This is really great when you’re not in position to manage the entire file. You can use file_line as many times as you like, but be sure to give each resource a unique name. Don’t get carried away—this is not a replacement for managing an entire file with the proper file resource and the optional template.

In Part 2 we’ll cover the validation functions provided by the puppetlabs/stdlib module and how to validate input in your manifests.

In Part 3 we’ll cover the use of facts-dot-d and discover how we can get Facts from external sources and cache them in a central location so Facter can find them.

We’ll round out the mini-series in Part 4 with a look at the remaining functionality by exploring some data functions that allow you to do things like load external data from YAML files and merge parameter values.

Resource Overview – file_line

Installing the module

Installing the puppetlabs/stdlib module is as simple as using the puppet module tool (available as a rubygem on github; and coming soon in Puppet and Puppet Enterprise):

$ puppet config print modulepath
/etc/puppet/modules:/usr/share/puppet/modules
 
$ cd /etc/puppet/modules
$ puppet-module install puppetlabs/stdlib

You should now have a stdlib directory in your module path.

/etc/puppet/modules/stdlib

Testing the module

The puppetlabs/stdlib module comes with tests—let’s run them.

$ puppet apply tests/init.pp --noop
notice: Finished catalog run in 0.05 seconds
 
$ puppet apply tests/file_line.pp  --noop
notice: /Stage[main]//File[/tmp/dansfile]/ensure: current_value absent, should be present (noop)
err: /Stage[main]//File_line[dans_line]: Could not evaluate: No such file or directory - /tmp/dansfile
notice: Class[Main]: Would have triggered 'refresh' from 1 events
notice: Stage[main]: Would have triggered 'refresh' from 1 events
notice: Finished catalog run in 0.02 seconds

Hmm, that’s not telling me much. I need to run this test in normal mode to get the full effect. While running tests without --noop is normally a dangerous thing to do, this test only needs to create a file named dansfile under the /tmp directory—a change that won’t affect the state of my system. I’ll confirm this by looking at the code:

cat tests/file_line.pp
# This is a simple smoke test
# of the file_line resource type.
file { '/tmp/dansfile':
  ensure => present
}->
file_line { 'dans_line':
  line => 'dan is awesome',
  path => '/tmp/dansfile',
}

Looks good to me. Lets rerun the test, this time without the --noop flag:

$ puppet apply tests/file_line.pp
notice: /Stage[main]//File[/tmp/dansfile]/ensure: created
notice: /Stage[main]//File_line[dans_line]/ensure: created
notice: Finished catalog run in 0.02 seconds
 
$ cat /tmp/dansfile
dan is awesome

The test works as expected, and I can confirm that Dan is in fact awesome.

Since file_line is a resource type, there is really nothing to configure here. Once the stdlib module is available in your modulepath, file_line will be automatically distributed and usable as a resource on all of your nodes.

Example usage

When prepping for blog posts, I normally start with a fresh VM and, without fail, forget to add a host entry for my test Puppetmaster to /etc/hosts. This leads to my Puppet agent complaining that it cannot locate its master, reminding me of the obvious mistake. It’s an easy fix. I just add the following line to /etc/hosts:

172.16.240.200  master.dev.puppetlabs.com master

Problem solved! Until next week, that is.

Some of you may be thinking, “Hard code the line above and take a snapshot of the VM.” I will then pretend that I did not just hear you say that. I’ll then remind you that this is a blog about Puppet and there’s obviously a better way to solve this problem. Besides, that approach is less than optimal. I would have to repeat that process for each of my VMs and remember to keep them all updated if things were to change.

Lets put the file_line resource to use.

The current state of my /etc/hosts file looks like this:

cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	pmotw.puppetlabs.com	pmotw
 
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Notice the missing entry for master.dev.puppetlabs.com?

We’ll skip creating a whole manifests and declare our file_line resource on the node:

$ cat /etc/puppet/manifests/site.pp
node 'pmotw.puppetlabs.com' {
  file_line { 'puppet master host entry':
    ensure => present,
    line   => '172.16.240.200  master.dev.puppetlabs.com	 master',
    path   => '/etc/hosts',
  }
}

Apply the changes.

$ puppet agent -t
...
notice: /Stage[main]//Node[pmotw.puppetlabs.com]/File_line[puppet master host entry]/ensure: created
notice: Finished catalog run in 0.02 seconds
 
$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	pmotw.puppetlabs.com	pmotw
 
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.16.240.200 master.dev.puppetlabs.com master

It works, but what happens if I remove that line and rerun Puppet?

$ vim /etc/hosts
remove 172.16.240.200  master.dev.puppetlabs.com    master
 
$ puppet agent -t
...
notice: /Stage[main]//Node[pmotw.puppetlabs.com]/File_line[puppet master host entry]/ensure: created
notice: Finished catalog run in 0.02 seconds

Puppet does the right thing, and puts it back. The other nice thing about file_line, it continues to work even if I manually add new lines above or below the one being managed:

$ cat /etc/hosts
..
172.16.240.200  master.dev.puppetlabs.com	     master
172.16.240.100  someotherhost.puppetlabs.com  someotherhost
 
$ puppet agent -t
notice: Finished catalog run in 0.02 seconds
 
Notice: no changes are being reported.

Conclusion

We’ve only scratched the surface of the puppetlabs/stdlib module. Be sure to join us next week as we cover the validation functions provided by puppetlabs/stdlib which can help make your manifests more resilient to run-time failures by utilizing the ability to validate input; nothing like catching errors before hosing your systems!

Additional Resources:

• puppetlabs/stdlib module
• Puppet Forge
• Module Plugin Sync
• Module cheat sheet
• Previous Modules of the Week

I am very pleased to announce that R.I. Pienaar, founder and lead developer of the widely used Marionette Collective (MCollective) orchestration tools, has joined Puppet Labs as a Software Architect. R.I.’s message-based orchestration tools have become some of the most widely used tools in systems management, and have literally changed the way that people handle ad-hoc command and control, orchestration, and parallel job management. Having R.I. join the Puppet Labs team is a significant milestone for us, as R.I. will help shape product efforts in MCollective, Puppet, and Puppet Enterprise.

Puppet Labs acquired MCollective from R.I. in late 2010. Since then, MCollective has become a critical piece of the Puppet infrastructure with direct integration in Puppet Enterprise for Live Management, as well as standard orchestration functionality. R.I.’s efforts in this regard have had significant impact on product for the company including Puppet Enterprise 2.0.

R.I. will continue to work on MCollective (since MCollective is now directly integrated into our products), but will also work on some of our new projects to be announced in the future. We are very glad to have R.I.’s considerable creativity and industry experience on the team helping with new products that will give sysadmins new tools and delight Puppet users.

In R.I.’s own words:

I’m really excited to finally be part of the Puppet Labs team. I’ve been part time member for over a year and it’s great to finally be a full time team member. I look forward to the opportunities this new venture brings in helping me further the DevOps eco-system.

2011 has been an amazing year, although I always find it a bit awkward living through a prime year. In the startup world, just continuing to survive another year sometimes feels like an accomplishment, but we’ve done so much more than that. Puppet Enterprise has been the spine of 2011 for us, with a first release in February and the 2.0 release in November. We’ve managed to be both broad and deep, with PE running across the majority of server platforms and also providing a few new capabilities in 2.0 that support specific activities like compliance and reducing arbitrary infrastructure variation.

In some ways, the biggest change at Puppet Labs was the shift to being design focused. Our development process has been wrapped around a tight focus on you, our users, and we’re building our plans and stories around who we’re building products for and what problems we’re helping them with. To make sure it’s not just our designers and developers who think in design, everyone at the company was given a copy of The Design of Everyday Things.

Finally, there was the investment at the end of the year, which will be the foundation for our future in many ways. Look for interesting partnership activity with VMware, Cisco, and Google Ventures in 2012, and for our product to grow and develop with their input and customer knowledge.

As interesting and challenging as 2011 was, however, 2012 looks even better. As Greg Lemond said, it never gets easier, you just go faster. We aren’t resting on our laurels—we still wake up scared every day—but there is still far more to do than is already done. Gartner says less than 20% of companies use any kind of server automation, and someone has to help those people. This is especially the case as companies try to adopt new technologies like private clouds or bring in new culture with devops—can you imagine trying to replace traditional infrastructure with self-serve, on-demand provisioning but no server automation? Inconceivable.

Data is a major area we’ll be looking to help people in 2012. Companies have huge amounts of data trapped within their infrastructure and few ways to extract value out of it, and there is a direct relationship between the efficiency and agility of a company and its usage of this data. Companies like New Relic and Nodeable are building businesses around helping people extract meaning from their operations data, and Puppet is one of their critical data sources. It produces vast amounts of data as a natural off-shoot of the work you’re using it for anyway, and we’re working to help you get more value out of that data. We’ve got one customer whose Puppet infrastructure—that’s just Puppet, not the services maintained by Puppet — is producing 750GB of data a day. One one hand, it’s expensive to do much with that volume of data without a clear business driver, but on the other hand, it makes clear how much more you could know about what’s going on in your world.

We like to think of our efforts in this area as Big Data in the Infrastructure. Big Data projects are already a popular way for companies to start using Puppet, but here we’re talking about getting more from your Puppet data, not just managing Hadoop. Puppet already knows what you’re managing, what it’s related to, and how it’s changing, because it needs that to do its job. We’re working on giving you a clearer picture of all of this data, and some great levers and knobs on that data so you can take action based on this new-found information.

Outside of Puppet itself, I think 2012 will be an interesting year, too. We’re a bit isolated from it up here in Portland, but there’s an interesting tech/cloud bubble going on in Silicon Valley, and I’ve got a lot of friends who see a cloud winter on the way. Personally, I think we’re finally leaving the world of pure-hype clouds and 2012 is when real-world companies start figuring out how to invest practically in the cloud, and it’s also when the cloud vendors will start to separate. Hopefully we won’t see any more “Enabling the Cloud for Business!” banners, but I’m not getting my hopes up.

I think 2011 has been a critical year for devops. Almost no one I talked to had heard of it in 2010, but this year it seems to have taken over. I can think of three long-standing conferences that had a major focus on devops, and it has gained visibility up and down the organization. The only downside is there’s still a lot of disagreement on what it means and how people can take advantage of it, but great tech movements are powered by passion and vagueness, and devops looks to be the driver for innovation in operations in the next ten years or so.

Here’s looking forward to another scary, great, fast, tedious, invigorating, draining, and amazing year.

I’m thrilled to announce that VMware, Google Ventures, and Cisco have joined existing investors Kleiner Perkins Caufield & Byers, True Ventures, and Radar Partners in our $8.5 million Series C financing.  Gene Kim, author of VisibleOps and founder of Tripwire, has also invested.

It’s an exciting milestone for our company.  In 2005, after years of working with and on a range of IT management tools, I started Puppet Labs with the mission of building great tools for system administrators.  We wanted to build the best tools, but we also wanted to build tools that sysadmins actually enjoyed using, tools that were easy enough for anyone but powerful enough for everyone.

Great design was never considered a key feature in software for IT, but we stayed focused, and later that year we released the first open source version of Puppet.  Since then, together with growing numbers of community members and employees, we have built and refined Puppet such that tens of thousands of sysadmins in thousands of organizations around the world have come to rely on it to automate their IT operations.  Inspired by this adoption – and wanting to make these powerful tools even more accessible to all sysadmins – earlier this year we released our first commercial product, Puppet Enterprise, to a reception that’s exceeded even our own high expectations.

Demand > Supply

So why bother raising more money?  Simply put, the market demand for our products is outstripping our ability to satisfy it through organic growth alone.  Consider the following:

• Last week, InfoWorld announced that #1 of its “Top Ten Emerging Enterprise Technologies” is “private cloud orchestration” and noted Puppet’s leadership;
• Amazon recently responded to the demand for Puppet by bundling Puppet into their Amazon Linux EC2 images;
• The Wall Street Journal last month noted that the demand for sysadmins with Puppet skills grew more than 200% year-over-year;
• In September, Bloomberg Businessweek’s article on Puppet Labs underscored our momentum, highlighting that our products accelerated customers’ “transition to cloud computing”;
• Recognition of our thought leadership in DevOps, a revolution in IT operations, grew this year such that our insights are widely sought and cited, as evidenced as recently as earlier this month in The Register’s “Cloud’s New Rules” article.

Enter VMware, Google, and Cisco

This combination of strong momentum and the challenges of a fast-growing startup led us to seek the best partners we could find for the next leg of our journey.  We wanted partners with insights into the trends driving our industry, who understand our customers, and who get the unique nature of our approach to IT automation.  Given these goals, VMware, Google, and Cisco are an ideal fit, both for us and for our customers.

As trends go, while at times it’s difficult to separate reality from hype, it’s clear that virtualization and cloud computing are disrupting our industry at every layer in the stack. Amidst this chaos, VMware has carved-out impressive leadership in virtualization and private cloud computing.  And Google, in order to scale their businesses to meet exponentially growing demand, pioneered many of the concepts of cloud computing that are just now being commercialized for the broader market.  Such partners provide us with an incredibly powerful crystal ball into the dynamics and impact of these trends.

With these disruptive trends, we see our mission as enabling customers to take full advantage of their resulting benefits; thus the desire to work with partners who understand our customer, the system administrator.  Here, both VMware and Cisco are trusted, strategic partners of IT organizations worldwide; they understand the challenges facing system administrators to deliver ever shorter change cycles while maintaining enterprise-class service levels.  Working together, we’ll be able to build software that allows system administrators to deliver business-critical results with both higher quality and greater agility.

Finally, for us, how we achieve these results is as important as the results themselves, and finding partners who understand the value of our approach was critical.  These partners have hands-on, in-production-at-scale experience with Puppet – in some cases, going back several years.  Not only do their experiences validate the dramatic productivity improvements which our approach delivers – from 10s of nodes per sysadmin our competitors see to 100s and even 1000s that our users routinely experience – they also recognize the agility, portability, and insight that Puppet enables.  We’re humbled that their experiences with our product motivated exploration and consummation of a closer relationship.

The Road Ahead

How will we use these new financial and partner resources?  From the enthusiastic reception of our recently released commercial product, Puppet Enterprise 2.0, it’s clear that doubling down on designing powerful IT automation tools that are easy to use – and, going forward, integrated with the our new partners’ products – will result in tremendous benefits for system administrators.  In particular, we will invest more in designing products that allows our users to move faster, with more information, and across a wider selection of technologies than ever before, as it’s clear is necessary to take full advantage of the disruptions of virtualization and cloud computing.  In addition, our community over the years has consistently provided great feedback and guidance on our technology, and these new financial resources enable us to increase our investment in both community and platform.

I’ll wrap-up with a round of thank-yous.  Specifically, thanks to our community members for their ongoing engagement and collaboration, our existing and new investors for partnering with us on this journey, our customers for trusting our software to help them run their businesses, and our employees for their passion, intelligence, and drive to build awesome IT automation tools for system administrators.

Stay tuned for more – it’s going to be a fantastic 2012.

- Luke

Additional Resources

• Read the Series C press release
• The Wall Street Journal:  “‘Puppet’ Masters In High Demand”
• InfoWorld: “Top Ten Emerging Enterprise Technologies”
• The Register: “Cloud’s New Rules”
• Learn more about Puppet Enterprise 2.0

The day after the party is always the hardest. As you brush your teeth, you remember all of the things you accomplished the night before: the people you met, the names you have forgotten, the number of extremely large Puppet t-shirts you somehow acquired, and two or three OSL mugs you carried across town back to your hotel. Perhaps those last few things only apply if you attended the Puppet Labs OSCON party last week.

Here at Puppet, we have our own list of accomplishments, and a lot of it has to do with you.

We are proud to announce that at this party:

• 784 participants entered the building
• Around $1500 of spirit, 3 kegs of beer, 40 lbs of ice, and 2000 sandwiches were consumed
• Thousands of memorable conversations took place—there is an old Chinese proverb that is roughly translated to this: a single conversation across the table with a wise person is worth a month’s study of books.

We had a party at Puppet Labs because we hold individuals like you in high regard—individuals who value curiosity, self-motivation, and adaptability. By hosting networking parties like the one you attended, we expose ourselves to a wealth of knowledge and inspiration. So thank you, for attending, socializing, drinking, and having a blast.

With that said, I am going to bluntly state that if you have the above-mentioned values and have a passion for what Puppet is all about, come work for us. We’ll have a grand time.

Moreover, attend PuppetConf in September so that we can keep having these conversations.

Lastly, thank you to OSUOSL (Oregon State University Open Source Lab) for their donation to the party. For more information or to donate, please visit their website.

Keep in touch, and see you soon.

(Our Pro Services Engineer Gary Larizza took the photo above and many more of the night; check them out!)

You’ve got a great idea, and you’re starting a tech company. What’s next? Luke recently addressed that question with twelve helpful opinions in a Software CEO feature: Startup, Funding, Design, and Hiring Tips from Puppet Labs CEO.

A few of our favorites:

Tip #1: Companies are organic beasts. Don’t expect to tame them.

Interestingly, Kanies doesn’t have formal education in software development; his Bachelor’s Degree, from Reed College, is in chemistry.

“Science degrees are one of the best ways to learn how to think,” Kanies says. “Running a company is all about understanding the system of running your company.

“The company I’m trying to run is more like an organic being than anything I’ve ever seen. You can’t just push it one way or another and get the expected result; it very much has a life of its own.”

Tip #8: Use your services people for usability testing.

“We have a professional services team that works with people all the time,” Kanies says. “They sit down with brand-new customers to watch how the software is used. If it sucks, our customers don’t just suffer, we do — because it takes our services people 10 times longer than it should.

“When I first started selling, this is exactly what I was doing: I’d work with the customer during the day, then go back to my hotel room at night and sand off the rough edges.”

If this topic is especially near and dear to your heart, come up to Portland this June and catch Luke’s “Diary of an Open Source Sysadmin Entrepreneur” session at Open Source Bridge.