Matty: [00:00:06] Welcome to Arrested DevOps, Episode 6, DevOps Mythbusters. I’m your co-host, Matt Stratton, @MattStratton on Twitter.
Trevor: [00:00:14] And I’m your co-host, Trevor Hess, @TrevorGHess on Twitter.
Matty: [00:00:17] This episode of Arrested DevOps is brought to you by TenthMagnitude, helping businesses realize true agility through DevOps and cloud-enabled innovation.
Trevor: [00:00:25] Tonight on ADO, we’re going to be talking about DevOps myths, Trevor. DevOps myths. Sorry, Matt put together this delightful new script in which he put X. And so I very immediately said, tonight we’re going to be talking about X.
Sascha: [00:00:43] It’s the Xtral.
Trevor: [00:00:44] Let’s introduce our panel. Tonight we’ve got Damon Edwards and Sascha Bates.
Damon: [00:00:50] I’m Damon Edwards. I’m a co-founder of actually 2 companies. One is DTO Solutions, you guys might know me from. It’s a DevOps and automation company. Consulting company. The other is a company called SimplifyOps, which is a new venture. It’s a much more focused thing. It’s providing support and services for the Rundeck project. So people are into kind of adding self-service capability to their operations. Rundeck is a thing they add to their toolchain, and we develop it, and we also provide training services, all that good stuff for it. So we’re heavily involved in that end of the world.
Sascha: [00:01:22] Hi, my name is Sascha Bates, and I currently work for the company Chef. Where I do automation consulting. Prior to that, I was an independent consultant where I did a lot of automation consulting as well. And I also co-host the Ship Show podcast, which is produced by my friend Paul Reed. And I don’t know, what else do I do? I have opinions on the internet, which apparently landed me here.
Damon: [00:01:45] Oh yeah, if we’re throwing our podcast out there, I gotta throw out the DevOps Cafe that John Willis and I do. I also do a lot of blogging at the DevOps blog, I was—
Matty: [00:01:58] yeah, that’s one thing I was kind of— it’s too bad John was— we were hoping John was going to be able to join us tonight too, but he had some actual real work to do. But I was all set to talk about how I consider you the Pat Hughes to John’s Ron Santo, which really only makes sense to Chicago Cubs fans.
Damon: [00:02:14] Yeah, sure, right.
Matty: [00:02:16] Might look that one up sometime. Thank you. So I think we’re ready to— we want to jump right in because we have a lot to talk about. And what we’re going to be doing in this episode is Trevor and I have compiled a list of beliefs that organizations have about DevOps. We’re going to throw them out to the panel and determine whether or not they’re true or they are myths. And we’re going to start with a basic one, which is you’re either DevOps or you’re not. It’s a, it’s a, it’s a yes or no question. Is that true?
Sascha: [00:02:43] I don’t know. I mean, no, I don’t think anything is absolute, ever.
Damon: [00:02:48] I don’t think really something can, can be DevOps. I’ll put it that way. I mean, I think that’s kind of a big— if you really look at what the definition or what your own definition of DevOps would be, what I would say DevOps is, is looking at everything from a business idea to a customer outcome that’s happening in a production environment, right? How do you streamline and remove the bottlenecks and inefficiencies and wastes that prevent you from getting through that process? To what end? So you can get fast feedback to the to the business, right? So if that’s your field of focus for DevOps, you’re never done, right? You’re never going to get to the end of it. If you look at DevOps as, I’m just going to automate everything in my build and deploy, then maybe there is an end in mind. But I think if you look at sort of what the general, more broader accepted definition of DevOps or view of DevOps, it’s more of an aspiration than it ever would be a absolute state.
Matty: [00:03:47] And I think we have our first myth. So that’s a myth.
Trevor: [00:03:51] Alright, so we’ve broken out our myths into different sections, and the first section we’ve got is myths the company kind of as a whole sees, and we’ve subcategorized that. We’ve got management beliefs. So the first management belief is DevOps only works for startups or web companies. Myth or not?
Damon: [00:04:13] I’m going to say that’s a pretty big myth. I think that it’s, again, it’s for any business, you know, that idea of fast feedback, you know, time to market, quality, these are all issues that any business suffers from. And any business that needs to run software as, you know, the underpinnings of their business, which is pretty much every business these days, can benefit from these ideas. I think you just see the web companies that have come out of the gate with this because for them, you know, number one, they have no legacy, there’s no history, right? They’re kind of, you know, they get to make it up as they draw their world as they go. And, you know, number two, this is their factory floor, this is all they do is build and operate some type of, you know, software-based service. So for them, you know, this is just life or death and it’s part of the startup, you know, battle they go through. But, so they just kind of got out in front of this first, but no, it’s a general topic.
Sascha: [00:05:14] Yeah, I’d agree. I have to say that DevOps is actually not easier, but more likely more valuable in big companies because that’s where you really need to break down those silos, not in startups where there aren’t any.
Trevor: [00:05:27] Matt, it sounds to me like we’ve got another myth confirmed.
Matty: [00:05:31] I think it is. I think that part of it is what drives it as a myth is that places are doing it in enterprise, and they may not be calling it that. I would agree with Sascha’s point, which is that’s where you really do need it. And I think it plays into some of the other myths we’re going to talk about, which are these beliefs that it doesn’t work because of these specific things, where they actually end up being much more beneficial because of— almost because of the very things that you think keep you from doing it.
Damon: [00:05:57] So yeah, I think also most of those— like, you hear us coming— we deal with a lot of enterprises, and when you hear it coming from the enterprise you know, context. It’s more that we can’t do things exactly like Facebook does, or we have a far more complex world than Facebook does, right? I mean, you know, they have multiple business lines that have been acquired over the last, you know, 20 years, multiple teams, multiple people around the world. You know, it’s a much different starting point that they’re coming from. So really, it’s just often a matter of, you know, they— it’s not that they don’t agree with the principles or they can’t somehow translate the principles to their organization. It’s more that I can’t copy those exact tools or that exact way of doing things, so therefore it must not be good for my organization.
Sascha: [00:06:39] My special snowflake is too special.
Matty: [00:06:40] Yeah, exactly. I actually was specifically told, you’re the second person to come in and compare us to Netflix. And I said, I’m not comparing you to Netflix. I’m using Netflix as an example, but yes, you guys are not Netflix. So that’s kind of to your point, oh, we’re not Facebook, so it doesn’t work. Well, we’re not Netflix. Doesn’t apply.
Trevor: [00:07:01] And always an excuse.
Damon: [00:07:04] I mean, it feels like the most sacred thing in any organization, or, you know, the thing in any organization is the, is the, you know, it’s the way we’ve always done it, right? It’s like, well, that’s the way we’ve always done it. We couldn’t do it any other way. So more often than not, you’re fighting that, right? And that’s the thing that makes them feel like we could never move like one of those other organizations because that’s not the way we do it.
Sascha: [00:07:23] And that’s the first thing you actually do want to question, because a lot of times the reason that people are doing things the way they’ve always done it is for a reason that doesn’t even— isn’t even valid anymore, and often was implemented by somebody who isn’t even there anymore.
Damon: [00:07:34] Yeah, it’s the hallway requirements, right? It’s like, well, somebody told me that that’s the way we’re supposed to do it, so of course that’s the way I’m doing it.
Matty: [00:07:41] And then you also get the— I feel people get back on their heels about that too, if you— because they feel defensive, even like you said, even if it wasn’t their decision. And I’ve, you know, told clients before, and I said, nobody does things because they’re dumb, right? There’s always a reason that it happened, but—
Trevor: [00:07:59] Is that reason still valid?
Matty: [00:08:00] Right. Doesn’t mean we can’t change it. So, I think that’s busted.
Trevor: [00:08:05] Absolutely. No, it’s confirmed. It is a myth.
Matty: [00:08:07] Confirmed, yeah. What’s wrong? I told you. This is why I edit this thing. So I don’t—
Trevor: [00:08:12] That has to stay in because my script fail is going to stay in too.
Matty: [00:08:15] Yeah. So the next myth, which goes along those lines, is the belief that DevOps doesn’t scale. And I hear this a lot, which says, oh, it’s fine when we have a small team, but it won’t scale to a large organization or to a larger team or a larger project.
Sascha: [00:08:30] I think it does. I think it just really depends on how you do it, and there are different ways to implement this kind of a strategy, right? Maybe you can’t have like one giant room full of people in an enterprise the size of, say, GE or Microsoft, or I can’t think of anything, but you know, like big places. But there are ways to mix it up in ways that are not maybe the way a startup does it with 10 people or whatever. But there are ways to have floating experts who are cross-functional team members and generalists and things like that. And there are ways to mix it up in such a way that you actually can have that kind of flexibility and generalist knowledge across teams and can still support things that you are trying to create. I really think that you can.
Damon: [00:09:15] Yeah, I’d actually argue that DevOps is actually— or thinking about DevOps is something that you really only need to do in larger organizations. If you have— if you’re the classic 5-person-in-a-garage startup, you don’t have any DevOps problems. You don’t have any misalignment problems. You don’t have silos because everyone’s on the same team, everyone’s doing whatever has to be done, and you’ve got one goal, which is find out how to go as far as you can without running out of money. So, it’s pretty simple. There are no DevOps problems there. It’s when you get to larger organizations, as you start to grow up, as you start to scale, that these silos start to form, and these silos and these disconnects and the bottlenecks and the bad handoffs, and that’s where these DevOps problems start to occur, that you start to need to actually think about how do you bring a DevOps mindset or a DevOps style of working into your organization. So I wouldn’t even say it’s a question of does it scale. It’s a question of, I think, it becomes more and more essential as you scale. And again, it’s not like a methodology. It’s not like scaling agile. It’s a mindset. It’s a goal. It’s a set of practices. So, you know, by its nature, it’s not a thing whether it will scale or won’t scale. You just have to adjust your mindset or adjust your practices based on whether you’re talking about, you know, 2 teams of 10 people or, you know, 5 teams of 500 people each. Indeed. I’m starting to sense a pattern here.
Matty: [00:10:46] I told you, I actually tried to not have them be so blatant, but I do think they become a little— but I do think they’re pretty prevalent beliefs because a lot of this came from things that I was finding with customers saying this is why we can’t do this stuff.
Sascha: [00:11:02] Well, and I think it’s important to point out, I guess we should probably talk about this a little bit more, that this is hard. I mean, and the bigger your family, the harder it is to make stuff work. So I mean, it’s not easy. It’s not— there’s no magic sparkle dust, right? You didn’t buy that. That didn’t come in the box. So I mean, I think that’s what really people are like, why can’t you give us the magic sparkle dust? And we’re like, well, you can’t. I mean, this is just like anything else, like any other organizational challenge in that you have to work at stuff and you have to give a shit. You have to help other people give a shit. If they don’t, then nothing is ever going to work because you can’t make people do this stuff.
Trevor: [00:11:39] Right.
Damon: [00:11:39] I mean, people are hard, right? I mean, this is always— this is something which isn’t— this is not a technology-specific problem. I mean, this was the same problem in manufacturing. It’s the same problem in organizing armies. I mean, this has been a problem throughout history whenever you try to enable people. We try to bring people together to work together to achieve some goal. This has always been a problem, and we shouldn’t think we’re special snowflakes as an industry, even though we do, that we’re somehow rethinking the world here or kind of thinking outside of the box here. If you look back to manufacturing history, I mean, these problems have all been lived through, and it’s just now being applied to a new— to a different discipline. You know, this is— on its face, it’s human behavior and organizational dynamics far before you ever even think about any technology.
Trevor: [00:12:31] Which brings us to our next myth. You can’t do DevOps without being Agile.
Sascha: [00:12:38] I think that you won’t be able to help it, I guess. But I don’t think that you have to go into DevOps going, we must also be Agile. But I think that in order to do a lot of the DevOps things that people want to do, you have to understand again, like what Damon was saying with speed to delivery and things like that. A lot of Agile and DevOps and Kanban and things all have the same goal in mind, which is really fast turnover times for feedback loops so that things are taken care of quickly.
Damon: [00:13:05] Yeah, that’s exactly— I mean, again, it just goes down to definitions, right? I think there is unfortunately a large percentage of the world out there that equates equates Agile to Scrum, right? You say, are you Agile? They’re really asking, do you guys do Scrum, right? So, you know, if that’s your definition of it, then no, one’s not really dependent on the other. But if you’re, as Sascha was talking about, if you’re really talking about, you know, fast feedback and small batch sizes and single-piece flow and sort of all the classic principles that underpin, you know, all the lean principles that underpin what we think of today as Agile, then you really can’t escape getting there. In fact, Gary Gruver, I keep forgetting his last name, but he ran the HP firmware division for the printers, the firmware group for the printers, and he did a book called Scaling Agile.
Matty: [00:13:58] This one.
Damon: [00:13:59] That one, there you go. Yeah, is it Groover? Large Scale Agile, what’s the name of the book?
Matty: [00:14:03] Yeah, it’s A Practical Approach to Large Scale Agile Development.
Damon: [00:14:06] Yes, God, I met the guy and I feel sorry about it, I keep mangling his name. But yeah, he’s actually, it’s a fantastic book, but the whole point of the story is You read that and you’re like, this is the Continuous Delivery book applied. It’s all the same principles. It’s all translated. And wow, isn’t that funny? It’s a printer firmware division. Like, you know, that’s, that’s, that’s an interesting story. But the real interesting story is they figured all that out without actually going out and reading all those books. So they read them all afterwards and they mapped all those ideas back to the stuff they were already doing. They just started out and said, how can we do a better job of delivering software? How can we be more responsive? How can we stop these quality problems we’ve had in the past? How can we improve our throughput? They kind of assembled all these ideas just by thinking through the problems, and when they got done at the end, you compare that to, you know, what we think of now as continuous delivery and agile and all that good stuff, it’s pretty much a one-to-one match. So I think it’s kind of inescapable.
Matty: [00:15:04] The funny thing with that book, and there’s just one little anecdote, not to go off the rails, but it cracks me up. So the first episode of DevOps Cafe I ever listened to was the one with Jez Humble. I was listening to it in my car, and he was explaining continuous delivery. I was sitting there in my car yelling at the radio, that won’t work. That doesn’t work. This won’t work for us, blah, blah, blah. Then he brings up that HP book, and I went, oh, okay. Never mind.
Sascha: [00:15:31] That’s great.
Matty: [00:15:33] I think my thought on this, not doing it— I think you can. I would go so far as to say this is not necessarily a myth. I agree with Sascha’s point that it can be challenging, but you can still have— just like you can, for the same reason that we say it will work in an enterprise, if you aren’t necessarily looking at the feedback loop, there’s still value in breaking down the silos, and there’s still value in coordinating the knowledge work. And there’s a specific enterprise that I worked in that the team was very DevOpsy, but it was not an agile team, and it didn’t work to be agile for the product. It wasn’t a product that worked well for small feedback loops, but it helped us substantially to have a pretty clean line, or lack of line, between our sysadmins and the developers. So I don’t think this is a myth, or I think it is a— I’m so confused about what’s positive or not. No, it’s not a myth. It is a myth.
Trevor: [00:16:30] It’s plausible.
Damon: [00:16:31] Yeah, well, yeah, the Agile principles, the actual things. I don’t mean the ones that you sign on the Agile Manifesto. I mean the principles that allow— that people put into place when they really go Agile are the same principles you’re going to be applying to a broader domain when you’re thinking DevOps.
Matty: [00:16:50] So I was right, it is a myth. No, it’s not a myth because it says you— there’s too many negatives in this thing. Here’s my answer. My belief is you can be DevOps without being Agile. Whether that means this is a myth or not, I don’t know. That’s what I’m trying to say. I think that’s to Sascha’s point, you can do it, it just might be harder.
Trevor: [00:17:09] So it is not a myth, it is true.
Matty: [00:17:12] No, it’s not, because it says— oh my God. Drink more.
Sascha: [00:17:17] They’re not mutually exclusive and they’re not required. I mean, one does not require the other. I mean, they’re correlation without causation in some ways, and they’re apples and oranges in other ways. So I mean, you need to do what works for you. I think that you’ll find that eventually you’re going to have to have some kind of organizational flow, whether that’s, you know, part of the Agile Scrum or the Kanban or like your own made-up fun. I have no idea, right?
Matty: [00:17:44] We’re going now into— this was a section that we called Business Semantics, and I think this is— which is what it is. And this is— I can’t wait for the answer to this one. This one I’m going to insist that Sascha goes first. So, if you’re doing DevOps, you should have a team that’s called the DevOps team. That’s the belief.
Sascha: [00:18:01] Oh, you just think I’m just going to go off and be silly about that. But—
Matty: [00:18:06] I would too.
Sascha: [00:18:06] Yeah. I don’t know. I mean, I think you’ve got to do what works for you. I think it sounds silly, and a lot of times people call things DevOps teams and what they really are are the DevTools team. And I really think that what you really need to do is be really specific about what your team does and the name that it has and its mission, regardless of what you call it. And creating a siloed team to break down silos is really highly ironic. And you just really need to be careful with what you’re doing and that it makes sense and that it isn’t fad-chasing. So be thoughtful and self-aware.
Damon: [00:18:38] I have an interesting take on this, I believe. I mean, on one hand, I’ve always railed against the idea of creating a DevOps team, right? If it’s just— if you’re going to create a silo, or really just a renaming of the silos or reshuffling of the silos doesn’t get you It doesn’t really get you anywhere. You know, there was— in fact, I think we see a lot of times enterprises, there was the point of contention, right? The point where it all goes wrong is the release function, right? It’s the build and deploy team that it all went terribly wrong. And someone put it once great that, you know, they’re a— it’s the canary in the coal mine, right? And so when the canary falls over dead, Instead of saying, hey, we’ve got gas in the coal mine, everybody says, well, we need a stronger canary. We need a better canary. The canary must be all screwed up. So we’ve got a new canary. So what are we going to do? Oh, no problem. They’re no longer the release team. They’re the DevOps team. We’ve got DevOps. We’re going to solve all of our problems, right? Again, they just kind of renamed the silo. I think that’s a bad, dangerous thing. I think it’s too easy to do that, so I always recommend against— to say, hey, It’s just, don’t do that. Call them something else if you want to say less.
Sascha: [00:19:47] Yeah, I mean, a lot of times it is. It’s the release engineering team or the DevTools team. And if you just rebrand the release engineers to DevOps, they aren’t going to be happy about that either. I mean, people don’t want to be branded like that a lot of times. And folks who have been doing certain things for years and now are all of a sudden getting a new title like that feel like they’ve been doing the same thing already and they haven’t been appreciated. And now you don’t really see them at all. You’re just stamping a label on them.
Matty: [00:20:13] I think the other thing that can come into play that I’ve seen— I mean, I’ve seen places where, like you said, where it’s just the developer tools team and that’s what they— they just rename them that, or it’s release engineering. But also I’ve seen places where they do build a new team and it’s almost to go around ops. It’s like they take developers and they say, now you’re going to be DevOps and you’re going to do the ops stuff as well, but I still have my legacy sysadmins and they really get It does not break down the silos. I mean, it makes things worse.
Damon: [00:20:41] So the new name for that— there’s a new name for that— and that’s cloud operations. So we see this at a number of enterprises. They call it cloud operations, and it’s basically like application operations that used to be a thing. You’d have your application operations and your infrastructure operations, and the app ops guys have gotten together with the release guys and have created the cloud operations team, and they’re all focused on deploying to the the, you know, whether it’s Amazon in some cases or it’s their own private cloud, and as a way to go around the operations guys. So that’s— we’ve seen that one, but I want to go back to the idea of, is there— can you have a DevOps team? And this is, I think, the peculiar, you know, part of my answer I was alluding to, that I think there are certain scenarios where putting a team in charge of this type of thing is actually— can be done correctly. And I think there’s sort of 2 ways it can be done. One is if you think about sort of the Toyota Production System way of doing things. They had their chief engineer, or they had their— some people called it in the lean world their value stream manager, which is somebody who is responsible for the flow of work and the quality of work through the end-to-end system. It’s like they’re the overarching control of the design, the production, everything for that particular product. So if you were the chief engineer for the Toyota Prius, you would, you know, be responsible for that end-to-end process. You need to talk to the design guys, the production guys, making sure that the parts Part suppliers are moving, everything is flowing through that organization. Very high-pressure job, but have that overarching view of production of the thing you’re trying to do. So I’ve seen organizations that have tried to anoint that type of role, that type of position, that kind of manager of the value stream. I think that could work. It’s much more of an architecture job. And I think a model that works for, or really should be looked at, in large organizations you can’t escape having specialization. You can’t escape having the combining a lot of like things together because we’re going to get an economy of scale, or these all happen to be in one part of the world. So, you know, the ones that I think have been very successful in this model, sort of like before you referenced Netflix, and Roy Rapoport had a great presentation called Metrics at Netflix. That would be weird if it was at Etsy. Metrics at Netflix, that was a great talk about this, how whenever they’re going to have a silo for something, The effect is instead of creating the metrics and monitoring team that when you want to monitor something, you fill a ticket out and they will go and configure the monitoring tools to make things happen for you. They have a, you know, your job is someone is in charge of that, but their job is to make a service and APIs and libraries that other people in the organization can consume, right. So it’s no longer there is a third party that will do the work for you. It’s someone who is creating tools that you can use to get your job your job done. So it’s almost like you create— you still have a silo, but that silo, their job is to create a service that will then be consumed on demand, you know, on a pull basis by the rest of the organization who needs it. I think that combo of things, you know, that combo of the architect-type person who’s looking at the end-to-end process at all times and coaching and trying to drive things along, and that operational capability as a service, I.e., release tooling and that type of stuff. I think those 2 things combined can be a DevOps-like organization that is there to drive it throughout the organization. But if you put the DevOps— as soon as you put the DevOps title on it, you risk falling right back to, well, everyone will say, that’s the DevOps team’s, that’s their problem, let’s just push all the responsibility on them. New silo created. So end of long rant. Sorry about that.
Sascha: [00:24:17] Also, I had a client recently who said, yes, we have a DevOps team. We’re not really sure what they do. We just had somebody who moved over there and he’s still not really sure what they do. It’s important to not fall into that.
Trevor: [00:24:29] That’s always useful.
Matty: [00:24:30] I don’t know if it’s prevalent in other areas, but in Chicago right now, DevOps engineer is synonymous with sysadmin. There’s no jobs for sysadmins in Chicago anymore. They’re all for DevOps engineers, but you read the job rec and it’s just a sysadmin.
Damon: [00:24:46] For a while it was actually good for hiring because it gave a little bit of a clue indication. It’s like, hey, that guy talks about DevOps in his job and what he does in his job, you know, he or she.
Trevor: [00:24:57] Like, that might—
Damon: [00:24:57] that’s great. They must know what they’re talking about. Or likewise, if someone had a job that was like, look for somebody who’s hip on these job skills, you know, these DevOps skills, someone might say, oh, this company might actually have a clue about what’s going on. So I think there was some of that sort of clueness, and that helped people in hiring. And I think that’s driven why you see this a lot in people’s job titles.
Trevor: [00:25:17] I see on the development side, I’m seeing a lot of DevOps being referred to as knowing developer tools.
Sascha: [00:25:24] Really?
Trevor: [00:25:24] Knowing CI, knowing PowerShell, knowing, you know, those things. Knowing how to use Git, I’ve seen referred to as a DevOps skill, which was interesting. You know, stuff like that.
Sascha: [00:25:39] The words DevOps tools make me cry, and if I read them— I’ve been doing a lot of conference— I’ve been reading a lot of conference proposals lately for 2 or 3 different conferences, and I have really had a hard time avoiding giving things just straight-up thumbs down when I see those words. I can’t cope. I can’t cope at all.
Matty: [00:25:56] Alright, so I think that’s not necessarily a myth. I think the word should is what’s hard in there.
Trevor: [00:26:05] Yeah, which brings us to our next question, which is kind of really well following on to that discussion. We can’t do DevOps because we need to have separation of duties.
Sascha: [00:26:15] Oh, that is— let me go first.
Trevor: [00:26:17] Please, go right ahead.
Sascha: [00:26:21] That is straight up bullshit.
Trevor: [00:26:23] It’s called a myth.
Sascha: [00:26:26] Oh, is that the word for it? Okay.
Matty: [00:26:28] I think you had it right the first time.
Sascha: [00:26:30] I mean, so what I love about this is there’s a great 15-minute video on the Continuous Delivery site where Jez interviewed Mike Rambetsy from Etsy, and they talked about separation of duties. One of the things that you get with— this is the other thing, is that I have a thing for configuration management. One of the things that you get with managing your environments better is that when you absolutely need separation of duties, you can do it, but you don’t have to inflict separation of duties everywhere and everything because one couple of places needs it. Yes, you need customer data to stay safe, and maybe you can’t have developers logging into production data, and you have to do all of these things that keeps that stuff safe. You don’t have to like lock everything in Fort Knox because you’ve got one gold bar in your giant pile of straw, right? I mean, it’s just that’s, that’s not even a thing. All you have to do is make sure that your database is locked away safely, correctly, but you just separate everything else from it. When you have something that needs that kind of separation of duties, you isolate it. You don’t isolate everything else with it, right?
Matty: [00:27:35] Right. So I would agree. I think it’s a— it’s—
Sascha: [00:27:38] that one really makes me mad.
Matty: [00:27:39] Well, I think like a lot of these myths, they really could be rebranded as excuses because it’s easy, right? People like to throw the compliance word around. Oh, we can’t do that. Compliance, compliance, compliance, you know, and you don’t actually look at it and say, what does that mean? You know, again, to your point, compliance does not necessarily mean that it’s every single piece. It’s your auditable stuff. That you have to track all your changes.
Trevor: [00:28:04] When I was writing the list together, it was really hard not to use the word excuse. Damon, do you have something to add there?
Damon: [00:28:15] Yeah, well, you know, so this is one of those things that, going back to what Sascha said the first time, is people aren’t really sure why they’re doing things, right? They just know that they’ve been told this is the way it’s supposed to be done. The separation of concerns issue is one that goes back to a lot of organizations. There’s some external force that’s telling them to do this, right? Whether it’s PCI compliance or SOX audit or HIPAA or some other thing that’s driving them to do this. On one side, it’s the idea of, yes, you need to protect your data, and there is that access to that data. In others, it’s this idea that you need to protect against harmful change, right? So the idea that, well, if, you know, Trevor has access to the source code and Trevor has access to the production servers, then Trevor can just, you know, can steal everything and, you know, become an evil supervillain, right? So the idea is, well, if we have, you know, where Matt is the one that has access to the source code, but Trevor is the one that has access to the, you know, production servers, that’s going to solve the problem. When the reality is the control there is quite weak itself because Matt just says, hey, I got a change for you, Trevor, and Trevor goes, oh great, you know, one of 500, and just goes and deploys it. No one’s actually done any validation there. So you can actually argue, and this is really not truly a DevOps thing. In fact, DevOps doesn’t— I mean, I don’t think DevOps would have any— it’s just how do we bring these 2 things closer together. If part of the requirements here is to have that control, there’s, you know, there’s plenty of ways to do it. You can argue that For example, if you use continuous— this comes up in the idea of continuous delivery or continuous deployment— that if you’ve actually built up this immune system where everybody is contributing to this deployment system, where you have people putting tests in there, they’re putting different checks, and you have this gauntlet, this immune system to which all your changes have to go through. If Matt then commits his code and it starts on its merry way, it’s actually passing a review process. That many people have weighed into. There is no single point of failure there in terms of somebody can go around that process. You can actually argue that in this— some of these, you know, high iteration, high throughput environments that are following that model, that true continuous delivery model where they have all that automated testing and checks and balances put into place, they’re actually more secure and more compliant than somebody who just has, you know, the random role that can check into the source code and the random role that can that can deploy the servers. But part of that is, you know, you have to understand fundamentally what that means and then be able to convey that to the auditors and the people who are putting those requirements on you. And in fact, most of those requirements, separation of concerns is not really actually a thing. It’s not even something that they’re really— that they’re even checking for. People just assume that’s what has to take place.
Trevor: [00:31:11] Right. Sounds like we have Another confirmed myth going by our current semantics. The statement, we can’t do DevOps because we need separation of duties, is false. Or as Sascha would call it—
Matty: [00:31:25] Exactly. We may have our first explicit—
Sascha: [00:31:30] Oh God, I work for a product company now. I gotta stop talking like that.
Matty: [00:31:33] We know who your boss is, Sascha. From what I understand, you got a lot to go before you catch up to him.
Sascha: [00:31:41] Well, I guess that is true. That’s good. But you know what? Marketing doesn’t care. They’re going to come after me anyway. It’s not Adam I have to worry about. It’s marketing.
Trevor: [00:31:53] Well, speaking of different teams, that brings us to the next section, which is things about DevOps and teams.
Matty: [00:32:01] So we kind of broke this into what ops people assume DevOps means and what dev people assume DevOps means. Being the ops of the rest of DevOps, of this I’ll speak for the ops, or what the beliefs are. And one of the big ones that ops people believe, for better or for worse, is that DevOps means that developers are doing the job of ops, are doing operations work. Is that true?
Sascha: [00:32:23] Well, it depends on what the day-to-day stuff is. I mean, in my opinion, first of all, you have to— before we can even have this conversation, we have to actually establish what are the day-to-day things that operations does. And if it’s a bunch of tedious bullshit that nobody should do, then nobody should be doing that. And that should all be automated. Second of all, application developers should be seeing to the health of their app, whether that means they’re building in monitoring and stability to it when they build it and then caring for it once it goes to production still, then yeah. But the ops aren’t babysitters. Once they’re freed up from a lot of the stuff that’s app-related, they can be doing stuff to work on stabilizing infrastructure and more important things. That all kind of centers around the whole automation deal as well. You automate all that crap out of the way so that you can work on important stuff. You know, developers can see to a lot of the care and feeding of their app if they have the tools in place to do it. So I don’t know what that really means, except that developers need to understand shit, and operations folks need to understand shit, and there’s a lot of overlap.
Matty: [00:33:21] I think what the truth of it is that the developers can make the automation— I’m sorry, developers can make the operations work easier, right, or less is your point. You know, by having the apps that are production ready.
Sascha: [00:33:40] It goes back to that short feedback loop too. So you dump something in production and you don’t set it and forget it, right? I mean, technically you want to have something in production and you want to constantly be working on that feedback loop to improve it. And that is a core concept of both Agile and DevOps really, is the short feedback loop. And yeah, I mean, if you have an app that’s actively being developed, then I think developers are going to be actively involved. And it really depends and what kind of tools that, you know, people have available to them.
Damon: [00:34:07] There’s this idea that we talk about a lot, which is operations as a service, right? That, you know, in any relationship in an organization, you know, there’s people who produce things and people who consume things, right? Any of these handoffs. And, you know, if you look at what operations, you know, has been doing historically, you know, it’s all very ticket-driven, right? It’s very much like, you know, I’m going to do everything, I’m going to be the doers. Operations is going to do everything for you. That’s highly ineffective, and also it’s just going to be always a massive bottleneck because developers always outweigh operations, outnumber operations, and often it’s a vast outnumbering of operations. So, you know, we look to say, well, you know, there are certain things operations does that are good things. Operations knows how to do certain things very well, so turn those things into services that the rest of the organization can consume. I.e., deployment. That’s a great one, right? Or allowing people to manage their own QA and dev environments, or providing restarts, or providing self-service capabilities for people to run various data processing jobs, or diagnostics on particular services. All the things that operations gets into the habit of having to do all the time, turn those things into services that you can then leverage the mass numbers, the vast numbers of the rest of the organization to actually do that work, and that frees up operations to actually focus on adding value to the organization. Whether it’s teaching other groups how to build scalable, high-performance, secure applications, or it’s doing things internally to improve the infrastructure, improve the tooling, or move the ball forward.
Matty: [00:35:50] Yep, so I think it’s, in a way, it’s true. They don’t do the work, but they facilitate the work, and you get the work out of the way if you’re in DevOps.
Damon: [00:36:00] Yeah, I mean, it’s— you want to change— actually, John Willis called it the 80/20 flop, right? He’s like, right now, classically, operations is spending 80%, probably 90, like 90/10 of their time in the muck, right? They’re mucking around, they’re doing all the crap, they’re doing stuff that’s not really adding value to the organization, right? Versus 10% of the time they are actually moving the needle forward. They are actually improving the lot of the organization. So we need to flip that around so, you know, they are spending, you know, 80-90% of their time moving the ball forward and adding value to the organization and managing the exceptions and the edge cases, and the other— the rest of the time, you know, that small amount of time they are doing, you know, stuff in the muck.
Matty: [00:36:44] Alright, so Trevor, dev perspective on the myth.
Trevor: [00:36:48] Well, DevOps means developers get admin access in production, right?
Sascha: [00:36:52] I totally think that’s legit. I think that the way I usually say it short is that if you treat developers like children, they’re always going to be children. And nobody breaks things on purpose, and people are going to be pretty careful most of the time. So I don’t see why not. If everybody else is logging into production, why can’t developers too? And flippantly, I mean, why is anybody logging into production in this day and age of advanced tooling? So, it’s more a matter of what kind of tools do you have in place to make sure that developers can get their work done and see how their app is performing. Because, you know, contrary to what most operations teams believe, and I have been on one, developers don’t want to hand you shit that breaks. And they don’t want to walk away from it and never see it again because it’s got their name on it. They actually give a shit about what they’re deploying, and if you actually give them the tools to monitor and care for their app, they’re going to want to.
Matty: [00:37:49] That’s your point, like, why is anybody doing it? The first thing I want to do, one callout, I’ll put it in the show notes. You guys at Chip Show did a whole episode about this.
Sascha: [00:37:57] Uh-huh, we did. It was a really interesting episode.
Matty: [00:37:59] I really liked it. I don’t remember who it was that mentioned it, but I’ve kind of taken it to heart and I’ve used it in a lot of conversations with customers, which is— and this sounds like something you would have said, Sascha— but it was something to the effect of that as soon as you don’t allow, you know, that you make it an exception or like you said, treat developers like children, you lose control over your production environment because you never know what it’s like because you never know if someone’s hiding things.
Sascha: [00:38:25] Right. Oh yes, that’s the blameless culture for sure.
Matty: [00:38:28] The blameless culture piece of that, yeah.
Sascha: [00:38:30] I mean, if you make it a crime to make mistakes, people are not going to own up to mistakes and you’re never going to know.
Matty: [00:38:37] And I always also like when you said, why are you logging into production? I call out the Mark Burgess quote, which is that every time someone logs onto a system interactively, they compromise everybody’s understanding of that system. And I agree. I mean, that should— like you said, nobody should be logging into anything. I had a team once that, fortunately, I guess for those guys, I don’t manage them anymore, but it was getting to the point that we were going to start auditing interactive logins and it was going to be part of their review. Because our automation was such that it wasn’t required. And pot in the kettle, I was the worst of it, right? Like, you know, so that’s why I shouldn’t manage people.
Damon: [00:39:13] So that—
Trevor: [00:39:14] I was going to say that kind of also answers the following myth as well, which was developers can’t be trusted. So it sounds like that is a myth if—
Sascha: [00:39:25] I think Damon wants to jump in as well.
Trevor: [00:39:26] If you treat them as children.
Damon: [00:39:27] Yeah, so I mean, so like one time I think there’s— hear what you’re saying here, right? I mean, on one hand you’re saying nobody needs root, right? Which I totally believe in actually because you should have the tooling in place.
Sascha: [00:39:40] I think that’s a great place to work towards.
Damon: [00:39:42] Right, so nobody needs root, right? So, but then on the other hand you say, you know, don’t treat developers like children. But at the same time I think it’s a little bit childish when developers say, you know, I have to have root access, trust me, trust me, you know, give it to me. The problem here is not are you giving developers root access or not? The problem is, do developers have the level of access? And really, it’s, do they have the level of control and visibility that you need to, you know, to actually let them get their job done, right? So there’s a certain amount of freedom you need to give them, but there’s also a certain amount of responsibility that has to come with that freedom. It’s kind of like this, you know, you want to centralize standards, centralize— yes, centralized standards and centralized, you know, kind of process and tooling ideas. And you want to decentralize control to, you know, to the point where it needs to be done. I think the focus is on that. I think actually giving everybody root access, you’re actually losing control in a very important way in a large organization. It’s very difficult to track, you know, what is going on, what isn’t going on. Of course you can trust everybody, allegedly, but I think, you know, the larger the organization, you need to be able to verify what’s actually happening, what’s actually going on. And I think, you know, people should respect that in a large organization and realize that, hey, if you’re, you know, if you’re Target, to use that, and you have, you know, 500, 1,000, I don’t know how many people are in the Target organization. Aren’t they up in— are they in Minneapolis near you? Yeah, Minnesota. Yeah, right. How many people are in their technology organization, right? Thousands. Thousands, right. To say, hey, of those, maybe, you know, say a third are developers, 300, 400. Let’s give all of them root access, let’s give all the ops people root access and just trust everybody. You know, it’s a little bit, I think, naive and it’s never going to happen, especially in this kind of age of high compliance and large risk in big organizations. So rather focusing on that, saying give me all access pass to everything, I think it’s a matter of focusing on, you know, do we have the right tooling in place that gives people the control and the visibility that they need. And that’s kind of going back to that operations as a service concept or idea that if you’ve given somebody all the buttons they need to push to get their job done and access to all the information that they need to get their job done, then everybody should be happy working within their respective areas. And you’ve closed your risk down to the smallest footprint possible without constraining people from doing what they have to do.
Matty: [00:42:15] I agree. We aspire to not need root, but there is also the realism of what we can expect. So I know we always try not to be too tool-oriented, but— and I know we all hate the, you know, download the DevOps, and DevOps is about the tools, and we know it’s about people and about culture, but this is one that I hear a lot, and I might have some personal beliefs on, but I have a hard time. A lot of these myths are very absolute, and that’s what makes them kind of seem ridiculous. So I’m going to reword this one a little bit. I’m going to say, DevOps works best with open source tools and operating systems, i.e., I can’t do DevOps in a Microsoft shop. Is that true or a myth?
Damon: [00:42:57] Yeah, so the question is about Microsoft? Can you do DevOps in a Microsoft shop?
Matty: [00:43:00] I think it’s a better way. I mean, I was using the example of saying doesn’t work in a Microsoft shop. But the real belief that I wanted to state is that DevOps works better with open source tools and operating systems.
Damon: [00:43:11] Ah, okay. I think the issue is that the open source world, I think, went to small composable, you know, small tools that do small things excellently well. And then you basically got, you know, you compose those into toolchains, sort of the Unix toolchain style of things versus commercial vendor tools that basically said, hey, you only want to talk to so many vendors, so you buy everything from me. I’m going to give you the entire stack, and it’s all integrated together. And because of that, I think you had one thing that was small, lightweight, was very API-driven, was very friendly and easy to integrate, often very source-driven because usually we’re kind of source-driven type folks that are using them versus the very point-and-clicky large integrated stacks that don’t have those qualifications, right? So I think in places where you see commercial tools that have the APIs and have the flexibility and have the composability that the open source tools do, I think you’ll see those succeed. So I think it’s more a question of the ease of use and the capabilities of those tools than it is the the fact whether they’re open source or not.
Matty: [00:44:27] I’ll— not to interrupt, but I mean, like, one of the things I see, and again, big— I’m very agnostic. We do work all over the place. I happen to be doing a lot of consulting now where we have a lot of Microsoft clients, but we really embrace a lot of the open source tools for doing the DevOps work. And I think that there is something to be said that it is easier when you’re using more of an open or Linux operating system system as opposed to Microsoft OS just because there’s more tools. You know, we run into things like Test Kitchen where it’s like, hey, it’s not that we don’t want to support Windows, we just don’t know how to do it. We just don’t work there. You know, where we’re getting there. So I think things are turning around a little bit, but it is a little challenging and sometimes frustrating when you really want to embrace and you say, hey, no, I don’t want to use System Center. I want to use these open tools that are out there, but I happen to be on a different stack. It can sometimes get a little frustrating trying to implement that.
Sascha: [00:45:21] I completely agree, really. I don’t know that I have anything else to add to that.
Damon: [00:45:25] Yeah, I think a lot of that’s the legacy of it. There’s— we did a DevOps Cafe with Jeffrey Snover, who’s the Chief Architect for Windows Server. He talks a lot about— he talks about why, right? That, you know, that there’s a culture of Microsoft was about the GUI, whether you thought Microsoft GUIs were pretty or not. You know, they put the GUI on the world, really, right? I mean, you know, Steve Jobs might have came up with it in the first place, but they put the GUI, they put the GUI on the world. And so of course everything’s going to have a GUI, and that was just sort of their way of doing things. And, you know, better for worse, they said, hey, if you fall into our set of tools and read our set of books, you’ll always have a job being, you know, a Microsoft admin or Microsoft developer. So, you know, they just had a legacy of closed kind of systems. You look at like the new PowerShell stuff, it’s, it’s You know, looks good. I mean, I think they can do some cool stuff. It’s just a question of, you know, will the rest of the ecosystem catch up with it, and will they be able to, you know, kind of have that ubiquity across all their systems that you would find in a typical, you know, Linux environment? You know, I think eventually they’ll get there. They’re definitely playing catch-up, but there’s no— you know, again, it goes back to just, you know, you can find a way to do it. You just need to think about those requirements and translate them to, you know, all of your Microsoft tools.
Matty: [00:46:43] I think— and I remember that episode, he talks a lot about standards-based management, which was really interesting. And I make everybody in my team listen to that episode, by the way, and understand. But one of the things I think is interesting too with that is the direction they’re taking over there is, for example, like with the PowerShell DSC, they say, okay, here’s a way you can do this, but we’re not necessarily saying you have to use something that we have to manage it. You can use Chef, you can do whatever. And I think there’s a lot of turning to make that a lot more accessible, which is great. You know, I think there’s— I think that direction is happening so that you don’t necessarily have to depend upon the Microsoft tool because their systems are becoming a little bit easier to manage. But it’s still not like— again, to go back to your episode when he was talking about Microsoft tools are very API-driven versus the file-driven capabilities you have in Linux, which make them really a natural fit for infrastructure as code, right? I mean, that’s why Config Manager, System Center Config Manager, I never— I can’t see how you can use that and do infrastructure as code because it’s a big database. You can’t version data, you know, like you can version recipes or whatnot. So I think it’s a shift, but I’d like— I for one would very much like to see more the capability of using the tools that we really want to use to be a little more stack agnostic. So I don’t think that’s a— I guess if we reword it to saying that it works, it’s easier with open source tools and operating systems, I think it’s true.
Trevor: [00:48:11] Here it is. Do the tools promote DevOps cultural change?
Sascha: [00:48:17] They enable it. They can. They can enable it, but I don’t know that— I think promote is too strong a word. Just because that kind of implies that the tool is pushing the change, and all it does is exacerbate friction. It exacerbates friction if you don’t have the cultural imperatives in place. If people aren’t already trying to get on board with this stuff, all it really does is irritate people. Because a lot of these tools will try to break break down some of the silos and insert tendrils into the silo walls and stuff. It’s friction as opposed to enabling people at that point, because people are not on board. So all they really are is threatened. But I mean, it can help to bring in one or two and start introducing people and concepts, or tools and concepts at the same time. But if you think you can get a tool and it’s going to do the job for you, you’re wrong.
Damon: [00:49:14] Yeah, and I think what you see more often than not is If people want to jump to the tool because tools are what we love, it’s like, you know, hey, we’re, you know, technologists.
Sascha: [00:49:24] It’s easy to talk about tools. They’re concrete.
Damon: [00:49:27] You’re right. People are squishy, right? People are like complicated, you know, with tools. People like talking, you know, it’s the show me in code, you know, sort of mentality of things. I think also it’s just the tradition of people like tools. They like talking about it. It gets them excited, right? Like technology. And so because of that, and I think also people tend to think they’re a bit more evolved or smarter than they are, or more self-aware when it comes to, you know, the culture issues than a lot of organizations actually are. So they think, oh, you know, we’ve got our— yeah, yeah, we know what we’ve got to do on the culture side. Of course, of course culture is important. But let’s talk about the tools. And then you give them the tools, and what do they do? They just recreate their old broken world in those tools, because their culture, really their organizational programming, why they do things the way they do them, is— has not been changed. Their worldview has not changed. Their view of each other, their view of the work they’re supposed to be getting done has not changed. So they just end up recreating their old world in the new set of tools, and, you know, things fail miserably, and they go on looking for the next tool. Also, one last piece about that: in a big organization, nobody ever gets fired for a successful tool implementation, right? So It’s one of those things where, hey, I got that tool in there. I got Chef in there, and Chef’s working. Chef is able to do this, do that. It’s true, right? Statement of work complete. That tool’s in there, and tool’s working, but they’re using Chef in a completely screwed up way, or they’re not— or they’re trying to push it down some other organization’s throat, or they’re not actually handing it off to other teams. All kinds of issues that could be going terribly wrong there. That have nothing to do with the tool, nothing to do with the quality of it. It’s just they’re using it the same old, same old broken way. But that can always be somebody else’s fault. So the person that did the successful tool implementation gets a gold star, they get a promotion, and, you know, they can shift the blame to the fact that— whether or not it actually helped the organization, right? You can always come up with some BS ROI statistics that make it look like you actually did something good, but if you step back far enough, you realize you spent a lot of money and a lot of time and nothing ever actually improved in your— probably got worse.
Matty: [00:51:35] Right. You got to add Chef to your resume.
Damon: [00:51:39] Right, there you go. So you can go on and get a job at a place that’s actually— that’s actually, uh—
Sascha: [00:51:44] I can’t say a thing without sounding like— that’s the problem with working for Chef now is that I just sound like a douchebag whenever I talk about anything that isn’t Chef. Like, I used to be able to have opinions about stuff, but I don’t anymore because I just sound like a jerk. It makes me sad.
Matty: [00:51:59] We won’t sell you out. So we got— we’re going to wrap up with one belief, which I think we know where we’re all going to feel on this, because if we don’t, then we’re all in the wrong podcast. But it’s this— we’ll hit this myth and then we’ll move into our checkouts. But this is the belief that DevOps doesn’t work. It’s a fad. It doesn’t accomplish anything.
Sascha: [00:52:21] It depends on what you mean when you think of DevOps, because I get really frustrated these days, and I get to the point where I don’t want to use it at all as a word because I just get mad about how it’s being used. And I think that really what you really need to do is work on your communication and collaboration and call it whatever you need to call it to get the job done. I don’t know.
Matty: [00:52:42] We’re along those lines. It’s, you know, within my company, we’re doing a lot of offerings now that has to do with this. And it’s interesting that, you know, being kind of dialed into this part of the culture and knowing This stuff, you know, I’ve been working very closely with our marketing folks to be like, we cannot use this word wrong or incorrectly because there are these things. But we also— there’s a point when it has to be somewhat embraced because that’s what our customers want the word. But we don’t sell it as fairy dust, right? You don’t do the sparkle dust like you say. You don’t say, okay, here, buy the DevOps. And while, you know, there’s that part of you that sits there and says, ah, it’s kind of going into this loaded word. It is becoming the point. And that’s kind of like why we have this podcast, because our intent here is like, you guys all have podcasts for the big thinkers. This is— now I’m just insulting our entire audience.
Trevor: [00:53:32] And our one viewer during the show left.
Matty: [00:53:37] But my point is we’re trying to be accessible. We’re saying, because that was the thing for me was when I was kind of getting started, and was I would listen to John and Damon or whatever, and I’d be like, I don’t really know what you guys are talking about, but I’m gonna stick it through. But my point is, people are knowing these words and they’re coming in and they’re wanting to understand it, and I think we can shepherd them through it. But like you said, it’s a matter of knowing what your expectation is out of it. And that’s where you could say, does it work or does it not work, is what do you mean by it?
Damon: [00:54:06] Well, you know, there’s— I think there’s a lot of people out there that, you know, they like things the way they are, right? And they have a difficult time seeing that, you know, there might be a problem out there, that things could improve, that things need to, you know, need to get better. And, you know, often that— I think that’s a matter of people are just entrenched in their silo. You know, they’ve got their head down, they’re doing what they want to do. Suddenly you’re coming in at them and you’re giving them all these new ideas like, hey, you’re a developer, you now got to care about what a production environment really looks like. You got to know about how people are actually deploying and running this thing that you’re building. In fact, I want you to actually wear this pager, not really a pager, but I want your phone to go off when something breaks at 3 o’clock in the morning. Screw you. Who are you and what are you telling me all this stuff for? That’s where I think this comes down to. I said DevOps is a management problem. The management of the organization is the thing that structured and built itself, and that’s why things are the way they are today. So it’s up to— what management has to do here, I think, is align the organization around the goal. They have to literally get people understanding why it is that they’re trying to act and what they’re trying to accomplish and make them understand the larger system that they’re working within. Because without that kind of organizational alignment, then these ideas are just, you know, a bunch of extra requirements that you’re lumping on top of somebody. Or completely misunderstood. But if you’re just saying, hey, look, this is the big picture, this is what makes the business run, this is your part over here, and these are all the bottlenecks and issues we’ve got, and we want to— our mandate is to shrink this down to where the cycle time is X, the quality is, you know, all the way up here, and everyone’s job is easier and the customer’s happy. Like, if you give people that kind of instructions and that sort of alignment view of the world, you’ll find that people will suddenly become more energized and actually go and solve the problems for you. Right? I mean, if people get aligned the right way, they just go and, and just like they created problems in the past, they’ll go and solve the problems in the future. Because, you know, I said before, people don’t show up for work looking to do the wrong thing. They don’t show up looking to make things worse. They just do what they do and they, in their world, they think they’re doing the right, the right thing. And they might be doing the right thing. Just may not be aligned with everybody else in the organization to do the right thing for the organization. So sorry.
Sascha: [00:56:36] Well, let me interject. The other side of that too is the idea that you have to figure out a way to communicate that message in a way that makes people give a shit. Because one of the big stories that I really like to tell is when I still worked for corporate several years ago, the video of the Seattle Fish Market was going all over and management, like this was a huge revelation to management. It came all the way down from the top. Like everybody has to learn to throw fish, like the Seattle Fish Market. Like, it was this thing, like, if we could all just learn to cooperate and work together like the fish throwers, kumbaya, right? And all of us at our level were like, whatever, right? So like, yeah, don’t, don’t try to like peanut butter over with kumbaya because really you need to figure out a way to make it relevant to people or it’s just gonna be bullshit coming down from senior management.
Damon: [00:57:30] You know, that’s actually an interesting point that I think this is where the responsibility comes onto the management side of things is that often if you come in with these DevOps ideas into an enterprise organization, just like if you came in with Agile before that, the managers go, yeah, that’s right. Those technology folks, they’re all screwed up.
Matty: [00:57:48] Right? Good.
Damon: [00:57:49] Go fix yourselves.
Sascha: [00:57:49] Let’s fire them.
Trevor: [00:57:50] Let’s fix them.
Damon: [00:57:51] Right, right. Go fix yourselves. They don’t realize their responsibility for that process. That would be like, I would say, like, it’s like if I went to Ford, and I grabbed any exec-level executive and I said, let’s go to a factory and tell me how you make cars. Probably the CFO could probably tell me how they make a car. They may not tell you what all the machines and people do, but they could probably say, oh, we got these suppliers, they bring it in here, and we go there, and we do this, we do that. They can walk you through their business and like, well, wow, you’re the— you’re accounting, you’re in marketing, you know, how do you know this? And they’re like, it’s our business, we make cars, of course I know how we make a car. Right, and you know, how many technology organizations is that true? Even in pure, you know, SaaS-type companies, can you walk into the executive suites and say, hey, how is software made in this organization? How do we conduct business in our organization? You know, getting the work done so we can conduct business, how does that happen? And a lot of times they can’t tell you because there’s always been this idea that, you know, we’re the high priests of IT. You know, these are not the people you’re looking for, right? It’s the Jedi droid trick, and then we all have to scurry along. And technology has used that to hide a lot of sins, hide a lot of problems, right? That, oh, this is tough stuff, you just couldn’t understand, couldn’t understand. And the business guys have used it the opposite way to say, you know, hey, you know, I don’t want to know about that stuff, you’re smarter than I am. And I think that’s got to end, and that needs to break down. And, you know, somebody probably thought from their perspective that, you know, Sascha’s example, the Seattle fish market thing with some meaningful and powerful metaphor, because that’s all they really got, right? So I think it’s as much on the business side of it to learn about technology as the technology side to learn about the business that they’re in. We can’t just say, hey, you know, I just deploy servers, get off my back, you know, you worry about your own, you know, business thing. Like, no, you need to understand the business you’re in just as much as technology needs to understand the business. The business needs to understand the technology of what they do.
Matty: [00:59:53] Agreed.
Damon: [00:59:54] I agree as well.
Matty: [00:59:55] So we’re coming up to our end here, so that is definitely busted. And let’s go through our checkouts real quick. This is the part where we just sort of give a little shout out to something cool we want our listeners to listen to.
Trevor: [01:00:10] Or check out.
Matty: [01:00:11] Yeah, that too. I can’t talk. So I got 2 checkouts real quick. One is something that, of all things, a customer told me about today. It’s a website called gitdrunk.com. That’s G-I-T-D-R-U-N-K dot com. It’s a drink, a game, forget. Lots of fun. We’ll put a link in the show notes. And I’m going to give a little bit of a shout out to— this is for any of our local to Chicago listeners— next Thursday is the Downtown Chicago Azure Meetup, but we’re collaborating with Google on this, calling it Speed Dating in the Cloud. It’s at CloudBakers, and we’ll be talking about Azure and Google Compute and Google App Engine. We’ll put a link in the show notes, so if you’re Chicago-based, come on by.
Trevor: [01:00:52] It’s fun stuff. It is.
Matty: [01:00:53] That’s how Trevor and I met, all the way back there. Speaking of Trevor, what you got?
Trevor: [01:00:58] I guess first of all, I’ve got my cat that you’ve all seen periodically popping up and affecting at me. Her name is—
Matty: [01:01:07] I wanted to check out your cat.
Trevor: [01:01:10] I held her up to see. I always forget that this is going to be a recording, because she keeps rubbing my face while I’m talking. But the other thing I want you to check out is Marvel Comics just released an API where you can look up through endpoints. You can get characters. You can get story arcs. You can get comic writers, all kinds of neat stuff, make visualizations. It’s really interesting. I’m gonna start playing around with it because, you know, something fun to teach myself some more tools with. Sascha, do you have anything fun for us to talk about?
Sascha: [01:01:54] So I have a couple things. I guess since you guys are talking about local stuff, I can toss out that tomorrow night— I’m not there, I’m in Iowa— but tomorrow night is the monthly DevOps meetup in Minneapolis, and they’re actually having— every other month they just have a go out and drink. So they’re just having their, what they call the mixer. But it happens in a bar with beer and it’s lots of fun. So that’s on meetup.com. I don’t have any of the details, but you can go find it there. Everybody’s really nice there and you should go if you are in the Minneapolis-St. Paul area. And then the other shout-out I have is it’s conference submission season. If you haven’t submitted to speak at a conference, you really should. It’s a good exercise even if you aren’t accepted. And it’s amazing the topics that you could talk about if you thought about it for 2 seconds. The first conference I ever went to was Velocity 2000-something. I heard some topics and I was like, this is a thing? This is something that we have to spend 40 minutes talking about? Really? You know a lot more than you think you know. If you have something that has been interesting in your life or something that you— if you find yourself ranting about something to friends a lot, That’s usually conference talk worthy, and you should submit, especially if you haven’t done it before, because it’s a pretty awesome way to also get people to pay for you to go to conferences. You know, it’s a lot more likely that work will pay for you to go if you can get a conference talk submitted, because that’s good business. So I think you should. The Velocity New York submission is open until the end of March. That’s the one I have off the top of my head, but there are a lot of good ones coming up, including— there are the Velocity conferences and Well, ChefConf is coming up too, and I know that Puppet Labs has theirs in August. So, and there are usually a couple of Puppet camps floating around too, and DevOps Days Philadelphia is at the end of May. So lots of good places that you could submit talks to, and you should. That’s mine.
Damon: [01:03:42] Okay, David? So speaking of speaking, I’m going to be at the QCon conference, the DevOps track, on March 5th, I believe it is. In London. So if your European listeners are out there and want to talk DevOps, definitely come by and say hi, or hit me on Twitter or something like that, and we’ll meet up. But on a total self-serving front, but I think it’s cool to the world, is Rundeck 2.0 just got launched, and it’s fully open source. Cool thing about it is that in the past, Rundeck sort of had a bit of an identity problem. It was, you know, people either got it and loved it, and other people are like, I’m not sure what I’m supposed to do with this thing. Is it like a Jenkins for operations? I’m not really I don’t get it. I think some people saw it as lightweight orchestration. Some people saw it as an operations console. Some people saw it as an engine that you can use to connect your continuous delivery pipeline together. The reality is, it kind of came on what the biggest use case people use it for, the thing it adds, is self-service. How do you enable self-service operations? You’ve got all this automation out there. Automation is kind of a solved problem. There’s a lot of details and inflation in the details, but we know how to get the bits on the box. We know how to make things dance and do what they got to do, but you still have this human-to-tool interaction where you still have, you know, operations takes place, right? And it’s that idea of, you know, how do you actually enable people to, you know, serve themselves, whether it’s you want to create a bunch of standard operating procedures to hand off to other people on your team, or you want to hand them off to QA folks or dev folks or even, God forbid, business folks. You know, how do you take those procedures and turn them into services that can be either at a button or an API somebody can use to do, you know, kind of a capstone to all your automation work you’ve been doing. So it’s out. It looks a lot better than the old one, and it’s ready to rock and roll.
Trevor: [01:05:31] Great.
Matty: [01:05:32] All right. Well, I want to give some special thanks to our guests, Damon Edwards and Sascha.
Damon: [01:05:36] Absolutely.
Matty: [01:05:37] This was amazing to have you guys join us. I think we had a great conversation. Be sure to check us out at arresteddevops.com or @ArrestedDevOps on Twitter. I’m Matt, @MattStratton on Twitter.
Trevor: [01:05:49] And I’m Trevor, @TrevorGHess on Twitter.
Matty: [01:05:52] We’re Arrested DevOps, and remember, there’s always DevOps in the banana stand.
