Just before heading off to EclipseCon, we talked to Puppet Labs CEO and founder Luke Kanies about their latest release of sysadmin aid Puppet Enterprise and the rise of DevOps in general.

Yesterday, those guys at Puppet Labs deployed their latest
generally available release Puppet Enterprise 2.5,
enabling system administrators to manage heterogeneous IT
environments of Linux, Unix and for the first time Windows systems.
With close ties to their Puppet Forge online marketplace, Puppet
Enterprise 2.5 also facilitates DevOps giving cross-functional IT
teams a common framework that allows rapid, continuous deployment
of applications.

We caught up with Puppet Labs founder Luke Kanies just
before he went to EclipseCon to talk about the release and how it
fitted into the infrastructure picture…

JAX: So Puppet Labs Enterprise 2.5 is here. Can you tell
us about what is new within this version?

Luke Kanies: Puppet Enterprise 2.5 is our fourth release of
Puppet Enterprise since it launched in 2011, and follows on from
the major 2.0 release in November of last year. First in the
release is support for Windows, which allows Puppet users to use a
single language and platform to manage their entire infrastructure,
from Red Hat servers on EC2 to Windows servers on physical
hardware, and even including the Cisco networking hardware and F5
load balancers.

Next is integration with the Puppet Forge, where users can
find, download, install, and manage more than 300 freely
downloadable pre-built solutions in Puppet. These solutions stretch
from MySQL and Apache to Hadoop and OpenStack, and provide the
fastest way to automate solutions to new problems. Because they are
built and maintained by our wonderful community, they are also a
way of sharing and benefiting from community best practices, so
everyone learns together rather than in separate
silos.

Lastly is our big data for infrastructure work, which wraps
up all of Puppet’s open data, formats, and APIs into the Puppet
Data Library, which is perfect for building applications on top of
Puppet and integrating it into existing infrastructure. This
includes data like hardware and software inventory, run reports
that tell you everything that’s happening on your infrastructure,
and our configuration graph which tells you not just what you’re
managing but what it’s related to. With the Puppet Data Library,
our users have applications like a warranty report that uses
discovered serial numbers to automatically determine when a piece
of hardware goes off warranty.

Why was Puppet Labs Enterprise created in the first place?
Was it a response to the sluggish cloud computing infrastructure of
old?

Puppet Enterprise was more a response to the fact that the
software around at the time wasn’t useful enough for people to even
bother with it. When we started with Puppet, there were multiple
commercial products and tens of open source projects in the space,
but fewer than 20% of companies ever used any of them, and those
that were used were barely so at that.

Part of the problem was just that these tools were meant to
be all-encompassing solutions that took 12-18 months to deploy, but
they also didn’t make life easier or better for the sysadmin, they
just changed the job. I wanted a solution that sysadmins would
love, that would allow them to move away from firefighting all the
time and focusing on strategic work, and that would allow
operations to become a source of leverage for the organization
rather than just a cost center.

The fact that Puppet has been at the forefront of DevOps, and
a big enabler in the cloud, is a testament to how important this
better tooling really is to moving forward and quickly.

What do you feel are its best features, something that
Puppet Labs 2.5 offers differently to others?

I think the best features of Puppet Enterprise revolve
around its simplicity and abstraction. The simplicity means that
anyone can get started with Puppet very easily, and it’s worth
doing even for small problems. We have some customers who began
using Puppet by just managing a single file on a small pool of
machines, but within a few years they were managing hundreds of
servers. Puppet’s abstraction means that sysadmins and developers
can focus on the high-level problems in their infrastructure,
rather than spending time on problems like how a package manager
works, or what the format of a configuration file is.

Even if Puppet doesn’t directly support a tool, it’s easy
to build this support into Puppet via its many extension points, so
at worst you pay a small extension cost and from then on the plugin
is again a source of leverage.

What exciting modules are we seeing pop up in Puppet
Forge?

There are really all kinds of modules there, and in fact we
run a blog series called Module of the Week, where we highlight
something special that week. We’ve been focusing for the last few
weeks on a module called ‘stdlib’ that was built by our community
and includes a ton of useful extensions to Puppet. I like that one
because it both provides a lot of functionality and showcases how
easy and valuable it really is to extend Puppet.

There are also the OpenStack modules, which have been getting
a lot of attention recently. Many of our customers and partners
have been collaborating on them, and it’s been impressive how
useful they’ve been given the early state of
OpenStack.

Was the decision to provide Windows support logical
progression for Puppet Labs Enterprise?

Puppet Labs grew up as a mostly Linux/Unix shop, and all on
the command line, so moving into Windows is really a response to
customer demands. Our customers are excited because it will allow
them to use a single tool and a single language to manage their
entire infrastructure, rather than having each team or platform
having its own silo. Even better, you can build a single solution
that builds and manages a service across both Linux and
Windows.

DevOps has long been a sort of buzzword, but a lot of
enterprises are coming round to the idea. Do you feel the future
for development teams is DevOps and if so why?

As I’ll be speaking about at EclipseCon this week, DevOps is
more about operations than development, but I think it’s absolutely
the future. I think it is to operations as Agile development was to
the developer world – refocusing on the customer, on the problem,
and finding the best, shortest way to solve the problem rather than
focusing on processes and controls.

We think it’s a critical part of getting IT past being the
gatekeepers of technology and instead having them be a great source
of innovation and leverage. We’ve already seen that in some
organizations, like Google and Amazon, operations is a real
competitive advantage, and DevOps practices are exactly how they
got there.

What is the biggest challenge for DevOps do you
feel?

I think like all movements, DevOps has to stay just edgy
enough for people to care deeply about it but just mainstream
enough that it can really spread. We’re starting to see a lot more
DevOps consulting – in fact, we offer some forms of it – and while
that can help people get up and running quickly, it can also
provide a kind of false conversion to some organizations, similar
to what has happened in Agile. Just because you have iterations
doesn’t mean you’re agile, and just because your sysadmins are
talking to your developers doesn’t mean you’re practicing
DevOps.

What things have Puppet Labs got lined up in the future, or
is the focus simply on 2.5 for the time being?

At Puppet Labs, we like to work to the future but talk in the
present. We’re very excited about 2.5, but we’ve already been
working for months on our next major capabilities. You’ll be able
to see the direction of our releases from our upcoming open source
release in May, but you’ll have to wait a few months after that to
see our next major Puppet Enterprise release. You can bet that all
of these features will be focused on making Puppet more powerful
but less complicated, and easier to use by newcomers but providing
more long-term value to veterans.

In other words, it will all be about well-designed
software, by sysadmins for sysadmins.

Luke is the founder and CEO of Puppet Labs and the founder of the Puppet project. He helped kickstart the DevOps movement by preaching ‘Infrastructure as Code’, and he believes that computers should be used, not managed.