Speaker 1: For real this time, Warren, sound check.
Speaker 2: I think I'm still here.
Speaker 1: All right, you are welcome, glad to have you. Jillian, Hello, Hello,
Speaker 1: welcome back after your time jet setting around the world
Speaker 1: or whatever you were doing.
Speaker 3: I was helping somebody move last week.
Speaker 4: So now that I like live back home my family,
Speaker 4: I keep on being expected to be like a real
Speaker 4: adult who shows.
Speaker 5: Up for them.
Speaker 3: It's been quite the transition for me. So there we go.
Speaker 1: And then joining us today, Adriana. I forgot to ask
Speaker 1: how to pronounce your last name Valleyla Valela Valela. Oh
Speaker 1: you were close everybody that's an e in there. Yeah, yeah,
Speaker 1: I should probably have my glasses checked. But hey, welcome.
Speaker 1: I'm glad to have you here, happy to here right on.
Speaker 1: So the big thing I want to shout out right
Speaker 1: away is you are the host of the Geeking Out podcast.
Speaker 1: I am right on, so tell us how that's going.
Speaker 5: So I started the podcast, say twenty twenty three. I
Speaker 5: was in the fall of twenty twenty three. It came
Speaker 5: on the heels of a previous podcast that I was
Speaker 5: doing through work with former coworker of mine on the
Speaker 5: Margarita Medina and Our podcast. And this was a work
Speaker 5: related podcast, and you had the best name. It was
Speaker 5: called on Call Me Maybe. Damn it. It was like
Speaker 5: so much fun. We had about two seasons of it.
Speaker 5: I want to say it was like about twenty six episodes,
Speaker 5: and then we were no longer able to continue it.
Speaker 5: So then I thought, well, I want to still keep podcasting,
Speaker 5: so I started my own podcast, Geeking Out. And then
Speaker 5: I was because we used to have like an editor
Speaker 5: for on Call Me Maybe, and I'm like, damn it,
Speaker 5: I don't know how to do any of this podcast
Speaker 5: editing stuff. And my daughter, who I guess was fourteen
Speaker 5: at the time, she's like, I'll help you out, mom.
Speaker 5: So I'm like, okay. So she helps me out with
Speaker 5: the editing. I've up to my editing game as well.
Speaker 5: But she's also designed the logo for it, which has
Speaker 5: copy batas, which I love. I don't know. They're just
Speaker 5: fun animals, and I got introduced to them on Instagram.
Speaker 5: I started like getting all these videos. I'm like, oh
Speaker 5: my god, where have you been all my life? So anyway,
Speaker 5: they're like our mascot, so cute. They're doable because I
Speaker 5: just scored a couple at Miniso. I don't know if
Speaker 5: you guys have that in the States. But yeah, it
Speaker 5: was Yeah. I was like, oh my god, this is
Speaker 5: the best. And yeah, and the podcast itself I have.
Speaker 5: It's a tech podcast. I interview a lot of folks
Speaker 5: in tech. I especially like to give voices to women
Speaker 5: and other under ruppers groups, and of had a I
Speaker 5: don't know a combination of people who are both super
Speaker 5: well known in the industry and not so well known.
Speaker 5: So I guess my highest profile guest was Kelsey high Tower.
Speaker 5: I've had Charity Majors, Liz Fung, Jones, Hazel Weekly, so
Speaker 5: lots of lots of fun guests and then other people
Speaker 5: that I've met along the way where I'm like, you
Speaker 5: have such a cool story, you should be on my podcast.
Speaker 1: Right, Like, once you start a podcast, like you're always
Speaker 1: it feels like a sales role, like always be closing.
Speaker 1: You know, you're always like trying to pull people into
Speaker 1: the show.
Speaker 5: So true.
Speaker 1: True, So you're also a CNCF ambassador and principal developer
Speaker 1: advocate at Dina Trace. That's correct, right on, Dina Trace
Speaker 1: is cool. Like some of the stuff that they expose
Speaker 1: and dig into, it's like, wow, you you went way
Speaker 1: deeper into this than I wanted to go.
Speaker 5: It's so true and it's funny. So I just I
Speaker 5: just started my job at Dina Trace in November of
Speaker 5: last year, so I'm pretty fresh, and you know, I
Speaker 5: I I came in because of my connection to the
Speaker 5: open telemetry community and my previous job. I was a
Speaker 5: developer advocate at light Step, which had gotten acquired by
Speaker 5: a service now, so I'd gotten into the open telemetry
Speaker 5: and observability community and and so when I joined Dina Trace,
Speaker 5: I'm like, well, you know, it's like also an observability vendor,
Speaker 5: but it's like so much more. And so one of
Speaker 5: my one of my co workers, h Andy Grabner, he's
Speaker 5: been with Dina Trace forever. I call him mister Dina
Speaker 5: Trace because he's like he's so he's so passionate about
Speaker 5: the platform and what we do and and everything. And
Speaker 5: he's really helped me. Uh He's given me a tour
Speaker 5: of the platform, and we have this video series that started.
Speaker 5: It started because he was like, hey, you know, it
Speaker 5: would be good for you to like get to know
Speaker 5: the platform. And every time he showed me new stuff,
Speaker 5: I'm like, dude, this stuff is so cool. You know
Speaker 5: it would be really fun if we did like a
Speaker 5: YouTube reaction video series kind of thing where you just
Speaker 5: show me stuff for the first time and I react
Speaker 5: to it. So then we started this video series called
Speaker 5: Dina Trace. Can do that with open telemetry, and my
Speaker 5: reactions are are like O natural because I can't act.
Speaker 5: So it's been it's been a fun way to learn
Speaker 5: about what the product does and also like share share
Speaker 5: that same wonder with the rest of the world.
Speaker 1: So yeah, yeah, Dina Trace is like a gateway drug,
Speaker 1: Like you come for the observability and then you're like,
Speaker 1: oh wow, and then just go deep down the rabbit hole.
Speaker 2: That name sounds familiar. It was was Grabner on our
Speaker 2: show already.
Speaker 1: He was, yeah, I think it's been Actually, I don't
Speaker 1: know how long ago. I had this conversation with my
Speaker 1: I have this conversation with my wife the other day.
Speaker 1: Like I have three time periods in my life. I
Speaker 1: can group things like prior to nineteen ninety, between nineteen
Speaker 1: ninety and yesterday and today, and I can't get any
Speaker 1: more granular than that.
Speaker 2: I think that's one up on most of the population, though,
Speaker 2: like what happened five minutes ago and that's it, right, So.
Speaker 5: True Also, I thought nineteen ninety was like yesterday, Like
Speaker 5: where did this time go?
Speaker 1: Don't do the math, don't do the math. It's just
Speaker 1: gonna do no.
Speaker 3: No.
Speaker 5: It really depresses me when people are like so I
Speaker 5: was like born in nineteen ninety three. I'm like, oh,
Speaker 5: I was in my first year of high school. Cool.
Speaker 1: Cool. So we were going to talk today about observability
Speaker 1: in the CICD platform, So tell me a little bit
Speaker 1: about what that means to you.
Speaker 5: So, I guess the main thing is, I think when
Speaker 5: we talk about observability, there's thillse this uh stigma. I
Speaker 5: guess I don't know if stigma is the right word,
Speaker 5: but we have this association that observability is like an
Speaker 5: essry concern, right, because that's that's where when when things
Speaker 5: go kaka in prad, you know, you you turn to
Speaker 5: your observability solution and look through you know, the traces,
Speaker 5: the logs and metrics to figure out what's going on
Speaker 5: and all that, which is awesome, but you know, it's
Speaker 5: it's so much more than that, because, first of all,
Speaker 5: like it, observability is a team sport, right in order
Speaker 5: for that telemetry to even get emitted in the first
Speaker 5: place and it Yes, there's some telemetry that you automatically
Speaker 5: pick up from from your infrastructure and whatnot, but there's
Speaker 5: also the telemetry that has to be written by somebody, right,
Speaker 5: so you're you're developers and and so the developers have
Speaker 5: to care about observability, right, So now we're we're not
Speaker 5: seeing observability is just like, oh, it's not just a
Speaker 5: necessary thing. Someone had to put in that telemetry in
Speaker 5: order for us to be able to even have this
Speaker 5: conversation of understanding what our system's doing. And we can
Speaker 5: take it a step further and say, well, you know
Speaker 5: what if during the software development life cycle, like you know,
Speaker 5: developers instrument their code. This gets handed off to QA,
Speaker 5: and QA can use the observability data and say, hey,
Speaker 5: I can use this to troubleshoot my code or to
Speaker 5: troubleshoot the code that I'm testing, and I can provide
Speaker 5: that feedback then to developers and say hey, I found
Speaker 5: a bug and this is what's happening. Or they can
Speaker 5: say hey, I found a bug. I don't know why
Speaker 5: this is happening. You need to instrument better. So now
Speaker 5: we're like we're shifting, We're shifting left right on observability.
Speaker 5: So we've got so we've got the development side, we've
Speaker 5: got the qaside, we've got the production side with with
Speaker 5: our sries and whatnot. But then there's that also piece
Speaker 5: in the middle, which is, you know, our CICD pipelines
Speaker 5: that we've come to rely heavily on our CICD pipelines
Speaker 5: to ensure that our code gets built and our automatic
Speaker 5: automated tests get run and gets deployed to production. Awesome,
Speaker 5: but like what happens when that pipeline goes KACA Because
Speaker 5: that pipeline, even though it's internal in itself, it is
Speaker 5: a production system. So how frustrating is it when you've
Speaker 5: got you know, your CICD pipeline is working like a
Speaker 5: well oiled machine, and you're like, this is amazing, And
Speaker 5: then you come to realize that suddenly one day something
Speaker 5: goes weird, some change was made, and you have no
Speaker 5: idea why it's failing, And wouldn't it be nice if
Speaker 5: we could also have observability into our CIICD pipelines. And
Speaker 5: so we are starting to see a movement in that direction,
Speaker 5: which is amazing because now we're no longer in the
Speaker 5: dark around around our CICD pipeline. So this is for me.
Speaker 5: I think this is a really fascinating topic. I dug
Speaker 5: into it a little bit a couple of years back.
Speaker 5: So I have I have this video course that I
Speaker 5: did with O'Reilly that it came out last year early
Speaker 5: last year, and as part of it, I'm like, hey,
Speaker 5: I want to do something on observability CICD pipelines. Is
Speaker 5: like just a short chapter on that. And then I'm
Speaker 5: like starting to do some research. I'm like, crap, there's
Speaker 5: like nothing on this, what the hell? And then I
Speaker 5: was I was messaging one of my friends in open Telemetry.
Speaker 5: We we're both maintainers of the Open Telemetry and User
Speaker 5: SIG and we've done a bunch of talks together. She's
Speaker 5: she's my hotel writer. Recently, we we we talked at
Speaker 5: keep Con together all the time. It's like it's a
Speaker 5: great partnership. And I'm messengering her. I'm like, you know,
Speaker 5: there's really not a lot of material out there on
Speaker 5: the observability of c ICD pipelines. She's like, that could
Speaker 5: be a really good talk topic. I'm like, that's so awesome.
Speaker 5: So we we put together we put together a talk
Speaker 5: I think it was I want to say it was
Speaker 5: I want to say it was cubecan Chicago in twenty
Speaker 5: twenty three that we we talked. We did that talk
Speaker 5: for Observability Day, and it's been nice to see that
Speaker 5: space evolve over time. I think there's now an official
Speaker 5: like CICD SIG within open Telemetry I want to say,
Speaker 5: so then there's actual like movement towards standardizing the observability
Speaker 5: around CICD, because at the time when we were we
Speaker 5: were doing the stuff, like when we were investigating, it
Speaker 5: was this mish mash of tools that were available. So like,
Speaker 5: for example, depending on what tool used for CICD. So
Speaker 5: Jenkins for example, had some observability capabilities built in, so
Speaker 5: it did emit some like hotel some Hotel signals. But
Speaker 5: then get Hub if you wanted to have like observable
Speaker 5: get hub actions, there's some like homegrown options. But now
Speaker 5: that means you're having to rely on someone else maintaining
Speaker 5: that if you want to have observable CICD pipelines, And
Speaker 5: then what if they stopped maintaining those get hub acts,
Speaker 5: are they discontinue?
Speaker 4: Yeah?
Speaker 5: Right, So like that that's a little bit scary if
Speaker 5: you want to rely on that get lab. At the
Speaker 5: time when we were investigating they they were starting they
Speaker 5: were having conversations around standardizing around that answable. At the time,
Speaker 5: I think they had like an hotel plug in so
Speaker 5: you can have like uh, when you're when you're doing
Speaker 5: your your ANTSPEL playbooks, you have some observability around that.
Speaker 5: And then there's there is I want to say, there
Speaker 5: was like an hotel. I forget now what it's called,
Speaker 5: but basically you could have hotel for Bash. And it
Speaker 5: was funny. We were we were talking about this at
Speaker 5: our talk and then later at that cupcon recent I
Speaker 5: met the person who who created that, Amy Toby from
Speaker 5: She used to work at Equinox, but she created that tool.
Speaker 5: I'm like, oh my god, like mega fangirling. I'm like,
Speaker 5: we talked about your.
Speaker 3: Tool and you're here.
Speaker 1: So when we talk about observability in the C I
Speaker 1: C D pipeline, what kind of metrics or insights are
Speaker 1: you looking to expose there?
Speaker 5: You're wanting to look at things like how long you're
Speaker 5: spending on on your builds, how long you're spending like
Speaker 5: at each stage of your pipeline, for example, identifying pipeline failures.
Speaker 5: That's another thing, because and and and being able to
Speaker 5: standardize it with open telemetry in particular, because I think
Speaker 5: that's the main thing too, is because like a lot
Speaker 5: of I would say, a lot of the industry has
Speaker 5: moved towards standardizing on open telemetry, making sure that then
Speaker 5: we're still continuing to speak that same language.
Speaker 2: Right, gotcha.
Speaker 1: Yeah, So then you still have access to all of
Speaker 1: those same insights, but you get it from your same
Speaker 1: observability tool that you get all of your other metrics.
Speaker 5: From exactly exactly. And and also like you know, you
Speaker 5: add distributed tracing into the into the mix, and all
Speaker 5: of a sudden, now you're also able to have this
Speaker 5: nice visualization of like your your build pipeline, right you
Speaker 5: can you can see like all of the stages nicely
Speaker 5: as well through through your observability vendor, which I think
Speaker 5: is really cool.
Speaker 2: I think I think every company I worked for had
Speaker 2: a pretty good hands on strategy for managing observability of
Speaker 2: their pipelines. Whenever it failed, someone got an email and
Speaker 2: then they went to the product and they clicked retry.
Speaker 3: So my favorite one is when you're in a feting
Speaker 3: and somebody's like, shouldn't this have been done already?
Speaker 4: And then I go and I check the pipeline and
Speaker 4: I'm like, well it should have, but it failed and
Speaker 4: so it didn't.
Speaker 3: And then.
Speaker 2: You didn't even have the emails. Yeah, that's step one.
Speaker 3: No, it's just it's too many emails and then I
Speaker 3: turn them off.
Speaker 4: It's like how every like messaging platform is really great
Speaker 4: until everybody's on there and then I get too many
Speaker 4: messages and then I and then I turn it off.
Speaker 2: It's like, oh, I mean, let's let's go the horror
Speaker 2: story route. So the one I know is we were
Speaker 2: using SPN at the time, so already a great start.
Speaker 5: Oh damn.
Speaker 2: And this was an upgrade from what my previous company
Speaker 2: had been doing, which was no source control for their
Speaker 2: source code. So this was yeah, this was like, wow,
Speaker 2: actually there is a company that knows how to do
Speaker 2: source control. Because I had been using get for a
Speaker 2: lot of years before that, and so I was shocked
Speaker 2: that this is what the state of the industry was.
Speaker 2: But the genius thing was that you couldn't figure out,
Speaker 2: like you knew who the committer was for each each failure,
Speaker 2: but you had no idea if it was like their fault.
Speaker 2: So the genius thing was that they converted it so
Speaker 2: that when an email went out, they tried to dynamically
Speaker 2: figure out who made the change that actually caused the problem,
Speaker 2: so that they could actually put the right people in
Speaker 2: the email. Like this was. This is not a trivial thing,
Speaker 2: especially if there's like you know, multiple things going on.
Speaker 2: You have two thousand engineers committing to the same mono repo. Yeah,
Speaker 2: I don't work there anymore.
Speaker 3: Did you take two thousand, two thousand engineers?
Speaker 2: Yeah? Yeah?
Speaker 3: Is that like real or is that hyper because that's
Speaker 3: a lot of engineers too.
Speaker 2: That's a lot of engineers.
Speaker 5: Yeah.
Speaker 2: I mean there's like I mean monolists and mono repos
Speaker 2: like this is the this is the Google way right there.
Speaker 2: I think that's the two trains of companies here, the
Speaker 2: ones that go well oiled monolith on one side and I
Speaker 2: mean right before well the oil model that there's like
Speaker 2: distributed monolith, and then on the other side is micro
Speaker 2: services everywhere and individual repository. So the closer you get
Speaker 2: to the monolith side, the more you have just engineers
Speaker 2: thrown at the problem. I think Google last check was
Speaker 2: like over one hundred thousand or something like. It's it's
Speaker 2: a massive number that these companies try to make happen,
Speaker 2: So two thousand is not that big in my in
Speaker 2: my experience, you know.
Speaker 5: You mentioning SVN. I worked at a place that used
Speaker 5: this version control tool called Harvest.
Speaker 2: I don't know if you beat me, because I don't
Speaker 2: know that one. I like, I have a long list
Speaker 2: of ones that I've seen and Harvest is not on
Speaker 2: that list.
Speaker 5: And it was like such a piece of crap. And
Speaker 5: it was one of those ones to where you had
Speaker 5: to like check in check out the file. So like
Speaker 5: while that file was checked check doubt, you know, no one,
Speaker 5: no one could touch it. And I mean it was
Speaker 5: better than I've worked at places where we had a
Speaker 5: network drive with the source code, pray pray that someone
Speaker 5: didn't overwrite your work.
Speaker 2: So at least by default, even on Windows, there's a
Speaker 2: little bit of conflict resolution. But before I convinced my
Speaker 2: company to move to GET, at the time they were
Speaker 2: using before SPN, they were actually using uh Perforce by Microsoft,
Speaker 2: and that didn't have file conflict resolution. So if two
Speaker 2: people committed a file at the same time, it would
Speaker 2: literally crash the entire database and you were not restoring
Speaker 2: your source code.
Speaker 5: Now, has anyone ever used ClearCase.
Speaker 2: You go to tell us that you have an hotel
Speaker 2: uh for for every single source codel?
Speaker 5: Oh my god, wouldn't that be something? But ClearCase I
Speaker 5: think they were bought by IBM at some point and
Speaker 5: it was the most ridiculous source control system ever because
Speaker 5: you had to write like configurations for being able to
Speaker 5: do the source control. So it's like akin to like
Speaker 5: you know on mainframes where you have to write the
Speaker 5: JCL to like run your code. It was kind of
Speaker 5: like that. It was like so archaic and like it
Speaker 5: hurt my brain and I'm like, I don't want to
Speaker 5: touch version control ever again after this experience. And then
Speaker 5: we moved to GET and I'm like, thank god, someone
Speaker 5: understands me.
Speaker 1: So, whenever we're talking about putting observability in a CICD platform,
Speaker 1: are there specific are there specific plug ins or specific
Speaker 1: tools that help you instrument this, or are we talking
Speaker 1: about just like using Bash and netcat to fire off
Speaker 1: data to an endpoint?
Speaker 5: So you if you're if you're c i CD tool
Speaker 5: supports it, then I would definitely say use whatever plugins
Speaker 5: are available the official plug ins. Use that because I
Speaker 5: think that'll give you some good insights. But barring that,
Speaker 5: there is, for example, there is a plug in for
Speaker 5: Java around uh, like specific for for Java builds. I
Speaker 5: believe that gives you some additional c I c D
Speaker 5: insights or stuff like around Maven and gradle uh. And
Speaker 5: then there's this, uh I'm trying to remember now what
Speaker 5: the hotel bash thing is called. I'm going to just
Speaker 5: google this quickly dash.
Speaker 2: Uh.
Speaker 5: I can't find the one I'm looking for. Oh yeah,
Speaker 5: open telementary cli hotel cli.
Speaker 1: That's I could imagine that that one is probably pretty
Speaker 1: popular because I mean, let's just be honest, most of
Speaker 1: your CICD stuff is just a Bash command.
Speaker 2: No, no, don't say that.
Speaker 5: I mean, barring that, you can definitely you can definitely
Speaker 5: use that. It's it'll at least give you something.
Speaker 2: What do you have to instrument like within the pipeline.
Speaker 2: So I think we talked a little bit about the
Speaker 2: let's say, the steps or the jobs or the workflows
Speaker 2: that you have and the amount of time that they're
Speaker 2: spending in each one of them, or like where the
Speaker 2: failures end up being, especially for I mean c ID
Speaker 2: pipelines are notoriously flaky in some way, like maybe the
Speaker 2: package repository is down, or the machine runs out of
Speaker 2: memory or gets gets killed because gethub thinks that you're
Speaker 2: running a crypto minor on there, or any number of
Speaker 2: other things. But like you know, one one step above
Speaker 2: that though, Uh, there's a lot that goes on during
Speaker 2: the CICD pipelines. And I can imagine there's tools like
Speaker 2: you have you mentioned a bunch like you know, say antsable,
Speaker 2: but obviously there's I A C stuff. Maybe you know
Speaker 2: you're building artifacts and whatnot. How hard is it to
Speaker 2: get into all those tools and get all that telementary
Speaker 2: data to actually you know, export it out somewhere, even
Speaker 2: if the platform supports them.
Speaker 5: So one of the things that we explored was there's
Speaker 5: this component of so for I don't know how familiar
Speaker 5: you are with with open telemetry.
Speaker 2: You're going to get a range of in the audience here,
Speaker 2: like there are some that are going to be experienced
Speaker 2: and on the other side may have no idea what
Speaker 2: you mean when you even say hotel all right.
Speaker 5: So, so basically open telemetry there's like a couple of parts.
Speaker 5: There's like the A P I and s d K,
Speaker 5: so use that to instrument use that to instrument your code.
Speaker 5: So you go into your Java and Python code or whatnot,
Speaker 5: and there's like a bunch of hotel languages that are supported,
Speaker 5: and you go in and you write the instrumentation. So
Speaker 5: that means like you're manually typing in like this is
Speaker 5: where I want to insert my traces, my logs, my metrics.
Speaker 5: There's also automatic instrumentation and where basically there's like essentially
Speaker 5: like a wrapper around your code that as long as
Speaker 5: you're using like certain like popular libraries like Python flasks
Speaker 5: for example, it'll it'll automatically generate some telemetry like some
Speaker 5: traces for for for your code there for any code
Speaker 5: like using using that library. But then there's another component
Speaker 5: in open telemetry, which is the Hotel collector. So that's
Speaker 5: a vendor neutral agent basically, and you can think of
Speaker 5: it as like an ETL tool, So it'll extract the
Speaker 5: telemetry from multiple sources. So the sources can be like
Speaker 5: your applicationmetry can be your infrastructure telemetry from various various
Speaker 5: things at the same time. And then there's processors which
Speaker 5: basically can you know, massage your data. You can add attributes,
Speaker 5: remove attributes. You can do some some transformations. So for example,
Speaker 5: you know you're using like underscores and you're naming conventions
Speaker 5: for your attributes, but you're you want to switch to
Speaker 5: like dot notation, use that, and you do. You do
Speaker 5: that in the collector and then it gets sent somewhere
Speaker 5: and you can send it to multiple somewheres at the
Speaker 5: same time with the collector. So basically this enables you
Speaker 5: to for example, if you don't have like an all
Speaker 5: in one tool that can ingest all all of your
Speaker 5: telemetry that you're collecting, then you can send it like
Speaker 5: to one tool for traces, one for logs, one for metrics.
Speaker 5: I don't recommend that ideally, you want everything sitting in
Speaker 5: the same in the same back end, because then you
Speaker 5: know you have like your single source of truth and
Speaker 5: all the related data. But if that's your if that's
Speaker 5: your setup, the open Plumetry Collector allows you to do that.
Speaker 5: Now I'm trying to think of where I was going
Speaker 5: with that when we were talking about the collector.
Speaker 2: You know, you can think about this for a moment.
Speaker 2: You know, just to sell hotel, you have three components here.
Speaker 2: You have your code that's emitting traces or data or
Speaker 2: logged and you have someplace where you want to see them,
Speaker 2: you know, maybe it's your grafhaunas, your elastic searches of
Speaker 2: the world, and you could have a custom protocol and
Speaker 2: for a long time you had a custom protocol, custom
Speaker 2: libraries on the software development side to get that log
Speaker 2: information from the source to the saying to the target
Speaker 2: where you wanted to go. And that means that every
Speaker 2: single time you want to change which provider you were utilizing,
Speaker 2: or which language or which team you're working on, you
Speaker 2: needed to find a new library for then the new
Speaker 2: thing that you were utilizing. Wouldn't it be great if
Speaker 2: it was some sort of standard that made this all easy.
Speaker 3: You know.
Speaker 2: That's hotel for me.
Speaker 5: Yeah, essentially, essentially.
Speaker 2: Yeah, well, you know, I can see one problem here
Speaker 2: is making sure that every single thing that you were
Speaker 2: utilizing could be supported. For instance, you mentioned Python flask.
Speaker 2: You know, it's great that there's a library out there
Speaker 2: that you can throw into Python flask or if it's
Speaker 2: supported by flask by default, and it just it just
Speaker 2: works because the output of those logs matches the standard.
Speaker 2: But I can imagine there's lots of tools that you
Speaker 2: could be using you brought up you know, bashed cli
Speaker 2: as one of them, which you know don't have these
Speaker 2: things by default. My example would be, you know, let's
Speaker 2: assume everyone's using open tofood today. What is what does
Speaker 2: that look like? You know it? Like? Does do these
Speaker 2: tools I see offer configuration to make it easy to
Speaker 2: do that or is it a matter of like having
Speaker 2: to parse uh you know output you know, raw text
Speaker 2: out and get it converted.
Speaker 5: Yes, now I remember I was going with that. Yeah, So, like,
Speaker 5: for example, one one thing that a lot of these
Speaker 5: tools have in common is that they met logs right,
Speaker 5: and so you can so the hotel collector has this
Speaker 5: component called the foul Logs receiver where it can basically
Speaker 5: just logs and it'll parse out your logs given like
Speaker 5: some rejects expressions, so that you can do something useful
Speaker 5: with the data and send that to you to your
Speaker 5: hotel backend. So that's where you, you know, things that
Speaker 5: aren't necessarily like have hotel baked in, you can kind
Speaker 5: of turn it otel esque and get it to send
Speaker 5: you send the hotel data that you need to hopefully
Speaker 5: troubleshoot a little bit better.
Speaker 2: So well, well, was about to make this joke, but
Speaker 2: I'm going to steal it from him because you I
Speaker 2: think fundamentally, it's like, oh, I have a problem. The
Speaker 2: solution I know it's to use rejects. And when you
Speaker 2: think that the solution is red jocks, and now you
Speaker 2: have two problems.
Speaker 5: I know, I always have to look up rejects anything.
Speaker 2: I mean, I think this is where log for JA
Speaker 2: the exploit ended up coming from, is having to parse
Speaker 2: literally log messages that we're coming from everywhere, and you
Speaker 2: could get it too, execute arbitrary code because of it,
Speaker 2: and you know there's a number of huge gotcha's there
Speaker 2: that if you'd not really experienced, especially parsing logs, that
Speaker 2: you'll end up in situations with your reject will like
Speaker 2: literally crash due to catastrophic backtracking.
Speaker 1: So that's that's something I hadn't thought of, like when
Speaker 1: we first started talking about this, Like I was thinking
Speaker 1: about like during the CICD process, you know, there's the
Speaker 1: build time, but then there's also like time associated with
Speaker 1: you know, with Terraform going off and doing terraform things,
Speaker 1: which is can be really significant at times because sometimes
Speaker 1: you know, Terraform decides to just completely delete and rebuild
Speaker 1: this thing from scratch. You're like, dude, I just I
Speaker 1: just wanted you to change this parameter, and so this
Speaker 1: could be a really good way of exposing that.
Speaker 5: Yeah, yeah, exactly. It's it's all of a sudden, like
Speaker 5: you're able to see the things that you weren't seeing
Speaker 5: before necessarily, right, So it's not just the troubleshooting troubleshooting
Speaker 5: when things go bad, but also like can I use
Speaker 5: this information now to further optimize? And even the other
Speaker 5: part too, which is like you think it's going okay
Speaker 5: and you find out otherwise, right, like behind the scenes,
Speaker 5: something very bad is happening that wouldn't have necessarily been
Speaker 5: exposed because there's like no catastrophic failure of your pipeline
Speaker 5: as far as you're concerned. It's completing and things are
Speaker 5: you know, getting delivered, built and whatever.
Speaker 1: That's one of my favorite phrases to hear is oh,
Speaker 1: that error message is okay.
Speaker 2: No.
Speaker 1: No, just the fact that you called it an error
Speaker 1: message makes it not okay. Can we agree on that?
Speaker 5: Yeah, exactly.
Speaker 4: So.
Speaker 2: I think because we're in the engineering discipline, you know,
Speaker 2: we have to be cognizant of this. And if we
Speaker 2: have new data available, new metrics that we're able to track.
Speaker 2: It's going to create a signal that caused us to
Speaker 2: make a change. And so one of the questions I
Speaker 2: want to ask you is do you feel like that
Speaker 2: Hotel has caused this shift in the mindset or focused
Speaker 2: areas that we've been dealing with in the last let's say,
Speaker 2: before up and to this point. So I'm not sure
Speaker 2: exactly how old it is. I want to say it's
Speaker 2: like five years now, although that maybe that it's a
Speaker 2: little bit short, not right.
Speaker 5: It started in twenty nineteen.
Speaker 2: Okay, great, So before that, you know, we didn't have it.
Speaker 2: It's like, has there been some fundamental shift with how
Speaker 2: we're tackling problems in the observability space? And you said
Speaker 2: shift left? So really development teams, engineering teams in general,
Speaker 2: compared to what we were doing beforehand.
Speaker 5: I mean, I think with Hotel, because so pre Hotel,
Speaker 5: like it was kind of a free for all, and
Speaker 5: there had been attempts at standardization, right because there was
Speaker 5: open census on the one side from Google and then
Speaker 5: open tracing from CNCF, and then like each vendor also
Speaker 5: had their own thing. And so I think there's a
Speaker 5: lot of time and effort expended into you know, maintaining
Speaker 5: these like instrumentation libraries. And now with Hotel, I think
Speaker 5: the conversation has shifted because we're like, Okay, this is
Speaker 5: the single standard. We all agree that it's going to
Speaker 5: work this way, and now we're not using like you know,
Speaker 5: now it's not a single organization or individual organizations using
Speaker 5: their brain power like I'm gonna say in air, it's
Speaker 5: wasting their time on instrumentation libraries, because we're all like
Speaker 5: as competitors working together towards a common goal. So now
Speaker 5: we're we're you know, combining brains towards a singular purpose,
Speaker 5: which means then we're we've essentially democratized data in the
Speaker 5: sense that now all of these observability tools are ingesting
Speaker 5: the same data. And so the differentiator is what do
Speaker 5: they do with your data in a way that is
Speaker 5: helpful to you?
Speaker 1: Right?
Speaker 5: And the answer to that question varies, right because what's
Speaker 5: meaningful to me might not be the same, it might
Speaker 5: not be as important to you. And I think the
Speaker 5: other thing that Hotel provides that open sends us and
Speaker 5: open Tracing didn't provide at the time was this unified
Speaker 5: view of TRACE's logs and metrics where now we have
Speaker 5: this ability. First of all, we have a standard for
Speaker 5: these three signals, but also we have correlation of the
Speaker 5: three signals. And I think the correlation is really important
Speaker 5: because I I for me, at the backbone of observability
Speaker 5: is the distributed trace, because it tells the story right
Speaker 5: end to end. And then you've got the supporting actors.
Speaker 5: We've got the metrics that give us an idea of
Speaker 5: thing like our CPU usage and are our RAM usage
Speaker 5: or how long we've spent on a particular process, or
Speaker 5: even having an idea of like hey, I sold like
Speaker 5: fifty telescopes last month compared to this month. And then
Speaker 5: our logs that are like our point in time indicators, right,
Speaker 5: and all these things separate are like yeah, that's that's cool,
Speaker 5: that's useful, but together like they paint that full picture. Right,
Speaker 5: we have this very rich understanding of what's happening with
Speaker 5: our systems. And I think that's that's the thing that
Speaker 5: observability brings us. And I'm going to borrow a definition
Speaker 5: of observability that I really like from Hazel Weekly, which
Speaker 5: is observability allows us to ask meaningful questions, get useful
Speaker 5: answers and act effectively on the information that we get.
Speaker 5: And I think we are we are getting to that point.
Speaker 5: I'm not. I don't think we're fully there in the
Speaker 5: same way that like you know, so many organizations back
Speaker 5: in the day and maybe even to a certain extent now,
Speaker 5: or like we're doing DevOps because we have a CICD pipeline.
Speaker 5: It's like we have observability because we are collecting metrics
Speaker 5: and sending them to Blah back in. It's like you're
Speaker 5: you're on your way.
Speaker 3: There.
Speaker 4: Yet I think the real thing there now is can
Speaker 4: we have an AI agent that will look through your
Speaker 4: logs and tell you what the problem is, because that's
Speaker 4: what I think I need.
Speaker 5: Yeah, And I think a lot of vendors and that
Speaker 5: is a fair ask, and I think a lot of
Speaker 5: vendors are moving in that direction. I mean, including Dino Trace.
Speaker 5: Dina Trace has an AI assistant named Davis AI.
Speaker 2: And well, I guess that's the success of hotel is
Speaker 2: because now you can shop around for the provider that
Speaker 2: offers you that exact benefit without feeling like you you
Speaker 2: lose your data or have to spend engineering time to
Speaker 2: actually adhere to whatever backwards protocol that that provider is offering.
Speaker 3: Yeah, but like biologists don't like paying for stuff.
Speaker 2: I know, I know what it what it means. Like
Speaker 2: when you say they don't like paying for stuff, what
Speaker 2: they mean is they don't like paying for stuff when
Speaker 2: that money has like clear price tags on it. But
Speaker 2: when there's suspect value associated with running it yourself on
Speaker 2: on prem hardware, then they have no problem shelling out
Speaker 2: you know, hundreds of thousands of dollars for it.
Speaker 3: Well, that's true.
Speaker 4: I mean we can still have on site HPCs like
Speaker 4: that's that's fine, That's totally fine.
Speaker 2: Right, just throw Grafana in your in your cluster and
Speaker 2: you know, you can use your hotel collector and point
Speaker 2: it at that and you get all your data into
Speaker 2: whatever you're saying. You know that Graffana is pointed at
Speaker 2: and you're going to go.
Speaker 4: I mean sometimes, but not all the platforms that I
Speaker 4: use have like all these nifty tools you know built
Speaker 4: into them, like like the AWS, like Healthcare Pipeline platform
Speaker 4: does not have this stuff built in.
Speaker 3: It just sends everything a cloud watch and then it's like, well,
Speaker 3: good luck with that.
Speaker 1: I think you, I think you started that problem. Definition
Speaker 1: with the problem a ws.
Speaker 4: WS is listen, I'm still I'm still on my like
Speaker 4: drifting like a WS pay my bills please, So we
Speaker 4: can't we can't bad talk them because every once in
Speaker 4: a while they do throw some credits my way.
Speaker 3: So I love you as.
Speaker 2: And if you stick around at the end of the episode,
Speaker 2: I actually have something to say about a WS credits.
Speaker 3: So you have a coupon to send me. I love coupons.
Speaker 2: Well, Jillian, unfortunately you're going to be excluded from this.
Speaker 2: I wonder why a host of this podcast is going
Speaker 2: to be excluded from a giveaway we're having.
Speaker 3: Oh okay, that's.
Speaker 5: Damn it.
Speaker 1: Fine. So one of the things I want to dig into,
Speaker 1: like I see the benefits of US, where I struggle
Speaker 1: with implementation. No, you know, like the developers I support,
Speaker 1: they see the benefits of this, but only after I
Speaker 1: build the whole thing for them and show it to them.
Speaker 1: So what are some ideas you have to like get
Speaker 1: them excited to kind of like throw a few hours
Speaker 1: of their own time towards getting this implemented.
Speaker 5: I think I think one way to be effective with
Speaker 5: this is making developers responsible for their code and prod
Speaker 5: like right after, right after it's deployed.
Speaker 2: Align the ascentives.
Speaker 1: Nothing tells a story like staring at a screen at
Speaker 1: two am, knowing other reason you're there.
Speaker 5: Yeah, exactly exactly. I think another thing on exactly right
Speaker 5: other thing I was going to say, you know, back
Speaker 5: to what I was saying in the beginning about qa's
Speaker 5: using that telemetry also during the testing phase to be
Speaker 5: able to identify bugs in testing making basically making telemetry
Speaker 5: quality gait. So before going into QA, you it's a
Speaker 5: it's basically mandatory to have instrumented your code. Otherwise you don't,
Speaker 5: you don't pass go. Basically that's another that's another way
Speaker 5: to incentivize and and I think one way to think
Speaker 5: about it, and I think this is where people have
Speaker 5: have a bit of a hard time like wrapping their
Speaker 5: brains around it.
Speaker 3: Uh.
Speaker 5: I see instrumenting code as no different than like, you know,
Speaker 5: we're writing print statements all the time, we write log statements.
Speaker 5: So like you're already writing logs, So do it the
Speaker 5: open telemetry way. You're already like that's part of your mindset.
Speaker 5: So adding traces here and there isn't a terrible idea,
Speaker 5: especially if it can help you as well as a
Speaker 5: developer debug your own code, and I think that's another
Speaker 5: value add It's like, oh my god, I have more
Speaker 5: insight when I'm writing my code to understand why this
Speaker 5: like weird era keeps happening like every fifty runs of
Speaker 5: the program, Like wouldn't that be nice?
Speaker 2: I think you could put your perspective though, on the
Speaker 2: controversial side, right, Like, I mean, maybe there are the
Speaker 2: engineers out there that they don't write any bugs, there's
Speaker 2: no production, never goes down, there's no incidence whatever, and
Speaker 2: then and then you know, this isn't a value added activity.
Speaker 2: So you know, if they're out there and they're thinking
Speaker 2: to themselves, all my code is absolutely perfect and I'm
Speaker 2: not accountable for it. I don't know if there can
Speaker 2: be another argument.
Speaker 5: I know, well, what can you do to question perfection
Speaker 5: like that?
Speaker 2: You did say something interesting though, which is basically what
Speaker 2: you're advocating for here, which is shift left on telemetry.
Speaker 2: And one of the complaints that I've heard from uh
Speaker 2: my collities across the industry have been, well, there's like
Speaker 2: shift left testing and shift left telemetry and shift left security,
Speaker 2: and now we're doing infrastructure as code instead of release
Speaker 2: engineering I mean at some point, like if everything is
Speaker 2: shift left, there's there's nothing left, Like everything is now
Speaker 2: on the right, right.
Speaker 5: Right. I mean, yeah, you're right, but like I guess
Speaker 5: the way I'll look at it is, but if you're like,
Speaker 5: if you don't shift left, then it's going to be
Speaker 5: so much more painful after.
Speaker 2: Oh, for sure, there's no question.
Speaker 5: And I don't I don't know. Maybe maybe it's me,
Speaker 5: like my personality. I like learning new tech. So it's
Speaker 5: like you got to learn you know, terror form, Yay,
Speaker 5: that's awesome, you get to learn doctor, yay.
Speaker 2: Cool.
Speaker 5: I think I think honestly, for this to succeed, you
Speaker 5: almost you have to come in with the right mindset,
Speaker 5: and and there's no better way to do that than
Speaker 5: with like fresh hung blood, right. The new folks coming
Speaker 5: into the industry like that, that is the way. You
Speaker 5: know that, that is the way that it works. But
Speaker 5: for the older folks you're like, oh, I'm telling I
Speaker 5: mean they I'll have to do all this extra crap.
Speaker 5: Oh damn it.
Speaker 2: I like how you stopped after a terraform and doctor
Speaker 2: and you didn't say, oh, we have to use Kubernetes.
Speaker 5: Yeah, like Kubernettes and I have a love hate relationship.
Speaker 1: That was a given, like who doesn't love Kubernetes.
Speaker 2: So I mean that's an interesting perspective that those that
Speaker 2: are more experienced are likely I don't I want to
Speaker 2: say that they're you know, thinking the wrong direction or
Speaker 2: have the not the right mindset, but they're focused in
Speaker 2: the areas where they think it has the most value.
Speaker 2: Like maybe the experience helps tell them what they need
Speaker 2: to do more effectively. And if you are looking at
Speaker 2: something and say, oh, well, I don't know how to
Speaker 2: test this effectively, and I don't know how to make
Speaker 2: this is super secure, and I don't know where my
Speaker 2: bugs are going to be, then you do want to
Speaker 2: take all of these steps, at least a little bit
Speaker 2: in each one of these directions. And that isn't to
Speaker 2: say you need to design the perfect platform, but having
Speaker 2: the logs end up on an ephoremal like on hard
Speaker 2: disk of an ephemeral compute environment, like isn't going to
Speaker 2: help you when there's a problem in that thing crashes.
Speaker 5: Yeah, very true, Very true. Yeah. I you know, I
Speaker 5: think with this kind of shift left it like for
Speaker 5: those of us who've been in the industry long enough,
Speaker 5: I think embracing that is born out of one of
Speaker 5: two things, extreme trauma for your like oh my god,
Speaker 5: I can't take this anymore, and and the other is
Speaker 5: just like pure curiosity like ooh this looks really cool,
Speaker 5: and like having an open mind. And I honestly, I
Speaker 5: think the most successful techies are the ones who are
Speaker 5: open to change, open to like what what the new
Speaker 5: tooling brings. And maybe maybe it's like, oh, this thing
Speaker 5: doesn't do exactly what I wanted to do. And then
Speaker 5: this was like where startups are born, right. I mean,
Speaker 5: Krubernetes has got a whole ecosystem around it because of
Speaker 5: I guess it does stuff, but like some stuff is
Speaker 5: kind of gnarly to do, so let's make things easier.
Speaker 5: And I think that sort of thing drives innovation. At
Speaker 5: the end of the day, are you are.
Speaker 2: You happy where we're at, Like do you feel like
Speaker 2: that there's like just one more thing, like get the
Speaker 2: observability done in CICD pipelines and then everything will be great?
Speaker 2: Or do you see like there's a concrete objective next
Speaker 2: step to get to the you know, the pinnacle of
Speaker 2: perfection and observability.
Speaker 5: Ooh, that's a great question. Actually it's a topic for
Speaker 5: a talk that I'm giving next week. Out of observability,
Speaker 5: Dan like, leg it, what is it? All right, I'm
Speaker 5: gonna plug it. So basically, the ideas, why does observability
Speaker 5: have to exist within the traditional confines of tech? Why
Speaker 5: don't we bring observability and open telemetry to things like
Speaker 5: the recruitment process, Like you know, it's it's a yucky
Speaker 5: jobs market out there, and the recruiting process has always
Speaker 5: been painful. You never know, you know, you send out
Speaker 5: a resume, you don't know if you're going to get
Speaker 5: a response, and when you do it might be a while.
Speaker 5: And then when you finally get that interview, it's it
Speaker 5: might be like a chunk of time between interviews. Wouldn't
Speaker 5: it be nice if organizations put observability in their recruitment process,
Speaker 5: for example, so that they have an understanding of like
Speaker 5: how long it takes in each stage of the interview process.
Speaker 5: Wouldn't it be cool to have a distributed trace that
Speaker 5: represents the end to end recruitment process. And we can
Speaker 5: take this to like several under several other industries, like
Speaker 5: even the healthcare industry. Look at hospital r waiting times.
Speaker 5: Understanding you know what if what if you do open telemetry,
Speaker 5: apply open telemetry and observe ability to uh to ers
Speaker 5: where you're like, okay, now you have an idea of,
Speaker 5: like what the workflow is from from intake all the
Speaker 5: way to getting treatment. You have an idea of like
Speaker 5: the types of cases that get seen faster versus the
Speaker 5: ones that don't. You can have a better understanding. You
Speaker 5: have better data on racial profiling. For example, wait times
Speaker 5: the amount of time you know first to get seen,
Speaker 5: to get like imaging done, to get the results of
Speaker 5: the imaging. So I feel like the sky is the limit,
Speaker 5: and I think it's I would say easier. I'm going
Speaker 5: to say in air quotes and in larger organizations that
Speaker 5: have access to to be like monetary access to to
Speaker 5: be able to like you know, purchase a subscription from
Speaker 5: a SaaS vendor or or like run a homegrown solution
Speaker 5: for observability. But I think I think it can open
Speaker 5: up some really cool possibilities around that.
Speaker 2: See, I had a secret fear You're going to say,
Speaker 2: government oversight.
Speaker 1: Why would that be relevant at all?
Speaker 2: Yeah? So I know, but I think you touched on something. Yeah,
Speaker 2: well okay, yeah, so we won't we won't go there,
Speaker 2: uh I do. I do want to touch on something.
Speaker 2: I think you you added a nuance too, which is
Speaker 2: that the value that could be captured here is actually
Speaker 2: directly related to the business and not arbitrary tech metrics
Speaker 2: about your running service like how many two hundreds and
Speaker 2: three hundred do you have or how long it's running,
Speaker 2: but maybe the value to the actual customer and or
Speaker 2: the pain they're suffering through the you know, user experience
Speaker 2: of your UI because you you automatically coded it using
Speaker 2: one of these new vibe coding auto creation UIs, and
Speaker 2: so you know, yeah, I think it's a really good point,
Speaker 2: and like this could be applied to to every industry,
Speaker 2: not just ones that are hard in tech. You know,
Speaker 2: how are you collecting metrics today? How are you actually
Speaker 2: evaluating these things? Don't you want data? And now I'm
Speaker 2: starting to wonder all of those smaller companies that are
Speaker 2: between zero and let's say two or five employees, you know,
Speaker 2: what are they doing. I know that like maybe the
Speaker 2: last thirty years was all about digital transformation, and I
Speaker 2: still know companies are hiring digital transformation consultants to make
Speaker 2: this happen. And I think you've hit on like, really
Speaker 2: the why which is you're missing the data? You're like,
Speaker 2: you're not collecting it, and this, this process, this standard
Speaker 2: is what's going to help you achieve that.
Speaker 5: Yeah? Yeah, and I mean unfortunately, like we speak in
Speaker 5: data right, like show me, show me the metrics, and
Speaker 5: then tie the metrics to the money, right.
Speaker 1: Well, Jerry Maguire reference there, show me the money.
Speaker 5: Yeah, yeah, I do.
Speaker 2: I do want to share this because I I do
Speaker 2: think this list is quite ridiculous. So you're a CNCF ambassador,
Speaker 2: you have a podcast, you're an author, I wrote a
Speaker 2: bunch of other things down here. But I see, like,
Speaker 2: you know what conference speaker, right, what is there still
Speaker 2: some milestone you're hoping to achieve next after this that
Speaker 2: you're you know, currently focused on. You're like, no, I've
Speaker 2: done enough things, you know, I feel accomplished enough.
Speaker 5: Oh well, I would love to, like someday, keynote at
Speaker 5: a cupe gun. I got my first keynote last year
Speaker 5: at KCD in Potho, Portugal, and that was like, that
Speaker 5: was super exciting. I've never been asked a keynote. I
Speaker 5: think I think the ultimate experience would be a keynote
Speaker 5: on a at a really large conference that would be
Speaker 5: super fun. I did also find out this one's up
Speaker 5: there on the list. I found out last week that
Speaker 5: I'll be going to keep Con Japan, which is super
Speaker 5: exciting because it's the first ever keep conjup and I've
Speaker 5: never been to Japan. And I'll be giving a talk
Speaker 5: on basically what we can do to make our observability greener.
Speaker 5: And it's, uh, it's it's a follow on, if you
Speaker 5: will to a talk that I'm giving next week in
Speaker 5: London with my same co speaker, Nancy Chohan, where we
Speaker 5: it's the talk is next week is called how Green
Speaker 5: is my Open Telemetry Collector? And it talks about like
Speaker 5: what you can do to start looking at at optimizing
Speaker 5: your hotel collector to make it, you know, more more
Speaker 5: environmentally friendly.
Speaker 2: Do do you feel lucky now that there is another
Speaker 2: piece of technology out there that is just so much
Speaker 2: worse for the environment that no one's paying attention to
Speaker 2: any sort of problem with story extra data I mean
Speaker 2: storing the data. I mean now that that's a trivial
Speaker 2: matter as far as impact goes.
Speaker 5: It's funny that, like, you know, I almost feel I
Speaker 5: feel guilty, like working in this industry to be honest,
Speaker 5: because like I've always, like since I was a kid,
Speaker 5: I was like really into like environmental stuff, and you know,
Speaker 5: like I bring a reusable cup to like Starbucks, or
Speaker 5: like I love bubble Tea, so my local bubble tea place,
Speaker 5: I'll bring a reusable cup. And you know, I've done
Speaker 5: the reasonable shopping bags for like twenty years, and yet
Speaker 5: I'm in an industry that is inherently terrible for the environment.
Speaker 5: You know, data centers I think contribute to like one
Speaker 5: or one to two percent of of like the world's
Speaker 5: greenhouse gas emissions. And then you add AI into the mix,
Speaker 5: and it's like ouch observability, I mean the fact that
Speaker 5: we're trying to understand our systems better through observability. Well,
Speaker 5: guess what, You're emitting a crap ton of data, So
Speaker 5: your systems are are expending more energy in doing so,
Speaker 5: and then your your observability tooling and ingesting the data
Speaker 5: are also emitting a crop ton of energy to do that.
Speaker 5: So it's like we're you know, we're adding to the problem.
Speaker 5: But then I also feel like technology can solve the problem,
Speaker 5: Like you know, those same AI agents that that do
Speaker 5: expend a lot of energy can also helpless further optimize
Speaker 5: our you know, our energy usage to lessen our carbon footprint.
Speaker 5: I think it's all that will be a balance.
Speaker 2: Well, there's the paradox there, and I don't remember the
Speaker 2: philosopher's name. Hopefully someone else does. If you increase the
Speaker 2: efficiency or you optimize it, you end up with more
Speaker 2: usage because it becomes cheaper and more so in the end.
Speaker 2: So that's not Unfortunately, that's not a path forward that
Speaker 2: I'm willing to I'm willing to bet on. But like
Speaker 2: I'm still bringing reusable like paper bags to the grocery
Speaker 2: store for my bread and vegetables, like I am, I
Speaker 2: am just as bad, uh know, put it in a
Speaker 2: backpack and no plastic bags or anything. And I've still
Speaker 2: got the same paper bag that my wife is like,
Speaker 2: why are you still reusing that? Carry stuff in?
Speaker 1: I always forget mine. So I ended up making it
Speaker 1: a trip out of the store with thirty seven things
Speaker 1: in my arms.
Speaker 2: Oh yeah, backpack.
Speaker 5: I used to buy the bag.
Speaker 3: It's ridiculous. At this point, I have like a closet
Speaker 3: full of them.
Speaker 2: I'm like, yeah, just with you should donate them to
Speaker 2: some other people, like just or sell them right outside
Speaker 2: the store. Like just see like when Will comes out
Speaker 2: of the store and he's carrying a.
Speaker 5: Lot of things, be like, hey, ooh, clever.
Speaker 2: I don't know if that's legal not for resale?
Speaker 5: Yeah, probably not, damn it.
Speaker 2: I think you just have.
Speaker 1: To be fifty feet away from the door, and by
Speaker 1: that time I'm a very motivated customer of your product. Anyway,
Speaker 1: if you haven't, if you haven't gotten to your motive
Speaker 1: transportation after fifty feet, I mean, I I.
Speaker 2: Worry what's going on there? I will ask maybe you
Speaker 2: can spoil it a little bit for us? What as
Speaker 2: you mentioned data centers as not being that environmentally friendly?
Speaker 2: Is it? Is it the data storage? Is it? The compute?
Speaker 2: Is it you know, memory usage?
Speaker 1: Is it?
Speaker 2: The menu? The hardware manufacturing that's doing it? So the
Speaker 2: building new data center, like do you know like which
Speaker 2: area is contributing or is the most problematic for us?
Speaker 5: I don't know specifically, but I would gather like the
Speaker 5: power consumption alone of data centers is huge and puts
Speaker 5: like a massive strain on on power grids. So there's
Speaker 5: definitely I would say, I would guess. Now, don't don't
Speaker 5: quote me on that, but I would guess that that's
Speaker 5: that would definitely eat into things a.
Speaker 1: Fair bit from some of the stuff I've heard. It's
Speaker 1: the cooling mhm.
Speaker 2: I could I could believe that. Yeah, dealing with extra
Speaker 2: heat is a huge challenge. But if it's the energy,
Speaker 2: then what we have to make sure realistically, is it
Speaker 2: the energy we're creating is green?
Speaker 1: Just build more nuclear power plants always the solution it is.
Speaker 1: I can tell Warren Lust to disagree.
Speaker 2: Oh no, no, no, no, I no, no, I absolutely
Speaker 2: agree there is no better form of energy, even though
Speaker 2: there's all these problems with I say nuclear, but you
Speaker 2: know we're saying fission right because we're not at the
Speaker 2: fusion stage yet. And there's just a lot of arguments
Speaker 2: where like what do you do with the wastewater? I'm like,
Speaker 2: compare that to the mining of the raw materials and
Speaker 2: the manufacturing of solar panels, or the actual damage to
Speaker 2: like my migratory birds for flight pass for wind turbines,
Speaker 2: and not to mention the non renewable ones, like you know,
Speaker 2: it's just so absurd to me. Sorry, that's that's my
Speaker 2: own personal rant. Just cancel, just cancel all non commercial aircraft.
Speaker 2: There should be no private jets. You know that will
Speaker 2: solve a majority of the world's problems from there.
Speaker 1: True, I can't disagree. It's not going to impact my life.
Speaker 1: I'll tell you that for sure.
Speaker 5: Damn it, I'm gonna cancel my Gulf Stream.
Speaker 4: Order right.
Speaker 1: Hold on b RB.
Speaker 5: Yeah.
Speaker 1: But now that's like a few minutes ago, you brought
Speaker 1: up a really interesting point about using hotel metrics in
Speaker 1: other parts of the business, and like immediately my mind
Speaker 1: exploded with like ten different things in the company I
Speaker 1: work for right now, I'm like, holy shit, Like they
Speaker 1: they totally need to see this on a on a
Speaker 1: metrics dashboard. And it's like, you know, you mentioned recruiting process,
Speaker 1: but I'm thinking like the sales pipeline or the implementation
Speaker 1: pipeline whenever we implement someone onto our product, the employee
Speaker 1: review process, what stage that's at, Like there's just so
Speaker 1: many different things where like oh wow, even Jira, like
Speaker 1: where are things stalling at moving tickets from from new
Speaker 1: to done?
Speaker 5: Yeah, yeah exactly, or like onboarding new employees. It's such
Speaker 5: like such a pain no matter where you go, there
Speaker 5: is not a streamlined onboarding process right.
Speaker 1: Time to first commit. That's a big metric for me,
Speaker 1: when I bring somebody on, like how long before their
Speaker 1: first commit goes to production? How are you measuring that
Speaker 1: manually at this point?
Speaker 2: Is it? Because there's just not a scale that you
Speaker 2: would need to make it like you're not hiring that
Speaker 2: many people like your turn rates you know low, and
Speaker 2: so you know, I guess that maybe the counter argument,
Speaker 2: why collect the data when the manual process is still sufficient?
Speaker 1: Yeah? For that for that specific example, time to first commit,
Speaker 1: you know, it would be hard to justify automating it
Speaker 1: unless you already had everything in place and it was
Speaker 1: just building the dashboard that shows it. So that one
Speaker 1: hopefully it's a little value. Like if you're putting on
Speaker 1: that many new employees where you have to build a
Speaker 1: dashboard for that, maybe you should be looking at metrics
Speaker 1: of like what am I doing to piss my employees
Speaker 1: off and make them leave? Maybe that's a better metric
Speaker 1: for that scenario.
Speaker 2: I mean, I think you're onto something there, because if
Speaker 2: you're if you're pushing the data towards to them and
Speaker 2: they have to now consume technical dashboards. I think what
Speaker 2: we're saying is we're hoping that by doing this, we're
Speaker 2: changing the role from directly hands on to someone that's
Speaker 2: more understanding of what like of a knowledge management process
Speaker 2: is in that area. So you know you're talking about HR,
Speaker 2: but not so it's not HR anymore. It's a new
Speaker 2: kind of human resources where it's already being managed. Now
Speaker 2: it's about improving the process and that's a whole other
Speaker 2: step above it.
Speaker 1: Yeah, we don't have hright now, we have people business partners.
Speaker 2: M Well yeah, you laugh. But I do think that
Speaker 2: there is something like all labels are wrong, some of
Speaker 2: them are useful. And I think if you call it people,
Speaker 2: they are more two things happen. They do think about
Speaker 2: their leaders, like how to build leaders and whatnot, and
Speaker 2: then more importantly about the careers of these people rather
Speaker 2: than as you know, fundamental resources like your turn rate
Speaker 2: is important and whatnot. And I think that's that's something
Speaker 2: that's only happened recently.
Speaker 4: See, I don't know about calling HR people. I mean,
Speaker 4: clearly they're people, right, but like they're not.
Speaker 3: They're not robots yet, Like they're not there for the employees.
Speaker 3: They're there to protect like the company.
Speaker 4: So this idea that they're sure for you in your
Speaker 4: career is maybe.
Speaker 3: We don't Maybe I'm going to disagree with that.
Speaker 2: Well, that's the point. So if this organization is there
Speaker 2: to protect the company, then why of course the company
Speaker 2: would want to be making decisions based off of a
Speaker 2: metrics and a framework that is collecting actual data about
Speaker 2: the organization before making those decisions. And there was something
Speaker 2: there was a research study done like ten or twenty
Speaker 2: years ago that was a consult came in and had asked,
Speaker 2: like all the executives of an organization to make a
Speaker 2: guess about how successful their sales will be over the
Speaker 2: next couple of quarters. And they were all like, of course,
Speaker 2: super confident about whatever it is that they were doing,
Speaker 2: and just absolutely wrong in a lot of ways. And
Speaker 2: I think you see the same thing over and over
Speaker 2: again across the field. So like a majority of people
Speaker 2: think they're better than average, which is statistically not possible.
Speaker 2: And I think this is where, you know, having the
Speaker 2: additional data just goes to show you that you're making
Speaker 2: more accurate decisions no matter what they are. True story,
Speaker 2: Will just can't wait to get back to to or
Speaker 2: get to work so he can start implementing these in
Speaker 2: his least favorite department.
Speaker 1: I am Hotel.
Speaker 5: Everything that's right Hotel everything.
Speaker 1: So, speaking of which, how did you end up as
Speaker 1: part of the Hotel sid group?
Speaker 5: Oh? Well, so, first of all, I got into Hotel
Speaker 5: because of my previous job at Lightstep, which was my
Speaker 5: first job as a developer advocate. So before that, I'd
Speaker 5: been doing a mix of like individual contributor work and
Speaker 5: management work. I decided at that point at my previous
Speaker 5: job that I'm done with management. Thanks, but no thanks,
Speaker 5: had had a good run, but we dine and But
Speaker 5: so the job before light Step, when I was a manager, right,
Speaker 5: i'd been I was managing two teams thirteen people total,
Speaker 5: and I was managing a platform engineering team and an
Speaker 5: observability team. Platform engineering team was a Hashi Corp stack
Speaker 5: and I knew Kubernetes and they were using Nomad. So
Speaker 5: it was like, great, now I have to learn a
Speaker 5: thing that I don't know, which my brain was like yay,
Speaker 5: fun stuff. And also this observability team, which I was
Speaker 5: new to observability. I've been dabbling. Like my understanding of
Speaker 5: observability came from like reading Charity Majors tweets, and you know,
Speaker 5: my thought was, well, I have to do right by
Speaker 5: my team, by my organization and if I'm going to
Speaker 5: lead an observability team at the organization, and we were
Speaker 5: an observability practices team, So defining the observability strategy at
Speaker 5: the company two cows, which is that two Cows if
Speaker 5: you remember the yeah, yes, yes, but not doing that.
Speaker 5: It was not the download of free Windows software anymore.
Speaker 5: They're a domain wholesaler when I joined, and so as
Speaker 5: part of it, I'm like at the time, I already
Speaker 5: had like this blog on Medium where I've been using
Speaker 5: the blog to like basically learn in public, right document
Speaker 5: document cool things that I've discovered and share them with
Speaker 5: the world, because my personal pet peeve is a lot
Speaker 5: of stuff is documented very poorly in tech. People assume
Speaker 5: that you know what they're talking about, and it makes
Speaker 5: me think of those math textbooks where they're like, we'll
Speaker 5: leave the proof to the reader, and it's like, no,
Speaker 5: show me how the proof works, because I have no
Speaker 5: freaking clue. This is you know how I feel with
Speaker 5: regards to most technical blogs, so you know mine are
Speaker 5: in excruciating detail. So I basically thought, well, I'm gonna
Speaker 5: I'm going to learn nomad in public. I'm going to
Speaker 5: learn observability in public. Blog blog blog as I'm as
Speaker 5: I'm doing my job, and then one of my blog
Speaker 5: posts got the attention of my former manager at Lightstep
Speaker 5: and they reached out to me and said, hey, how
Speaker 5: would you like to do this for a living? I'm like,
Speaker 5: what you could do this for a living? And when
Speaker 5: I started on the job, they said, you know, it
Speaker 5: would be cool to like contribute to open telemetry. And
Speaker 5: I had been in like, you know, super enterprise corporate
Speaker 5: life pretty much up until that point, where like closed
Speaker 5: source all the things, like the most open source stuff
Speaker 5: we did was like Java and Maven and everything else
Speaker 5: was like there better be, like, you know, a support
Speaker 5: plan for this open source software, otherwise we're not going
Speaker 5: to buy it, which otherwise we're not going to use it,
Speaker 5: which I understand, like large enterprise, they got to cover
Speaker 5: their asses. But so that was my first forayan to
Speaker 5: open source. So I first started just contributing to the
Speaker 5: hotel docs and then there was an opening in the
Speaker 5: Hotel End User SIG and the end Users SIG basically
Speaker 5: connects end users with each other with an open telemetry,
Speaker 5: but we also relay feedback from the end users to
Speaker 5: the open tele telemetry maintainers. So there was there was
Speaker 5: a gap in leadership because one of the one of
Speaker 5: the original founders of the SIG had changed jobs moved
Speaker 5: away from Open Telemetry. So, you know, my my manager
Speaker 5: at the time, asked if I wanted to step in
Speaker 5: and help out, and that's that's how I got involved.
Speaker 5: And at the time it was a working group and
Speaker 5: then it was converted into into a SIG, And we've
Speaker 5: done a bunch of things to like just really elevate
Speaker 5: elevate the hotel community as part of the SIG. So
Speaker 5: we do a bunch of regular things, like we have
Speaker 5: this series called Hotel Me where we interview one of
Speaker 5: our end users and they share how they use open
Speaker 5: Telemetry in their own organizations. We have Hotel and Practice,
Speaker 5: which is basically it's a meetup style thing where you know,
Speaker 5: you have a cool presentation on something hotel, like, come
Speaker 5: on and and and present to us, like you know,
Speaker 5: you want to test out a talk that you want
Speaker 5: to give, like, use us as your guinea pig, and
Speaker 5: we do them as live streams and then the recordings
Speaker 5: are available afterwards for folks to consume on the on
Speaker 5: the Hotel YouTube channel we've run. We've partnered with the
Speaker 5: other SIGs to run end user surveys to and understand like,
Speaker 5: for example, the first one we did was on the
Speaker 5: Hotel Collector. The collector folks wanted to partner with us
Speaker 5: to understand how how end users use the collector to
Speaker 5: help inform the direction of the collector, like what what
Speaker 5: features are most important to the user so that they
Speaker 5: can you know, push forward with those as part of
Speaker 5: the Collector's roadmap. So that's effectively how I got involved
Speaker 5: with Hotel. So most of my work is in the
Speaker 5: sig I do. I'll pop in every so often and
Speaker 5: update docs and read mes, especially like when I'm doing
Speaker 5: research for my my technical talks and I'm digging into
Speaker 5: a topic and I'll notice, oh there's a gap here.
Speaker 5: I do two things. One is like I'll write a
Speaker 5: blog post on it because I love to do that.
Speaker 5: But then the other thing is like I want to
Speaker 5: be a good open source citizen and also like I
Speaker 5: want the docs, i e. The source of truth to
Speaker 5: have the information that I also make available in my
Speaker 5: blog so so that you know, we have that completeness.
Speaker 5: And I encourage everyone in open source to do that
Speaker 5: as well. You know, like so many vendors have wonderful
Speaker 5: blog posts out there on observability, like on on Open Telemeture,
Speaker 5: and I think it's great. But if you're noticing a
Speaker 5: gap in the docks, like take take the time to
Speaker 5: to update update those docks, update those read mes, because
Speaker 5: it'll just save a lot of people a lot of
Speaker 5: a lot of effort. Because the docs are the place
Speaker 5: I think where most people start start their journey, and
Speaker 5: then they'll you know, move to the blogs and the
Speaker 5: YouTube videos and whatnot for added information.
Speaker 1: Yeah, for sure. And it's like writing docks is really hard,
Speaker 1: so there's there's always room for improvement, and especially for
Speaker 1: people who are just starting their career, like that's such
Speaker 1: a great way to just start getting getting some experience,
Speaker 1: you know, because you read the docs, you try it,
Speaker 1: it doesn't work, you go off, you cuss and rant
Speaker 1: for a while, and then you come back and then
Speaker 1: you try it again, and eventually it kind of like
Speaker 1: clicks and like making that poor request back to the
Speaker 1: docks is a great way to start building a portfolio
Speaker 1: of expertise that will ultimately help you move on to
Speaker 1: bigger and higher paying roles big time.
Speaker 4: I think writing is probably one of the best things
Speaker 4: you can do for your career or like whatever, whatever
Speaker 4: the thing is that you do better with video or
Speaker 4: audio or like whatever. Just but just start to get
Speaker 4: your own voice and perspective out there.
Speaker 2: I don't think we should be discouraging people from entering
Speaker 2: the industry.
Speaker 3: I'm saying they have to write it.
Speaker 2: I mean, I don't know about other people, but I
Speaker 2: became an engineer because I wanted to just solve equations
Speaker 2: all the time. That that was my goal. And now
Speaker 2: I don't do anything with numbers or math in any way,
Speaker 2: and I spend it all the time going to conferences
Speaker 2: at writing writing books like Adriana. Yeah that's my life.
Speaker 1: Yeah. Well, communication is such a key part of being
Speaker 1: a good engineer, and I think it's it's underplayed a lot.
Speaker 1: But when it comes to writing, I know a lot
Speaker 1: of people with engineering oriented minds either aren't good writers
Speaker 1: or don't consider themselves good writers. And lately I've been
Speaker 1: using AI so I'll write something up and then copy
Speaker 1: paste it into AI and just have it just give
Speaker 1: me some feedback on it. And I found that to
Speaker 1: be really helpful.
Speaker 5: Yeah, I think I think it's a good starting point.
Speaker 5: My caution on that personally is I find AI. You know,
Speaker 5: it's like you use with hair, use with care. AI
Speaker 5: can take away your own like personal writing voice. So
Speaker 5: that that's just my my personal take on it.
Speaker 1: True story.
Speaker 4: Yeah, I don't think you can have the AI just
Speaker 4: like straight up right stuff for you or it is
Speaker 4: like very bland, like very very very bland. But I
Speaker 4: think you can use something like most of the grammar
Speaker 4: check tools all incorporate AI.
Speaker 3: Now, So if you're using like Grammarly or pro.
Speaker 4: Writing Aid or something and you're worried about punctuation or spelling,
Speaker 4: that that would be me.
Speaker 3: That would be me worried about the punctuation and the spelling.
Speaker 4: It's not like listen, it's just not going to happen
Speaker 4: if there's not some type of tool out there, or
Speaker 4: unless I hired an editor, which like I'm not going
Speaker 4: to do for a blog.
Speaker 3: Post, like nobody's going to do that. But I do
Speaker 3: think these you know, these tools do catch quite a bit.
Speaker 5: But I agree, and you know, like I'll whenever I'm questioning,
Speaker 5: you know, the grammar on something, I'll throw that into
Speaker 5: AI too, you know, to verify either I'm heinously wrong
Speaker 5: or like hey, I got it right, Yay.
Speaker 2: Do you have a tool of choice for your work?
Speaker 5: For me, I'll use a Microsoft co Pilot every so often.
Speaker 5: So like for my talks, for example, I have like
Speaker 5: talk mascots so on. On my slides, I'll have like
Speaker 5: a theme a theme animal. So for example, for my
Speaker 5: one of my talks next week, the the Green Collector Talk,
Speaker 5: we have a polar bear wearing a green recycling t
Speaker 5: shirt throughout. So Copilot generates some some fun, some fun animations,
Speaker 5: and you know, sometimes I'll ask it to like I
Speaker 5: did ask it when I was researching a talk to
Speaker 5: like write me some terraform code to do X, which
Speaker 5: was helpful, but then it hallucinated and generated me a
Speaker 5: actually it was in terraformos pullumi. It generated me a
Speaker 5: Pulumi function that didn't exist, and that kind of pissed
Speaker 5: me off for an hour. I'm like, where is this
Speaker 5: bloody function? Did not exist? But yeah, yeah, that's that's
Speaker 5: that's that's the main one that I use. My dad
Speaker 5: swears by perplexity. He says it's quite good. I've never
Speaker 5: tried it, but he swears by it.
Speaker 2: At least one of your parents using a modern tools.
Speaker 5: Oh my God. My dad is a retired software architect
Speaker 5: and he like learned Rust for fun two years ago.
Speaker 5: He's seventy two, and he's like, yes, I'm writing my
Speaker 5: own rust crates to do like some performance testing on
Speaker 5: some code that I wrote, and I'm using statistical analysis
Speaker 5: methods blah blah blah. I'm like, dude, I learned this
Speaker 5: stuff in university and I don't remember a bit of it.
Speaker 5: And he's like, you know, refreshing his knowledge on this stuff.
Speaker 5: I'm like, do you.
Speaker 1: Right on? Well, this feels like a good time to
Speaker 1: move over to Picks. What do you think?
Speaker 2: Yes, let's do it.
Speaker 1: Warren over to you.
Speaker 2: Well, I knew it was going to meet me first,
Speaker 2: so I was actually surprised that you weren't just going
Speaker 2: to immediately go to me.
Speaker 1: So yeah, I tried to change it up, Like man,
Speaker 1: I always pick on Warren.
Speaker 2: So well, it's okay. I'm always prepared, so it works out.
Speaker 2: So today I'm going to be super lame, but we're
Speaker 2: going to have a survey that's going to be posted
Speaker 2: on a venture in DevOps dot com slash survey at
Speaker 2: because I have them. I'm going to give away five
Speaker 2: awards of aws credits based on the responses. I don't
Speaker 2: know how many of them out yet. We're going to
Speaker 2: see based on the responses, and I'm not sure where
Speaker 2: the questions are yet, but the survey is going to
Speaker 2: be there. I assure everyone.
Speaker 1: Right on, that'll be cool. I'm looking forward to hearing
Speaker 1: from folks on that. And I mean, you get in
Speaker 1: AWS credits for it, so it's going to be a
Speaker 1: little incentive to go into it.
Speaker 5: Yeah, right, who doesn't love cloud credits?
Speaker 2: Right for sure?
Speaker 1: Andriana should bring us a pick today.
Speaker 5: A thing that I really like. It's an activity. I'm
Speaker 5: a rock climber, so I love bouldering. I think you know,
Speaker 5: if if if you have kids that like to scramble
Speaker 5: up things, highly recommend taking your kids bouldering, and also
Speaker 5: as an adult try it out. That is my pick
Speaker 5: for you, and as a personal thing. Every every city
Speaker 5: that I visit, you know when when, whether it's on
Speaker 5: vacation or at a conference, I always make it a
Speaker 5: point of checking out the local bouldering gym. Bouldering is
Speaker 5: a little bit scary for those who aren't familiar with
Speaker 5: rock climbing because there's like the rope climbing and then
Speaker 5: there's bouldering, which is like your up I want to say,
Speaker 5: like ten feet up, no rope, big fluffy mat at
Speaker 5: the bottom. You can still get injured. I sprained my
Speaker 5: ankle twice, the same ankle from just a bad fall.
Speaker 5: But it is great fun, especially if you're looking to
Speaker 5: just like step outside of you know, whatever it is
Speaker 5: that you do is your your day job. It's a
Speaker 5: great way to just decompress because you've got nothing better
Speaker 5: to do. But you know, focus on getting to the
Speaker 5: next move and going up the wall, and you can't
Speaker 5: your your mind can't flinch, can't get distracted because otherwise
Speaker 5: you fall.
Speaker 1: It's very therapeutic, Jillian, are you back with us?
Speaker 3: Okay, So I'm gonna pick the newest Expeditionary Force book.
Speaker 3: It's a science fiction series.
Speaker 4: That's like, unlike most science fiction, it's kind of campy
Speaker 4: and it kind of like goofy and silly and doesn't
Speaker 4: have a lot of horror or gore or things that
Speaker 4: I don't like reading, which is very hard to find
Speaker 4: in science fiction I found because a lot of them
Speaker 4: have just stuff that I don't want to read about.
Speaker 4: So that's an Expeditionary Force by Craig Allenson. It's probably
Speaker 4: one of my favorite science fiction series right on.
Speaker 1: Cool. I'm going to go with two picks this week. One,
Speaker 1: there's a guy, he's a kid, Let's be honest, he's
Speaker 1: a kid. I think he's probably mid twenties. His name
Speaker 1: is Dan Coe, and he's really fascinating just his take
Speaker 1: and like the amount of work and effort he's put
Speaker 1: into studying like philosophy and like the meaning of life
Speaker 1: and your your purpose, and you're calling like really extraordinary
Speaker 1: stuff for someone who's so young. He just released a
Speaker 1: new book yesterday called Purpose Profit two that he's giving
Speaker 1: it away for free on his website, the danco dot
Speaker 1: com d A. N. Koe and started reading it. But
Speaker 1: he's written so much other great stuff following him on
Speaker 1: x His stuff there has been so cool. I'm just
Speaker 1: gonna go right ahead and recommend his book before I've
Speaker 1: even finished reading it. I just feel like the quality
Speaker 1: is going to be there for anyone who's interested in
Speaker 1: reading that. And then the second pick I have so
Speaker 1: there's a really like humiliating story I'll go with first.
Speaker 1: To set the stage for this, Like I spent my
Speaker 1: youth going to a lot of heavy metal concerts and
Speaker 1: playing guitar in heavy metal bands, and so it turns
Speaker 1: out that because of all the headbanging involved, you can
Speaker 1: actually get whiplash. And so I have like the long
Speaker 1: term effects of whiplash from my taste in music, and
Speaker 1: it's I've had lots of had some different problems with
Speaker 1: it over the years. But recently I got this thing
Speaker 1: called an iron neck to like strengthen my neck muscles.
Speaker 1: And so that's my second pick. It's like this really
Speaker 1: super cool looking head gadget that you put on your head.
Speaker 1: Definitely want to you're the kid with the helmet, that's
Speaker 1: what you write, right, Yeah, It's a total fashion statement,
Speaker 1: absolute fashion statement. So if you're just looking to like
Speaker 1: have you painted it? Like, if you want to like
Speaker 1: either improve your neck muscles or just improve like your
Speaker 1: social credibility in life, you want to go streatting around
Speaker 1: town with the iron neck on. But yeah, right, we're.
Speaker 2: Gonna have to see this the whole next episode. I
Speaker 2: think it's just gonna have to be a deal.
Speaker 5: Deal the next fashion statement.
Speaker 1: Right, So yeah, those are my two picks. Dan Coe's
Speaker 1: new book at the danco dot com and iron Neck
Speaker 1: and and like The reason I bring up the iron
Speaker 1: neck is even if you don't have whiplash from spinning
Speaker 1: your youth headbanging I'm sitting at a desk all day
Speaker 1: long hunched over your keyboard also has negative impact on
Speaker 1: your posture and your next strength. So this is a
Speaker 1: way to help counteract that so that whenever you do
Speaker 1: make it to old age, that you still have the
Speaker 1: ability to you know, stand upright or even perhaps look
Speaker 1: at sky.
Speaker 2: I think I'm gonna need to see some research on that,
Speaker 2: all right, man, I don't know.
Speaker 4: I think it's a pretty bold claim to old age.
Speaker 1: I don't know about that.
Speaker 3: I want like a standing ovation from the universe if
Speaker 3: I make it past sixty.
Speaker 5: So there's a podcast that I've been listening to called
Speaker 5: Wiser than Me. It's with Seinfeld actress Julia Louis Dreyfus,
Speaker 5: where she basically interviews all these like older ladies like
Speaker 5: you know, high profile older ladies like Jane Fonda, Amy
Speaker 5: Pan and it's been it was recommended to me by
Speaker 5: actually one of my podcast guests. It is great fun
Speaker 5: right on cool.
Speaker 1: And then there's your podcast as well, right, the Geeking
Speaker 1: Out podcast that is correct.
Speaker 5: Yes, just look up geeking Out with Adriana Villela, because
Speaker 5: otherwise if you just look up geeking out, it's gonna
Speaker 5: like give you like so many different listings on on
Speaker 5: the various podcasting apps. So geeking Out with Adriana Villela
Speaker 5: do that search term. You should be able to find
Speaker 5: the correct one. And there's a copy Vada on the
Speaker 5: on on the cover art.
Speaker 1: So awesome. Adriana, thank you so much for being on
Speaker 1: the show. This has been fun. Thanks for having me anytime,
Speaker 1: come on back anytime that you want. Warren Chilean as always,
Speaker 1: thank you both for being here.
Speaker 3: Thank you was fun.
Speaker 1: And to all of our listeners, thank you for listening
Speaker 1: to the show, and be sure and check out the
Speaker 1: website for the survey to get your elf some AWS credits. Alright, cool,
Speaker 1: we'll see you guys next week.
Speaker 4: M hmm.