Screaming in the Cloud - Bringing Empathy and Humility to Tech with Conrad Heiney

Episode Date: July 7, 2020

Links Referenced: Twitter: https://twitter.com/substitute

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. sign up as an expert on AWS IQ today and help customers with their problems. Visit snark.cloud slash IQ to learn more. This episode is brought to you by Trend Micro Cloud One, a security services platform for organizations building in the cloud.

I know you're thinking that that's a mouthful because it is, but what's easier to say? I'm glad we have Trend Micro Cloud One, a security services platform for organizations building in the cloud, or hey, bad news, it's gonna be a few more weeks, I kinda forgot about that security thing. I thought so. Trend Micro Cloud One is an automated, flexible, all-in-one solution that protects your workflows and containers with cloud-native security. Identify and resolve security issues earlier in the pipeline and access your cloud environment sooner with full visibility

so you can get back to what you do best, which is generally building great applications. Discover Trend Micro Cloud One, a security services platform for organizations building in the cloud at trendmicro.com slash screaming. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Conrad Heine,

a principal cloud engineer at Glidewell Dental, but I much prefer his Twitter bio, which simply states, I would prefer not to. Conrad, welcome to the show. Glad to be here, thank you. So tell me a little bit about who you are and where you came from. Because my first introduction to you was somewhat unorthodox.

I saw you get retweeted a few times by the Pinboard account, use Pinboard. And you had a certain acerbic style that really resonated with how I tend to view the world. Intelligent, snarky, sarcastic, but also very clearly clued in to the current zeitgeist in modern cloud. Who are you and how did you get here? Well, I'm not a computer person originally. I was a humanities type. I was raised in a household full of writers and teachers. And I took one computer class in college.

And then the second class caused people to die. It was a weed out. So I went back to English, and computers were a hobby for some time. And I guess around 1989 or 90, I started getting into BBS stuff again. And then I made the mistake of getting Prodigy. The web service, not the band, to be clear? Correct. No fat of the land no

twisted fire starter there none of that no and uh of course prodigy was prophetic in a number of ways one of which it had ads and there was an ad for this new thing called america online because pc america online had just launched and so i was a so-called charter member and they had that trivia club online and i was always good at that, college bowl and all that. And I enjoyed that. But AOL at that time was off peak was four bucks an hour and didn't have any money. But if you won the trivia game, you got your hours comped. And that almost worked. Back in those days, that was amazing. I mean, now if you win the trivia game, you get a job offer as a developer. Right, right. So I got a little bit too into it and ended up being one of those AOL guides,

which was a combination of tech support and chat patrol. And at the time, I was a manager in medical records, and I was futzing around with computers. And the two sort of dovetailed that I had to manage, wait for it, a Novell Network 286 installer, 1990s healthcare. And I ended up leaving healthcare, taking a pay cut, and working for a company called Hollywood Online, which was AOL's only entertainment provider. And so that's in 95 how I ended up in that field. And then everything after that was sort of accidental. It was a kind of a backwards introduction into computing. what we'll call them modern generation of developers who have been doing this for almost three whole years, didn't get to experience in quite the same way. Which, on the one hand, is kind of sad because they didn't wind up getting the same deep level of exposure and experience with some of these things.

And on the other is good because we generally frown on child abuse. So there's definitely a strong sense of the world modernizing. But something that's always bugged me about that entire approach has been that I look at why I'm capable of answering weird questions about cloud computing. And invariably, I go back to fundamentals that I picked up back when I had to actually care about things like, is the SAN currently getting a full disk? Does it need to be partitioned further? What's the temperature look like?

Did someone actually pee into it? And now that I don't have to think about those things on a general basis, it's great because there are enough abstractions that have made it to a place where I don't have to. But the counterpoint is, is that I feel like I would be way less effective without that grounding in Unix.

Yeah, the progress of abstraction is a thing, you know, it's this train, right? And where do you get on the train? And so, you know, I knew people when I was a kid who were working on computers when you crawled inside them. And when everything was a big chunk of metal. And later on, when things got more abstract, they were very, very good at it. You know, my brother is a scientist, but he learned C because he had to write device drivers in order to make science go. And those people, to me, are sort of godlike because when they end up, say, writing a software, they know what's going on all the way down into, you know, electrical stuff. And I've always noticed that the people

who are really good at computing were not CS graduates necessarily, because that varies a lot, but they were electrical engineering graduates. Those people really know their stuff. So yeah, I mean, I joined at a time when, so to speak, the modern internet as a product was being invented, which was great because you didn't have to have a certification. We were inventing it, which was great, but we were still about five steps down from the originators. And as you're right, it's good and bad because when you get all those levels of abstraction, you keep moving up, you can get so much more done. I don't have to worry about anything, but at the same time, eventually you're going to have to go

to somebody who knows that stuff and it'll take you longer if you didn't have to worry about anything. But at the same time, eventually you're going to have to go to somebody who knows that stuff. And it'll take you longer if you didn't have that background. One of the things I find that's so compelling about vendor selection in terms of managed services or cloud provider or whatever phrase of the decade we're using to describe it is I always tend to bias for the one that I've worked with before. And some would say that, oh, that makes me a stick in the mud and I'm not willing to embrace progress. But my counter argument to that has always been that if I don't know how something fails, then I don't trust it in production because, spoiler, it's going to fail. And given my luck, it's going to be at two in the morning on a weekend. Right.

You know, one of the things that happens in this field, in a technical field, is people tend to carry around the other people they want. Like a new person comes in and their crew comes with them. Yeah. And I think technologies and products are that way too. It's like, yeah, I know the failure mode of this thing. As opposed to, well, they say there is, it doesn't fail. I wonder what it will be. So yes, I agree.

One of the strange things that always tweaks my notice is that you see folks who have resumes in the cloud engineering slash DevOps space, slash SRE space, slash production engineer, slash senior systems administrator. Again, we are all systems administrators. Some of us have just found the magic incantation that winds up leading to larger salaries. But there really tend to be two clear paths that people tend to go down before they land one of those roles. One of them is the path of the developer, the deep dive into, I write code all day, every day, and now I'm learning how operations works because, holy crap, it turns out that when I

write nonsense, there are consequences to it. And I love working with folks like that who have, I guess, seen the light. And then there are folks who generally tend to come from the other side of the world. And that's the one that I tend to come from, of being the systems administrator type, circa the 2000s era. The reason I call out the decade is because back in the 90s, to be a decent systems administrator, you had to know C pretty well. You had to have an in-depth knowledge of system calls. And you don't write code as a systems administrator was not something that anyone sensible would

ever say out loud more than once. Right. How did you come down this path? Where did you start? And do you see that being a real division or do you think that that's a bit of a false dichotomy? I'm very much in the SysAdmin end. I mean, I started out as sort of jack of all trades doing everything from, you know, plugging in the modem to bad web design to, you know, actually doing sort-related writing and things like that. And sysadmin was where I gravitated because I found that the human

factors end of it was terrible, but the technical part was easy. But I don't like sysadmin culture. I learned around that the job itself was negative, but that it was a bad idea to be negative. And that developers had more of the right idea of being optimistic. There was a guy I worked with who was old school. He hired the guy who wrote Pop 3. And then he gave me this lecture about your entire job is negative now. Your entire life is negative. You're just going to be the person who tells people it won't work and they can't do it that way. And you'll never create anything. You'll never be the hero. You'll never make money. You'll never do the product. And your entire task for the rest of your career is to spin negativity and make people like you. And I thought, yeah, he's absolutely right. And so my strategy after

that was to not be the BOFH, right? To be the nice assistant man, to be the one who says, we can't do that, but I'll help you get it done. And I think I learned both from developers and from the medical field, from people like physicians, that you have to combine that conservatism with an optimistic feeling and a desire to make things better. I, like you, really appreciate the developers who learn ops. They're rare because I'm not good at programming and having somebody to work with who can do both is tremendous. And I think that assistive means we criticize devs too much,

but that it's a good idea to take some of that confidence and positivity and put it into your work. Lots to unpack there. One thing I want to start with, I think, is how do you view this whole world of serverless? I mean, the idea is incredibly compelling. You write code, you throw it over the wall to your provider, and they handle all of the operational bits for you. And then you say, all right, great. What if it fails? How does it break? What does that mean for my application? And everyone just kind of stares at you blankly until you stop talking. Then they try to pretend that they didn't hear you. I feel like there's something that's getting lost there as far as being able to say, all right,

I'm going to write all of my stuff in Lambda functions. And now it is purely Amazon's problem because that's not going to break at all until suddenly one day it does. And we don't necessarily know how that's going to look. Does that make you uneasy? Yeah, it does, mostly because that way of looking at things, which you go back to containers, to JavaScript technology being used for lots of things or whatever. All that whole trend really grows out of startup web development and a very developer-centric world where basically everything should move fast and break things. The consequences for breaking things aren't huge. And everything is focused around getting something done and running. That anything else like planning or sort of the conservatism of

op stuff the scene is overhead kind of the negativity thing that i mentioned before and the thing about that is it gets stuff done real fast like you know if you're a developer and you can run a command line essentially and take all your code and it's just running that's awesome but the trend basically doesn't just abstract out all of this op stuff. It denies it, right? It basically says that's not happening. That's not a problem. If you've got a two-year exit strategy on the web service that just says, yo, this is awesome. If you've got a manufacturing line, if you've got a manufacturing line if you've got financial stuff if you've got stuff with real world consequences you have to look at the ops world and you have to either

have a really good vendor or have people who understand what's going on behind the curtain and can help with it because otherwise at that, it really is sort of a near fraudulent startup dream that you can just basically copy paste a bunch of code, pay someone with the fake money that you got from a venture capitalist, and it will just work. And that's a cultural or financial problem that I think has worked its way into technology to an extent where, yes, I love it. You can get stuff done really fast, but you really have to either not care about it being a black box or hire people who know what's going on in that black box. The problem that I see with this is on some level, it's always going to be a black box and hiring

someone who understands what that black box looks like is impossible at some level, it's always going to be a black box. And hiring someone who understands what that black box looks like is impossible at some level of abstraction. No one can hold everything in their head anymore. If you want to try this at home, listeners, all you have to do is wait for the next person to come interview who bills themselves as a full-stack developer,

and then ask them questions about device drivers to see how quickly people's knowledge erodes. No one is good at everything. There is no such thing in my mind as a full-stack developer. I'm the closest you get because I'm a full-stack overflow developer in which I copy and paste code that other people write and wind up doing that until it compiles. Right. You're right. There's something, one of the things I'm abhorred about is sort of engineering disasters and their implications for us. And there's a very, very good book called Normal Accidents, Charles Perrault. He defines a situation where if there's a system that one person cannot comprehend, and that is also very tightly linked, you know, so that a change over here causes a problem way over there, you will have accident. His example, unfortunately, his big example is nuclear plants. But you run into this a lot with what we're doing now. But yeah, even something like, oh, we have an app that, let's say, assesses risk for something. Well, the risk modeling person knows that part, and the op person knows this part, and the dev knows this part and the dev knows this part

but nobody knows the whole thing and so it will break and i think the nearest thing we can get to dealing with that in that serverless world sort of you're talking about is to educate first of all that people actually understand on some level what's happening back there and then get people with experience who've seen things because you develop a heuristic for things after a while i mean you do notice like you know this looks like there might be a disc full somewhere or you know this looks like network latency of this kind and i don't know how to get that aside from a making sure that devs do understand the basics of this stuff and what they look like. And then, you know, paying attention to ops and getting ops people who are able to penetrate that enough to do

diagnostics rather than just have to know how it all works. It's a terrific ideal. The problem is, and this is, I think, the real role of systems administration, however you want to systems administration, however you want to term it, however you want to lock that down and define it. It all comes down to, fundamentally, the idea that at some point, the buck has to stop somewhere. There's no longer anyone else within your company to technically escalate issues to. So the answer to almost everything that you wind up dealing once you've automated the banal away is, I don't know, but I'll find out. And that role has always had a

bunch of different terms. And my first job where I found myself in that role, we were the network engineering group or network administration group, depending on who you asked. And that was great. 90% of what I did didn't really touch networks, but rather had to do with digging into interesting problems and solving weird issues. And it was pretty apparent that what we found and how we wound up solving problems was in some ways dangerous because, easy example, someone on the support desk was terrific

at following instructions. He'd been there for 20 years and he was great at things. And I was making a change and I reached out proactively to him. What a concept, collaborating with the support desk because they are your phone firewall. And saying, look, for the next 24 hours, if anyone has issues with this particular system, use the command you give them to clear their local DNS cache because I'm going to be updating and repointing this, and it may cause some weird inconsistencies because, in fairness, I didn't plan ahead and reduce the TTL a week before. Oops. So the changeover went well, and things are going reasonably decently. And a couple of weeks later, I walked past his desk, and I listened to him telling someone to clear their DNS cache for a completely unrelated issue. And we saw some of this, where it's whenever you learn something new that applies to a specific problem, we often tend to have an incomplete understanding. It's why when you wind up calling for support, assuming that you do that for desktop support these days, I don't know

how that works anymore. I throw it away and buy a new one. But the idea was, oh, you call in and yes, I've rebooted it. Yes, I've reinstalled it. Okay, I'll defragment my hard disk and then call back. And there's this litany of, I guess, theater that you have to go through before you can get to the underlying issue in some cases. And because they tend to clear up occasional cases, it just gets added to the flowchart list of things to try before actually diving deep into stuff. Right. I feel like every company has a group that is responsible for coming up with these offbeat, deep dive solutions to esoteric problems where the buck has to stop with you. Invariably, those people get very well acquainted with things like Stack Overflow, Reddit, IRC, various forums, insulting people on Twitter, et cetera, et cetera.

Because that's, in many cases, where you find the answer to things. It's also why, even if you don't write code yourself, you find yourself reading an awful lot of source code as a step of last resort. Right. There's a level at which there's lore that accumulates with somebody, which is terrible. And then a level at which somebody is,

yeah, kind of a detective. And the gap between that role and the support people is huge. I trace it back essentially for the bad attitude system and thing of having contempt for users. I have to say, we often see the support people as our buffer against users, and we don't want to hear it or whatever. And so we give these incomplete instructions to support people as a way of shielding ourselves rather than a way of helping people out i mean ideally you should have run books for these things you know where the support person can intelligently look through steps to do or things to check or whatever that are explained so they

don't end up with what you're talking about. Like, oh, this is a solution thingy. It's like people who don't understand how medicine works are giving injections because injections work. And then it turns out they're injecting dirty water. So I think that, yeah, there does need to be a person or people with that escalated role of, hey, I'm going to go find out what to do about this. But if you don't take that extra step of then rationalizing that into something that you're perfectly capable and not inferior support person, you can then communicate to your also not inferior user, then you might as well be back in the 90s manually typing every single thing that

needs to be done and telling everyone else to get away from your desk. This episode is sponsored in part by Park My Cloud, fellow worshippers at the altar of turn that off. Park My Cloud makes it easy for you to ensure you're using public cloud like the utility it's meant to be. Just like water and electricity, you pay for most cloud resources when they're turned on, whether or not you're using them. Just like water and electricity, keep them away from the other computers. Use ParkMyCloud to

automatically identify and eliminate wasted cloud spend from idle, oversized, and unnecessary resources. It's easy to use and start reducing your cloud bills. Get started for free at parkmycloud.com slash screaming. There's this idea of the department of no, and I've heard it applied at different times to systems administrators, network administrators, security engineers, one very ornery barista, et cetera. And it seems like there's this adversarial historical culture where there's this natural tension that tends to exist between developments and operations. Whereas development wants to release features more rapidly, operations, on the other hand, wants to maintain stability. And if things are working right now, well,

change has the potential of disrupting that. And there's a natural tension and a requirement to work together that I feel is part of where the DevOps movement came out of. Is that something that you see? Yeah. And it's not at all specific to tech. And I think tech people can learn from how this works in other environments my very first job i was very lucky i got a professional journalist job when i wasn't even finished with college and i got to see how circa 1986 newspaper worked and so you had editorial so we write and we get photos and we edit things. We produce what we call nowadays the content. And we had advertising where they sold the ads and then they would end up with a spec for an ad and how big it would be. And then you had production who had to take the editorial stuff and the ad stuff and make a newspaper out of it. And we all hated each other. The editorial people didn't have what anybody needed. It was too long or too short or it angered the advertisers. And it was always late. And the salespeople were always coming at the last moment with something stupid or dictating what to be read or saying, please move the coffee cup on this thing 0.3 inches to the left. And the production people had to take all of this stuff and make a newspaper out of it. And it never worked. And so they were, so to speak, the BOFH sysadmins of this triad. And it was terrible. It was a weekly paper. And then we would have these screaming fights.

We put out the paper. We'd all go out drinking. And then we were friends again the next day. Because everybody understood that tension was going to happen. It's not going anywhere. It's how these things work. It's how the paper gets put out and how we survive. And you have to manage that tension and do your best not to be a complete jerk about it. But it's not going away. And the best thing you can do in that situation is to be less of the stereotype you want.

So, you know, as a sysadmin, I would like not be the department of no, I would be the department of hang on, let's get this thing right and get you what you want. I'm not saying no, I'm saying, please don't do this by pouring gasoline everywhere and striking a match. But I'm not going to hold you back. I'm going to get done what you want to do. And I think every job I've had along the way, I said some variant of that tension. The difference in tech is that I think that everybody's a little immature and they think they can win. The bosses, the devs, the marketing people, the assistant men's all want to win the argument. And that's not how anything gets done. That what you have to do is have those arguments, get things nailed down, and continue to cooperate

while knowing that this tension, in fact, isn't going to go anywhere and nobody's going to win. I feel like there's been a forcing function, at least, because you have development and operations. Both are required to work in relatively close proximity in order to get things out the door. Every time there's a release, that is a forced interaction. You see the same thing with the media interaction that you just described. This, I think, is the root of my actual problem with the term FinOps, the idea of finance and operations working hand in hand. There's nothing that forces that tight coupling. One of them is definitionally going to be a leading function and one is going to be a trailing function. And which one you pick to go in which spot

has a lot to dictate what culture you're building. I don't think that there's ever a story where you're going to have those people working in lockstep together on an ongoing close quarters basis in the same way. I think that the answer to the cultural story of FinOps, if you'll call it that, as a direct result, is simply distilled down to make sure that you keep different business departments in the loop and remember that we're all here to work together collaboratively rather than being massive jerks for the fun of it.

Yeah, the question of why are we here and what are we doing is one that tech people don't seem to want to answer. And you have to, I mean, if you're working for a business, what you're doing there is the business's goals, which are in some level to make money. If you're working for highway patrol, you're there to protect people's safety and the law or whatever. And you have to start with that and end with that. And FinOps, I hadn't heard that one. It's terrible. I mean, sure, ops, if you want to call it that, has to do with what the business does, just as everyone from the janitorial staff to the drivers to anyone else in the organization does. It's not special. Tech people aren't special. And I've had

these ridiculous arguments in the past where someone wanted to do something that was expensive and difficult solely because of some kind of tech purity reason and became enraged when someone asked, well, what is this going to do for the business? So yeah, you do have to work with tightly what the whole organization needs, whether that's finance people, marketing people, the person who sits next to you, turning it into a buzzword for a particular thing, I think obscures that essential problem that, you know, tech people need to get a little bit out of their gamer chair and realize that what we do all day is for the end of somebody else, that someone else is either paying for it or needs it, and that we're there to provide them something that works rather than them begging us for something that we have that's precious. So yeah, I don't like that concept of FinOps. I just think, right, well, everything is biz ops or org

ops, right? And you do have to know what your organization is about and that you're not rowing the opposite way from them in whatever buzzword you want to put on it. And that is not easy culturally for us. That's one of the problems that we see with, I guess, junior consultants, where it's easy as hell to come into any environment and say, oh, what have you folks built? Draw it out or describe it for me. And at the end, well, that's stupid. What complete moron built this?

Invariably, you ask that question to said moron. And in virtually every case, there is something that that person is missing. And that thing is context. It's no one, unless they work at Twitter's verification program, shows up in the morning hoping to do a crappy job at work today.

Right. Everyone is trying to get something out the door and achieve a business outcome. There may be constraints you're not aware of. Yeah, I can look at architectures from 20 years ago and, well, why don't you use some service that didn't exist back then? Oh, or people may not have been aware of an alternate way to do things, or there was a strategic imperative

to maintain some level of agnosticism, for example. There are a bunch of reasons that things could be radically different, but that's also with the benefit of hindsight. Remember, however broken and terrible it is, it's gotten them this far to the point where they're hiring said consultant to come on in and take a look at things. There's not a lot of value in just insulting the current state of the art. A child

can draw a whiteboard diagram that shows an architecture that works super well. The problem is how you get from the current state to that future state or something like it without shutting everything down for 18 months. Yeah. And again, this is a cultural problem on some level, again, about tech being special. You know, I worked in healthcare. I worked with physicians, you know, and they have the worst tech support job on the planet. Awful people show up and lie and they smell bad and they've done everything wrong and you still have to do your job if you're a nurse a doctor anybody in health care and you don't do that by being a jerk and

assuming things or whatever everybody arrives with their story and you have to deal with it and you know with technology the same you know you walk same. You know, you walk in, they say, junior consultant, you walk in and somebody has this horrible thing you need to fix. Well, you're going to go into a room with your friends and cuss about it later, right? Oh my God, who these people are doing? They've bolted something on the cold fusion to run Java. What year is this? But you can't do that with them, or even you can't keep that attitude while you're working at it. You have to say, oh, wow, okay, this is a big challenge. There's something here that needs to be improved. And we had to find out how much can we improve and what we can do for these people

and try to suss out what the brokenness is in the organization without saying the organization is broken. We can get something done. the organization is broken we can get something done sometimes it means you have to turn something down so the essential thing there's you arrive quite often with negativity and a mess you know the times when you have a green field thing that you can do yourself from the ground up and what you think of is right or very rare and also when you look back on what you've done quite quite often you think, oh my God, some unfortunate person is probably fixing that right now. So I think, yeah, the thing is, you can't get rid of that challenge. But just as the way that everybody from nurses to waiters has to go in the back room before they start cussing about how idiotic our thing is,

I think that as tech people, we should do our best to treat people as we would patients with a problem or people who want their fries done extra well and suck it up to a certain amount and treat it as something to improve rather than something to be disrespectful about. I think that that's the attitude to take with these things. As much fun as it is to be snarky and cynical and, I guess, difficult on the internet, we work with people and everyone's trying to do the best they can with the tools they have available. And I think that we still struggle as an industry with empathy. Yeah, it is. And I mean, a lot of it is just unearned arrogance from the past. I mean, some of the people who

originally came up with this stuff had to deal with really like weaponized stupidity, you know, and people who didn't understand anything at all and didn't want to and so forth. And it is a somewhat different world now that, you know, you're, so to speak, your customers do have some idea of what's going on or whatever. And also, you're not all that. I mean, we're not the people who invented the Internet. We're more like our customers than we are like Eric Allman or whatever, you're not all that. I mean, we're not the people who invented the internet. But we're more like our customers than we are like Eric Alman or whatever. So I think, yeah, that empathy and a certain amount of humility is a very important thing. And attitude. There's a thing that I call the fish food syndrome.

So let's say you have some friends and they have a goldfish and they don't know what the hell they're doing. They're feeding the goldfish like hot dogs and oatmeal and gasoline and dumping stuff in the bowl. And they kill like four sets of fish and they don't know what they're doing. Well, you know what you were really wanting to say, you are ridiculous. Goldfish get fish food and not that much of it. You have to clean the bowl. What are you even doing? You're a fish murderer. It won't work. They'll get mad at you. You won't have your friend anymore and they'll keep killing their fish. You come back to them and say, you know what? I heard about this awesome thing. There's special food for fish only for them.

You just give them a little of it. It works great. Your fish won't die. What you want to do is go to the pet store and say, I got some goldfish. I need some fish food. They'll help you out. It's not expensive and it's going to make your fish really great. And then they'll do it. But you kind of have to be next to them like, oh, we have this thing that we're both looking at rather than, you know, are you completely high? You know, you're shifting into reverse at 60 miles an hour. Not only will you be hurtful to people, which you really shouldn't be, but at the same time, you won't get anything done and people will hate you. So you do have to go to that level of, I'm not all that either, but I've got a secret I can share with you and then I can help you take care of it.

And together, we're going to get things done better. So Conrad, if people want to hear more about what you have to say, where can they find you? I don't know. I mean, I use Twitter, but like most people, I use Twitter in a way that is not particularly handy for technical people. Mostly it's me yelling about things, sometimes profanely. I don't know what you think technical stuff is, but that's where I live. Right, right. But, you know, there's like political stuff and shit posting and pictures of cats or whatever. I used to write on the internet a lot more. I mean, I did my decade of LiveJournal, and there is a blog out there, but it's old and not that great.

So I don't think I really have a place. So, yeah, my Twitter handle is Substitute. You can go there and look, and you might or might not like it, but it's not exactly a fount of technical information. Yet. There's always hope for a brighter tomorrow. There you go. Maybe I'll reinvent myself and start producing useful information. It's always possible.

Thank you so much for taking the time to speak with me. I appreciate it. Great to be here. Thank you. Conrad Heine, Principal Cloud Engineer at Glidewell Dental and Substitute on Twitter. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you've hated this podcast, please leave a five-star review on Apple Podcasts and a comment explaining why it is either the fault of development or operations. This has been this week's episode of Screaming in the Cloud. You can also find

more Corey at Screaminginthecloud.com or wherever Fine Snark is sold. This has been a humble pod production stay humble