DevOps, automation, and configuration

Image courtesy of Puppet

Before automation, writing and deploying applications was much more complicated. This involved setting up servers, configuring them, installing the necessary software, and numerous other steps, which were performed manually by system administrators. As a whole, the process resulted in more human resources costs and a higher chance of human error.

In today’s DevOps world, the entire process can be automated thanks to infrastructure as code. One of the programs used to carry all this out is Puppet – a software configuration management tool available in open source and commercial versions – which enables software developers and system administrators to work together.

Frontier Enterprise recently talked with Nigel Kersten, Field CTO at Puppet, about automation software, the future of DevOps, DevSecOps, and more.

- Advertisement -

You’ve been with Puppet for about a decade now. What have been the highlights of your time there, and what are the most significant changes you’ve seen over the years?

By far the biggest change has been the recognition that automation is no longer a nice-to-have, and something that the very best and most accomplished system administrators do, but that it’s literally impossible to manage a large IT environment without comprehensive automation being in place. We’ve gone from having to explain DevOps to skeptical enterprises to instead explaining to them how to succeed in their DevOps initiatives.

Another incredibly significant change in our field has been the recognition that we don’t just run IT infrastructure for the sake of it, but that it’s all in service of actually shipping value to someone, whether that be an internal or external user, and that value almost always comes in the form of an application or service. The infrastructure is just a means to an end. The days of the grumpy sysadmin who berated all their users for being idiots is drawing to a close, and I’m glad to see it go. 

How do you think organisations have fared in terms of DevOps implementation, especially since the beginning of the pandemic and the subsequent shift to remote work?

I don’t believe the pandemic and shift to remote work has significantly impacted DevOps implementations other than the general stress that it’s placed on everyone across all industries, but I do think that it’s caused a few cracks to appear faster than they would otherwise. The limiting factor in just about every large-scale DevOps initiative is how well teams are optimised to work together, and we saw from the State of DevOps Report this year that organisations with clear team identities and well-defined interaction paradigms between teams are the ones that see the best results.

The sudden shift to working from home has exposed limitations in communication between teams.

What are some of the most exciting developments in Puppet’s laboratories?

We’re really excited about Puppet Relay, our event-driven workflow automation tool, as we see a lot of similarities between the current state of cloud operations and the state of Linux system administration when Puppet first appeared. Too many teams are reinventing the wheel over and over again, gluing together cloud services with bespoke, in-house scripts that offer limited reusability, and make it difficult for us as an industry to progress towards building higher and higher level abstractions.

By codifying these workflows into a platform like Relay, we believe we’ll be able to expand the pool of folks getting value out of automation workflows, and provide a great user experience for everyone.

How do you envision modern DevOps environments will evolve within the next three to five years? How has the increased need for digital transformation affected today’s DevOps environment?

The most significant shift in DevOps environments over the next few years will be the adoption of the platform team model, as more and more organisations recognise that they’re unable to scale with lots of small, cross-functional teams unless they’re all working on a common platform.

As we see more and more companies adopt the platform team model, we’ll see the role of the platform product manager be more widely recognised as being critical for success, and those people will be very much in demand. It’s not easy to find that mix of technical knowledge, empathy for users, ability to evangelise internally, and do the job of a product manager for an internal platform, and the value those individuals provide is immense.

What are your thoughts on DevSecOps as an augmentation of DevOps?

Labels are useful when they drive actual change, and we know the relationship between security, operations, and development inside large organisations desperately needed to improve. Personally, I think we could have done without the DevSecOps label as it’s all just DevOps to me, but I’m not losing any sleep over it.

- Advertisement -