So there never was a grand plan about thinking about DevOps as a word, I was busy working on a project which had Agile development and I was so envying these people about their methodology and I like to do something similar in my world system administration, so I called it initially Agile System Administration, but it’s pretty long. And then I wanted to do a conference for getting people together and Agile System Administration Conference was just too long, so I just picked the word DevOpsDays as Dev and Ops working together because Agile System Administration was also too narrow on focusing on sysadmins only. So that is a bit of the origin and actually it’s also a pun on DevOpsDay, DOD, dead-on-delivery but that is kind of lame.
I think the breakthrough is a lot of the technologies and things we are doing and are now like put under the level DevOps, they were happening before the word DevOps was there, but because there is a label now, people can relate to it and they bring out the stories under that label which makes it easier to kind of search them, to kind of group them together and given that the number of stories was increasingly going up in the first years of DevOps. And by bringing up this stories, it got attention from the management world and from the analyst world as it is a very important thing that people should be doing. So I think that is the major achievement of DevOps as such, that it brought to the attention that two worlds, typically different or apart in an enterprise or in a company, need to collaborate and there is a synergy between them, that actually gives you a competitive edge. So I think that is part of the thing that it brought to the world.
It actually always makes me laugh. The word NoOps in a way that I understand what they mean by less complexity of managing things and not worrying too much about the operational things you do, and that gives you more time about spending time on things that bring business value, but actually, when you do this kind of stuff, even on a SaaS platform or a PaaS platform, you will have to do some operations anyway because you can’t trust the other that they're always up and always working. So you kind of have to monitor the other guys and you have to make sure that things are not failing or that you can migrate to the others. So I guess you can start in a NoOps mode and say "I am going to outsource everything to a company that kind of takes care of it and I can focus on my business idea wherever is viable or not", but once it starts growing in operational perspective I guess you have to do Ops anyway so that is why I think is an interesting goal as we should not be worrying about it too much, but it is like we are never going to reach it that there is no Ops anyway.
Let me give you the example of Amazon. Amazon is abstraction in a way that we don’t worry about like IP addresses and all that stuff, a machine gets there, we don’t worry. So you can say "We saved a lot of stuff", but once you start scaling you say "Ok, let’s take support contract with Amazon" because we don’t know what is happening, and what is happening in that support contract is they’re actually asking you for money for a guy on the other side that helps you, so he might not be like within your company but you are paying somebody else that you want to talk to when things are failing, so I think it’s exactly the same.
It's very hard for me to tell in a way that I live in this bubble because I follow the sphere of DevOps so hard, so it is kind of, everybody is doing it. In reality let’s say, I think I just started receiving after two-three years a request within Belgium about doing DevOps and conflict management. I am not saying some people didn’t do it, but it’s still very rare on a world perspective, there are several people doing it but it's still niche, it’s gaining attention but we have not broken everywhere.
6. So you’d place it still at an early adoption phase?
Yes, I think so. On a scale from one to ten let’s place it on four or something.
Obviously, tools are the most tangible things. There are things you can download, start running and doing stuff, but we learn of whatever tool we use that it’s not going to change you even though vendors try to make you believe that wherever tool you pick, that is going to change your life and so on. It can change your life, so there is an importance in the tools in a way that they might force you in new thinking patterns, but obviously if you just have a bunch of tools and you are not using them in a collaborative way, it does not make sense. Well, it does make sense but it does not make a difference. And the same was happening within Agile like you can do TDD and there was a lot of attention on TDD and writing tests. Does that make you Agile? No, but you learn that while writing in a TDD cycle it is not about writing those tests, it is about the feedback and the stuff you’re doing with it.
And they can bootstrap you into that mentality pattern but it is a bit of bottom up - top down approach but somewhere in-between you get more benefit. But it never started out as a set of tools, because in the beginning nothing was branded as a DevOps tool. I think still there is more value if you can change the culture of a company but it’s a lot harder than changing a tool, so that is what is happening.
8. Speaking of tools, I must ask this question: Chef or Puppet?
Both, of course, you pick the right tool for the job. I believe in a way that the more tools you have on your tool-belt, the better you can decide and apply to the situation that you are having. One example in Puppet that I really like is the fact of the NoOp that you can check things before running them that they don’t change things, currently Chef does not have that. I like Chef for its searchable metadata, if it is really dynamic, it is kind of very flexible, but it depends a bit of your environment whether to use one tool or the other. What is happening is, because they are in a competition mode, one is taking on the feature of the next one and this is driving a good evolution of the tools.
The things I want to bring more in DevOps as it’s being discussed now, is the perspective from managing it. Recently on the mailing list there was a whole discussion about hiring people with the right mindset, how do you do that? I get questions about certification not that I am completely for certification, but I can see what they're driving at. How can you see if somebody is actually fit for that mental model or not? I’d like to see more of this exploration work coming out, besides the evolutions in tools, but how you introduce that, how you cope with the problems that you are facing on DevOps, so I think that is part of the challenge of promoting it.
On the test driven infrastructure I see it actually evolving as, I usually say "There was a lot of focus on continuous deployment" and let’s say on the left side you have development and on the right side you have operations, so it makes you go faster -TDD and all that stuff. As said, let’s make tests because you need to have the brakes when you go fast that you can brake on time. But still it’s going from left to right, from Dev to Ops. I think there is an evolution to be made of feeding back from Ops back to Dev, and from that perspective I would extend the test driven development to actually monitoring and metrics and feedback on different levels as the channel that not only on a technically level, but on the business level people can see what is actually happening. So I am very eager to get that feedback-loop in a better way to the business.
I think it is here to stay, and giving a good example is that the conferences are actually picking it up as a separate track so it does not stay only on the DevOpsDays, so it’s there like the Cloud track will be there. It’s probably going to change over time but the fact that is closer relationship gives better results and all the things we doing in that old gap will keep on being interesting to companies.
My personal thing, like I said I am very eager to get the monitoring and metrics back, so I am playing around with things like logstash as a generic event feedback loop, so it could grep from whatever monitoring metrics source like Nagios, Ganglia, Open TSDB and get all the metrics you want to the place you want it to have. So that is what I am personally working on to get that easier. I am thinking about creating a Monitoring Abstraction Library like you have Cloud Abstraction Library so you don’t have to be using a specific monitoring, you are kind of able to change or make it more flexible and by making that abstraction layer and by making it easier, I almost dream that we can have the same power as we have with Vagrant but say monitoring Op, and that I am spending my time on.
There is one team emerging which is security related, the security people are actually seeing DevOps as an ally in their struggle to making things secure which is an interesting evolution, and I think the other evolution that I am seeing is on the management level, the HR and hiring and on that level. But they are going to be different from conference to conference based on what we actually get as proposals, but these are the main keys currently.