Share: |


devops_banner_for_communities.jpg-2.jpg

 

Here is the second excerpt from our great podcast interview with the educational, visionary Patrick Debois.

____________________________

 

Tom Parish:  You mentioned automation and tooling – can we refine this a little? Is DevOps, primarily an automation or a tooling issue?

 

 

Patrick Debois: It's not primarily automation; it's culture, as I said before.  To support that culture you use automation. If you take the automation step, you then can get workflow feedback from IT to code-check to development, to test, to production.  Automation makes that a very fast loop.   From the same perspective it could be also about other feedback and monitoring for testing stuff.

 

 

You need the philosophy, both at the people and the process level so that people collaborate. But if your technology doesn't support you to be flexible, you can have every good intention, but your feedback loop will be very long, or you don't see anything in that feedback loop. 

 

 

Tom Parish:  What's the role of change management in DevOps?

 

 

Patrick Debois: Traditionally, change management was a term within ITIL or CRMI, for approving things that would go into production.  What happens a lot of the time is that people were avoiding change, because they knew change was one of the primary causes of outages.

 

            Change management has always been meant that you have to make sure that nothing breaks, that you understand the risk and that you know that you can recover. With automation, a lot of the changes that we used to think were very scary become simple and safe.  It allows us to focus our time on the larger and the scary changes. Then the small items don’t have to pass through the change management cycle anymore.

 

 

Tom Parish:  I have a question I've heard from many managers in IT.  If all developers were to sysadmins and all sysadmins were developers, then would DevOps need to even exist?

 

 

Patrick Debois: I think the problems we are facing are just becoming more complex. To solve these problems, we need knowledge and skills that can't be found in one person.

 

            If you make everyone a generalist,  you just get bits of mediocre knowledge of development and system management. Instead, find people that are specialists because they can make a difference, but make them collaborate with other parts of the company.

 

The more knowledge you have from your collaborator, the  easier it is to translate your concepts, your ideas and what you need to do. But it's not about making everybody having the same skills.  Agile will be the same within their group.  There are people still doing tests, DBA, front-end, backend, and they were all specialists, but they're worried about the global code set.

 

You have all these people with different specialties collaborating, but they care about the whole delivery and production.  So I don't think everybody has to have every knowledge or skill.  That's not what I think DevOps is meant to be. 

 

___________________

 

More to come when Patrick discusses monitoring and the awkward teenage years . . .