The Relicans

Cover image for Tragedy and Resilience – Everybody Dies with Aaron Aldrich
Mandy Moore
Mandy Moore

Posted on

Tragedy and Resilience – Everybody Dies with Aaron Aldrich

Aaron Aldrich talks about applying the Red Hat treatment to Kubernetes, working as a Managed OpenShift Black Belt, resilience engineering, and running Tabletop DevOps.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.

play pause Observy McObservface

Jonan Scheffler: Hello and welcome back to Observy McObservface, proudly brought to you by New Relic's developer relations team, The Relicans. Observy is about observability in something a bit more than the traditional sense. It's often about technology and tools that we use to gain visibility into our systems. But it is also about people because, fundamentally, software is about people. You can think of Observy as something of an observability variety show where we will apply systems thinking and think critically about challenges across our entire industry. And we very much look forward to having you join us. You can find the show notes for this episode along with all of The Relicans podcasts on developer.newrelic.com/podcasts. We're so pleased to have you here this week. Enjoy the show.

Hello. Welcome back. I am joined today by my guest, Aaron Aldrich. How are you, Aaron?

Aaron: Actually, I'm going to say I'm doing pandemic fine, which is the word I just got from Twitter a couple of days ago.

Jonan: Oh, I'm taking that.

Aaron: Yeah, I'm employed and healthy during a pandemic but also depressed and tired and feel like trash all the time so, you know, pandemic fine.

Jonan: I have not been crying as much today as normal amounts of pandemic crying; therefore, pandemic fine. That's a good way to describe it, yeah. Well, I'm glad to hear that we are both pandemic fine. You are on this podcast because you work at this one place where they give out red hats when you get to work there. Do you have a red hat? Did you get one?

Aaron: I do have a red hat. It's in the background if we had video, but of course, being an entirely audio medium, this does not work out for you at all. But yeah, I've actually joked I said, “I think it's a requirement once you join that you're obligated to hide the red hat somewhere in the background of your video chat.”

Jonan: Now that I asked the question, I do see that the red hat is obviously there in the Zoom call that we're on. But I want to point out that I just had tunnel vision and wasn't paying attention at all.

Aaron: [Chuckles]

Jonan: But now that I see, you also have a Moonlander box under it, is that right?

Aaron: I do. If I started typing, that would be the thing that immediately overwhelmed all of the audio on the chat right now.

Jonan: Are they the loud ones?

Aaron: I suppose I can click for the podcast; that works out.

Jonan: Do it.

Aaron: I don't know how well you can hear them. [Keyboard clicking]

Jonan: Oh, that's good.

Aaron: Those are the Kailh. Is that how you pronounce their name? But they're the box, white switches from them. Cherry compatible, but they're made by another company. And they use an actual spring to make the clicky which is so satisfying.

Jonan: That is satisfying. And now that we're all pandemic fine and mostly working from home, then we get to have really loud keyboards when we want them. [Chuckles]

Aaron: Right. Only me. [Laughs]

Jonan: Yeah, it's perfect. I should do that more, but I do a lot of the streaming stuff, and so on a live stream, I imagine that would get kind of annoying. I could probably install some specialized noise cancellation. I've got the quiet switches on my Moonlander, which I still haven't adapted to using. How long did it take you to get used to the isometric layout?

Aaron: It took a while. The first day was awful, where it went from typing consistently like 100 words per minute to like 20, which was a very painful transition, but I'm pretty decent now. I wouldn't say I'm still back up to full speed, and this is probably like a week and a half, two weeks that I've had the keyboard. But I'm not noticeable at this point. The rate at which I can figure out what I want to type and the rate at which I'm typing is pretty good. I would only really notice it if I was doing copying from one thing to another if I was doing actual typographic work.

Jonan: Or like the keystroke combos like I'm trying to tab between things or I'm trying to copy-paste.

Aaron: Oh yeah. I've gotten those down pretty good and figured out -- I moved around the default layout a little bit to where I noticed I wanted to go. For some of the key commands, I'd always reach with a certain finger for a button. I was like, all right, well, let me change this around a little bit so that this works out.

Jonan: That's the nice thing about this keyboard is you can adapt it. I heard recently through someone complaining that it doesn't run custom firmware. You can't actually hack the firmware for it. It's like their firmware. Do you know anything about that?

Aaron: Well, I hadn't looked into it much beyond. I haven't wanted to do anything beyond just sort of changing the layout around a little bit, either.

Jonan: I feel kind of the same way about it now. I try to buy products that give me the option to hack them any way that I see fit. But it's like when I was an early Android user, and I was always installing these ROMs and rooting my devices, and now I'm just ugh, do I really want to break this essential device on the regular for fun?

Aaron: I've definitely crossed over that bridge in my life, having more of an Ops background than in Dev. At a certain point, I was like, you know what? I don't want to have to fix the one thing I use all the time outside of work constantly. [Chuckles] I'm just going to get the one that works. It’s in a walled garden, I know, and it's fine; I'm totally fine with that. It just works every time I want to use it. [Laughs]

Jonan: It's a walled garden; I picked it. So about that hat, what do you do there at Red Hat?

Aaron: So at Red Hat, I am a Managed OpenShift Black Belt or MOB for short for anyone that wants to really enjoy the acronyms there.

Jonan: This is a real title that you did not make up for yourself.

Aaron: No, that is the actual title that I have, yes. There is more than one of us, so you can look up Sasha Rosenbaum, who also has the Managed OpenShift Black Belt title.

Jonan: We're going to have to get Sasha Rosenbaum on the podcast, too, and then we can have a whole series about black belts. But in your day to day aside from what I imagine a lot of like karate-chopping and things, what do you do?

Aaron: We karate-chop Kubernetes for the enterprise. [Laughs] So yeah, the Managed OpenShift Black Belt, we do a lot of direct into enterprise customers where we work with a lot of -- think of it like DevRel but sort of targeted at some of your big customers. These big customers are part of that community, often hard to reach. Growing up in Connecticut, this has actually been one of my target demographics, even from community building stuff is these enterprise customers. How do I get these people who generally live in this isolated world of like, these are the problems that we have, and we’re like 500 of us, so why do we even bother talking to anyone outside of our organization? So yeah, it's like going into those places and actually talking about the cloud-native development and DevOps and all this other stuff to try and transform these big monolithic organizations into doing things in a new way.

Jonan: It's really interesting to me because it's a whole different approach to this kind of work. When you're doing community work in DevRel or wherever you're doing it, it's a very different audience. The enterprise developer is someone who has likely seen a non-zero number of webinars in their life.

Aaron: Right. Yeah. [Chuckles]

Jonan: Like, I have not seen a webinar --

Aaron: Especially now. I can only imagine the quantity of like -- whether it's technically a webinar or a virtual conference, the quantity of people talking at them through a screen about technical things has got to be incredible after this year.

Jonan: Yeah, the mandatory webinar attendance, I imagine to definitely be a thing at these enterprises. So you go, and you teach them about Kubernetes, but that's what OpenShift is. I'm sorry I am entirely ignorant of this thing. I'm revealing this in the hopes that you will educate me. OpenShift, though, is a managed Kubernetes from Red Hat.

Aaron: Yeah. So it's kind of applying the Red Hat treatment to Kubernetes. And so, if you're deeply familiar with Red Hat, you know they contribute and participate in the open-source upstream like the Fedora project lives upstream of Red Hat ultimately. And they refine that down the line until they have their enterprise version, which is locked down with industry best practices and maybe a few different default setting tweaks and is sort of certified to work on all your equipment, all that kind of stuff is Red Hat. Fedora won't do that, but it will give you the bleeding edge, but you don't want the bleeding edge when it's like making you money all day long; you want the reliable one. So it's kind of the same thing with Kubernetes, so it's not going to have the latest nightly release on it, but it's going to be certified for enterprise and packages with it all the extra stuff that you really want to get Kubernetes off the ground because it's really easy to start. That's kind of the problem with Kubernetes. It's super easy to get something launched, and then how do you manage that application from there? What do you do with the life cycle of that? So also includes all the operators and the huge use of the operator framework to automate things like hooking in your monitoring, hooking in all of your observability tools, all your life cycle management of the apps, and all that is defined really easily through both web interfaces and command lines. It's all that so that everyone gets the experience they need. If you operate a platform, developers just have to worry about pushing code.

Jonan: That sounds lovely to me. I have long made this case that I think startups get this wrong a lot when they are inventing ways to run their code. And I mean this is even at relatively small companies of 50 or 100 people. This is an entire team's worth of work that you're now taking on that's taking your attention away from building features. Find yourself a very, very easy way to get your apps into production and use that until you understand what you're trying to achieve in changing it, moving away from that platform. I was at Heroku for a long time, so I always recommended their product. Now we have Kubernetes and a lot of other options. If I install this OpenShift by default, I imagine there are a large number of security settings that are probably changed from their default. I know that you are just recently joining the company, but can you think of a thing that I should warn my enterprise friends about that exists in Kubernetes? Is it like, by default, it's wide open, and you can just get in the kernel?

Aaron: Kubernetes is always like new stuff. I'm trying to think of a good example. I don't know of a good default setting out of the box that specifically this changes for you. A lot of it is just out of the box you have to set all these things, and you have to kind of know, and it's like, well, what do you want to do for this? What do you want to do for that? And you're like, I don't know yet. I don't know about all that. It can have opinionated default, so I want to use Jenkins for my Pipelines. I'd like to deploy the Jenkins operator. It's like, great, here's the Jenkins instance. Here are all the defaults for that. It's up, it's running, and now you can configure it through everything else that you want to do. But yeah, there are some of the default security settings. A good example of the security was -- I'm trying to remember what it was. Last month or so, there was a big CVE that came down for Kubernetes. It was a container escape, right? Something like that happened.

Jonan: I think it was.

Aaron: So, based on the default configuration of OpenShift, none of our customers were even affected because of that default configuration; the workaround was already the default setting of OpenShift.

Jonan: You checked the box that said no container escape.

Aaron: Yeah, don't do that, please.

Jonan: Yeah, don't do that.

Aaron: It was defaulting to say, "Don't do that, please." [Laughs]

Jonan: Excellent. Nice. I'll pass on that security advice to my friends. Okay. So things that you do outside of wearing red hats, you also did this DevOpsDays thing in Hartford.

Aaron: Yeah. So I started the DevOpsDays in Hartford in 2017. So we have the three years, 2017, 2018, 2019, and then, you know, it's the now times, so that stopped. But yeah, it's been a great event there. I had gone to a DevOpsDays in Colorado in 2016 and came back to Connecticut, and we didn't have anything there. There was some stuff in New York and some stuff in Boston. But even though we're smack dab in the middle in Connecticut, it has its own unique group of people; it's a different type of developer that's there. So yeah, I started DevOpsDays there too.

Jonan: Have you heard of any of these going online? I'm sure there are people who've taken DevOpsDays online.

Aaron: Yeah, absolutely. There were a few of them last year all over the place. The biggest ones that I was involved in were DevOpsDays Chicago, which is headed by a number of folks you might know, Matt Stratton or Sasha Rosenbaum, who both are Chairs of DevOpsDays Chicago. And yeah, they did a fantastic event with all pre-recorded talks, and they really brought the production value up. They had professional recordings done for all the talks. So they would actually contact a recording crew near the speaker like in their home city and say, "Hey, are you comfortable going out to this place and getting recorded?" Based on your comfort with the pandemic and everything else, you would go and actually get a professional recording of your talk, and then that was played. So the production value was really, really high, and they actually did the hosting of it live in. I think it was a restaurant that no one else was there because they're not doing business there anyway. So they borrowed the space, and they were actually live hosting it from there. So it was done more like a television production which I took a lot of inspiration for DevOpsDays Boston, which I helped to do the production of. I wrote a whole blog post about all the background on what I did. Ours was more done live streaming style. I used OBS to do all the production for it, but it came out really good. So that's another one people should check out.

Jonan: This is no small feat. We just launched our team here at New Relic. I'm on the DevRel team, and we have this -- we call ourselves The Relicans. So we had this big launch event, a 24-hour live stream. And just to help people empathize with the experience of live streaming, we didn't let our audio work for the first 30 minutes or so.

Aaron: Yeah, that's the right way to do it. [Laughs]

Jonan: Yeah. We wanted to make sure they really understood the pain of the experience. Yeah, this online video production is not a small thing. That's actually a really clever idea to send people to a local studio if they are comfortable, of course. I'd want a recorded video from the studio of them just coating everything in Lysol before I went.

Aaron: [Laughs]

Jonan: But it overcomes this issue that we all have with online events where someone's got a bad camera or bad audio or bad internet. It's too much. There are too many moving parts. We all know computers are terrible, too much moving at once for everything to go well. So you mentioned as you were talking about the way that this OpenShift product is set up the idea of an opinionated default. And I'm curious to hear your thoughts on opinionated systems and opinionated software. You've got people who are in communities around software where they say, "Yes, I would like someone who is an expert on authentication to give me the easiest best way to do that thing like choose the quality solution for me." And then there are people who want the flexibility and almost as a requirement have to go and understand that thing in depth in order to set it up. Which side of the camp do you lie on there?

Aaron: I'll give the great and wonderful answer of it depends.

Jonan: Oh, nice. Thank you for that.

Aaron: [Laughs] Which is always the answer you get when you’re asking questions like this sort of thing. I love an opinionated tool, and I think the line to remember is your culture informs the tools that you use, and the tools can inform the culture as well. Tools can make practices easier or hard. Actually, startup realms and where I was before actually make a lot of sense. So I used to work for Elastic talking about doing observability and all these sorts of things. And I talked to folks who were saying, "Well, what should we do for this, that, or the other thing?" And I would generally come back and say, "Well, what's your workload at? Are you three engineers who are all doing everything and you have no free time? You should not set up Elastic right now. [Laughs] You shouldn't do it because it's too big, and it can do too much, and it has too many options for you. You have to learn it, you have to know it, and you have to understand it before you can really get it to do what you want. Go out to the Honeycombs or the Lightsteps or the New Relics and have someone just dump a thing on you. It's opinionated; it's going to give you something out of the box. You're not going to have to operate it. You're not going to have to think about it. You can just get through this phase. If you come to the point where you really need something custom out of it, you're not able to get the precise data you want, or you're not able to put the right things together you want to get insights out of, then we can come back and have that conversation because now you're interested.” There's a value to learning and having an opinion and developing that rather than just taking the expert advice.

Jonan: I think this makes a lot of sense. I don't like “it depends” as an answer to which opinion do you have, but I agree with you that it depends. It definitely does. It's about how much time and energy you have to expend exactly as we were talking about...

Aaron: Yeah, and whether you're getting value out of it too. So the other side of it is, is it worth it for you to spend time in engineering cycles building out your container platform and understanding exactly how it works and how all the components fit together, and maintaining their security vulnerabilities? Maybe that's valuable to you, and it makes your product better. But maybe the customers just want to access their Netflix, so you just buy a platform. Netflix is a bad example because they were doing it before everybody else, so they had to invent the platforms. But if you're doing it now, you're serving up: I just got gas today. You're serving up the gas app that authorizes the pump for your loyalty card, right?

Jonan: Oh yeah.

Aaron: You don't want to reinvent the platform just to make sure people can get gas. You can buy one that's opinionated and just write your apps.

Jonan: You didn't build the hardware to swipe the credit card on the --

Aaron: Right, exactly for the same reasons. You didn't need to be an expert in reading mag stripes; that’s not necessary. Let’s let someone else do that, and you just put the logic together in the back end.

Jonan: There are very few people who are uniquely suited to write the features for your users. You understand your product and your customer base to do that.

Aaron: Right. I’ve actually been saying that I think more and more the business logic steps and understanding how to get that like, where is our value? What's the business logic? What are our customers after? And understanding how you deliver that value that's going to be the key skills, especially for operations folks when you're looking at how do we optimize and modernize our infrastructure? Understanding that business process and where you're delivering value is big rather than just learning what is the best platform to do this on?

Jonan: Yeah, exactly, and chasing the thing because it is new and fun, and shiny is not ultimately the point; it's about the value. This service-level objective thing describes this. I understand the SLOs talking about actual outcomes for your customers. What is it that is affecting our customers here? When you're talking about the business generally, though, I want to hear your thoughts on this theory that I have that our software and our infrastructure is actually a mirror of the structure of businesses. And when you have a lot of departments -- You have a very large enterprise with a lot of convoluted departments that are similarly named, and like the equivalent of spaghetti code on a business, organizational level, then you see that mirrored in the systems that we end up creating. I have a theory that it's your job to fix that.

Aaron: [Laughs] I like that you put that just squarely on my shoulders. You're like, I want to know what you feel about my theory.

Jonan: [Laughs]

Aaron: My theory is you're responsible for this mess.

Jonan: Yeah. Could you fix it already? What the hell?

Aaron: [Laughs] I agree with that statement, and that's I think Conway's Law that roughly says the things we build represent the communication structure of our organization, right? So we're going to build that hierarchy into our software just because that's how we think about decisions, that's how the business logic happens, that's how the decision logic is going to get carried into what we write. And I actually talk a little bit about that in a talk I've given about resilience engineering, and it talks about how the aim is for those loosely coupled overlapping networks. That's the aim of DevOps is these networks that have tighter signaling around the things they're responsible for, and they're sort of loosely connected to everything else. Everybody overlaps a little bit here and there.

Jonan: Is resilience engineering how enterprise folks say chaos engineering?

Aaron: So resilience engineering is actually an academic field around the same concept. So it's existed for a while. David Woods has written a couple of papers on it. You'll end up with a lot of PDFs when you dive in here because it's a lot of academic favorites. [Laughs] It's a lot of things handed to you. John Allspaw is one of the big folks in that realm who came out of the computer engineering realm and started applying these concepts to computer engineering and realizing first off it's a great corner to study. Like the medical corner cares a lot because they definitely care about how do we operate under uncertainty at high stakes? So there’s lots of this that happens in hospitals and so on. And safety or like safety II or new safety sometimes is heard of like, that comes out of the same studies.

Jonan: Safety 2.0?

Aaron: Yeah, and sometimes it's been the marketing for it. But yeah, with computer engineering because we iterate so fast because we're constantly building over and over and over again, we're making new versions, trying it again, and trying it again, and trying it again, we can do some really interesting and fast study on what does it mean to be resilient? What does it mean to respond to the unknowns and the chaos?

Jonan: It's chaos engineering but with more PDFs.

Aaron: Right. It's a little bit more study, a little bit more academic, more PhDs. It's chaos engineering with more PhDs. That's really what it is.

Jonan: It certainly seems less offensive to someone in an enterprise boardroom. I had a person who was a banker teach me that you're not allowed to call old systems legacy systems in that environment, specifically with bankers; you talk about historical systems. Well, now the historical system, which is almost like these lovely servers.

Aaron: Legacy almost sounds a little better.

Jonan: Yeah.

Aaron: [Laughs]

Jonan: Yeah, historical systems.

Aaron: What are the pre-historical systems? That's the real question.

Jonan: That's the real problem, yeah. The pieces of this that you mentioned I want to call out real quick. This Allspaw fellow, John, wrote some books, right?

Aaron: Probably. I don't have them referenced off the top of my head.

Jonan: This is the one that was talking about– the air traffic control as an analogy for how air traffic controllers handle failure and protect themselves from failure in the systems they design. It comes up every podcast, and I keep trying to get people resources to find online about this kind of thing. I'll do a little bit of research and find some things for people.

Aaron: I've probably got some links bookmarked I can send to you after this that will -- some of the places I've got and where I've done my research on it too.

Jonan: I want to talk then a little bit about games, board games. I understand that you run a thing called Tabletop DevOps.

Aaron: I do.

Jonan: And I like board games. I've also lost a lot of friends over board games.

Aaron: [Chuckles]

Jonan: Settlers of Catan is the best one at this, in my experience. What is your best board game to never speak to someone you like ever again?

Aaron: I've got to decide which one really puts it over the edge, whether it's the betrayal or just the length of the game that really which one weighs more.

Jonan: [Laughs] I feel like it's the betrayal.

Aaron: I would say Diplomacy at that rate. Diplomacy is the one because there's someone who’s going to get stabbed in the back. It’s going to happen.

Jonan: Every time. Guaranteed.

Aaron: It's going to happen. [Laughs]

Jonan: Those kinds of games, Diplomacy, if I'm remembering, is the one where you're drawing a card, and you have a secret role, and someone is an assassin type-role.

Aaron: Diplomacy is like Risk, but it's World War I one setting, so all your moves are handed in. You give an order for all of your pieces, and you hand them in secret style, and then they all happen at once. Everything gets turned over and happens at once. So the only way you defeat an army is by having more units move into that space. This guy is going to get supported by this guy, and they're going to kick your one guy out. So it requires cooperation. But also, you can choose to backstab people, and there are only so many people, and there are only so many people who can win. You could choose to draw, but how many people do you want to tie with, all of them or just like one or two? [Laughs]

Jonan: So it's actually not just based on the rolling of the dice as you would find in Risk, right?

Aaron: Right. It's all diplomacy, as it says. It's all negotiations with all the other people at the table and making plans and schemes.

Jonan: So I don't end up in a situation like I had where my son knocked off 100 soldiers with his two soldiers in Irkutsk just destroying–

Aaron: [Laughs] Right. It's always Iceland for us. For some reason, like you stack up all your armies on Iceland, and no one can get in. [Laughs]

Jonan: The chance part of that game was never particularly pleasant. I don't enjoy games that are -- I mean, there is some strategy to Risk, and I'm getting emails about this. Yes, Risk, great game, the strategy involved.

Aaron: A whole lot of dice.

Jonan: Yeah, a lot of dice. I taught them the first game, and they teamed up on me, and they knocked me out of the game almost immediately. They decided that was a boring strategy. And so then the next time, they were like, “All right, we're going to play fair. We're going to just play the game normally.” And I just destroyed them, of course, because they're children. And then I lorded it over them for days.

Aaron: [Laughs] Well, they needed to know their place, obviously.

Jonan: I had to get my revenge. Yeah, just because I'm a grownup doesn't mean I'm not petty. So the gaming question comes up because you run a thing called Tabletop DevOps. Is that right?

Aaron: Yes.

Jonan: And what is Tabletop DevOps?

Aaron: So Tabletop DevOps is currently the live stream that I run monthly right now. So we just started in December, and then we had one as of recording this past Sunday, and we've played a game of Werewolf. And then this January, I put out a poll because I was trying to figure out what to play, and I was like, we probably shouldn't play the card game Coup, right? Would that be too on the nose or just the right amount of on the nose? And it turns out everyone that follows me is also the same kind of sick that I am. So we played Coup this past Sunday, which was great fun. We found a project that someone built sometime in 2020 for their college coding project, and it was Coup but online. So it was just this web app version of it. I was like, yes, we're totally playing the open-sourced web app version of Coup for Tabletop DevOps. It only crashed twice on us. So we did all right. [Laughs]

Jonan: That's pretty good, actually.

Aaron: I was like, someone did probably code it half-drunk in their dorm. So it's pretty good for that, right? [Laughs]

Jonan: Yeah. It's just like all of the tools that I found. Before this job, kind of early days in the pandemic, I was playing Magic with my friends, but I play this kind of Magic that is not fun to play on the online versions that they have.

Aaron: Sure.

Jonan: These giant decks of like silly old cards. And we would play on webcam, but then these platforms started to emerge, and they were all using WebRTC and crashing. I'm like, wow, you're going to melt my whole computer with a web app. How is that even possible? That's cool, though. This is only the second month that you've done it.

Aaron: Yeah. So January was the second month, and I'm just about to lock in the date for February. I have to go look at the Doodle results and figure out which date actually lines up for everybody. But sometime, at the end of this month, within the last week and a half or so, we're going to play a game of Ten Candles.

Jonan: Oh, cool.

Aaron: If you’ve sort of heard it before, it's a role-playing game in the tragic horror genre, so have you focused on storytelling, tragic horror because it's going to do a spook, and everybody dies because it's a tragedy. So yeah, it's really good. I checked it out. I fell in love with it. And Josh Zimmerman has a great idea for a scenario that we're going to play through. So he's going to GM for us, and it will be awesome.

Jonan: And everybody dies because it's a tragedy is going to be the title of this episode.

Aaron: [Laughs] Perfect.

Jonan: I mean, every game night has its downside, everyone dying, right?

Aaron: Right.

Jonan: Okay, so Tabletop DevOps is the thing. And if you go and watch now, then you get to say that you were there before it was cool, although it sounds pretty cool already. This is only the second month.

Aaron: It's always will have been cool, but before, it was popular at least, right?

Jonan: Right. You get the hipster cred by showing up now.

Aaron: Yeah.

Jonan: I look forward to playing some games with you when this pandemic ends. We've got to get together at a conference sometime and play some board games.

Aaron: For sure. My hope is this sort of continues, and then I can play in real life with people's Tabletop games. So like the Tabletop becomes more literal instead of a metaphor for the whole scenario.

Jonan: Yeah. Well, it was really nice having you on the show. I really appreciate you coming along. Is there any bit of advice? I ask this on all of the shows, but I like to leave a little gift for anyone who's new to their career here in DevOps. Or give yourself some advice when you were just starting out, is it: acquire a red hat as soon as possible?

Aaron: [Laughs] Well, I mean, if you can get an offer at Red Hat as soon as possible, it's not a bad place to work, so that's not bad advice. But I would say probably the best self-advice I can give when you get involved in whatever local communities you have around tech, probably hands down the thing that's given me the biggest leg up in my career has been being involved with DevOpsDays and being involved with the community work. Just the amount of people you meet and the new ideas that you're exposed to are wonderful. So yeah, I encourage everyone to do that.

Jonan: Get involved with your communities. This is a large part of why I do the work that I do because if not, I would have burned out and not recovered long ago. It's the people who sustain me.

Aaron: We are all we have.

Jonan: [Chuckles] Yeah. We're in this hell together. Keep fighting. We're going to defeat computers sooner or later. We will win.

Aaron: Computers were a mistake. We're trying really hard to turn the needle back the other way.

Jonan: [Laughs] So far, so good? All right. Well, thank you so much, Aaron. I hope you have a wonderful day or at least pandemic fine for the rest of it.

Aaron: Absolutely. You too.

Jonan: Take care.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. Right now, we're running a hackathon in partnership with dev.to called Hack the Planet, where we're giving away $20,000 in cash prizes along with many other fabulous gifts simply for participating. You'll also find news there shortly of FutureStack, our upcoming conference here at New Relic. We would love to have you join us. We'll see you next week.

Discussion (0)