DevOps from the ground - CTO Advisor 049

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, welcome to episode 49 of the CTO Advisor, long-awaited podcast to record at least. I have my good friend, John Hildebrand, and we're going to talk a little bit of DevOps today. I don't think I've talked DevOps on this podcast in quite some time. John, can you go ahead and introduce yourself to the audience? Obviously, my name's John Hildebrand. For the day job, I currently work as a cloud architect for a managed service provider there in the Midwest area, ranging from Des Moines, Iowa to Kansas City.

And recently, say in the last six, eight months, I started to become a DevOps enthusiast. All right, DevOps enthusiast. So let's, first off, let's define DevOps, because there's Netflix DevOps, and then there's the DevOps where I buy a product, and now I'm DevOps-y. What defined DevOps for us? Well, one could say that the constant funny argument is we just make code really fast and fail at doing so. So the two things you just brought up there, there's the old Netflix, Etsy, a lot of the models that everybody tries to mimic.

And then there's the supposed out-of-the-can, voila, you're now DevOps. Personally, I don't think that exists, the second one. The first one, if you go read into a lot of their stories, there's a lot of culture, organizational aspects that they had to do to make that happen. I personally don't feel you can't buy that on a shelf. So that's, to me, that second one, it doesn't exist. People who go down that track immediately are setting themselves up for failure. So we're both big fans of, what's the DevOps book by Jim King?

Phoenix Project. Phoenix Project, yes, that's what it is. In that book, mystically, they take a DevOps world, or they take a very non-DevOps world, transition that to a magical DevOps paradise, life is good. You're a DevOps advocate. Is it really that simple? Well, for the most part, the underpinnings, when you read Kim's book, he talks about the three ways that are in there. For the most part, they're very simplistic ways. Unfortunately, it involves having to do a lot with humans.

The humans are complex, they are stuck in their ways, they're very resistant to change. So organizations that go down that track, a lot of the time, it takes a long time to, the old turn the ship analogy, it always takes a little bit for people to change their behaviors. A lot of the underpinnings of DevOps are about behavior changes, even on the most personal levels, all the way down to, we talk about organizational structure, but some of the components that you get into when you start reading some of those books are just interactions with your own team.

The idea, ultimately, is to try to break down things, those dreaded silos. Silos are always a big problem. Right. So, speaking of silos, and breaking down walls of change and silos, we're actually at the St. Louis VMUG User Con, and this is, I think, one of the bashes of traditional IT, where we have our virtualization admin, we have our network storage admin, and we have this traditional organization that is very resistant to change. You recently actually did a presentation at one of the VMUGs on BlameChain of DevOps and that culture.

What are some of the challenges you see in changing an organizational change? Well, DevOps usually is rooted in a ground-up type of mentality. Usually a team, smaller parts of the organization will start, and ultimately you need buy-in from the top levels of the organization. I mean, ultimately, you can't mandate culture inside of an organization, but the person sitting at the top of the food chain in cultures, they can do a pretty good job of squashing most of any sort of new movement that's starting within.

So I think a lot of it is, some of the problems that you see, people start, try to do it too broad, too much, too soon, don't try to give it, in cooking terms, they don't let it bake a little bit before they try to do more with it. You've done a lot of stuff with SAP and things like that, I wouldn't recommend that type of application or anything with development within that to ultimately go with that first. Just like any sort of other project, start small, build, and see what happens with natural progression.

So the caveat isn't that you would start with SAP first, it's that you wouldn't end up applying DevOps principles to the SAP and SAP landscape and infrastructure, you just wouldn't start there first, because it's not really a fail-fast environment. When we think about DevOps, we think about the ability to give, to reduce the friction between developers and infrastructure, and allow developers to get in, get their work done, get started, get it done as quickly as possible, find out if a project is going to be successful or not, that's the ultimate business value, and then either expand that and grow that and scale it and reduce the friction to scale it and support it, or just say, you know what, this wasn't a great approach to this problem, and we can take another approach and quickly start over the concept of failing fast.

If we're not going to start with SAP, where do we start? When you say start small, let's give some practicals. Think about it, there's always little projects that are being spun up within an organization. I don't care if you're a small or a large organization, there's always little pet projects that are out there. Something that ultimately may be a trial, as you mentioned, something that may need to take a little bit of time to show some business value, but you do want to give it an attempt.

Those are the sorts of things that maybe you want to wrap some new approaches around, just to see if not only can that project be successful, but to also see whether or not the persons working on that can actually change behaviors and work in different dynamics, especially, as you mentioned, where we're at right now. I can tell you stories in large enterprises about how I sat next to a network administrator and I was told not to talk to the network administrator. Not for the usual network administrator being grumpy type of thing.

Network administrators are grumpy. As a virtualization admin, my organization had silenced them off, even though we were sitting next to each other, as far as the cubicle farm was concerned. Those are the sorts of things, just the realization that all that stuff needs to come together and you need to be communicating with the other people who are involved in that process. Finding a small project, and I wouldn't say forcing it, but just putting them next to each other is logically going to be the first start for this, especially then when you involve development and some of the others.

Just getting everybody involved in the same room to start talking, it's amazing what can ultimately happen. What are some of the natural friction points as you get people in and they go to assimilate into this DevOps culture? What are some of the natural points of contention where, hey, there's somebody else in my sandbox. What's going on? Well, I think there's a couple of things I've highlighted before in the past. You've heard about the hero culture. Yes. Obviously, in the DevOps world, the idea is to spread the load relatively evenly across, make everybody feel the pain, not just one individual or a group of individuals.

There are some people, as masochistic as they are, they actually enjoy that. They enjoy getting paged at three in the morning to fix something. I don't know why, I don't know how that ever happened, but those sorts of people realizing that maybe that's not their way to shine in an organization, they may have to take a different approach for getting noticed because now there's not this ability to put a spotlight on parts that are broken and have you swoop in and fix those problems and look like you're the hero to the organization when really no one ever questions why does it keep breaking in the first place and trying to get to root cause and things like that that ultimately in some of the DevOps principles, the idea is to cut through that and get to that point quicker.

We've spent a lot of time talking about people and process, but very little time talking about technology. What are some of the technology hurdles or challenges or opportunities when it comes to DevOps and changing to a DevOps culture? I've wrestled with this because there's a few myths that come through stating that things like that DevOps is only open source tools or shoot, FUD that you see out there, I think it was even Red Hat may have even done something that said DevOps is open source.

Oh yeah, I remember that social media campaign that made my eyes bleed. Well, not exactly. I've cross pollinated through multiple different, if you want to call them groups, the Microsoft camps and everything, the Microsoft camps, the open source camps, the buy off the shelf and add your own nuances to a technology package. Really for the most part, as far as I'm concerned, the tools, the people in process will ultimately choose the tools. That's why one of the things that always gets me is when you hear things of somebody in a vendor booth telling you, well, my stuff's better for DevOps.

Are you sure? Really, it's the team. I know I feel like I'm copping out here and you asked about the technology part of it, but I'm still under the belief that 90 to 95% of it is people in process, 5% is the technology. That'll fall by the wayside and then it'll come naturally to it. One of the examples that Jim Kim used in his book was taking a mainframe app and applying DevOps principles to a mainframe app. I think the gist of it was that if you can get DevOps principles applied to mainframe, you can get those principles applied to all types of technologies.

I would say one of the things that you get a little bit is take that old mainframe app and they tell you now about things like micro segmentation and containerization and components like that. Basically, you start breaking the monolith into smaller pieces and maybe you tackle parts of it. You spin things off from the mainframe component to true middleware or front end components and lessen the burden on a legacy system. You may still need that legacy system, but you can add new things to it by going down those new tracks that we all hear about that DevOps gets wrapped around.

We're going to get to wrap. John, where can people find you online, social media, events, et cetera? I'm pretty active on Twitter. My Twitter name is SnoopJ123. Don't ask. It's kind of like a Gmail address. You get stuck with it after you select. I just went with it. Also, I'm starting to get highly active in going to these user cons and doing more DevOps intros to groups that may not have done it. You may see me on quite a few user con dockets over the next six, eight months.

Well, that's it for me. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Well, that's it for this episode of the CTO Advisor. com. Subscribe to us in iTunes. Rate us. It helps out a lot for discoverability.

Talk to you guys next episode. Thanks a lot, John.