Share: |



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 . . .

Share: |

There have been a lot of great discussions and differing points of view about DevOps and what it means since Patrick Debois coined the word in late 2009. The organic growth has been spontaneous and lightning quick, from inception to spontaneous meet-ups occurring globally to sold-out DevOps Days around the world. It took mere months after coining the term for the first iteration of the Wikipedia DevOps entry to appear (I remember the timing well because . . . I wrote it).  And many amazing folks have emerged to move the discussion forward and today DevOps is a mainstream movement (heck, it's even a job title now).


And there are a lot of awesome DevOps blogs out there now (Debois, Rockwood, Edwards, several others, etc.). So why am I starting this one? I’m going to kick off this DevOps blog with an announcement of "The DevOps Leadership Series".


Basically, all of these great voices on DevOps are scattered all over and the idea is to have their perspective — or a small representation of it — gathered all in one spot, right here. One spot to go to. We’ve already got some great interviews and more are in the works. So, BMC can have this Series bring together various thought leaders, users and visionaries in the DevOps space to record their points of view.


And now onto our very first Leadership interview with the guy who started it, Patrick Debois, as he discusses what DevOps is, how he came to coin the term, and what DevOps is not.

Share: |


I launched the BMC DevOps Leadership Series by starting with the man who brought us DevOps, Patrick Debois. He's smart, savvy, and one of the most freindly and generous souls I've ever met. I am proud to know him.

That said, we asked him a few things about DevOps. As usual, we worked out all of the

questions ahead of time and went from there. Tom Parish, the one-time BMC podcast hsot, conducted the interview.







Tom Parish:  I'm glad you're here.  It's not often that I get guests from Belgium, so this is a special treat.   The first question is: what is DevOps?


Patrick Debois: The multi-million dollar question everybody keeps on asking me.  There is not one definition, and I doubt if there will ever be one.  It can mean different things to different people.  I can tell you about how I came to coin the term, what it means to me and how other people have begun to see it.


Before I came up with the term, I was very involved with projects that used Agile Development methodology. I was supporting them from a system administration point of view, and I felt a bit left out of their group. I wanted to start doing the same things and help them from my perspective.  I first named it Agile System Administration, and then I thought it was more like a system administrator doing Agile, while development was doing Agile – we needed development and operations to work together.



I saw the term DevOps as collaboration, but in reality, this is a narrow definition.  It's not just about development and operations collaborating, it's getting every silo, every part of the business, of the enterprise and the organization collaborating to meet business goals.  The term is short and is catchy; making it longer, like Dev-Security-Ops just didn’t make sense, so DevOps just started getting around.



Tom Parish:  I guess it's fair to say that it's not just a technology and it's not some interim thing, it's more of a philosophy that combines technology and people into a single perspective.  Isn't that it?



Patrick Debois: Yes.  That’s because it was born from my perspective of Agile Development, Agile as such has a manifesto and talks about more of a mentality or philosophy on how you collaborate.  Tools exist to support that methodology or mentality.  There is a direct leader relationship, of course, but getting the culture and getting the collaboration going will make sure you succeed.  Your tool alone will not make you successful.



Tom Parish:  How old is the concept of DevOps?



Patrick Debois: It was first coined in September/October 2009, but as a philosophy, there were already a lot of people doing it. People who were automating and collaborating, but there wasn't like a common term for it.  Some people just say. ”Oh, DevOps is just being a professional system administrator who proactively reaches out to all parts of the company, or a developer reaching out to all parts of the company,” I guess that's a bit different.


Even with all the tools and automation in place, it just shifts in the way that you actively go out of your silo and seek out that collaboration. 




To be continued when Patrick discusses tooling, ITIL and collaboration in DevOps.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.