We’ve been talking about DevOps a lot on the Packt Podcast. The reason for that is simple: it’s a critical part of how we actually build software from both a technical and an organizational perspective. And anything that draws us closer to the relationship between people and software can only be a good thing right?
For this edition of the Packt Podcast we spoke to Nigel Kersten, who’s the VP of Ecosystem Engineering at Puppet. With Puppet playing an important role in the evolution of DevOps over the last decade or so, we thought he would be a great person to give an insight not only on how Puppet has been adapting to industry trends (yes, we’re waving at you, Kubernetes).
Listen to the episode:
Nigel Kersten talks DevOps
We covered a diverse range of topics in the episode. From Nigel’s move from Google to Puppet (which, he tells us, slightly upset his mom…), through to the challenges – and pitfalls – engineering teams face when trying to implement DevOps.
Key quotes from this podcast episode
How to automate workflows effectively
“One thing we definitely tell people to do is… don’t automate one service from end to end. Don’t pick one complicated three tier web application put a small team on it and say “your job is to puppetize all of this infrastructure. What, instead, is a more powerful way to work is you go what are those low level building blocks that are across all of your infrastructure…? What are the things that are common across all of your infrastructure? Automate those things because they’re often really simple to do, and the rewards are huge.”
“Look at the things that are causing you pain in production. If you go and talk to the people who are on call, in charge of deployments, any of those parts of your infrastructure and ask them what would be the one thing that you would fix that would make your infrastructure more reliable, they will always have a shortlist of things… and when you do this, you start building trust across the whole organization.”
The fear of automation
“There’s always fear about adopting automation. There’s always fear about people’s jobs changing and adopting new tools and disciplines – sort of in an endless cycle of new tool adoption, people being told that they have to learn new things – the more you can actually show value across the whole organization that this thing’s relatively easy, a small investment for large returns, the more powerful an effect you’re actually going to have.”
“I think it’s a huge mistake if people think they’re embarking on a DevOps journey and they’re not willing to actually make some of the cultural and organizational changes – it’s about creating more cross-functional teams, it’s about giving them more autonomy, and it’s about actually letting people work across organizational boundaries without having to go up and down the hierarchy of the organization.”
“Most people are actually struggling pre-DevOps in many ways… the people who we’ve seen fail are the ones who have gone, look we’re going to jump exactly from where we are now and try to move to an incredibly automated environment without putting a lot of the ground work in place – like building up trust within the org, giving teams more autonomy, allowing service owners to configure monitoring themselves – I think all of those sorts of things are really prerequisites for a whole organization succeeding at DevOps.”