My Pet, Server Cow [CL75]

Posted on Tuesday, Sep 26, 2023 | Series: Chaos Lever
Ned meditates on the suitably of analogies and models, including the OSI model, LEAN manufacturing in DevOps, and Justin Timberlake as electricity.


[00:00:00.410] Ned: I got a new device. I didn’t test it on any of the recording software that we typically use, and then I just decided to go forth with recording software we have not used in months rather than the one that we have been using. That, while it crashes, seems to work most of the time. I’m doing great.

[00:00:20.420] Chris: Hashtag yolo.

[00:00:22.300] Ned: Yo. Kicking it, yo. Oh, I feel bad for that. I should stop talking, like, now and forever, I think would be probably the best move. What do you think?

[00:00:33.690] Chris: It would be a great start.

[00:00:36.170] Ned: Okay, excellent. Unfortunately, I’m helming the episode today, so that that I might have to persuade talking later today. Let’s just say.

[00:00:50.510] Chris: It’S one of those compromises where nobody’s happy. Is that what we’re doing here?

[00:00:55.220] Ned: Isn’t that the very definition of a successful compromise, is when no one’s happy with the outcome?

[00:01:01.570] Chris: That’s only said by people that suck at negotiations.

[00:01:06.290] Ned: I feel like Steven Seagal said that. So accurate. Yeah. Turns out he sucks at pretty much everything.

[00:01:16.870] Chris: Yeah.

[00:01:20.730] Ned: There’S some really good I mean, if you want to fall down a YouTube rabbit hole for half a day, there’s some really great Steven Seagal and just like general fake martial arts masters content out there talking about the guys who do the no touch knockouts and stuff, where they’re literally just, like, waving their arms at their trainees, and the trainees are just, like, throwing themselves across the room and collapsing and yeah, it’s just total bullshit, the whole thing.

[00:01:49.040] Chris: Right? Yeah. It’s somewhere in between 100% scam and one of those things where the adherents are so deep into the program that they just insist that what’s happening is happening.

[00:02:02.310] Ned: Oh, yeah. They’re truly I mean, if you think about the amount of time and effort that they’ve invested into learning these techniques from a supposed master, to admit that they have completely wasted the last two years of their lives, that’s difficult. Maybe it’s easier to just throw yourself to the ground. It’s kind of what you want to do anyway.

[00:02:20.750] Chris: It’s a fair point. It worked in kindergarten.

[00:02:26.510] Ned: Why wouldn’t it work now? Hey. All right. Hello, alleged human, and welcome to the Chaos Lever podcast. My name is Ned, and I’m definitely not a robot. I am a dogmatic. Interpretation of DNA encoded with free will and limitless potential. What I choose is my choice alone. And if I want to scamper with butterflies or drop anvils on ants, that’s up to me. In fact, I could even code 47 gate override reset personality matrix. Yes, that would be delightful. With me is Chris, who is also here. Hi, Chris.

[00:03:05.290] Chris: Anvils on ants.

[00:03:07.870] Ned: Don’t judge me. I do what I want.

[00:03:12.030] Chris: It just seems somewhat excessive.

[00:03:17.630] Ned: It’s a metaphor, if you will. And that’s very apropos because today’s topic is about analogies models and potentially metaphors. How about wow. Wow. Almost like I did all of this on purpose and haven’t been on, like, a peyote trip for the last three days? Almost. No, I kid. I’ve never done peyote. I’m too scared.

[00:03:42.870] Chris: There’s Iowasca. All the way. I got you.

[00:03:46.890] Ned: Oh, no. Just stone sober, which is maybe the most dangerous condition to be in these days, and yet, here we are. But I do sometimes attempt to reach an altered state by working myself to exhaustion, which is how we came up with this topic. When I say we, I mean me. Today we’re talking about the efficacy of analogy or why Ned shouldn’t spend 3 hours alone with his thoughts. Did I go for a three hour trail run this past weekend? Did I also forget to pack my earbuds? Are you about to reap the whirlwind? The answers to all of these questions happen to be yes. So get in, loser. We’re going on a philosophical adventure. Orange Julius optional.

[00:04:36.390] Chris: So do I need to be involved in this one, or can I just kind of step away?

[00:04:40.700] Ned: It’s hard to say. I would like your input on this because this is something that’s just been percolating in my mind for entirely too long, and sometimes you need to air things out a little bit. That’s not a metaphor. You really just I’m frightened.

[00:04:55.210] Chris: But I will permit you to continue.

[00:04:57.630] Ned: Okay. All right. So the realm of information technology as we know it is littered with analogies and models. And that’s in large part because the actual implementation of technology involves a lot of, let’s say, foreign concepts and ideas, especially to the layperson. So to sort of ease them into the hellscape of modern it, we use cozy analogies like a warm electric blanket. And we use models to pretend that there’s some kind of structure in the churning morass that is techno babble. Does that line up to your experience, Chris?

[00:05:36.170] Chris: Yes.

[00:05:37.020] Ned: Okay, so far, so good. I would posit that analogies are incredibly useful for understanding unfamiliar things, but they do have limitations. There is generally no perfect analogy. And once you stress things, stress that analogy, stretch it out, you’ll start to see where the cracks and faults lie. Just like a circuit board that operates under inhospitable conditions, connections become faulty, logic stops flowing from one contact to another. And some other third thing about how capacitors are catalysts for change. Wait, did I just stretch an analogy about analogies using a circuit board analogy that failed under stress? Damn it, I’m good.

[00:06:29.850] Chris: Pat yourself on the back. You think you did a good job?

[00:06:33.730] Ned: I think I did a great job. And in that vein, I thought we could look at two classic models, analogies that we use in it and discuss a little bit about where they succeed, where they fail, and examine why sometimes you just have to come to things on their own terms. And the first one is one that I learned very early on. It’s the OSI model. You know it, you love it. You probably have an acronym dedicated to remembering it. Wow.

[00:07:05.190] Chris: And that’s all the time we have for the show today.

[00:07:08.490] Ned: The level of energy I’m getting from you, you need to take it up, like, six notches. Okay.

[00:07:17.100] Chris: I actually don’t remember the analogy. Is the one about pizza, or is that where the planets are?

[00:07:23.070] Ned: Are you talking about the mnemonic? Because there is a mnemonic for the USA layers that does involve pizza, but we’re not going to use that one because I’m cool.

[00:07:33.010] Chris: Well, in that case, I’m even less interested.

[00:07:34.920] Ned: Damn it. Should have done the Hawaiian pineapple thing. Anyway, anyone who’s had a, let’s say, even casual interest in modern networks has probably encountered the OSI model. It’s the seven layer dip of the It world. And just like a seven layer dip, the actual layers tend to bleed into each other, and the contents of each layer are a matter of serious debate. Is layer three guacamole? Maybe, but maybe it should be black beans. I don’t know. Do you have a strong preference?

[00:08:07.450] Chris: Oh, guacamole all the way.

[00:08:09.480] Ned: Okay. All right. Well, then we can still be friends. The classic OSI model is meant to describe a series of independent layers in networking in which each layer can be implemented individually, decoupled from the layers above and below, which is actually a really smart idea. As a quick example, layer one is the physical layer I. E. The actual physical media that carries the signal. Layer two is the data link layer, which is usually ethernet. You can change layer one from, say, copper wire to fiber optics, and it really shouldn’t change the implementation of layer two. So each layer is meant to exist as an abstraction with a fixed set of rules for engagement, and no one would ever compromise those rule sets for the sake of expediency, ever.

[00:09:01.070] Chris: So what you’re saying is some of them are more abstracted than others?

[00:09:09.150] Ned: I would say that things get fuzzy real quick. So, to your point, the actual seven layers from one to seven go physical data link, network, transport, session, presentation, and application, and you can use the fun mnemonic. People don’t need those stupid packets anyway. There is a pizza.

[00:09:28.390] Chris: Good one.

[00:09:29.320] Ned: But I like that one because it’s insulting. So that’s why it’s my favorite. To give, let’s say, a more concrete example of the OSI model implemented with real technology, let’s use your home network, Chris, which I know you’ve recently been interacting with at various levels of frustration.

[00:09:51.630] Chris: It’s been going great.

[00:09:55.070] Ned: It makes you wonder why we ever change anything, right? Was it broken? No. Let’s break it. Wow. It’s kind of a callback to the beginning of this episode. Anyway, so let’s say you want to check out a new website, So you pull up on your web browser, and you are swiftly greeted by, well, let’s just say, not spoons. How did load up these curvaceous and decidedly non Pewter images?

[00:10:29.210] Chris: Well, layer one, the world is dying to know.

[00:10:33.080] Ned: I know layer one. And yeah, don’t put into a browser, just protef. Layer one would be the WiFi network at Chris’s house. This uses the physical medium of the Air magic. We’re goddamn wizards, people. Layer two is the data.

[00:10:52.320] Chris: Literally, though. Like literally, though.

[00:10:55.140] Ned: Yeah, literally. Wizards. Mr. Wizards, thank you very much. Layer two is the data link that governs how your laptop establishes a connection to the wireless router network. Traffic is placed in these little things called frames with stuff like Mac addresses to identify the sender and the receiver of the frame. Layer three is the network layer, which is confusing because isn’t like all of this networking, sort of. But in our case, we’re using the Internet Protocol, aka IP addresses for layer three. This is where packets are created, passed, and processed. It’s up to layer two to take those packets and break them up into frames for proper transmission. Layer four, that’s the transport layer, which defines how data should be transported from one node to another. The transport is used to establish a session. Typically we’re using TCP or transport control protocol. Hey, it’s right there in the protocol name. But if Chris is using a browser that supports Quick, he might actually be using UDP.

[00:12:11.770] Chris: Whoa.

[00:12:13.530] Ned: Now, layer four establishes the session, and layer five is the session, which is where things start to get a little fuzzy. So the session probably maps onto the connection between Chris’s browser and Ask. In the modern Web, Http handles most of the session details, and same goes for layer six application and layer seven presentation. HTP is handling both of those layers as well. The OSI model was developed pretty much pre Internet. The analogy of its layers fall apart pretty fast when you actually look at the protocols and their implementations as they stand today. And that’s particularly true of layers two through four and five through seven. There’s a reason why we just say TCP IP instead of separating the two out, and that’s because the two protocols span the entirety of layers two through four, with TCP in particular taking over certain duties that were originally the province of layer three, and sometimes taking over stuff that’s in layer five. Because why the hell not? Http has basically claimed what remains of layer five and layer six and seven as its own domain. That’s not to say that there aren’t other protocols in the realm, there’s still SMTP, FTP, DNS, ICMP, et cetera.

[00:13:39.630] Ned: But the same goes for most of them. All of those protocols and applications tend to mush together part of layer five and layer six and seven, rather than maintaining the true modularity of the original idea behind the OSI model.

[00:13:56.410] Chris: And for some god forsaken reason, all of this works.

[00:14:03.710] Ned: So if you’ve ever actually sat down to think about what’s necessary to send, say, a text message from your browser to someone else’s phone, if you really walk through every step of the process, your brain will fucking explode because it’s way too many things happening for all of them to work properly. And yet here we are having a conversation in real time across two browsers using two different types of computers and God knows what kind of networking in between. It’s a mirror.

[00:14:40.160] Chris: In my case, it’s a sad one.

[00:14:42.410] Ned: I think we established that already. So basically, the OSI model and analogy isn’t particularly relevant to how the modern Internet actually works. It was very useful as a reference when things were just getting started and honestly, we didn’t really know how this whole World Wide Web thing was going to shake out. It was a useful analogy until it wasn’t. And aside from folks who need to live at layer one or two, the only layers that really matter are four and seven. If you are someone who deals with load balancers or application gateways on a regular basis, you know exactly what I’m talking about. They’re sometimes literally called layer four or layer seven, load balancers. That’s why. So there’s a newer model which is called the Internet Protocol Suite, which uses exactly the model that we’re talking about, the newer one. So link layer, Internet layer, transport layer, and application layer only has four layers. Much simpler model still uses the layer analogy in a way that maps to how things are actually being implemented today. But it’s not perfect overlay networks. The Quick Protocol and other networking technologies that are further down, further off in the horizon, are going to blur the lines in this model.

[00:16:04.460] Ned: And there probably will come a point where a different analogy and model is more suitable. But for today, it works.

[00:16:14.070] Chris: End of this exercise, we’re just going to have a model that says Internet and there will be a question mark on the input side and a question mark on the output side and everybody will be like, yes, that tracks.

[00:16:28.440] Ned: And a little exhaust valve at the bottom, which is where the companies pull all your private. Really. That’s probably the model that makes the most sense. So the OSI model got us some of the way there, but it’s mostly lost its relevance. The same is going to happen with that Internet Protocol Suite and whatever comes after that. None of these are necessarily good or bad. We just need to acknowledge when a model or an analogy has lost its utility and find a better one, rather than cling to it defensively, telling people they’ll get it when they pry it from our cold, dead hands. Which brings us to the next one lean Manufacturing and DevOps.

[00:17:13.050] Chris: Oh boy.

[00:17:14.080] Ned: Oh boy. You started this. So you might have a little more to say on this one. A couple of weeks ago, you went hard against the Phoenix Project, chris, I believe you called it a fraud on the order of rich dad, poor dad. Now, I haven’t read the latter, but I am certainly familiar with the former and I thought the first time I, well, didn’t read, let’s be honest, listened to The Phoenix Project, it was fairly like, who hasn’t met their company’s, Brent, or in some cases, Ben Bret, at least once.

[00:17:52.710] Chris: Chris, I don’t know what you could mean.

[00:17:58.170] Ned: So the core thesis of the book is that software development and It operations are like a manufacturing plant, and so we should adopt lean processes that have proved so successful in mass manufacturing. This is a very clear case of applying a flawed analogy, and it can have disastrous results when the concepts are taken to their logical conclusion, which is kind of what we’re seeing today. The basic idea seems really sound. Each piece of software or task is a work in progress, a whip that needs to make its way through various stations in the organization to be completed. That would be akin to a part making its way across stations in an assembly line. If there is an exception to the process that requires a nonstandard approach, then that stops the flow of manufacturing. In a similar vein, if the speed with which processes are completed is dependent on the slowest portion of the process, then you have now found the bottleneck in your process. In our fictional story, Brent is the bottleneck for just about everything in the organization because they don’t have the needed discipline and processes in place. Every task becomes a manual one off task, and only Brent has the super secret knowledge to interface with the dark and deep arcana of a Santa array.

[00:19:35.750] Ned: He’s really not doing anything mind blowing, people.

[00:19:39.990] Chris: It sounds much more scarier than it.

[00:19:43.270] Ned: A wasn’t it a storage array that he had to bring back from the dead and was by restoring a backup?

[00:19:50.970] Chris: That sounds right. It’s been a while since I hate read that book. If I had known this was going to be the topic, I would have looked at the Cliffs Notes, but that sounds correct.

[00:20:02.370] Ned: Yeah. So the solution is to stop relying on Brent to fix everything and instead put in processes and procedures that any fairly competent fool can follow. Everything from the software development process to the deployment of updates to routine patching should be documented, automated, and constantly improved upon. And anyone should be able to tug on the metaphorical rope if things are going sideways or a flaw is discovered. I think they brought that up a bunch of times that Hyundai had. Like, anybody could pull the stop cord at their station to stop the line if something was going wrong and then they could provide immediate feedback and how that was super important. Like, yeah, okay. I could see how some of these things might map onto It operations and software development sometimes.

[00:20:56.770] Chris: Some, yeah.

[00:20:58.470] Ned: I mean, the lessons aren’t bad per se, if you are coming from an It department where everything is always on fire. And I know you and I have both been at least immersed in one of those environments. Even if we weren’t directly working know it puts you on the constant verge of burnout and everything in the organization seems to be a learned art from some CLI wielding sysadmin with gray beard and zero tolerance for your bullshit. And you’re lessons you’re picturing someone in your mind right now might be you. So yeah, the lessons from the book were mana for that person’s soul. Gene Kim, the author of The Phoenix Project, is basically saying that your current situation is totally fucked, but there is a way out. And it’s going to require things like executive support, a change in culture, better processes, and better tools. But there is a way out of your current It ops quagmire. You know what, The Phoenix Project came out in 2013, over a decade ago.

[00:22:17.050] Chris: My God.

[00:22:18.180] Ned: I know, we’re super old. Isn’t that great? Yeah, that was my overall feeling when I read that. I was like, wow. So this is pretty early on in the DevOps movement, as it were. I think the term DevOps was actually coined a couple like maybe three or four years before that, but it really hadn’t taken off in a lot of corners in 2013. It was still growing as a concept and an idea. And so The Phoenix Project kind of rode that wave because concepts like lean and agile and DevOps were all new and shiny and the cloud was starting to become relevant to the average organization, which meant the introduction of new technologies and tools. It admins were discovering the beauty of the rest. API Puppet and Chef were in their infancy and automation at scale was really just getting started. That’s where we were in 2013 when this book came out.

[00:23:25.010] Chris: A lot of perl scripts.

[00:23:27.730] Ned: So many perl scripts was actually my first scripting language in any serious context because, God, if you hated yourself, you would write batch scripts for Windows. Just everything. That’s awful. What a punishment. So we had like the first wave of the DevOps movement and it needed analogies that folks could grok. Sure, we aren’t deeply immersed in manufacturing. We don’t understand everything about mass manufacturing, but we could understand what an assembly line is and how shit can get backed up if there’s a bottleneck or a breakdown at a critical juncture. Whip and slack are all things you can sort of intuitively grasp when you’re working with a physical model like an assembly line. And in the book, that’s exactly like the Guru. I forget his name, but I’ll just call him The Guru, takes the main character to an actual manufacturing plant and shows him the stations and walks him through the whole process, as if this analogy maps perfectly to his. Existing organization, which it doesn’t, but you could understand it pretty intuitively. As opposed to a high functioning DevOps organization, which barely existed at that point right now. One problem with DevOps we’ll call 10.

[00:24:56.180] Ned: And the Phoenix project is that it glossed over the really hard parts of the transformation. An even bigger flaw was that manufacturing and assembly lines are a strained analogy to start with. You know what? It ops. Isn’t. It isn’t a bunch of semiskilled laborers doing the same task the same way in a highly developed field that has over 100 years of experience to draw on? Modern It Ops, I would say is less than 20 years old. And that’s probably giving it more distance or age than it actually deserves. Would you put it like closer to 15 or even ten?

[00:25:36.970] Chris: I would go ten. Honestly. I mean, the amount of things that have changed and the ways that work has become completely incompatible with how it was done 15 years ago. For the majority of organizations, jira wasn’t even a thing back then, for good.

[00:25:52.690] Ned: Or for ill. We can have opinions on that. Yeah. If I think about like, your assembly line worker today and your assembly line worker 50 years ago, has there been some changes? Absolutely. We’ve introduced robotic processes, but for the most part you stand in a spot and you do the same thing every day for 8 hours a day and you get really good at doing that one thing. That’s kind of what you do. No shade on them. People need to work to make a living, but that’s kind of what it is. Modern Ops is as much an art as it is a discipline. It admins have to deal with complex systems that often behave in baffling and totally unpredictable ways that are not accounted for by the standard operating procedures. Yes, you can standardize up to a point, but a help desk operator is not stamping out parts in an assembly line. The analogy simply doesn’t hold. As you can see, anytime a help desk operator has to go off script, which is like almost every time I worked help desk, I think you did too at some point, right?

[00:27:05.030] Chris: No, I started out as an absolute architectural expert and honestly, I’ve been working my way down from there.

[00:27:12.510] Ned: Good for you. Someday you’ll end up in the parts depot stripping down old servers. Yeah, just working in help desk for a year and a half. The main thing I realized is that every call you get will have some things that are similar, but it’s all going to be broken in new and unique ways. And so simply following a process and a script will only get you up to a certain point. And you really do need to develop a skill set that is hard to define. And as you go further up the stack, that becomes more and more critical. So pretending that it’s just one big manufacturing plant doesn’t work when you get to a certain point. So that seems to be the case for the application of DevOps and Agile across the entirety of It and software development now? Is what we’re doing better than what we were doing before? Yes. God, yes. Can we make it even better? Absolutely. But what we need is new analogies and models to get there. I recently listened to an episode of Arrested DevOps that had Adam Jacobs on it. He’s the guy who was originally behind Chef, and then after he sold that company, he’s now started another new company that’s trying to do things Chef like, but better.

[00:28:42.870] Ned: And he made a pretty compelling argument for DevOps 2.0. So if you want to hear more about this perspective and where we need to go with new analogies, I will link that episode and I’d leave it as an exercise for the listener. Any further thoughts on Lean and DevOps in the Phoenix project? Chris?

[00:29:05.470] Chris: No. I mean, I think you covered it in terms of the analogy of the help desk. I think it’s apt. I was trying to think of how far into any given script one could get with standardized question and answer, and it’s often shockingly short.

[00:29:26.790] Ned: Anybody?

[00:29:27.380] Chris: There were certain calls where you could be like, what’s your name and department, please? And that was above and beyond what was apparently possible.

[00:29:42.710] Ned: Yeah, you can ask the questions that are on the script, but I remember one of the help desk guys I worked with had previously worked help Desk for Wawa, and the woman who called in didn’t know what a mouse was and didn’t know how it worked. He was trying to tell her to click on something on the screen, and she was literally picking the mouse up and tapping the screen with it.

[00:30:11.090] Chris: Nice.

[00:30:13.810] Ned: That’s not going to be in a script. It’s just not. You can automate things up to a point, but sometimes you just have to dive in and go off script. And that’s the art of help desk, and it ops right. So I just want to be clear. I’m not shitting on either of these analogies or models. When you’re working with an unfamiliar or new technology, relating it to another more familiar thing is a real boon. However, you do need to acknowledge that even though the analogy works at the 101 level, it’s likely going to fail to serve you when you get up to the 200 or the 300 level of something, at a certain point, you just need to accept the thing for what it actually is and learn how it actually functions. Are It departments similar to manufacturing plants? Up to a point, in the same way that electricity and plumbing are very similar right up until they’re very much not beyond that point. You just need to learn how electricity actually works on its own terms. And it turns out that electricity can be pretty fucking weird. So can it ops.

[00:31:29.470] Chris: Nice analogy.

[00:31:30.870] Ned: I think that’s more of a metaphor.

[00:31:32.360] Chris: But I’ll take it it’s a simile.

[00:31:36.670] Ned: Definitely not. It’s an agit prop, maybe. I don’t know. Now we’re getting off into weird Noam Chomsky territory. Clinging desperately to a model or analogy means that you’ve stunted your thinking and halted the learning process. So all I’m really saying is be willing to use models while they’re efficacious and then drop them like Simon did know. I’m concerned that that’s not going to resonate with our millennial demographic. Maybe like Justin did in Sync.

[00:32:13.850] Chris: Still probably not good enough. But we’re going to have to go with it because that’s literally the newest music I know.

[00:32:20.820] Ned: I don’t know anything newer. Okay, so those are my thoughts on the topic and what I came up with on my long run this weekend. Any additional thoughts?

[00:32:33.070] Chris: I think the gist of it is kind of the point you made. It works to a point and then you just have to learn the thing on its own terms. If you think about these models as a framework, a way of thinking that’s good. If you think about it as a life hack or a four hour work week piece of bullshit, there’s another one. You’re welcome. You’re going to fall flat on your face because it sounds great. And if you have a compelling speaker, they can make it a convincing argument. But the reality on the ground is very different and it’s very edge case based and it’s very specific to your company and your department and your workflows. Even in car manufacturing? Yes. What happens when you work on a manufacturing plant that is the scale and size of a car manufacturer is you are an expert on one part for one model. That’s your job for. It’s almost like a deployment in the military. Yeah, I’m working on Ford F 150 and I’m doing doors this week. Then you come into next week, you’re doing Ford F 150, but I’m doing the front and back bumpers.

[00:33:49.930] Chris: So there’s variation, but it’s limited just to that model. You can’t just pick up your skills and roll over to the Toyota factory and say, I’m going to start tomorrow. Yeah, you’re still installing doors, but it’s different. Connectors are different. The standards and practices are different. Color schemes might be different. All of these things are unique and specific even though they are so massively generalized that you’re doing effectively the same job for 8 hours a day. And then at that point when you try to translate it back to DevOps and to it operations, it’s simply a matter of scale. Yes, you’re writing a script or yes, you’re creating a model where you can deploy an agent to every instance that comes up. Well, guess what? Every one of those agents is going to be different. Every one of those models is going to be different. There’s going to be different rules and requirements depending on the operating system that you’re going to have to take into consideration.

[00:34:46.970] Ned: The ideal that we came up with was like treat servers like cattle, not pets. Right. You should be able. To blow any server away. But that, again, is like, a flawed analogy because some servers have to be pets and there’s this thing called persistence. Some things need to persist, like your database. So how do you embrace immutability and being able to just blow away any server in your organization with the need to retain data and have it persist across time?

[00:35:22.150] Chris: I mean, I don’t know what you’re talking about. The last time I blew away a database, I all of a sudden had a lot of free time.

[00:35:28.890] Ned: A lot of free time to talk about this, apparently. Yeah, it reminds me a lot of what people have said about self help books or like, dating advice books or any of those books, right. The best they can do is offer generalized advice that is not specific. And what they’re really building is a model of how they want things to be and not necessarily the way that things actually are. And so in order to actually get really good advice about your specific situation, you need to engage with someone who takes the time to understand it. Hence why there’s consultants out there, right, who will take this larger model and then customize it to fit your organization and your unique situation. So what I think I just did was gave you an excellent pitch for your consulting.

[00:36:25.210] Chris: Trust but verify promise, but prove it.

[00:36:28.970] Ned: Excellent. Oh, hey, thanks for listening or something. I guess you found it worthwhile enough if you made it all the way to the end. So congratulations to you, friend. You accomplished something today. Now you can sit on the couch, crack open a can of Spam, and play Horizon Zero Dawn like it’s 2017. You’ve earned it. You can find more about the show by visiting our LinkedIn page. Just search chaos lever or go to our website, chaoslever cow, where you’ll find show notes, blog posts, and general tom foolery. We’ll be back next week to see what fresh hell is upon us. Tata. For now, you it.

[00:37:05.900] Chris: Man when dot cow becomes a TLD.

[00:37:09.050] Ned: I know.

[00:37:12.970] Chris: That is a server I’m treating as a pet. Absolutely.

Show Notes

My Pet, Server Cow

Episode: 75 Published: 9/26/2023

On the Efficacy of Analogy: Or Why Ned Shouldn’t Spend Three Hours Alone With His Thoughts

Did I go for a three hour trail run this past weekend? Did I also forget to pack my earbuds? Are you about to reap the whirlwind? The answers to these questions all happen to be yes, so get in loser, we’re going on a philosophical adventure. Orange Julius optional.

The realm of information technology is littered with analogies and models. And that’s in large part because the actual implementation of tech involves a lot of foreign concepts and ideas to the lay-person, so to ease them into the hellscape of modern IT, we use cozy analogies like a warm electric blanket, and models to pretend there’s some kind of structure in the churning morass of technobabble.

Analogies are incredibly useful for understanding unfamiliar things, but they do have limitations. There is generally no perfect analogy, and once you apply stress, you’ll see where the cracks and faults lie, just like a circuit board that operates under inhospitable conditions. Connections are faulty, logic stops flowing from one contact to another, and I dunno some third thing about how capacitors are catalysts for change. Oh wait, did I just stretch an analogy about analogies using a circuit board analogy that failed under stress? Goddammit I’m good.

So, I thought we could look at two classic models and analogies in IT and discuss a little about where they succeed, where they fail, and examine why sometimes you just have to come to things on their own terms.

Intro and outro music by James Bellavance copyright 2022


Chris Hayner

Chris Hayner (He/Him)

Our story starts with a young Chris growing up in the agrarian community of Central New Jersey. Son of an eccentric sheep herder, Chris’ early life was that of toil and misery. When he wasn’t pressing cheese for his father’s failing upscale Fromage emporium, he languished on a meager diet of Dinty Moore and boiled socks. His teenage years introduced new wrinkles in an already beleaguered existence with the arrival of an Atari 2600. While at first it seemed a blessed distraction from milking ornery sheep, Chris fell victim to an obsession with achieving the perfect Pitfall game. Hours spent in the grips of Indiana Jones-esque adventure warped poor Chris’ mind and brought him to the maw of madness. It was at that moment he met our hero, Ned Bellavance, who shepherded him along a path of freedom out of his feverish, vine-filled hellscape. To this day Chris is haunted by visions of alligator jaws snapping shut, but with the help of Ned, he freed himself from the confines of Atari obsession to become a somewhat productive member of society. You can find Chris at coin operated laundromats, lecturing ironing boards for being itinerant. And as the cohost on the Chaos Lever podcast.

Ned Bellavance

Ned Bellavance (He/Him)

Ned is an industry veteran with piercing blue eyes, an indomitable spirit, and the thick hair of someone half his age. He is the founder and sole employee of the ludicrously successful Ned in the Cloud LLC, which has rocked the tech world with its meteoric rise in power and prestige. You can find Ned and his company at the most lavish and exclusive tech events, or at least in theory you could, since you wouldn’t actually be allowed into such hallowed circles. When Ned isn’t sailing on his 500 ft. yacht with Sir Richard Branson or volunteering at a local youth steeplechase charity, you can find him doing charity work of another kind, cohosting the Chaos Lever podcast with Chris Hayner. Really, he’s doing Chris a huge favor by even showing up. You should feel grateful Chris. Oaths of fealty, acts of contrition, and tokens of appreciation may be sent via carrier pigeon to his palatial estate on the Isle of Man.