{"id":"baa11f97-8395-411a-a546-d627c7602352","slug":"s11e11-but-what-is-certain-technology","subject":"s11e11: But What Is Certain Technology Infrastructure Anyway?","title":"But What Is Certain Technology Infrastructure Anyway?","publish_date":"2022-03-08T17:00:12.890555+00:00","year":2022,"month":3,"season":11,"episode":11,"episode_label":"s11e11","canonical_url":"https://newsletter.danhon.com/archive/s11e11-but-what-is-certain-technology/","is_premium":0,"word_count":1099,"body_html":"<h1>0.0 Context setting</h1>\n<p>It's 8:44am on Tuesday, March 8 2022 and in a retroactively claimed &quot;it was my plan all along&quot; attempt to stick to fifteen minutes of writing for this episode, I have a standup in... fifteen minutes. So let's do this. Oh, and it's grey and misting with rain here in Portland, Oregon.</p>\n<h1>1.0 Some things that caught my attention</h1>\n<p>One thing that's in my mind right now is related to one of the clients I'm working with and I haven't done the secret boys club thing of give it a CODE NAME which on the one hand does still feel cool and lend a bit of a frisson of excitement and at the same time feels, you know... a bit boy-ish?</p>\n<p>Anyway, the thing: a question that has kept coming up for my work at the moment has been &quot;what is infrastructure&quot;, specifically along the lines of &quot;we have all of these independently developed business systems and we want to do the New Thing which is DevOps or even DevSecOps or even dare I say it DesignDevSecOps, and, well, how do we start?&quot; To which one of the answers is &quot;well, you get your infrastructure working and you move toward something like continuous integration/continuous deployment&quot;.</p>\n<p>Some things that normally happen when you have that conversation:</p>\n<p><em>Some</em> people understand what CI/CD means, and some people (myself included) might reference the fact that modern software companies deploy software to the web hundreds or maybe sometimes thousands of times a day. This <em>freaks people the fuck out</em>. They are used to dealing with planned releases, say, once a quarter, and even then (say it quietly) maybe they don't even meet the deadlines for that planned release. The release to UAT or acceptance testing or whatever for someone to just click around and say &quot;oh, this looks fine&quot;, which is <em>nothing</em> like &quot;actually use the thing and try to do the thing in something approaching real world conditions&quot;.</p>\n<p>So really, the deal with something like continuous deployment isn't that suddenly someone (a consultant, or a trendy vendor) is coming in saying, hey, now you can push updates to prods, tiny updates, many times per day! Even once per day! Because they may freak the fuck out and assume that now you <em>actually</em> want to push lots of those updates, many times a day, when if you stopped and you thought about it, it's totally reasonable to be freaked out by that. They (expansively, the organization in general) is barely past graduating from &quot;here's a three ring binder for you to learn how to use $business_system&quot; to &quot;here's a word document and PDF for you to learn&quot; to &quot;here's a video, updated maybe every other planned release&quot;. And now they <em>think</em> you want to push changes to prod multiple times a day? What kind of change? What kind of change would possibly be worth pushing, that's that small?</p>\n<p>There is clearly a disconnect here. Pushing that much, that frequently, is, like, a <em>long term goal</em> and you there in baby steps.</p>\n<p>The second thing that normally happens with the whole &quot;we should have infrastructure that supports this&quot; is that someone will say something like &quot;I don't want duplication&quot; and then I say something like &quot;no, but I don't like forcing people to use something that <em>at best</em> provides no appreciable benefit, and <em>at worst</em> makes things worse, fixes nothing, and burns a bunch of goodwill and political capital&quot;. And then people think about that a bit.</p>\n<p>An example! I don't know, people want to send email. Some applications are doing totally fine sending email. Some aren't. A ham-fisted, by-the-books, plain irresponsible &quot;enterprise architecture roadmap plan strategy&quot; would say &quot;hey everyone we're moving to $email_service&quot; and then everyone would have to move to do it and someone somewhere would get to tick a box that said &quot;reduced duplication of unneeded services across n business applications&quot; and then someone else would say &quot;we did that for 9 months and got what?&quot;</p>\n<p>And you can guess whether the people who had email problems were likely to have had them resolved to their satisfaction.</p>\n<p>So yeah, there's some easy examples of what &quot;infrastructure&quot; is, but one problem is getting people<sup class=\"footnote-ref\"><a href=\"#fn1\" id=\"fnref1\">[1]</a></sup> to care about infrastructure when from their point of view the lights are on and stuff mostly works and they know who to yell at if it doesn't work (you know, we get power cuts... infrequently. And then it always comes back. So it's fine). I mean, why <em>should</em> they care? One reason is because the infrastructure is invisible and it mostly works and if it's invisible, that's the point? They don't have to care about it? But they might in abstract understand that behind the thin veneer of civilization everything is constantly fraying and in a state of decay. So how to persuade them?</p>\n<p>Well first: you know you actually <em>do</em> have to persuade them? I mean, you don't just get to say &quot;we should do this because it's vital for our business to operate&quot; because duh who wants to be told that they're being stupid and they don't want to do things that are vital for their business to operate. And just because they <em>say</em> they want these things (who doesn't want more resilient infrastructure! Sure!) that having that is a choice and a choice means <em>not doing some other thing instead</em>?</p>\n<p>So yes. Sorry, you have to persuade people and you have to make a case and then you (sorry for looping around) end up with &quot;well, what's infrastructure supposed to be and why would we invest in it?&quot;</p>\n<p>And this is where this turns into, tomorrow, and for some of you, rather predictably, a story about When I, A Person Born In England, Presented To A Group About Just Wanting A Cup Of Tea, and Just Why Am I Machining Metal Pipes Anyway?</p>\n<hr />\n<p>OK, that's it! That was, like 14 minutes on the dot which gives me 1 minute to write this part. I think I need more practice at this.</p>\n<p>Have you been practicing anything lately? By &quot;practice&quot;, I mean &quot;hmm, here's something I'm not great at and instead of seeing it as an inherent character flaw, it's actually just a sign that I can get better at it?&quot; which I say to myself as much as I am saying to anyone else. Physician, etc.</p>\n<p>Best,</p>\n<p>Dan</p>\n<hr class=\"footnotes-sep\" />\n<section class=\"footnotes\">\n<ol class=\"footnotes-list\">\n<li id=\"fn1\" class=\"footnote-item\"><p>You know. The people with the money, or the internal stakeholders, or the people who ultimately have the soft power and exert it over whatever gets prioritized. <em>Those</em> people. <a href=\"#fnref1\" class=\"footnote-backref\">↩︎</a></p>\n</li>\n</ol>\n</section>\n","body_text":"0.0 Context setting\n\nIt's 8:44am on Tuesday, March 8 2022 and in a retroactively claimed \"it was my plan all along\" attempt to stick to fifteen minutes of writing for this episode, I have a standup in... fifteen minutes. So let's do this. Oh, and it's grey and misting with rain here in Portland, Oregon.\n\n1.0 Some things that caught my attention\n\nOne thing that's in my mind right now is related to one of the clients I'm working with and I haven't done the secret boys club thing of give it a CODE NAME which on the one hand does still feel cool and lend a bit of a frisson of excitement and at the same time feels, you know... a bit boy-ish?\n\nAnyway, the thing: a question that has kept coming up for my work at the moment has been \"what is infrastructure\", specifically along the lines of \"we have all of these independently developed business systems and we want to do the New Thing which is DevOps or even DevSecOps or even dare I say it DesignDevSecOps, and, well, how do we start?\" To which one of the answers is \"well, you get your infrastructure working and you move toward something like continuous integration/continuous deployment\".\n\nSome things that normally happen when you have that conversation:\n\nSome\npeople understand what CI/CD means, and some people (myself included) might reference the fact that modern software companies deploy software to the web hundreds or maybe sometimes thousands of times a day. This\nfreaks people the fuck out\n. They are used to dealing with planned releases, say, once a quarter, and even then (say it quietly) maybe they don't even meet the deadlines for that planned release. The release to UAT or acceptance testing or whatever for someone to just click around and say \"oh, this looks fine\", which is\nnothing\nlike \"actually use the thing and try to do the thing in something approaching real world conditions\".\n\nSo really, the deal with something like continuous deployment isn't that suddenly someone (a consultant, or a trendy vendor) is coming in saying, hey, now you can push updates to prods, tiny updates, many times per day! Even once per day! Because they may freak the fuck out and assume that now you\nactually\nwant to push lots of those updates, many times a day, when if you stopped and you thought about it, it's totally reasonable to be freaked out by that. They (expansively, the organization in general) is barely past graduating from \"here's a three ring binder for you to learn how to use $business_system\" to \"here's a word document and PDF for you to learn\" to \"here's a video, updated maybe every other planned release\". And now they\nthink\nyou want to push changes to prod multiple times a day? What kind of change? What kind of change would possibly be worth pushing, that's that small?\n\nThere is clearly a disconnect here. Pushing that much, that frequently, is, like, a\nlong term goal\nand you there in baby steps.\n\nThe second thing that normally happens with the whole \"we should have infrastructure that supports this\" is that someone will say something like \"I don't want duplication\" and then I say something like \"no, but I don't like forcing people to use something that\nat best\nprovides no appreciable benefit, and\nat worst\nmakes things worse, fixes nothing, and burns a bunch of goodwill and political capital\". And then people think about that a bit.\n\nAn example! I don't know, people want to send email. Some applications are doing totally fine sending email. Some aren't. A ham-fisted, by-the-books, plain irresponsible \"enterprise architecture roadmap plan strategy\" would say \"hey everyone we're moving to $email_service\" and then everyone would have to move to do it and someone somewhere would get to tick a box that said \"reduced duplication of unneeded services across n business applications\" and then someone else would say \"we did that for 9 months and got what?\"\n\nAnd you can guess whether the people who had email problems were likely to have had them resolved to their satisfaction.\n\nSo yeah, there's some easy examples of what \"infrastructure\" is, but one problem is getting people\n[1]\nto care about infrastructure when from their point of view the lights are on and stuff mostly works and they know who to yell at if it doesn't work (you know, we get power cuts... infrequently. And then it always comes back. So it's fine). I mean, why\nshould\nthey care? One reason is because the infrastructure is invisible and it mostly works and if it's invisible, that's the point? They don't have to care about it? But they might in abstract understand that behind the thin veneer of civilization everything is constantly fraying and in a state of decay. So how to persuade them?\n\nWell first: you know you actually\ndo\nhave to persuade them? I mean, you don't just get to say \"we should do this because it's vital for our business to operate\" because duh who wants to be told that they're being stupid and they don't want to do things that are vital for their business to operate. And just because they\nsay\nthey want these things (who doesn't want more resilient infrastructure! Sure!) that having that is a choice and a choice means\nnot doing some other thing instead\n?\n\nSo yes. Sorry, you have to persuade people and you have to make a case and then you (sorry for looping around) end up with \"well, what's infrastructure supposed to be and why would we invest in it?\"\n\nAnd this is where this turns into, tomorrow, and for some of you, rather predictably, a story about When I, A Person Born In England, Presented To A Group About Just Wanting A Cup Of Tea, and Just Why Am I Machining Metal Pipes Anyway?\n\nOK, that's it! That was, like 14 minutes on the dot which gives me 1 minute to write this part. I think I need more practice at this.\n\nHave you been practicing anything lately? By \"practice\", I mean \"hmm, here's something I'm not great at and instead of seeing it as an inherent character flaw, it's actually just a sign that I can get better at it?\" which I say to myself as much as I am saying to anyone else. Physician, etc.\n\nBest,\n\nDan\n\nYou know. The people with the money, or the internal stakeholders, or the people who ultimately have the soft power and exert it over whatever gets prioritized.\nThose\npeople.\n↩︎","raw_format":"markdown","source":"app","summary":"This issue explores the gap between what organizations think they need (modern infrastructure, CI/CD pipelines, DevOps practices) and what they're actually ready for, using email services and deployment frequency as examples of how enforced standardization often fails to solve real problems. The throughline is a meditation on infrastructure as an invisible public good that's hard to justify investing in when systems are already limping along acceptably, and the challenge of persuading organizations that resilience and change capacity are choices worth making—not just obvious necessities.","reading_minutes":5,"links":[],"sections":[{"id":3577,"ord":0,"number":"0.0","heading":"Context setting","level":1,"word_count":54},{"id":3578,"ord":1,"number":"1.0","heading":"Some things that caught my attention","level":1,"word_count":1043}]}