Kris Buytaert on Trends in Open Source and the DevOps Movement

Brian Dawson: Hello. You're here today with me, Brian Dawson, and Kris Buytaert on DevOps Radio. I'm looking forward to a really fruitful, really interesting interview, as we have a chance to talk to one of sort of the originators of DevOps, pioneers of DevOps, and also a person that continues to be an important thought leader and luminary in what has become a DevOps movement. I'll risk giving it that term. We'll talk a bit about it with Kris. Kris, hello. Welcome. How are you?

Kris Buytaert: Hi. How are you?

Brian: Doing well. So you and I had a brief moment to talk before we started this session and I learned some really interesting things about your background, what you do today, and really what your role in DevOps is. So maybe you can go ahead and share some of your background and some of those interesting facts with our listeners.

Kris: Sure. I started my career about, what year is it again, long ago, over two decades ago, as a web developer/software engineer and I was writing software in all kinds of languages. I had a strong preference for doing things on UNIX and mostly Linux back then. After a couple of years of working for a regular software consultancy, my need of actually not being in a proprietary world and working with more open source tools and things where I could actually contribute and things where I could fix the bugs of the software I was using or actually build new things was so great and so big that I actually completely switched and since somewhere in early 2000, I stopped using any form of proprietary software. I've been on that open source, Linux and free software movement for somewhere since the late '90s. What I was doing there was helping organizations adopting open source, adopting Linux into their infrastructure. I helped them to build their business with these tools. While I was doing that, working for large companies, working for banks, for telco equipment manufacturers, for all kinds of organizations, I was also speaking at conferences about what I was doing. How do you do this at scale? How do you do high availability? How do you do performance? How do you do all of those topics? Somewhere in 2006, '07, '08, we started talking more about virtualization, about automation, about doing all those things, doing the early things of CI/CD. How do you do builds? How do you do all those topics? I started bumping into a number of people who had some ideas, like how do you do automated deployments. How do you do built engineering? One of those people was actually Patrick Debois, and at some cloud camp in Antwerp in April 2009, we basically figured out that we had a lot of common friends and we had a lot of different conferences we went to and we figured out it was like there was this group of people who went mostly to operations conferences, the Linux conferences, the UK/UG conferences, the ... conferences in the States and similar scenarios. Then there was another group of people who went more to developer conferences like DevOps and other more focused on actual application development. We realized even though there people with similar ideas, there was a huge gap. That basically was where we had the idea: what if we bring together some of our friends, if we bring together some of those people and start doing things and start talking about it. That's how DevOpsDays got born. From DevOpsDays, which was the first time in November 2009, which is close to 10 years ago, from DevOpsDays the conference, the whole global movement got started. That's basically my background. Since then, we have a name for what we were doing. We had a name to discuss how do we do software delivery better. How do we prove all of those things? The name has evolved into some direction some people might like, some others don't, but it's been growing since. It's been going pretty much the same with new technologies, new insights, with new ideas. But now we have a name for it.

Brian: That is an interesting story. Actually, let me take an opportunity to say thank you. Thank you to you and Patrick for, I think, challenging status quo, realizing a gap and bringing together a group of like-minded people that needed to be brought together. I am sure that you're getting royalties on the use of the name, right? So if need to borrow any money from you, I could give you a call?

Kris: Wishful thinking.

Brian: There's so much to ask you, Kris. Let me try to pull on a couple of threads. One question is just what is your thought now? Would you have ever envisioned that when you guys pulled together that first DevOpsDays that we would be where we are today, where the term DevOps and the idea or concept of DevOps is literally driving economies? Is that something that you guys thought about or is this is a surprising outcome thus far?

Kris: No, absolutely not. The first DevOpsDays was basically 60 or 70 of our good friends having a good time and discussing our challenges, and discussing our experiences and sharing our knowledge. Even at that event, we were looking at what was happening with Agile. We were looking at the Agile manifesto and said well, so the whole concept of the event was mostly open spaces, and one of the open spaces was about should we have a manifesto. We agreed, most of the people that were there, that we should not have a manifesto. So we were definitely not planning on doing something big and doing something that was going to change the industry. It was likely ...  first commits to Linux Kernel. It was just a small hobby project.

Brian: Yeah. So I'll just call out I think there's an interesting maybe lesson there. I think some of the greatest ideas, some of the biggest movements, and I'm not going to go through the list, but you just gave an example, come from people solving a problem that they're passionate about. And if you're solving the right problem and you're bringing the passion and solution to it, it can grow to change the world, as Linux has done, as DevOps has done. Actually, let me ask. This sets us up for an interesting question to ask you. I will say I use, and maybe somewhat lazily, I say if I ask 10 people what the definition of DevOps is, I will usually get at least nine different answers. Maybe that's improved and I'll get three, four, five different answers, but rarely would I ask 10 people and have them all agree on what DevOps is. I have to take this opportunity to ask you. What is DevOps and why should people care about it?

Kris: For me, it's a global movement has been discussing and improving the global state of software delivery. It was a movement that was started in Ghent back in 2009 and it was founded on the crossroads of open source, Agile, and early cloud adoption.

Brian: Got it.

Kris: If you see what people talk about when they discuss DevOps, I really often point them to the CAMS keyword, which Damon Edwards and John Willis came up with when they were running the early days of the DevOps Café Podcast, when they were interviewing a lot of people. Those four keywords: culture, automation, monitoring and measurement, and sharing. And S for me also stands for security and has stood for security since day zero. Those four words are really what people are talking about when they talk about DevOps.

Brian: Awesome. To repeat, that was the CAMS.

Kris: Yeah.

Brian: Again, culture...

Kris: Culture, automation, monitoring and measurement, and then the sharing part.

Brian: Or security for S.

Kris: And security, yes.

Brian: Awesome. Actually, that sets me up well for the next question. I was really curious about and I'll go back to the definition. I oftentimes think, especially with the advent of a DevOps engineer position, which I hope we will get a chance to talk about, that oftentimes DevOps has kind of been incorrectly relegated to the process and technology that sits at the seam between dev and operations, handing off an application or deploying an application. But as you just said in the original DevOpsDays, Agile was a key aspect of what you guys were looking at. So that leads me to ask: Where does Agile fit into DevOps? What does Agile have to do with DevOps?

Kris: You kind of touched on three interesting topics. Obviously, where does Agile fit in? Secondly, the term DevOps engineer. Thirdly, the word DevOps, which somewhere sits in between the devs and the ops, being .... So let's start with the agile part.

Brian: Okay.

Kris: If we look back the first DevOpsDays, the talks we had there were from early agile practitioners. They were from people who had been doing Kanban for operations. They had talks and experiences on, "Hey, we did this huge software development project and we were having cross-functional teams where we had the operations people and the developers in one team and they were doing scrum things and we were learning from those people on how to improve that and how to actually embed not only the developers into those teams." Typically, scrum was something that people were doing only for developers, but once you started adding more people to those teams, you saw change happen. You saw improved quality and you saw less frustration. Then we also had discussions like if you're having larger operation things, where you cannot plan upfront or you cannot commit on the number of resources that are going to be available because your data center is going to be on fire at some point and your sprint goals are going to be completely impossible to reach. Then maybe something like Kanban is a much better approach. And you see the influence on how teams collaborate and how teams work together. That's a large role of how agile works. Now if you walk into a lot of organizations today and they say, "Hey, we're going to do this DevOps thing. We're already agile," what you really often bump into is that they're implementing some kind of broken Agile. They've pretty much taken their waterfall approach. They give new names for the teams, new roles for the managers, and they fundamentally do not change anything. If you look at things like the Scaled Agile Framework and some of those things, they're not agile at all. They're actually the opposite of agile, but they're called agile. That's one of the first problems when you talk about doing DevOps. You walk into the organization and they say, "Hey, we're going to do DevOps. We have 20 DevOps engineers. We created a DevOps team. And, by the way, we're doing SAFe."

Brian: Right. Let me ask and keep your thought because I'm going to want to continue, but I think something that gets lost, correct me if I'm wrong, when we start to try to codify agile in something like SAFe, we forego or lose some of the cultural elements that are key to it, the sharing elements, and maybe we focus just more on automation or measurement. Before you pick back up, any thoughts on what gets missed?

Kris: What gets missed is people over process. It's process over people. It's about self-organizing things. It's about collaboration and when you're doing SAFe there is nothing collaborative about it. It's just command and control management saying, "We want you to build this in the next quarter." There are no developers into those organizations saying, "Yes, we can actually commit to that and we can do this. We have decided as a group that we actually do this." No. It's basically still just a waterfall command and control.

Brian: Right. I will just say before I hand it back to you that I agree fully. Whether we do it now or we get a chance to follow-up later and dig more into culture, I will tell you, in my experience, you can apply all the scrum ceremonies you want, all the Agile ceremonies you want, SAFe or not SAFe, but until you focus on the culture, you're not going to see success. So I think what I hear you saying, I am experiencing and have experienced and agree wholeheartedly. I'm sorry. I interrupted you. You were on three subjects. We were talking about where agile fit, DevOps engineers.

Kris: And then you said DevOps engineers and you asked about … you said DevOps is something that fits in between the devs and the ops, like we're going to hand over this whole application thing to a new team and that new team is, well often when you see a DevOps team in an organization, it actually is the silo between development and operations. It's the people who put things in production. It's the people who write the build paths, the people who in some old organizations provide the runbooks to deploy something and still do manual deployments. DevOps is about breaking down those silos and doing more collaboration and working together with each other, and not throwing something over the wall and now it's somebody else's problem. Creating that DevOps team really often is exactly the opposite of what they want to achieve. They just have more handovers. They just have walls where things are being thrown over. I find that sometimes actually the DevOps team is a true team, is a team in charge of things or just supporting and giving tools and giving self-service to other teams, but those are the rare exceptions. Typically, when I walk into an organization and they say, "We have a DevOps team," the first step you need to do is ask, "Does that team sit before or after the release management team? And do they actually have access to production or not?" When the answer is, "Well, they ... the release management team," you know that it's still a completely siloed organization and you know that they ....

Brian: Right. And is your opinion there, I mean really if they say that DevOps sits in any single place in the delivery pipeline or in that software development lifecycle, is it the case that that is the indication of an incorrect implementation or approach to DevOps?

Kris: Well, incorrect implementation, there is no book that dictates how it has to be done, but it does show, typically, that the pains that people have been trying to solve are not being solved. It does show that it's something that's been put in place by people who don't have the experience, who have never felt the pains, and who said, "Hey, we didn't understand what this DevOps thing is really about. What about if we make it a team?"

Brian: Right. And then you talked about, I'm going to lead you to the other topic that you picked up in my never-ending question. I'm going to reference back to a blog that you wrote, I believe sometime last year, titled "The Return of the Dull Stack Engineer." I think you put forth pretty strong and very valid opinions about this concept or this idea of DevOps engineer, which I think many of us in this space probably get contacted on LinkedIn on a daily basis for a DevOps engineer role, and then how that kind of morphed into a full stack engineer role. I read it. I wholeheartedly agree. I was hoping maybe you could comment and share some of your thoughts with our listeners.

Kris: There's actually two blog posts I wrote. I think one is much older, which is, “Don't hire DevOps,” which dates from probably 2011/2012. The first question I ask when somebody asks me, "We need a DevOps engineer," what do you need? Do you need a developer who knows how to deploy things? Or do you need an operations person who can automate things and will understand Java ... traces? And, by the way, where are you going to seat that DevOps person? Are you going to sit him next to the Agile and to the collaborator? Typically, when you start a conversation, people go like, "We're just looking for a senior Linux engineer, but we don't want to pay him a senior rate," because that's what they're looking for. They're looking for somebody who has grown through the pains, who knows how things are being built, and who has taken that step further and automated things. That's what they really want. The challenge there is that you cannot automate what you don't understand. When they're looking for junior DevOps engineers, that's kind of a contradiction because you're asking people to automate things they don't understand, whether that is a built pipeline, whether that is deploying 10,000 Apache instances or something else. If you don't know how the thing really works, it doesn't matter if you can automate it. That's the real challenge. So now we have DevOps engineers. We have full-stack engineers. By the way, do you know what happens if you add something to a full stack?

Brian: No. I want to know the answer though.

Kris: You get a buffer overflow because the stack is full.

Brian: Yes.

Kris: So then you really want to hire a full stack engineer, because if you give him one more job...

Brian: The buffer's going to overflow and then who knows what happens after you get a buffer overflow.

Kris: Exactly.

Brian: The whole program crashes. Great analogy actually. I hadn't thought of that.

Kris: Saving things is one of the hard problems in IT.

Brian: Right. I'll certainly have a conversation about it. I've struggled with and have posted and had conversations about this concept of a full stack engineer. Are there people that exist that would fit the bill of a full stack engineer? I think, Kris, when you walked us through your career path, you're an example of somebody that might fit the bill of a full stack engineer.

Kris: I know ... Linux kernel. I did front end and stuff. It used to be to one ... but that's the whole point. It's long gone.

Brian: Right. You cannot be a deep domain expert in everything.

Kris: Exactly. There's definitely a lot of people who have touched on a lot of the layers which are required to understand a number of things, but there's not a lot of people who are doing that on a day-to-day basis. That's the problem.

Brian: I think, too, and you can help guide me there before we move off of this because I do think this is really important. You kind of shifted to talking about that it's really about, and these aren't your exact words. I'll paraphrase them, about respecting the individual expertise and bringing people together in a cross-functional team, so you can get the most of everybody's domain expertise. I'll use a corny analogy. Everybody has certain superpowers and when you form a cross-functional, Agile team, you are getting the best of everybody's superpower to deliver software. Any comments on that? Did I capture kind of where you move on from when you talk about the issue with the full stack?

Kris: That's kind of funny because I used to use the analogy of superheroes or really top-notch sports people. But I stopped using the analogy of superheroes because if you look at most movies, in movies heroes fight, and that's exactly what you don't want. You want people to collaborate. But I do see where you take a number of people with compatible skills and complementary skills and they can work together, but you don't want those superheroes. You don't want those...the superhero, typically in a movie, it's the one person who just walks in and kills all the bad guys and then moves on. That actually is the opposite of what we want to do. We want to collaborate as a team, and I haven't seen that many movies where it's a team effort that makes things happen. Typically, when you see that superhero, that is the ... engineer who will … of course if you work alone, you only communicate with yourself. You don't have ... where you need to talk to more people to get agreement and you don't need to collaborate, but that is actually what you need to do. You need to understand what other people are doing, so you can work better with them, and that's the opposite of doing something solo. That's the opposite of sitting in this corner and fixing all the operational problems and nobody else knows what he's doing.

Brian: Right.

Kris: It's about if we work together, we don't need to fix this problem anymore. We've actually tackled it from a different way because we talked and we agreed on, "Well, this is a better approach and I don't need to manually change things and fix things."

Brian: Right. So I'm going to, just so you know, I'm really resisting, I think I could spend two or three hours on this session with you, but I know you don't have the time. So real quick, before we shift to technology, you've done years of consulting around DevOps, as well as have been at the core of the movement. Are there three things that you would say are critical or imperative to starting an organization on the right path to, I'll just say following DevOps tenants? So when you go into a customer or a client, what are the first three things that you try to effect?

Kris: Actually, there are literally three things that I try to focus on. They're not the cultural/automation/monitoring things. They are the fact that we talk about Agile and understanding that people really need to understand what Agile is about because a lot of the foundations of organizations are not Agile. They've just re-implemented waterfall. That's the first thing, which is really important. I talk about open source. We started to ask a bunch of open source people, senior open source people for examples with experience, with tools that could build things. The open source thing to me is more. It is about the culture. It is about the collaboration. It is about being able to read somebody else's code and contribute to that and experiencing that. The huge culture difference is if you walk into an organization who has been doing proprietary software for decades, the typical engineering problem is, "We have a problem. We don't know how to deal with it. What are we going to do? Are we going to call a vendor or are we going to call support?" And those people are not going to spend time understanding why things work the way they work. They actually have been dumped down to people who just take phone calls and shift blame to somebody else. They've got a support contract in place. If there is a problem, their ass is covered because they have a support contract. They're going to call somebody else and somebody else is going to fix it. In an open source organization, when there is a problem, people start reading log files. They start looking on forums. They start looking on IRC. They start talking to the developers. They start actually trying to understand what is going on. What is the problem and how can we as a group, with people from both internally and externally, fix that problem? Those are two completely opposing approaches, and that is a culture thing. It's not the about fault. In my experience, you can go faster with open source tools. You can go smoother because there is a lot more transparency and a lot more openness, and there is much more interoperability in open source. But it is that culture of investigating. It's that culture of trying to understand how things work as opposed to, "Well, it's not my problem. I made a phone call. I need to wait now." That's a culture thing, but it's so visible in the difference of tools people use. Those two are really important. Then the third thing, which is also important, is the availability of resources. Whether that is actually a cloud or something where people can basically spin up things and test, whether that is Amazon or something internal, or Google or whatever. That's not a problem. The problem is as a developer you need to be able to just say, "Hey, I want to try this thing. I want to spin up something. I want to play with it. I want to be able to throw it away if it doesn't work, and if it works, I'm going to sit together with somebody and we're going to try to figure out how can we bring this to production. And if that means you can get a proof of concept of something in a couple of hours, a couple of days, if you can do that internally, perfect, but is that flexibility unique? In a lot of large organizations, the way to do things is still you're going to fill out a form. You're going to wait for a virtual machine. You're going to get that virtual machine in three to six weeks. It's going to be the faulty one. And you cannot test. You cannot experiment. In an ecosystem where there is a cloud, you just spin it up. You talk to an API. You spin it up. You do it. You decommission it. You pay only for what you use. Even large organizations who say, "We are doing cloud adoption," they still put in place those forms. If you want a virtual machine, fine, fill in this form. You'll get it tomorrow.

Brian: Right.

Kris: And they claim they've been doing cloud. They claim they've been doing some Agile. But fundamentally, it's not about, "We're doing cloud. We're doing Agile. We're doing open source." It's about those mentalities, about that flexibility. Can you as a small team build something, test it, and throw it away if you don't like it? Or you can understand technologies you need to collaborate with the business, to collaborate with your peers. Or are you just going to say, "Oh, I called somebody. They're coming in three weeks and they're going to fix it."

Brian: Yeah. There's an interesting thing there and I don’t know if it's by design, but you brought up kind of the three things that you always focus on and it sounds like if they're not the primary, sometimes maybe they're the only, right? You said Agile, “Are they truly practicing Agile?” How they practice, the adoption of open source, as much for the tooling as for the culture of ownership that it indicates. Then you talked about access to resources. If we go through it, you kind of indirectly hit on process, culture and tools as three things that you need to influence. It sounds like, I assume, tell me if I'm wrong or not, if any one of those three things are missing or can't be corrected or resolved, then the chances for positive outcomes are low.

Kris: It's going to be much more painful. It's going to be a much slower process than if all the right seats are in place. I'm not saying it's going to be impossible. I'm going to be less interested in helping. It's going to be a hard fight and it's going to be a long battle. But the more of those seats that are present, the more of those requirements that are there, we're going to have a much smoother adoption and you're going to have a much smoother flow to production.

Brian: Awesome. Thank you for that. Thank you for those three things. I think that's going to help a lot of our listeners. As a matter of fact, it's going to help me. To shift gears a bit, looking at some of your posts and writings recently, you've spoken a lot about open source monitoring and measurement. So in terms of monitoring and measurement, do you see it as more of a dev problem or any ops problem in terms of realizing it and incorporating it into the process? I realize that question is an anti-pattern, but I ask it that way particularly. Are monitoring and measurement the responsibility of devs or ops?

Kris: Obviously, it's a responsibility of the team. The challenge is who creates the checks? Who creates the monitoring? Who is being woken up? Is what we see where we come from? We come from people who are building things and throwing it over the wall, and software delivery was done while offer gets commit, and that wasn't always the way we liked it. Then people started building infrastructure that was resilient, and we started monitoring our infrastructure, and we started learning, well, if ... is running, fine. We have sufficient disk space, fine. We have sufficient memory, okay. But the application is not doing what it's supposed to do. So we went one step further. We started checking the application. We started talking to the developers, like, "How do I know this thing is actually working? How do I know this thing is on? Does it still do what it needs to do?" That's a journey a lot of us have been going through. Now, together with that journey of trying to understand the behavior of the application, we also saw scale change. We went from 15 years ago we had two servers in a data center. Now, we have a couple hundred virtual machines running with a variety of applications. So managing those checks and managing what needs to be monitored was something that was really painful. Ten to fifteen years ago, if you looked at a dashboard, by the time the dashboard was read it was basically because there was ... over not looking at actual production stacks, because they were using a huge and expensive monitoring system, which they could only afford to run in production and there was no way they were going to get money from their management to actually have exactly the same system looking at their development and acceptance stacks. So monitoring was something that was built in, but not really.Open source tooling and specifically the combination of monitoring with infrastructure codes, where we define the role of a platform and we also define what should be monitored, both on the infrastructure and application level, started to make that, what John Vincent called back in 2013 or 2011, what he called "monitoring sucks." We transformed that from leveraging new open source tools, such as Icinga, Graphite, Logstash and those things, and automating that so that every time we provision something new it was automatically being monitored. It was there. It worked. And we knew that the fine-tuning was the part where we could spend time out, not setting up the monitoring, not fixing the monitoring or the _____, but actually finding those false positives and tuning them out, to appoint where if now we look at things, you're actually looking at fairly green dashboards. They have often less than one percent of checks that are acknowledged, things like that, which is completely different from before. And those are things which we couldn't achieve with proprietary software, because it was not, well, a lot of those tools we couldn't automate because they didn't understand the infrastructure's codes. They didn't understand that we want an API to talk to, that we wanted to be able to write the conflict file and trigger checks. Those tools were still stuck in, well, you'd go to a user interface. You click on the right button, then the third option on the left, and then you press submit, and then wait for three days and maybe some check shows up.

Brian: Right.

Kris: That's how open source monitoring has really pushed that movement forward.

Brian: That's interesting. I think that's true in a lot of spaces. Open source has, I think, not only resulted in purpose-built solutions, right, built by the people that have particular problems cutting out some of the fluff, but I think more importantly when it comes to enterprise adoption, it's made it affordable to innovate. It's made it affordable to do the right things is what I hear you saying, to an extent.

Kris: There used to be a time when we had licenses for software in large companies that could run on one CPU, that could run on two CPUs. Now virtualization happens, so we need 50 CPUs and 50 VMs. The license costs of those clients were already skyrocketing. Now imagine going to an ecosystem in the cloud where you have a couple of thousand nodes. You just couldn't afford the licensing for that. It's not only the cost. It's also the management of which licenses do I need. Combine that with an inferior product, with a product that doesn't do what you want, a product that was basically pushed onto you by a vendor. You saw that the open source implementations were the ones that were popping up left and right. Some were under the radar. Some were open in the wild and have been evolving.

Brian: Yeah. As I start to shift to a couple more things to ask you, and then we'll kind of get ready to wrap up, but I really want to ask about, as we talk about open source, right, I think we acknowledge how much of an enabler it's been for things like growth of monitoring and measurement. With this coming generation of software engineers, operations engineers, and the advent of freemium-based SaaS software, where do you see open source fitting in this new world of free SaaS solutions, free or low-cost SaaS solutions?

Kris: I've been, I'm not going to say close with this, but I've seen a couple of those freemium and not-so-open SaaS solutions pop up. I think people adopted them because they were easy to adopt and they were easy to work with. Then those companies end up not making their targets, end up going bankrupt. Then there has been known cases of suddenly the monitoring and the metrics that those people had spent on building just disappearing and suddenly they were flying blind again because the company that they were talking to just ceased to exist or they got acquired, but that particular business line was being dropped. That's one side of the picture. The other side of the picture is that I don't know how much percent of the world is currently already in the cloud, but if I look at my current customer base, that is still a pretty low number. I realize Europe is a different model there than the US, but the cloud is still not the default. We have a lot of things that are happening on-prem. We have a lot of setups where the software-as-a-service solution is available in the cloud, but a lot of the governments and other large organizations still want to have that same piece of software in their own datacenter.

Brian: Internal, right.

Kris: And if you do that with the freemium SaaS solution, it's not going to work because those IT departments are not going to open up their firewall rules to ship logs and metrics and things to the cloud, with both good and bad reasons. So using open source there means that you can still rebuild that stack, and you can still give them that option to run things internally, to run things the way they like.

Brian: Right.

Kris: A lot of those open solutions actually have a hosted version. A lot of those things are available. So you could basically say, "Hey, we're going to use this tool. We're going to have some external supplier who runs it for us, but if we really need to, we can still..."

Brian: Still get back in.

Kris: We can still move it back in. We can still run it ourselves. This is about vendor lock-in. This is the discussion we had 15 to 20 years ago with one vendor being a big monopolist and now we're heading pretty much in the same direction. There are more large players popping up, but this is about freedom of moving around. This is about vendor lock-in. We're not at a point yet where there is a universal API where you can say, "Hey, I'm going to send my metrics," or, "I'm going to send my logs to an API, to an endpoint, and I can choose which tool is going to …"

Brian: Process or handle it.

Kris: Yeah.

Brian: But yeah, having a way to unlock your data from a vendor, so that you have future tool choice flexibility. Yeah, I think that's an interesting take. That's why I bring it up. I have a daughter that is a CS major and I've sort of observed that while she is absolutely leveraging some of the free software and open source software around the Linux movement, there is also, like at we see with GitHub, in pursuit of easy start, easy onboarding, removing friction so I can focus on what I want to do, I'm seeing a lot of newer generation software engineers gravitate towards going in their browser, using Olaf to log in or single sign-on to log in, based on their Google account and start using something as opposed to going to SourceForge.net or Google Code and searching for…

Brian: Yeah, I have a history. I used to work for SourceForge. But as opposed to going and perusing for solutions to solve their problem. So thanks for sharing your comments on that. A couple of more questions and I'll stop bugging you, Kris. I'm really curious to ask, based on what we've talked about, coming off of open source and monitoring and measurement. What current technologies or emerging technologies do you find most exciting, empowering or enabling for what the goals of DevOps are for enabling CAMS? Is there anything in particular, ... cloud, native?

Kris: Actually, no. In a way, and you might have seen other talks, I've seen a lot of cases where the tool was giving you the opposite, specifically because people were just thinking, "Hey, this is easy. Let's do this. Let's build this. Let's click together a couple of things and, look, it works on my machine." And now we need to go and have that discussion of, “How are we going to scale this? How are we going to monitor this? How are we going to run this? How are we going to move this to production?” And that's a real challenge. A lot of people have been focusing about these tools, and they've been jumping onto all kinds of new, fancy things and saying, "Hey, this is the magic bullet. This is going to solve all of your problems." But in a way, a lot of these tools actually set them back. We literally went from the slide I had 10 years ago, where I said, "It's 5 p.m. on a Friday. Somebody walks up to my desk and says, “Here's a .... Can you put this in production?" And we went like, “But where do we host this? What sort of a whatever?” Literally, what happened, it wasn't a customer. Actually, it was a couple of days after I came out of ... Amsterdam some years ago. I was with this customer and we had a full pipeline. We could spin up new instances of the infrastructure in a couple of minutes. We could build new pipelines for the replications. Most of them were Java-based. We could basically, a couple of config files and have a completely new pipeline for the replication that was all automated. Then there's this person from ... who walks in. "So we bought this new application. So here's a container. Can you put this in production?" I realized at that point that we've completely missed it because this is exactly the same problem we had 10 years ago. Those people are just throwing stuff at it.

Brian: Interesting. Yeah, that's a different take on containers than I had.

Kris: We need to go through exactly the same discussion again. So, “How did you build this? Where did you get this from? How are we going to monitor this? How are we going to scale this?” And you still have the same two physical servers in the data center. “How are you going to manage this?” That whole discussion needs to happen again. “Why did you do that in containers or in serverless or in whatever is going to pop up next?” The technology is not going to solve the problem. When a developer says, "It works on my machine," it's probably not ready for production. That's the real challenge. And yes, you can do awesome things with containers. You can go much faster if you collaborate, if you work together. But if you end up in a situation where some developer shows up like, "I clinked around and here are some containers. I have no clue where I got them from. I guess they might be vulnerable already when you push them." We haven't solved the problem.

Brian: Yeah. I love what you're calling out there. That's a surprising take on kind of misuse or misapplication of containers as an example of a technology and it just goes back to saying technology alone is not going to solve the problem. In fact, you're looking it out. It has the ability to exacerbate the problem. You still have to communicate, collaborate, and work together.

Kris: Exactly. People really jump into, "Oh, this is shiny. This is new. Oh, look, there's this new thingie. We're going to do this new thingie,” and forget everything we learned over the past two and a half to three decades.

Brian: Right, right, right. Okay. So thank you for that as well. Unfortunately, I don't get to talk to you all night. I know that you're in Belgium, so we have to let you go at some point. So let me ask. I was really curious about this. I never really read what the explanation is. But your blog is called, "DevOps Needs Sushi." So what does that mean, and do you like sushi yourself?

Kris: I do like sushi, but if you see what “DevOps Needs Sushi” stands for, it's DNS. The title of my blog is, "Everything is a Freaking DNS Problem," which is something that I learned really early in my career. I know to this day, a lot of people, when they bump into a DNS problem, they curse at me, like, "Kris was right. It's a DNS." There's even haikus that have been written about it. The fact that “DevOps Needs Sushi” is also DNS, we're still discussing this problem. DevOps and DNS are not solved problems. It's actually a joke inside of a joke.

Brian: So let me ask. I was wondering about this. Everything is a DNS problem. You are applying that literally. You're saying that when you're diagnosing or troubleshooting problems in your data center, it oftentimes is boiling down to DNS and routing. Or are you using that figuratively?

Kris: It's pretty much the first thing you check is DNS. Even if you don't think it's going to be DNS, it's going to be DNS. I think 15 years ago I had a t-shirt made, which said on the back, "It's DNS." I wearing that at the office and people basically came to me, saw me wearing the t-shirt, walked back and said, "You were right." I was right about what?

Brian: That's funny. That is cool. All right. Well thanks for clearing up that mystery for me. Are there any final thoughts that you would like to share with our listeners? I guess not putting too much of an expectation or burden on you, any suggestions on how we collectively as a community could be better?

Kris: I think there are two things I want to say. It is not about the tools. It is about collaboration. Those shiny new tools might help you but might not help you. That's something we need to be careful about. A lot of the people who have been in the industry, they start sounding like grumpy old people who are nagging at everything they see, but they also have been seeing everything. They've been seeing things go in circles. They've had hands-on experience with things going wrong. Sometimes when they say, "This might not be the best idea," they have stories to back up what happened when they tried that before, and they don't want to experience those again. So we should definitely teach more and more people about why we started doing infrastructure as code, which problems we tried to solve with it, why we started doing Agile. Because I'm pretty sure in a couple of years, people will pop up and say, "Hey, what about ... and everything up front?" If we don't teach people, why are we still doing that? The same we see with vendor lock-in, whether it's a proprietary source or proprietary software or it's actually jumping into the one cloud vendor. There are good things about it, there are bad things about it, and we need to teach people about this. So history is important, why we're doing things the way we're doing it. It's the culture of an organization. It's the culture we need to teach people. That's something to me that as I get older is really important, bringing over that experience to young people, making them ... from their mistakes. I have a couple of interns every year, and I predict that before the end of their internship they're going to have to bump into DNS problems because I know. Each time when that happens, they go like, "Oh, he told me." Yes, I told because I've experienced. That's important. The next thing, the second thing I want to share is, we've been talking about this DevOps thing for 10 years. I think we still have a really long road to go. We have not covered the miles of ground of what needs to change or what needs to be fixed. A lot of organizations are talking the talk, but not walking the walk. A lot of organizations are not even looking at how to improve. They have not realized that they need to change yet. That's still going to be a challenge. We're going to run DevOpsDays again and again. It's the tenth year anniversary. That's someplace where we can have that discussion. Basically, I hope to see a lot of people there. But go to those local DevOpsDays. Go to have that discussion with people on how they experienced their changes, what they tried, what their failing was, what their success rate was, why they changed things and had that experience. Go to that community of people who talk to each other and share those experiences, because that's where we can learn so many things.

Brian: Phenomenal, awesome. I want to say a couple of things before we sign you off here. First, congratulations on the 10-year anniversary of DevOpsDays and thank you for starting DevOpsDays, starting the movement. I wanted to capitalize on something you said there, to tie back to something else you said earlier. Really, it's about collaboration. I think this is a movement that you and Patrick and others were at the forefront of, but really this is our movement and it's up to us as practitioners to get together, engage, identify what needs to be solved and solve problems together. I think, Kris, the information, what you've done earlier in your career, all the way up to the information you shared with us today has exemplified that. So I want to thank you for that and I want to thank you for your time this evening.

Kris: You're welcome.

Like what you’ve heard today? Don’t miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz follow CloudBees on Twitter, Facebook, and LinkedIn.