March 8, 2022

s11e11: But What Is Certain Technology Infrastructure Anyway?

0.0 Context setting

It'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.

1.0 Some things that caught my attention

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?

Anyway, 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".

Some things that normally happen when you have that conversation:

Some 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 freaks people the fuck out. 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 nothing like "actually use the thing and try to do the thing in something approaching real world conditions".

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 actually 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 "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 think 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?

There is clearly a disconnect here. Pushing that much, that frequently, is, like, a long term goal and you there in baby steps.

The 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 at best provides no appreciable benefit, and at worst makes things worse, fixes nothing, and burns a bunch of goodwill and political capital". And then people think about that a bit.

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 "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?"

And you can guess whether the people who had email problems were likely to have had them resolved to their satisfaction.

So yeah, there's some easy examples of what "infrastructure" is, but one problem is getting people¹ 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 should 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?

Well first: you know you actually do have 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 say they want these things (who doesn't want more resilient infrastructure! Sure!) that having that is a choice and a choice means not doing some other thing instead?

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 "well, what's infrastructure supposed to be and why would we invest in it?"

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?

---

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.

Have 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.

Best,

Dan