Five Key Lessons from PuppetConf 2014
| DevOps |
PuppetConf 2014 is behind us.
Running an event circuit every year can be challenging. On the vendor side of the booth, most exhibit floors look alike; it’s the rare show that is memorable, let alone definitional for an industry sine qua non.
PuppetConf bucks the trend. As a gathering point for the community (many of whom stopped by our booth to chat about topics that ran the gamut from IDM in Red Hat to encryption for GPG keys), the three days we spent in San Francisco were markedly focused on the most exciting themes in our world: automation, continuous integration, and modernization of infrastructure.
In the hallways, ballrooms, and sessions of the Marriott Marquis, we eagerly dove into the DevOps for a week, and while we are happy to be home, surfacing to the snap of a New England autumn has left us reflective. In considering our time there, we’ve assembled what we think of as the five essential take-aways from the conference:
Many of our discussions were driven by the recognition-and-knowing-smile that Active Directory, LDAP, Kerberos, RADIUS, and the like simply don’t scale to the kind of infrastructure that you see being automated and deployed through technologies like Puppet.
Simultaneously, the folks we heard from were on the forefront of technological adoption: they are solving real problems, making things work, and are willing to try new tools in order to make their teams more productive. Anything that blocks that initiative is sidestepped for the good of the business.
DevOps, like any technology centeric group, needs to both drive their business forward and be able to prove that they are doing so with respect to their legal and ethical obligations. Handling PCI, PHI, PII, and other sensitive/regulated data imposes specific requirements upon the DevOps team, and demonstrating to auditors that those requirements are being met can be (as always) a headache.
By definition, DevOps teams are capable builders, with deep skill sets in technology. However, their time is highly valuable, overly taxed, and best spent on solving the problems that nobody else can. Even a casual stroll around the show floor at PuppetConf revealed that there is a robust ecosystem of vendors solving problems that shouldn’t be managed in-house just “because we can”.
The next frontier in the space is going to be the convergence of security and DevOps, what some are calling SecDevOps, by default. The concepts of people-centric security hold true in the DevOps world: your users — developers and IT teams, in this case — will not wait for approval; it behooves the DevOps team to get in front of issues and provide easy, secure, and robust alternatives to insecure behaviors, whether that means a facility for key distribution or a strong set of permissions for service-to-service communications.
What was your experience like? Do you see the SecDevOps frontier as being where you or your team are headed? Are there other lessons you’d focus on?