Speaker 1: All right, what's going on, Let's do another episode of
Speaker 1: Adventures in DevOps Born. How's it going.
Speaker 2: Uh, it's a pretty good and Uh. I actually have
Speaker 2: a fact we're all prepared this week. Uh, and that
Speaker 2: is we've gotten upgrade to our website, adventures in DevOps
Speaker 2: dot com. So if you're listening to the podcast via
Speaker 2: a different source and you probably don't never see it,
Speaker 2: you know, here's an opportunity. Uh, you know, don't pay
Speaker 2: too much attention to it. But I think it's much
Speaker 2: better than where we were at before.
Speaker 1: Awesome, that's cool.
Speaker 3: And do you make the new website. I had a
Speaker 3: part of the.
Speaker 1: Dev chat, had a hand in it. Hi, Jillian, welcome back.
Speaker 3: Hello, thank you for having me back.
Speaker 1: Yeah, how's it been going.
Speaker 3: It's good. It's good.
Speaker 4: We had like the snow apocalypse here last week, but
Speaker 4: this week we're good. We're back to just snow right on.
Speaker 3: Yeah.
Speaker 1: This is my first year living up north and I've
Speaker 1: been so happy with the fact that I bought a snowblower.
Speaker 1: That's been so much fun. But I don't think.
Speaker 3: About getting one for the driveway. But I haven't.
Speaker 4: I haven't quite done it yet because there's guys that
Speaker 4: come to plow so.
Speaker 3: I don't know, I don't know.
Speaker 1: Yeah, highly recommended. It's just a great feeling, just chugging
Speaker 1: along behind it, blasting the snow. So, Matt Gowie, welcome.
Speaker 1: Happy to have you on a show.
Speaker 5: Yeah, thanks for having me. Nice to meet y'all be here.
Speaker 1: Yeah. So, Matt, you are you own master Point consulting company, right,
Speaker 1: so give us a little bit of the background on that.
Speaker 6: Yeah, I've run Masterpoints since the end of twenty sixteen.
Speaker 6: For a long time it was me as a solo consultant,
Speaker 6: and then around very beginning of twenty twenty two, I
Speaker 6: kind of started to build a team. So we're a
Speaker 6: boutique consulting shop. We're entirely focused on infrastructure as code nowadays.
Speaker 6: What that means is particularly terror form and open TOFU
Speaker 6: because those are the market winners in infrastructure as code today.
Speaker 6: And then we do a little bit of work with
Speaker 6: Polumi and yeah, we help our clients automate, migrate, implement
Speaker 6: best practices, and really help them build the right workflows
Speaker 6: on infrastructure so that they don't have that as a
Speaker 6: bottleneck and they can help their application engineers move fast.
Speaker 2: Yeah, I mean that's like almost a decade, right, it's close.
Speaker 1: You must have seen some.
Speaker 2: Wild changes that have occurred in the space over that time.
Speaker 5: Yeah, it's been fun.
Speaker 6: I got into you know, I always had a background
Speaker 6: in DevOps. I started in startups where you just a
Speaker 6: you wear fifteen different hats and you do whatever you
Speaker 6: can to help the team move forward. But I didn't
Speaker 6: get into infrastructure as code specifically. I was really big
Speaker 6: an answerable until like twenty seventeen and twenty eighteen maybe,
Speaker 6: and then I around zero goot eleven is when I
Speaker 6: got into terrorforms specifically, and I was like light bulb,
Speaker 6: got got to get into this more.
Speaker 5: This is the way to do things for sure.
Speaker 1: So I know that, like consultant is like one of
Speaker 1: the common career paths for people in our industry, and
Speaker 1: the big challenge there is always how do you find clients?
Speaker 1: You know? And is this a consulting arrangement where I'm
Speaker 1: technically a full time employee but I don't get any
Speaker 1: of the benefits. So how how does it look from
Speaker 1: your perspective, like what do you look for in a client?
Speaker 1: How do you approach this whole problem?
Speaker 6: Yeah, I think being solo is very different than running
Speaker 6: an agency.
Speaker 5: But I think one truism, one you know.
Speaker 6: Fact of life that I've found is that you know,
Speaker 6: people do business with who they know and who they trust.
Speaker 5: So referrals are always king within consulting.
Speaker 6: You know, you'll get a referral from a previous client
Speaker 6: or a colleague who knows you well and can speak
Speaker 6: to Hey, Matt and his team do really good work,
Speaker 6: and that client that referral, that prospect is ninety percent
Speaker 6: more likely to you know, sign on the dotted line
Speaker 6: and trust that, hey, we're going to do a great
Speaker 6: job for them, then somebody who finds us through SEO
Speaker 6: or I've never done outbound email marketing because I don't
Speaker 6: believe in that as a viable business. But you know,
Speaker 6: that type of stuff is not the approach that I take.
Speaker 6: I take a very like human approach to it, where
Speaker 6: I go out and network a bunch.
Speaker 5: I try and.
Speaker 6: Be a good person within my community, and that is
Speaker 6: the means by which I like really work to try
Speaker 6: and bring in business for my coany. For some people, Hey,
Speaker 6: if you're just getting into consulting, maybe that sounds awful
Speaker 6: to you. Maybe you just want to be heads down
Speaker 6: writing code. You can go and join a consulting shop.
Speaker 6: We're hiring every once in a while, so reach out.
Speaker 1: For sure. I think that's one of the big surprises
Speaker 1: for people who take on the consulting route is understanding
Speaker 1: that you are leaving your one job to take on
Speaker 1: three jobs, because now you have Job number one is
Speaker 1: a consultant where you're generating the billable hours. But then
Speaker 1: job number two is you're an accountant because now you
Speaker 1: have to do all the taxes and the legal paperwork
Speaker 1: and the bookkeeping. And job number three is you are
Speaker 1: in marketing because you always have to be recruiting and
Speaker 1: finding your next job once this one wraps up.
Speaker 6: Yeah.
Speaker 2: I mean, I'm with Matt that I don't believe in
Speaker 2: the code calling. I don't think those emails work, and
Speaker 2: yet I still see I probably get five to six
Speaker 2: a day from random people on LinkedIn saying, hey, you know,
Speaker 2: can we sell you our services whatever it is. They
Speaker 2: don't even know what my company is doing, and yet
Speaker 2: they're already like, oh, we know, we can help you.
Speaker 5: It's just constant. I think if you have any C suite.
Speaker 6: Level title in your name, I think we all get
Speaker 6: a insane amount of of both spam email and you know,
Speaker 6: the the LinkedIn messages and it's just it's just piles up.
Speaker 5: It's kind of insane.
Speaker 6: And I still don't understand how people do it because
Speaker 6: I can't think of a worse Like I, you know,
Speaker 6: get ten thousand emails here, you know, maybe that's high,
Speaker 6: but like I've never responded to one, So.
Speaker 2: Yeah, you're you're missing out your opportunity here. I respond
Speaker 2: to every single one of them with a vengeance, like
Speaker 2: like I'm curious, like I really want to know, like
Speaker 2: is this person, you know, do they have a competency,
Speaker 2: you know, are they looking for something special? I really
Speaker 2: care about my like LinkedIn network, so I'm always looking
Speaker 2: to see, you know, making a connection with an initial
Speaker 2: person is it worthwhile for them and for me? And
Speaker 2: so like I'll try to dive into that. And some
Speaker 2: of them, you know, actually do turn it around and
Speaker 2: you know, are able to talk about the subject or
Speaker 2: the topic. But a lot of times they're just the
Speaker 2: partner portal expert or marketing manager or account manager and
Speaker 2: they have no idea of the thing that they're even
Speaker 2: selling in the first place. And I'm like why, like
Speaker 2: why did you think this was going to go like like,
Speaker 2: just walk me through your process here. Step one, connect
Speaker 2: with me on LinkedIn, h step two dot do dot
Speaker 2: step three profit like like, I don't know how as
Speaker 2: it is.
Speaker 5: That's pretty good.
Speaker 4: I would like to invite you to have a conversation
Speaker 4: with like some teenagers. It goes, it goes exactly the same,
Speaker 4: exactly the same.
Speaker 1: So do you find that a lot of your you know,
Speaker 1: you talked about your your network and everything's coming to
Speaker 1: you or your your most likely sources through referrals. Is
Speaker 1: that within your community or is that online? Does that
Speaker 1: include digital connections?
Speaker 5: Yeah, so yes it does.
Speaker 6: I mean, of course I think that you know, we're
Speaker 6: myself and a number of members on my team are
Speaker 6: big contributors maintainers of our own open source as well
Speaker 6: as like one of the larger open source infrastructure is
Speaker 6: code terrorform libraries. Uh, so we have a bunch of
Speaker 6: connections in that world. I have CTO online communities I'm
Speaker 6: involved in. I have a bunch of like volunteer with
Speaker 6: other extrajournal organizations that I'm involved in, and I think
Speaker 6: we try and pretty be pretty involved in like different slacks,
Speaker 6: and I think that things come from those all the time.
Speaker 6: So Yeah, it's not just you have to be going
Speaker 6: out and shaking hands and kissing babies. It's also some
Speaker 6: level of online Uh, you know, presence is really important.
Speaker 6: I personally am posting on LinkedIn three times a week.
Speaker 6: I have a lot of really good, uh colleagues, people
Speaker 6: that are I like a lot and highly respect their opinion.
Speaker 6: They are, you know, people I've met through LinkedIn and
Speaker 6: just like posting content. So I think that there's a
Speaker 6: lot of different avenues how that networking happens, but.
Speaker 5: It all, you know, kind of leads to a similar
Speaker 5: uh and result.
Speaker 2: Let's let's plug your your terror form open source library.
Speaker 1: Like what is that?
Speaker 6: So we are maintainers of cloud posse. Uh have you
Speaker 6: folks ever heard of them?
Speaker 4: I have, So you're that person I steal your code
Speaker 4: like all the time.
Speaker 5: See, they're the best.
Speaker 4: When I originally got it on the show before I
Speaker 4: didn't know this, this is like the best super event
Speaker 4: for a Tuesday morning.
Speaker 6: Ever.
Speaker 5: Yeah, they're they're not my company.
Speaker 6: Eric's a good and I really respect the hell out
Speaker 6: of what that guy's doing. But when I initially got
Speaker 6: into Infrastructure's code, they were the community that I found personally,
Speaker 6: and I was just like, Hey, these folks are doing
Speaker 6: this sensibly, like this is one infrastructure is not Infrastructure
Speaker 6: is a commodity, right, Like, we're all shipping the same
Speaker 6: load balancer, we're shipping the same certificate, we're shipping the
Speaker 6: same postgress instance. Why do we need to re Yeah.
Speaker 2: I have no idea what.
Speaker 3: You're talking about.
Speaker 6: Anyway, they they do it right. And when I found
Speaker 6: their modules, I was really excited. I was contributing a
Speaker 6: bunch and then as part of that, I ended up
Speaker 6: on their like maintainer teams. So we're helping them get
Speaker 6: prs tested and merged and complying with all the best
Speaker 6: practices that those folks have set out. And I have
Speaker 6: multiple my team have now joined that that we're organization,
Speaker 6: And yeah, that's the I really believe in open source
Speaker 6: infrastructure's code. I think there's like interesting discussions there. Some
Speaker 6: people do not Some people think that we should be
Speaker 6: copy and pasting and writing little snowflakes all over the place.
Speaker 6: But that's, you know the difference in opinion that happens.
Speaker 2: I actually want to get into that because one of
Speaker 2: my questions that I had thought of that I really
Speaker 2: wanted to ask you is what is the real impact
Speaker 2: of And I know someone's going to be kicking me
Speaker 2: for bringing this topic up at only whatever like the
Speaker 2: ten minute point, and that's realistically any sort of LLM
Speaker 2: integration here, because like I really do feel like that, Okay,
Speaker 2: well laugh it out that there's a lot like this
Speaker 2: is exactly the sort of thing that I think LMS
Speaker 2: are very good at generating. But at the same time
Speaker 2: it's the worst place to have those little mistakes that
Speaker 2: will cost you, you know, huge production incidents.
Speaker 6: Yeah, so I will say that we don't typically a
Speaker 6: ton of infrastructure as code. You know, we'll do it
Speaker 6: for new resources that we haven't seen maybe sometimes, but
Speaker 6: for the most part, you know, I'm I have a
Speaker 6: very serious talk with my team that like, hey, you
Speaker 6: need to understand how all these things come together. This
Speaker 6: can't be l generate, you know, get commit and ship it,
Speaker 6: because yeah, there's a lot of nuances in that one
Speaker 6: flag that might be a security loophole that might cause
Speaker 6: you to over provision something along those lines.
Speaker 3: And.
Speaker 6: I don't know, we see it a lot where people
Speaker 6: are generating a ton of code and then they don't
Speaker 6: really have a good handle on Hey, what all this
Speaker 6: is doing.
Speaker 5: And I think that's that's usually where i'm.
Speaker 6: You know, a proponent of open source, because hey, you
Speaker 6: could probably get that same use case that you are
Speaker 6: looking for.
Speaker 5: You know, you're trying.
Speaker 6: To deploy a bunch of data dog monitors, and instead
Speaker 6: of generating code around them and creating a you know, yeah,
Speaker 6: get the job done for today, but for day two operations,
Speaker 6: is it better to have a small open source module
Speaker 6: that provides that same monitor, that provides a spec, provides
Speaker 6: you something that you can upgrade in the future, provide
Speaker 6: something that's already tested and already secure. There's a lot
Speaker 6: of benefits to at least doing.
Speaker 5: The search beforehand.
Speaker 6: To go for open source, I think then just saying hey,
Speaker 6: we can generate the hell out of this code.
Speaker 2: Yeah, are the open source modules showing up in the
Speaker 2: LM results or is it pure like underlying HCl.
Speaker 6: Not that I've seen, And you know, we haven't done
Speaker 6: a good test of Hey, let's use an LM that
Speaker 6: we've given like a lot of really good instructions to
Speaker 6: read through the three hundred open source modules that we
Speaker 6: typically use. But I think that that's a good question.
Speaker 6: I haven't seen anybody who's like using a trained model
Speaker 6: to say, hey, these are our approved module libraries.
Speaker 2: I mean, it wasn't even just that, but because I
Speaker 2: remember there was like a pretty huge scandal with Pulumi
Speaker 2: where they tried to do something similar to this and
Speaker 2: the LM that they were featuring on their website just
Speaker 2: like could not provide more wrong information. Uh So that's
Speaker 2: totally a data point there.
Speaker 6: Yeah, that's interesting, always trying to do some something new
Speaker 6: and I applaud them for innovation.
Speaker 5: You're gonna get it wrong sometimes, right, you gotta try.
Speaker 1: It's good for sure, fell Fast. So whenever you start
Speaker 1: working with a new client, do you have like a
Speaker 1: particular vertical or size of company that you work really
Speaker 1: well with and have isolated on that intentionally?
Speaker 6: Yeah, we still love startups, and you know, it's sad
Speaker 6: that the VC market is.
Speaker 5: No good, but I still still love startups.
Speaker 6: We just have moved further up funnel in terms of
Speaker 6: we usually talked to the series C and above, you know,
Speaker 6: the folks who are well established and they're trying to scale,
Speaker 6: because that's really where a lot of our expertise comes
Speaker 6: in Handy is hey, you have an organization that has
Speaker 6: grown organically you've been trying to grow fast and you've
Speaker 6: made some mistakes and we can kind of come in
Speaker 6: and dig you out of your hole. So yeah, that
Speaker 6: realm is where we really like to engage is the
Speaker 6: mid market to like late stage series of funding startups.
Speaker 5: We have an anchor client who's a large enterprise.
Speaker 6: They're you know, a Fortune five hundred car manufacturer. But
Speaker 6: really I love those those later stage startup clients because
Speaker 6: they have the most fun problems. They usually have great
Speaker 6: engineers that are just like, we need to be pointed
Speaker 6: in the right direction, and hey, we can do that,
Speaker 6: so it's fun.
Speaker 2: Are you seeing the same holes at each of your
Speaker 2: clients or is it like everyone have their own special
Speaker 2: set of problems.
Speaker 6: I think that there's a you know, uh, there's always
Speaker 6: some combination of similar problems, you know. There there's a
Speaker 6: really common problem that we've written a bunch about on
Speaker 6: our blog, and we we have another blog post coming
Speaker 6: out really soon.
Speaker 5: That's you know, the terroorlyth problem. Have y'all ever heard
Speaker 5: of that term? This one's new for me. Okay.
Speaker 6: It's basically, when you build a infrastructure as code root
Speaker 6: module that's too big, so it's storing too many resources
Speaker 6: in state and then it becomes slow topply, it has
Speaker 6: blast radius issues, and you you know, can't really do
Speaker 6: role based access control in your team because hey, you're
Speaker 6: managing your network alongside your database, alongside your application cluster.
Speaker 6: So we've seen that a ton and you know that
Speaker 6: comes in all different shapes and sizes. It's very unique
Speaker 6: to the organization. We we know how to break those
Speaker 6: up really well. So that's that's an easy one. We'll
Speaker 6: have a post on that on the blog very soon
Speaker 6: that talks about how teams can break it up themselves
Speaker 6: give it away for free. You know. The other thing
Speaker 6: I think is there's still a lot of organizations who
Speaker 6: are applying locally and they don't they haven't figured out automation.
Speaker 6: And then on the opposite side of the coin, there's
Speaker 6: a bunch of organizations who have built their own automation
Speaker 6: around infrastructure as code and they've found out the hard
Speaker 6: way that that's not a good route, and they, you know,
Speaker 6: are really you know, continuing to toil in the details
Speaker 6: of like, hey, how do we you know, make this
Speaker 6: scalable for our organization.
Speaker 5: And it's it's kind of a bad rabbit hole.
Speaker 6: We always suggest, hey, either go again open source or
Speaker 6: pick one of the really awesome vendors in the space.
Speaker 6: But yeah, those are those are some of the like
Speaker 6: high level problems. There's a lot of like nuanced, like
Speaker 6: code level details that I think we see a lot
Speaker 6: that we have strong opinions on. But yeah, those are
Speaker 6: the ten thousand foot ones.
Speaker 2: See I saw will laughing here sort of like the
Speaker 2: villain at the end of a movie that is having
Speaker 2: some sort of s like logical breakdown, and I just
Speaker 2: I have to I have to wonder what was going
Speaker 2: through his head at that moment.
Speaker 1: Just reliving some past trauma. I think.
Speaker 4: Those Yeah, this whole show is just like PTSD induced.
Speaker 1: You know, no, I can totally relate to that, especially
Speaker 1: in the stage of company that you're you're focused on,
Speaker 1: you know, the late late stage series startup, because early
Speaker 1: on I've been guilty of this many times. You know,
Speaker 1: early in the startup stage, you think about your past
Speaker 1: experiences and you're like, I'm not going to do that again.
Speaker 1: We're going with I see from the very beginning, and
Speaker 1: so you start building all of these processes and controls,
Speaker 1: and the flaw with that is you don't actually have
Speaker 1: a product for your company. Yet, you know, because for
Speaker 1: every startup there's always the there's the product that you launched,
Speaker 1: and then there's the product that you're customers actually wanted.
Speaker 1: And never in the history of startups have those two
Speaker 1: been the same thing. So you make all of these
Speaker 1: process and design and architectural decisions around this product that
Speaker 1: now no longer exists. And it takes someone like yourself, Matt,
Speaker 1: from an outside perspective to come in and say, you know,
Speaker 1: you're holding on to these little nuggets here hoping that
Speaker 1: their gold, and they're not. Just let them go.
Speaker 5: Sound advice.
Speaker 2: I think it's a huge problem there though, which is
Speaker 2: that those processes are sort of coupled to the culture
Speaker 2: of your organization, so like you almost need to like
Speaker 2: actually start a new company to get rid like actually
Speaker 2: eliminate all of that tech deat In some ways, you've
Speaker 2: built it up, You've built up expectations on how that works.
Speaker 2: Like maybe you are career ladder is somehow hooked to
Speaker 2: the types of task and responsible. I mean, no one's
Speaker 2: got it that bad, but there's a lot that needs
Speaker 2: to be thought about other than just like you can't
Speaker 2: just click a couple of buttons and delete their code.
Speaker 1: I call it the polished turd syndrome, because you start
Speaker 1: with this turd and you just keep polishing it and
Speaker 1: polishing it, and then eventually it starts to get some
Speaker 1: shine to it, and so now you're really emotionally invested
Speaker 1: in making this turd nice and shiny, and you need
Speaker 1: someone to come in and say, dude, it's it's just
Speaker 1: a turd.
Speaker 3: It go.
Speaker 2: They have to want to listen, though, And I think
Speaker 2: that's part of the problem is that often you see
Speaker 2: like the maybe operations division or sales or marketing, or like,
Speaker 2: we're actually making a lot of money from that thing.
Speaker 2: It's not like as much money as we should be making,
Speaker 2: but we're making, you know, a million ten million a year,
Speaker 2: and we just need to keep the lights on, and
Speaker 2: they don't understand how much toil and complexity is actually
Speaker 2: involved to just keeping the lights on for that. And
Speaker 2: so I actually think I've seen this way more often
Speaker 2: than the other side, where an engineering team doesn't want
Speaker 2: to own it, they don't want to do anything with it,
Speaker 2: except someone keeps on telling them, oh, yeah, you know,
Speaker 2: you have to keep it working, but you're not allowed
Speaker 2: to spend any time doing that.
Speaker 5: I've seen that, and I think that, you know, a
Speaker 5: part of what you folks are talking about.
Speaker 6: I mean, yeah, at the level, at the stage of
Speaker 6: company that we usually engage with, there's always some level
Speaker 6: of like some cost fallacy, right, there's some group within
Speaker 6: the organization who's wrapped up in the idea that, hey,
Speaker 6: we've invested so much in this tooling, why why would
Speaker 6: we get rid of it?
Speaker 5: What do you mean? And yeah, it does.
Speaker 6: It does sometimes take a third party like my company,
Speaker 6: that comes in and says, hey, here's the reasoning. You know,
Speaker 6: we're the outside eyes. We're giving you this this perspective
Speaker 6: because honestly, your workflow is not great. You're not, you know,
Speaker 6: doing yourself favors here by continuing to polish this, so
Speaker 6: to speak. So, yeah, I agree with what you folks
Speaker 6: are getting at. It is it's always comes down to
Speaker 6: people problems in one way or another. And I think
Speaker 6: that luckily I've been consulting long enough where I like
Speaker 6: can navigate those well.
Speaker 5: Uh, and yeah, it's fun.
Speaker 2: Who who are the decision makers that end up signing
Speaker 2: off on needing to pull in a third party for you?
Speaker 6: It usually comes down to the director level or above,
Speaker 6: so it's usually director of Engineering, Director of DevOps infrastructure,
Speaker 6: the VP, the CTO, it's somewhere along that chain. Sometimes
Speaker 6: it starts with an engineer, where the engineer will be like.
Speaker 5: Hey, we have this horrible problem.
Speaker 6: We're not dealing with it like we gotta we gotta
Speaker 6: do something, and that it can go bottom up.
Speaker 5: But it's not typical.
Speaker 6: It's more a yeah, some somebody in engineering leadership realizes
Speaker 6: they got to make a change, uh, and they're reaching
Speaker 6: out to to kind of talk through, Hey, what does
Speaker 6: this look like? How can we, you know, actually benefit So.
Speaker 1: Yeah, how often I think this is like a non
Speaker 1: technical component of the job. I'm interested in your your
Speaker 1: take on it. How often is it that the problem
Speaker 1: that you're really trying to solve is the cost of scalability,
Speaker 1: where like, the company's doing well and they're scaling and
Speaker 1: they're growing, but the infrastructure costs are are growing quicker
Speaker 1: than revenue.
Speaker 6: So I don't think it's the actual cloud costs that
Speaker 6: it's not. That's not actually typically a problem. It's the
Speaker 6: maintenance cost for engineers and the amount of time that
Speaker 6: they're spending to feed the system that they've built in
Speaker 6: one way or another, and that's the thing that's.
Speaker 5: Slowing them down.
Speaker 6: Basically, they've made some bad decisions along the line that
Speaker 6: is causing their organization to overall have them be a bottleneck.
Speaker 6: Whether that's that's their infrastructure workflow as a whole. Maybe
Speaker 6: it's because they you know, need to hire an entire
Speaker 6: security team to make sure that things are not you know,
Speaker 6: going to cause a you know, critical CBD and you
Speaker 6: know day day five of new application launch or something.
Speaker 5: Those are the problems we more typically see.
Speaker 6: So it's less actual, hey, our cloud costs are growing astronomically,
Speaker 6: and more hey, we're we're spending too much time here,
Speaker 6: Like why is this? Why is my team telling you
Speaker 6: need three more engineers? That's that seems like madness when
Speaker 6: you know we're not we're not really doing doing all
Speaker 6: that much crazy stuff here. We should be more, we
Speaker 6: should be faster, we should be more streamlined.
Speaker 5: Yeah.
Speaker 2: Maybe I actually sort of want to flip this question
Speaker 2: around because I really like it and I think there's
Speaker 2: a different perspective here that really gets me thinking. Is
Speaker 2: you're not you're not solving technical problems, are you? Like
Speaker 2: I I get the sense that you know you're coming in.
Speaker 2: It's not that the organization is missing two more engineers
Speaker 2: to Oh, if we only had these two people who
Speaker 2: understood terrior form better, we would solve all our problems.
Speaker 2: I mean, is that really it? I got the sense
Speaker 2: of probably you could do that. And they may be
Speaker 2: missing technology, but they're probably missing something like a better
Speaker 2: uh strategy for on the personal level, like there how
Speaker 2: they're approaching problems, or how they're prioritizing work or something
Speaker 2: like that. And maybe before I ask the next question,
Speaker 2: I'll give you a moment.
Speaker 5: Yeah.
Speaker 6: I think it's interesting because it's multifaceted, right. It's sometimes
Speaker 6: they've I like the this is my new joke where uh,
Speaker 6: you know what, why do Masterpoint clients reach out to us? Oh,
Speaker 6: because they applied themselves into a corner. I don't know
Speaker 6: if it's a good joke you folks on second person,
Speaker 6: I'm trying trying it out on but yeah, they back themselves.
Speaker 5: Into a corner.
Speaker 6: They they you know, they go about things in from
Speaker 6: an infrastructure as code perspective. We're we're still young, right,
Speaker 6: it's still a really early day.
Speaker 5: We might be ten years old.
Speaker 6: But Hashikorp when they came out with terrorform and terrorform
Speaker 6: I see as like that's what mainstreamed infrastructure is code.
Speaker 6: They came out with that in twenty fourteen, twenty fifteen,
Speaker 6: and it was really early, and it was just it
Speaker 6: was way more configured than it was code. And it's
Speaker 6: slowly grown and it's gotten better. And the reality is
Speaker 6: they didn't put out many best practices.
Speaker 5: So you have a ton of organizations, a.
Speaker 6: Ton who have just gone and built whatever the hell
Speaker 6: they wanted and it has turned into a mess and
Speaker 6: that can be a such a operational detriment to their
Speaker 6: organization that we're coming in and we're providing some of
Speaker 6: those best practices on how to like do things streamlined
Speaker 6: that it is a technical problem and they do need expertise.
Speaker 5: The other side of it.
Speaker 6: Is kind of what we were talking about before, you know,
Speaker 6: the cultural you know, hey, some cost bowel see trying
Speaker 6: to guard like trying to direct them into direction that's
Speaker 6: going to be you know, operationally efficient.
Speaker 5: There's a bunch of other things too, but like that's.
Speaker 6: What it usually comes down to, is like those two
Speaker 6: sides of the coin. Yeah, does that make sense to
Speaker 6: answer your question?
Speaker 5: Yeah, Yeah, for sure.
Speaker 2: I mean, there's some fundamental problem here, and I really
Speaker 2: like the perspective of they didn't think enough about what
Speaker 2: the future was going to look like for them, and
Speaker 2: they may not have the right people on the team
Speaker 2: to I mean, you don't fix a problem with the
Speaker 2: same initial conditions still in play. You need to change
Speaker 2: something to have a different outcome. I feel like you
Speaker 2: keep on bringing up potential perspectives that master Point have
Speaker 2: that may be highly controversial, and I want to get
Speaker 2: those on the record in a way, and like one
Speaker 2: of them is like one terraform repository for your whole organization,
Speaker 2: or do you like merge it with the individual application code,
Speaker 2: so like code and infrastructure as code next to each
Speaker 2: other in the same repo or one centralized location.
Speaker 5: That's one we don't have as much of a strong
Speaker 5: opinion on.
Speaker 6: I will say that we do have a strong opinion
Speaker 6: on there should be an infrastructure mono repo for your organization.
Speaker 6: I think that that's just like there's beyond just environmental infrastructure.
Speaker 6: There's a lot of infrastructure that is global. Right if
Speaker 6: you're managing GitHub, if you're managing if you're doing observability
Speaker 6: as code, and you're managing monitors and SLOs and dashboards
Speaker 6: and things like that within a tool like data Dog
Speaker 6: or Honeycomb. You want those to be in a centralized location.
Speaker 6: They shouldn't be scattered into fifteen different repositories. But even
Speaker 6: when it comes down to environmental infrastructure, so hey we
Speaker 6: have a VPC, we've got a load balancer, we've got
Speaker 6: a Postcrest database.
Speaker 5: If a client.
Speaker 6: Wants to do a hey they want their let's say
Speaker 6: they're shipping on Kubernetes, they want their Kubernetes infrastructure to
Speaker 6: live alongside the application that it is, you know, the
Speaker 6: repository that it's managed in. That's totally fine, but we
Speaker 6: would say, hey, put your put the environmental infrastructure that
Speaker 6: actually supports that application in the infrastructure mono repo and
Speaker 6: really have it be a single point over off in
Speaker 6: its own land so that you can like scalably duplicate
Speaker 6: that repo so as you add more services, as you
Speaker 6: add more components to the overall system, then then there's
Speaker 6: it makes sense there, and then you don't need to
Speaker 6: have those engine application engineers doing pullar quest to some
Speaker 6: infrastructure mount repo that they may or may not have
Speaker 6: any clue about what's going on.
Speaker 2: So he I mean, it's it's always great when the
Speaker 2: answer is you know, it depends, right, you know that's.
Speaker 5: It always depends.
Speaker 6: Yeah, yeah, particularly as a consult always.
Speaker 1: Jillie, what was that?
Speaker 3: That is everybody's favorite answer? Is it depends?
Speaker 5: Yeah.
Speaker 2: I mean there are some things that you know, I
Speaker 2: just sort of want the canonical, like it's always going
Speaker 2: to be this, and you know one of them is
Speaker 2: a TF workspaces.
Speaker 1: What is that?
Speaker 5: Is that?
Speaker 6: Yes or no?
Speaker 3: I don't like that spaces I like I like directories.
Speaker 4: I want to be able to run Tree on a
Speaker 4: directory like you know, kick it old school here workspaces.
Speaker 4: Nobody ever remembers to change the workspaces. Know, everybody else
Speaker 4: can have an opinion.
Speaker 5: So that is this is it?
Speaker 6: This is like the you've you've now nailed the one
Speaker 6: which is this is the biggest divide within infrastructure as
Speaker 6: code is. We have people who look at infrastructure as
Speaker 6: this is configured that should be copy and pasted, and
Speaker 6: we have people that look at infrastructure as this is
Speaker 6: more like code that should be you know, there should
Speaker 6: be one instance of this thing and then we should
Speaker 6: deploy that instance. Many times we're of the camp I
Speaker 6: disagree with Jillian, but I, you know, do respect that. Hey,
Speaker 6: there's a thousand different ways to do this, and people
Speaker 6: have their own way.
Speaker 3: It's okay. I like it when we can find on
Speaker 3: the show, it makes it.
Speaker 6: Yeah, yeah, I'm glad that even immediately came in. But yeah,
Speaker 6: we used to have workspaces. A lot of people rag
Speaker 6: on workspaces. I think that you can do them wrong.
Speaker 6: They are kind of a very light abstraction layer.
Speaker 3: There's a really cool that tends to be my problem.
Speaker 6: That is a thing that'll plenty of people do is
Speaker 6: forget that they exist. There is a really great issue
Speaker 6: in the opa tofu GitHub organization right now where Martin Atkins,
Speaker 6: one of the biggest original implementers UH and biggest contributors
Speaker 6: to terrorform core for for many years now.
Speaker 5: He is now switched over to the open tofu team.
Speaker 6: And one of the things that he did within his
Speaker 6: first like month or so was put up an ish
Speaker 6: you about deprecating workspaces, and now that issue has Yeah,
Speaker 6: Gillian's laughing.
Speaker 4: But like, well, I'm not like opposed to workspaces in theory.
Speaker 4: It's just that every time I've tried to use them
Speaker 4: and practice me or somebody else forgets they exist and
Speaker 4: like and then that's a problem.
Speaker 2: It could be worse though, they could be having separate
Speaker 2: GET branches for each environment.
Speaker 4: Okay, that's totally reasonable.
Speaker 3: What are you talking about? No, I'm sorry, I know,
Speaker 3: I know that's not reasonable.
Speaker 2: There's only one main line in a Git repository, and
Speaker 2: I will die on this hill.
Speaker 5: I will die on that hill as well.
Speaker 6: Particularly, an infrastructure is code, Particularly an infrastructure is code
Speaker 6: because you're you're not dealing with twelve factor apps in
Speaker 6: infrastructure is code, right, you don't have a separation of
Speaker 6: the configure that drives that infrastructure is code like you
Speaker 6: do with a application that could be in a gifflow model.
Speaker 6: So you're then if you want to make a change
Speaker 6: to a production configt sating, you have to do it
Speaker 6: in the proud branch. And that might mean that you're
Speaker 6: you just get into branch nonsense. And I just posted
Speaker 6: this recently of like my favorite, one of my favorite
Speaker 6: sayings is you know, more branches, more problems.
Speaker 5: I think it's way worse, sick, I think.
Speaker 6: It's way worse in infrastructure is code world. If you
Speaker 6: are doing a branch based workflow.
Speaker 2: I mean just doesn't make any sense from against dowdpoint,
Speaker 2: because these are become separate trees. And if these are
Speaker 2: separate trees, why are they even in the same repository.
Speaker 2: You're not gonna really do anything effective. I mean someone
Speaker 2: may say, well, you can cherry pick some diffs from
Speaker 2: one to another one, but I mean, realistically.
Speaker 5: That's a nightmare. That's yes.
Speaker 1: Is that your billing model, Matt, Your your hourly rate
Speaker 1: is based on the number of branches they have in
Speaker 1: their repo?
Speaker 6: Oh, I hope we don't have a client that's a
Speaker 6: done of branch based workflow.
Speaker 5: The amount of work.
Speaker 6: Yeah, maybe our hourly rate doubles, Yeah, would be good.
Speaker 5: Maybe I haven't had to do it yet.
Speaker 6: But well you've only heard about those those clients or
Speaker 6: heard about those setups.
Speaker 5: Yeah, not yet.
Speaker 2: So another one is you mentioned early on in the
Speaker 2: episode public versus Private modules, And at least from my understanding,
Speaker 2: I think this is one of those areas where if
Speaker 2: your core competency isn't building open to fool HCl models,
Speaker 2: you're probably going to get it wrong. And I believe
Speaker 2: it's a huge challenge to undo that mistake and using
Speaker 2: the either raw resources or what's come before you out
Speaker 2: there in the world is way more valuable than what
Speaker 2: you'll ever be able to do. But you know, I
Speaker 2: want to hear I want to hear the experts perspective
Speaker 2: on this.
Speaker 6: Yeah, we view it as, Hey, these the open source world.
Speaker 6: As long as you're correctly evaluating your the open source
Speaker 6: modules that you are using your you're getting one a community,
Speaker 6: you're getting tested code, you're getting best practices in terms
Speaker 6: of naming, tagging, and potentially security or not potentially, but
Speaker 6: you know, more likely security. And then you're getting something
Speaker 6: that when you go to, let's say, add a new feature,
Speaker 6: you can always check if that module has been updated
Speaker 6: recently by somebody else's doing that same exact feature.
Speaker 5: Maybe they're adding IPv six support, don't.
Speaker 6: We don't support IPv six for all of our clients, right,
Speaker 6: I know that some of the modules that we use do,
Speaker 6: And if we had built those modules ourselves in house
Speaker 6: for our clients, then they would have to go in
Speaker 6: and find all.
Speaker 5: The places to add IPv six support.
Speaker 1: Right.
Speaker 6: So what we typically tell clients is, hey, if you're
Speaker 6: if you want to encode conventions for your larger organization,
Speaker 6: you want to make sure that Hey, the numberumber of
Speaker 6: variables and the you know, the best practices that you
Speaker 6: see or fit wrap open source with your own small
Speaker 6: layer on top of that child module. You can do
Speaker 6: a smaller child module that just consumes another child module,
Speaker 6: and that bottom layer child module can be a open
Speaker 6: source and you can really I think, still get a
Speaker 6: lot of the benefits and create a lot of the
Speaker 6: flexibility that you want for your organization.
Speaker 5: So that's usually what our recommendation is.
Speaker 1: So what's your background before DevOps, Matt? Were you in
Speaker 1: infrastructure or software development?
Speaker 6: Software development? I? Yeah, did CS in university. Luckily went
Speaker 6: to a co op school, so I started working at
Speaker 6: startups when I was still in school.
Speaker 5: I did two stints at two awesome startups.
Speaker 6: They taught me a thousand things not to do, which
Speaker 6: was great, and one of the those startups hired me
Speaker 6: before I even left, and I moved to Philadelphia and
Speaker 6: was doing full stack. You know. I started mobile development,
Speaker 6: did a bunch of back end rails work, did a
Speaker 6: bunch of front end stuff. I was really big an
Speaker 6: amber JS back in the day, and then got into
Speaker 6: infrastructure and AWS specifically during that second startup experience.
Speaker 1: Right on cool The reason I asked that is because
Speaker 1: of your approach to this. Like throughout my career, I've
Speaker 1: seen like two philosophies in doing this, and I think
Speaker 1: they they sort of resonate with what you were just
Speaker 1: talking about. Like you have people who have written code
Speaker 1: in the past and they understand, you know, like abstraction
Speaker 1: and rappers and things like that. Then you have like
Speaker 1: your your old school knuckle dragger it guys who would
Speaker 1: you know, drag the rack in and if you needed
Speaker 1: more network port, you would drag another network switch in
Speaker 1: and you would do it in IRAQ and you would
Speaker 1: crawl under the floor to wire it up and stuff.
Speaker 1: And I think depending on what your early part of
Speaker 1: your career looks like greatly influences how you solve ic problems.
Speaker 5: Yeah. Yeah, I strongly agree.
Speaker 6: And I think it's one of the things that I
Speaker 6: get confused about within the infrastructure as code space.
Speaker 5: Why are we all doing it so differently? And I
Speaker 5: think it's an interesting.
Speaker 6: Space because we do have the CIS admin folks who
Speaker 6: were just awesome at Linux and they you know, could
Speaker 6: one line bash themselves out of.
Speaker 5: Any hole that they were in. And you know, we.
Speaker 6: Have people that are coming from application engineering that are
Speaker 6: you know, coming from Hey, I'm going to pick up
Speaker 6: modern practices and I learned Python, but now I'm switching
Speaker 6: over into into writing code or writing infrastructure because that's
Speaker 6: what the organization needed today.
Speaker 5: And I think that it's this weird.
Speaker 6: It's not a traditional software path, so you know, you
Speaker 6: have all these different ways of thinking about it, but
Speaker 6: when it comes down to it, a lot of the
Speaker 6: time I asked the question, why do we not treat
Speaker 6: infrastructure as code?
Speaker 1: As code?
Speaker 5: Like that?
Speaker 6: That is like a core principle, a core like issue
Speaker 6: that I have with a lot of people's setups, and
Speaker 6: it seems.
Speaker 1: Obvious when you phrase it that way.
Speaker 5: Yeah.
Speaker 2: Well, I think that there was a fight in one
Speaker 2: of the online communities I'm in whether or not configuration
Speaker 2: that lives in a YAMO file counts as programming, Like
Speaker 2: if you go and change that, and you know, for me,
Speaker 2: it's just a DSL, and every DSL is programming language.
Speaker 2: Whether or not it's turning complete, it's sort of irrelevant.
Speaker 2: And I'm sure someone's going to be like, YAML is
Speaker 2: turning complete. I don't know that it is, but I'm
Speaker 2: sure someone will make that comment, in which case, yeah,
Speaker 2: for sure, but I mean you're changing something, you know
Speaker 2: what you're impacting here, and you know I do. I
Speaker 2: do think that the there is this fundamental disagreement on
Speaker 2: how people really think about the world, and their internal
Speaker 2: values and their own perspectives influence how they think about
Speaker 2: the infrastructure that they write or what they create.
Speaker 1: The psychology of DevOps.
Speaker 4: Yeah, people problems, like that's right. We have a lot
Speaker 4: more people problems than we do technical problems.
Speaker 5: Yeah, it's never a technical problem.
Speaker 4: I mean it work with like the teching people, I
Speaker 4: would just I would get so annoyed so fast because
Speaker 4: the people that I work with they don't like really
Speaker 4: care about like the nitty gritty of what I'm doing.
Speaker 3: They prefer not to know.
Speaker 4: They would prefer if they never had to deal with
Speaker 4: me at all, is like what they really they can't
Speaker 4: do that, Like they want me in and out as
Speaker 4: quickly as possible and have no idea what I'm doing,
Speaker 4: and that's that's like their wish list.
Speaker 3: So I can't imagine working with people who I don't know.
Speaker 4: I think I had like one client nitpick at me
Speaker 4: about like a load balance, the type of load balance
Speaker 4: so that I was using and I was just like, oh,
Speaker 4: I'm not doing this again.
Speaker 5: Yeah, I hear you.
Speaker 1: Yeah.
Speaker 6: I think, particularly at the larger organization level, a lot
Speaker 6: of people want you know, infrastructure and DevOps is not
Speaker 6: a driver for success, right, It's a requirement. It needs
Speaker 6: to be part of the like pyramid that builds up
Speaker 6: to you know, profit at the end of the day.
Speaker 6: But people want it to be a really small piece
Speaker 6: and they want it to be quiet, and they you know,
Speaker 6: want to build that upper application piece that actually drives dollars.
Speaker 6: And it's a frustrating place to be in in terms
Speaker 6: of psychology at DevOps, like as you just mentioned, well, like.
Speaker 5: That is when I when.
Speaker 6: I talk to a lot of DevOps engineers, platform engineers,
Speaker 6: whatever you want to call them, it's like, you know,
Speaker 6: they're always just struggling with They have a ton of work,
Speaker 6: they have a huge backlog, they don't have a bunch
Speaker 6: of it, like, they don't have a big enough team.
Speaker 5: And I think that's really consistent.
Speaker 2: I think part of it comes from the fact someone
Speaker 2: was saying this recently to me that they think the
Speaker 2: next innovation and DevOps will be where the DevOps teams
Speaker 2: and the platform and the platform engineering teams and the
Speaker 2: product engineering teams will come and work together. And I'm like,
Speaker 2: I don't I think you misunderstood what DevOps means. If
Speaker 2: you think that's that's a future we haven't reached yet.
Speaker 2: But I think you know, organizations definitely, you know, it's
Speaker 2: swopped out whatever the what they were calling release engineering
Speaker 2: or infrastructure management, they just gave it a new name.
Speaker 2: And so of course we're going to see those problems
Speaker 2: in organizations where they are stuck there, where they don't
Speaker 2: see a solution, where they don't see anything as different,
Speaker 2: and they need someone to come in and help them.
Speaker 2: Got I got another controversial one. Here we go, cross plan.
Speaker 5: Oh have you read our blog posts?
Speaker 1: I have not.
Speaker 5: Okay, we've got a great blog post on it.
Speaker 6: I I shared out all the time because it's I don't.
Speaker 5: Know, it just feels it's a shame.
Speaker 4: I so.
Speaker 6: Back when I kind of started to build my team
Speaker 6: and started to transition from solo to agency, I had
Speaker 6: been really stoked on Kuber Duddies for a long time,
Speaker 6: and you know, really, uh, I thought it was the
Speaker 6: Swiss Army knife to solve all the problems. I think
Speaker 6: about that less now.
Speaker 1: Episode over.
Speaker 6: Sorry, I still think it's a great tool, don't get
Speaker 6: me wrong.
Speaker 5: So anyway, I you know.
Speaker 6: I was thinking cross Plaine was the next thing. I
Speaker 6: was like really excited. I had my senior engineer Veronica
Speaker 6: on my team. We we did her and I like
Speaker 6: collaborated on a long term proof of concept to build
Speaker 6: a bunch of infrastructure in cross plane, and I was
Speaker 6: just bullheaded. I was really really excited. And then just
Speaker 6: as we got through this proof of concept, it just
Speaker 6: thing after thing. We're just too painful. It's just not
Speaker 6: There was things that were missing that I was like, wait,
Speaker 6: we can't do that. There aren't data sources. And they
Speaker 6: have some of those things now, but I still think
Speaker 6: that overall there's a huge chicken and egg problem, like
Speaker 6: where do you get that Kubernetes cluster? So you have
Speaker 6: to kind of solve that differently all the time, And
Speaker 6: there is a bunch of problems around ergonomics of that tool.
Speaker 5: And I just talked to somebody, somebody who worked at
Speaker 5: far Winds.
Speaker 6: She you know, they had gone all in on cross
Speaker 6: plane and then they ended up pulling it out and
Speaker 6: going back.
Speaker 5: To terra form. Uh. And our blog post kind of
Speaker 5: shares all our thoughts on that.
Speaker 6: But yeah, cross Plaine, is it was exciting as an idea,
Speaker 6: I don't think it.
Speaker 5: I don't think it delivered on the promise. Sadly.
Speaker 2: Yeah, I mean, I'm really with you here, I don't.
Speaker 2: I don't know what the best way of summing it
Speaker 2: up is, Like, imagine if Kubernetes deployed all of your infrastructure,
Speaker 2: and you.
Speaker 1: Know, I don't.
Speaker 2: I don't love that because I just don't like these
Speaker 2: two things coupled together. Uh, And I feel like it's
Speaker 2: taking one very complex thing and throwing yet like a
Speaker 2: second aspect to it where people are already over using
Speaker 2: Kubernetes in a lot of places where it may or
Speaker 2: may not need to actually be utilized, and then to
Speaker 2: throw this on top. I'm really glad there is an
Speaker 2: article out there that discusses these because I definitely would
Speaker 2: have wanted to throw it at some of my past
Speaker 2: clients and customers who share it.
Speaker 6: You know.
Speaker 2: I think there's one of these problems though, where if
Speaker 2: you find yourself in an organization that has those problematic
Speaker 2: patterns in place, how do you fix.
Speaker 5: That problematic patterns in places?
Speaker 2: And like, like, you know, you come in an organization
Speaker 2: and they are using cross Plane and you're like, okay,
Speaker 2: you know, they're probably I've been called in because they
Speaker 2: know that there are issues, and you can look at
Speaker 2: it and be like, okay, I bet one of the
Speaker 2: issues is how is the fact' using cross play you
Speaker 2: didn't think about what the implication of that was going
Speaker 2: to be. You're pretty much stuck on Kubernetes, you know,
Speaker 2: full on there. And it's the same teams in organizations
Speaker 2: that don't have Kubernetes experience but somehow of cross plane experience,
Speaker 2: and they also don't have infrastructure experience outside of Kubernetes
Speaker 2: or outside of cross PLAYE.
Speaker 5: I just I fear. I fear those organizations.
Speaker 6: Yeah, and I think there isn't a great answer there. Right,
Speaker 6: It's like, hey, either you continue down that path and
Speaker 6: you upscal you you try and make it as little
Speaker 6: as painful as possible. I think one of the things
Speaker 6: is like probably there's a new pricing model with that
Speaker 6: Upbound has introduced where cross Plane is now if you
Speaker 6: want access to their providers like the them, you need
Speaker 6: to pay at least one thousand dollars a month. I
Speaker 6: think that's like newer versions of their providers like maybe
Speaker 6: three or six months or something like that, which was
Speaker 6: kind of mind boggling to me. So I think you
Speaker 6: need to be you know, you need to accept that. Hey,
Speaker 6: if you've made that poor technology decision, you you either
Speaker 6: need to learn you need to migrate away from it,
Speaker 6: or you need to like go further into it. You know,
Speaker 6: you need to lean into it, which would if you
Speaker 6: have the expertise, maybe you can make that work. I
Speaker 6: think that it's still probably going to be painful, but
Speaker 6: I think you could probably continue to polish to bring
Speaker 6: bring it back to our earlier conversation. I like.
Speaker 2: I like that perspective. I think that's a good one.
Speaker 2: It's that you're in a problematic spot. You there is
Speaker 2: no there's no world where you don't spend more resources.
Speaker 6: Uh.
Speaker 2: It doesn't just magically get better. And you can either
Speaker 2: go deeper on it, uh, you know, level up your
Speaker 2: team's experience, utilize the technology the way it's supposed to,
Speaker 2: or pick a better pick a better answer. And I
Speaker 2: think a lot of people don't want to hear that answer.
Speaker 6: Yeah, we had a client they had built their huge wrapper,
Speaker 6: a typeescript rapper. They were they were a typeescript shop.
Speaker 6: They had a huge mono repo. It was kind of
Speaker 6: a thing of beauty. I think they were in the
Speaker 6: one hundred thousand plus pull requests count.
Speaker 4: But the.
Speaker 6: Thing they had done was they built a big typeescript
Speaker 6: wrapper around terror.
Speaker 5: Form and.
Speaker 6: It got complex. They were doing a ton of code generation,
Speaker 6: they were doing a ton of stuff that I was like, guys,
Speaker 6: come on, and they knew it too.
Speaker 5: They knew it was painful to them. They like they
Speaker 5: were like, hey, what do we do with this? Do
Speaker 5: we keep going?
Speaker 6: And our advice, you know, after we did an audit
Speaker 6: for them and then kind of just did some guidance
Speaker 6: sessions for a few months later, and our advice was like, no,
Speaker 6: you need to pull everything out, Like we need to
Speaker 6: get away from this because you're just going to keep
Speaker 6: building complexity and your engineers that you're hiring are not
Speaker 6: going to know that complexity. They're going to come in
Speaker 6: and say, hey, I know Terrorfarm, I can do this,
Speaker 6: and then no, they don't that because there's so many
Speaker 6: devils in the details. You've built so many layers of abstraction.
Speaker 6: A lot of the time is keep it simple. Stupid
Speaker 6: is a beautiful saying. To continue to repeat. So yeah, yeah, a.
Speaker 3: Lot of silly things. But like, I don't know.
Speaker 4: The thing that I like about terraform is it's just
Speaker 4: a fancy makepile, so I can't imagine throwing anything else
Speaker 4: on top of that besides making it like it get template,
Speaker 4: like I do that a lot, where it's it's like
Speaker 4: my template freepo, or I'll use like cookie cutter or
Speaker 4: something to generate the tf bars pile.
Speaker 5: But that's well, that's so I sort of get it.
Speaker 2: And I think where it came from for me is
Speaker 2: that originally things like terror gront needed to exist because
Speaker 2: of lack of workspace support, or lack of environmental variable support,
Speaker 2: or lack of good loop support within And I hesitate
Speaker 2: to call it terraform because now we have open TOFU
Speaker 2: and I'm now I need something that groups all the
Speaker 2: HCl language support together so I don't have to pick
Speaker 2: one word over the other one. I mean, I just
Speaker 2: want to see open TOFU Terraform's done for me, agree,
Speaker 2: So and maybe I want to get your opinion on
Speaker 2: that too, because I think that's that's a good perspective
Speaker 2: are I sort of get it, And actually with terrorform,
Speaker 2: with TF. Now you have the CDK as well, which
Speaker 2: is at least blessed version, but at least for me,
Speaker 2: I prefer the thing that's more declarative. Like I feel
Speaker 2: like that's sort of the point, is declarative infrastructure rather
Speaker 2: than programmatic infrastructure creation, because we had that with things
Speaker 2: like Puppet and Chef and it did not it did
Speaker 2: not go over well. But so I'll ask you, Matt,
Speaker 2: you know open TOFU or terraform.
Speaker 5: We're if you see any of my content, if you
Speaker 5: see our blog posts.
Speaker 6: We're big open TOFU folks. I have talked it open
Speaker 6: tofu North America. We've migrated five clients to open Tofu
Speaker 6: six and we're I honestly believe in the whole thing,
Speaker 6: not only just from the open source perspective and the
Speaker 6: fact that Hashi Corp. Did a rug pull, but because
Speaker 6: they're they're innovating, may be a bit better, right, Like
Speaker 6: they have new features that I'm like pretty excited about.
Speaker 6: And I like that they have a slack community and
Speaker 6: people are really active in it. I like that they
Speaker 6: are supporting their their community and being really on.
Speaker 5: Top of it. There's a lot of really good engineers
Speaker 5: on that team.
Speaker 6: I've gotten to, you know, go out and have have
Speaker 6: a beer with with Christian, who's the team lead, and
Speaker 6: I really like the guy. So I think that outside
Speaker 6: of even the license change, I would say I'd be
Speaker 6: going towards open TOFU. But if you're on terraform today,
Speaker 6: the biggest thing I always say this, it comes down
Speaker 6: to optionality. When you want to go and automate your terrorform,
Speaker 6: you either have on terraform, you have the option of
Speaker 6: open source tools like Atlantis. You have the option of
Speaker 6: writing earned pipes, which we highly recommend or highly don't recommend,
Speaker 6: recommend against.
Speaker 5: And then finally you have tear from Cloud. Tear from
Speaker 5: Cloud not a bad product.
Speaker 6: It does what it needs to do, but it is
Speaker 6: five to ten times more expensive than its competitors.
Speaker 5: And that is the big rub.
Speaker 6: Right, you have a product in the space and it's
Speaker 6: the only product you can choose and pay for and say, hey,
Speaker 6: we have a vendor that helps us manage the complexity
Speaker 6: of all of our infrastructure, but it's five to ten
Speaker 6: times more expensive than everybody else. Like that's it's a
Speaker 6: really hard pill to swallow. So I think that open
Speaker 6: TOFU gives you a way out of that, and that's
Speaker 6: one of the main reasons that we tell people to
Speaker 6: go that route.
Speaker 2: See, I have my fingers crossed that will finally get
Speaker 2: a switch for every single resource that allows us to
Speaker 2: turn it on or off without abusing the count variable.
Speaker 6: Interesting, why do you dislike count? Well, do you just
Speaker 6: want like an enabled flag?
Speaker 5: Yeah?
Speaker 2: I do just want an enabled flag. The number one
Speaker 2: reason I dislike it is, besides all the linting problems,
Speaker 2: is it converts your resources from a single into an
Speaker 2: array with a single object, and then if you want
Speaker 2: to turn it off, you can't like remove the count
Speaker 2: once it's true, Like, you can't pull that out and
Speaker 2: just have everything work.
Speaker 5: I get what you're saying.
Speaker 6: So there is now the moved block which allows you
Speaker 6: to like change the path of something within the state file,
Speaker 6: which can save you there.
Speaker 5: You know, it can make it so that, hey, you.
Speaker 6: Can add count to a resource even if it didn't
Speaker 6: have it before, and not have it destroy and then
Speaker 6: recreate that resource still pain.
Speaker 5: I get what you're saying.
Speaker 6: Maybe there should be some you know, smarts that gets
Speaker 6: built into that, but not really.
Speaker 2: Want Yeah, I mean you really you really want your
Speaker 2: tools to enable a pit of success and I feel
Speaker 2: like this is one of the things that is for
Speaker 2: sure a pedo failure and tricks people up. And yeah,
Speaker 2: there's ways around it, for sure. But the last thing
Speaker 2: I want to do is like you're, oh, yeah, let
Speaker 2: me put an extra ticket on our board for every
Speaker 2: single infrastructure change, just so someone can go back and
Speaker 2: write to move block and then delete the move block
Speaker 2: when they don't need it anymore.
Speaker 6: It's yeah, no one's gonna do that work, I hear you,
Speaker 6: And I wonder if they could build that.
Speaker 5: I don't know. I'm going to look up if there's
Speaker 5: an issue in the open tofu for this.
Speaker 2: I will put my thumbs up on it. I'm not
Speaker 2: going to do that tough for development myself, but I'm
Speaker 2: happy to use my very expensive thumbs up button to
Speaker 2: so expensive.
Speaker 5: Yeah yeah.
Speaker 6: I think one of the great things about open tofu
Speaker 6: is that they are being very community driven in terms
Speaker 6: of what they work on, so those thumbs up matter
Speaker 6: a lot. Where they have a board an issue that's
Speaker 6: like the top of their issue list that just lists
Speaker 6: all the issues that have gotten a certain number of
Speaker 6: thumbs up, and they're saying, hey, we're going to work
Speaker 6: on the top one and that is that's really cool
Speaker 6: because hey, we have a say, I think a lot
Speaker 6: of the a lot of the problems with terraform too.
Speaker 6: We're around we as a community where you know, banging
Speaker 6: the gavel like, hey, we need this thing, we need
Speaker 6: the thing, we need this thing, and just weren't getting
Speaker 6: anywhere with it, and open Tofu has just kind of
Speaker 6: flipped that.
Speaker 1: So for sure, Yeah, no, I think that the key
Speaker 1: driver behind that is Hashi Core had to satisfy the board,
Speaker 1: you know, whereas open Tofu has to satisfy the end users.
Speaker 5: Yeah.
Speaker 6: Yeah, it's a shame that Hashikor went public.
Speaker 5: I think they had some great leadership.
Speaker 6: And they did what companies do, which is you get
Speaker 6: to a certain point and everybody wants to make money
Speaker 6: off of your hard work.
Speaker 5: And I don't blame them for that, I really don't.
Speaker 6: But I think being a public company is brutal and
Speaker 6: you know, it's just rough.
Speaker 5: It's a shame.
Speaker 1: Now that is. Having spent my career in startups, I
Speaker 1: can't imagine in twenty twenty five why anyone would take
Speaker 1: their company public if you really believe in the mission
Speaker 1: of your company and the end users who are supporting
Speaker 1: your product. If that's your focus, there's I don't see
Speaker 1: a valid argument to take the company public.
Speaker 2: I have to imagine that it's not usually from like
Speaker 2: totally private to IPO like. It's usually through the VC chain,
Speaker 2: which is all about extracting the most money out of
Speaker 2: that thing and scamming the most number of people in
Speaker 2: that pyramid scheme until you know you can get it
Speaker 2: out to the public, and then from there the shareholders
Speaker 2: are very myopic, focused on just the next quarter and
Speaker 2: don't realize that having huge impacts on how the business
Speaker 2: actually works and the perception of the brand has a
Speaker 2: long lasting impact to the bottom line. I do have
Speaker 2: I do have a question of my own. Maybe it's
Speaker 2: just something that you've thought about a little bit. One
Speaker 2: of the problems that we have in our space. So
Speaker 2: for our product, it's logging and access control that we
Speaker 2: provide for our customers, and there's a white labeling experience.
Speaker 2: Now there's a whole part of the infrastructure which is shared,
Speaker 2: but then there is a bunch of pieces which are
Speaker 2: per customer, per account for each one of our customers,
Speaker 2: and sometimes they have more than one, and we're in
Speaker 2: this weird area where we don't know whether or not
Speaker 2: infrastructure as code makes sense for that, and whether or
Speaker 2: not we should be rolling out either. I mean, for
Speaker 2: this we're actually using CloudFormation templates and AWS, but we
Speaker 2: could just easily switch over to open TOFU whether or
Speaker 2: not that even makes sense, or whether or not running
Speaker 2: through this list of resources that a new accounts need
Speaker 2: is a programmatic process, or whether or not it should
Speaker 2: be declarative and infrastructure. And I know we're not the
Speaker 2: only company with this problem. We're not a special snowflake here,
Speaker 2: So I don't know if this is something you've seen
Speaker 2: before and have some wisdom to share.
Speaker 6: Yeah, I have some wisdom we have. Our most recent
Speaker 6: case study was with a company called power Digital. For
Speaker 6: each of their customers, they're basically spinning up a small
Speaker 6: data warehouse in Snowflake that connected data wus and a
Speaker 6: new GitHub repository.
Speaker 5: And like did a bunch of things.
Speaker 6: And they had five hundred customers, right, so they were
Speaker 6: doing this constantly.
Speaker 5: And really what.
Speaker 6: It comes down to is you you do probably want
Speaker 6: that in infrastructure is code because you want to manage
Speaker 6: the life cycle of that, right, you might change that
Speaker 6: that architecture for that client. Infrastructure that you're like just
Speaker 6: stamping out every time you get a new one. You
Speaker 6: might change a little thing, right, You might you might
Speaker 6: do something to it, you know, new tomorrow, and you
Speaker 6: want to roll that out across everyone. Infrastructure is code
Speaker 6: is great for that. You also might, you know, if
Speaker 6: there's any cost associated with those resources, you might want
Speaker 6: to destroy that infrastructure when that client goes away or
Speaker 6: customer goes away. I think that infrastructure is code makes sense.
Speaker 6: The point problem is that you just want that to
Speaker 6: be a highly automated, low touch workflow. Uh. And that
Speaker 6: is the point that becomes a rub, is that you
Speaker 6: need to kind of come at it from this perspective
Speaker 6: of all right, we need to be we need to
Speaker 6: have our infrastructure as code to be on such rails
Speaker 6: that it needs to get indicate and it needs to
Speaker 6: apply automatically, and it needs to do all of that
Speaker 6: very seamlessly so that we're not needing to.
Speaker 5: Think about it too much.
Speaker 6: We built that for our other clients, So if you
Speaker 6: want to talk one on one afterwards, I more than
Speaker 6: happy to give you all the the info on how
Speaker 6: that that worked.
Speaker 5: But yeah, I think that.
Speaker 6: Infrastructure should be a thing that we create provision, we
Speaker 6: can change if.
Speaker 5: We need to, and we can destroy it if we
Speaker 5: need to.
Speaker 6: And if we just do that with you know, calling
Speaker 6: the a ws STK or we.
Speaker 5: You know, do something.
Speaker 6: That that's the A w U S CLI bash script
Speaker 6: or whatever it is. Those types of things, they can
Speaker 6: be a they feel very programmatic and they feel like
Speaker 6: a really good solution at the time, but then you
Speaker 6: don't have as much control in the long term.
Speaker 5: So yeah, that's my thought.
Speaker 1: Cool, Yeah, I want to switch topics just a little bit,
Speaker 1: or not topics, but switch trajectory. Maybe it's a better
Speaker 1: word for someone who's listening to the podcast. Considering the
Speaker 1: consultant versus career DevOps approach, what's your your bullet lists
Speaker 1: of pros and cons of each?
Speaker 6: The pros list is high, is long in terms of
Speaker 6: just like you know, being a consultant, particularly owning my
Speaker 6: own business is very very advantageous to the rest of
Speaker 6: my life in terms of I set my own schedule,
Speaker 6: I decide who I work with.
Speaker 5: You know, I get to build a team, which is
Speaker 5: really nice and it's you know, they're they're my.
Speaker 6: People, and you know, I enjoy helping them grow as
Speaker 6: engineers and you know in their career. There's there's a
Speaker 6: lot of things on the pros list. What's more interesting
Speaker 6: probably is the cons list. The the cons I think
Speaker 6: come from you know, there's always going to be some
Speaker 6: level of like feast or famine. You know, I've been
Speaker 6: doing this for a long time and I still you know,
Speaker 6: find myself in are we gonna get a new client
Speaker 6: next corner? And usually it all works out right, Like
Speaker 6: you know, there's some you know, serendipitous occasion. I've never
Speaker 6: you know, had to let anybody go because we didn't
Speaker 6: have enough work. I've never had to you know, be
Speaker 6: uh out of work for for many months at a time.
Speaker 6: You know, I've had it well. But like, hey, if
Speaker 6: you're just starting and you don't have a network, you
Speaker 6: might go for a certain six months without you know,
Speaker 6: picking up a client and actually having work. So I
Speaker 6: think that understanding that you're you're on your own and
Speaker 6: you know your your livelihood can depend on that is
Speaker 6: its own like source of stress, and I think that
Speaker 6: there's something there.
Speaker 5: I think you also really need to be able to
Speaker 5: talk to people problems.
Speaker 6: A lot of the times I'm talking to clients and
Speaker 6: letting them know that I'm I'm there as an individual
Speaker 6: to help them, and I can see that they're stressed.
Speaker 6: I can see that we are are trying to solve
Speaker 6: some like deeper emotional need and you need to have
Speaker 6: those like soft skills at a deep level to help
Speaker 6: them navigate the right decision and get that stress off
Speaker 6: their plate. And I think those are two things that
Speaker 6: a lot of people that are like really excited about consulting,
Speaker 6: they don't think about those two things.
Speaker 5: Consultants are not the best engineers. I'll tell you that.
Speaker 5: I think that the.
Speaker 6: You know, I definitely wouldn't consider myself a you know,
Speaker 6: a wizard code er. I think I can write cleaning code,
Speaker 6: and that's like part of a craft that I really love.
Speaker 6: But I definitely have worked with a lot of smarter
Speaker 6: people in my career, and they're off being you know,
Speaker 6: senior engineers or above elsewhere at companies that just tell them, hey,
Speaker 6: we need to build this thing. They're not trying to
Speaker 6: solve those people problems. They're not trying to navigate those
Speaker 6: the intricacies of hey, this client you know, consultant relationship.
Speaker 5: So I don't know, does that answer your question?
Speaker 1: It does? Yeah, And I think It highlights one of
Speaker 1: the things that there's almost like a translator skill required
Speaker 1: to be a successful consultant, because your clients typically don't
Speaker 1: come to you describing a technical problem. They come to
Speaker 1: you describing some impact that's hattening to their business, and
Speaker 1: you have to be able to translate that talk with
Speaker 1: a mass follow up questions and then translate that into
Speaker 1: a technical problem that you can solve.
Speaker 5: For sure. Yeah, a lot of it is like can
Speaker 5: I repeat that back to you?
Speaker 6: Like this is what I'm hearing, right, And a lot
Speaker 6: of things come back to that. You have to be
Speaker 6: able to read between those lines and kind of understand
Speaker 6: at a root level, like what's the actual issue here?
Speaker 6: They're telling you one thing, but it's something else, and
Speaker 6: that's a skill.
Speaker 1: Yeah, yeah, can I repeat that back to you? Has
Speaker 1: probably got to be one of the most valuable phrases
Speaker 1: in humanity.
Speaker 6: Yeah, let's make sure we're on the same page here.
Speaker 6: That's the way it goes.
Speaker 2: I think there's a maybe an additional connection here, which
Speaker 2: you brought up early on who your decisions makers are.
Speaker 2: If you're a consultant, you're selling your services to someone
Speaker 2: they have to have money, like an engineer probably isn't
Speaker 2: going to make the decision on paying you to come
Speaker 2: in and help, which means you're talking to the like
Speaker 2: you said, directors of technology and higher and what problems
Speaker 2: do they think they have?
Speaker 1: Right?
Speaker 2: Uh, and they're not like, oh, well, you know, we
Speaker 2: have some terriform modules that don't work, right, you know,
Speaker 2: it's probably not what they're coming and saying.
Speaker 5: No matter.
Speaker 1: Yeah.
Speaker 6: And and the way we approach that is that, hey,
Speaker 6: I want to we want to come in and we
Speaker 6: want to solve both problems. Right, we want to solve
Speaker 6: the leadership's problems that are typically around scale workflow decreasing
Speaker 6: you know, engineering costs or maintainability costs.
Speaker 5: We also want to solve the.
Speaker 6: Ergonomic problems that the you know, actual people who are
Speaker 6: writing the infrastructure's code or the application engineers or are
Speaker 6: dealing with.
Speaker 5: So what we do is, well, typically.
Speaker 6: We have an audit and you know, more and more
Speaker 6: we're we're we're selling that audit as like are our
Speaker 6: way to really help understand an organization and get them
Speaker 6: the right prescriptive guidance that they need. And as part
Speaker 6: of that we and we you know, interview engineering leadership.
Speaker 6: We also engineer interview a bunch of the infrastructure engineers
Speaker 6: and application engineers. We make sure that we're kind of
Speaker 6: holistic in approaching the problem, not just from what we're
Speaker 6: being told, but making sure we're uncovering what else is there,
Speaker 6: because we don't want to, you know, leave any turn
Speaker 6: like rock unturned.
Speaker 5: It's important right on.
Speaker 1: Just feel like a good time to move on to picks?
Speaker 2: Yeah, I think so let's do it all right?
Speaker 1: Cool, Jillian, You've been out for a couple of weeks,
Speaker 1: so I can only assume that you have been diligently
Speaker 1: researching your next pick. So I'm excited to hear what
Speaker 1: you got this time.
Speaker 4: I'm just going to keep going with the shameless self
Speaker 4: promotion until I get more clients.
Speaker 3: This is what I'm going to be doing.
Speaker 4: You know, that's a bit on topic of the show,
Speaker 4: so you know, if you've been listening to the show lately,
Speaker 4: you know, I really like AI and LMS and all
Speaker 4: of those kind of tools. I do have a service
Speaker 4: to get all of that set up for you on
Speaker 4: your own AWS account. This is mostly geared towards data
Speaker 4: science companies, because if you're not a data science company,
Speaker 4: I don't really know what to do with you. Frankly,
Speaker 4: if you need kind of a junior, maybe grad student
Speaker 4: level research assistant to go querying your papers, querying structured
Speaker 4: and unstructured data sets. We've got more data sets being
Speaker 4: added every day so far. The top one is open
Speaker 4: targets for drug discovery. But I've had a whole bunch
Speaker 4: of single cell spatial TRANSCRIPTO mix. Like there's just people
Speaker 4: are starting to do some pretty like cool and wild
Speaker 4: things with it, which is exciting. So if you're interested
Speaker 4: in that, you can go to my website. It's a
Speaker 4: dabbleodevops dot com slash ai and you'll see that there's an.
Speaker 3: LM data discovery tool this week.
Speaker 4: The page is in fact up last time it may
Speaker 4: or may not have been, I'm not sure, but this
Speaker 4: is okay.
Speaker 3: There it exists.
Speaker 1: Open research for drug discovery. Sounds like my time in
Speaker 1: high school.
Speaker 3: Yeah, yeah, all right, that's good.
Speaker 4: It's a little bit too real for me to say,
Speaker 4: Will and my and my teenagers, so we're just we're
Speaker 4: right on over that.
Speaker 3: You can't do that this morning.
Speaker 2: I think I think that part may actually have to
Speaker 2: be cut from the from the episode before.
Speaker 4: I'm not sure if like anything gets cut from these episodes.
Speaker 3: I don't know.
Speaker 4: I've always wondered if the things that we can say
Speaker 4: and still have sponsors or do we just have sponsors
Speaker 4: at all for this show?
Speaker 2: Okay, we definitely have to cut that part, so I'm
Speaker 2: going to market the clip here at this point.
Speaker 6: And it was good though, I once it clicked, I
Speaker 6: got it as that was a great one.
Speaker 1: It's like a it was a joke grenade where you
Speaker 1: pull the pin and throw it out and it's three
Speaker 1: to five seconds before it actually lands. Yeah, all right, Warren,
Speaker 1: where'd you bring for a pick this week?
Speaker 5: Yeah?
Speaker 2: Uh so, I'm gonna be a show for our conference.
Speaker 2: I absolutely love DevOps Days. I think it's one of
Speaker 2: the best set of conferences anywhere in the world. They're
Speaker 2: volunteer run and my CEO will be giving the keynotes
Speaker 2: speak talk at devop Days Zurch this week. It's all
Speaker 2: about just some thinking at authors and it's a it's
Speaker 2: actually a great talk.
Speaker 1: Right on nice Yeah, I agree with you on devop Stays.
Speaker 1: Devop Stays Amsterdam is probably one of the best I've
Speaker 1: been to because those guys they just go out of
Speaker 1: their way so that when you leave all of your
Speaker 1: swag reminds you that you were in Amsterdam.
Speaker 5: You know.
Speaker 1: It's very very like cultural and historic and authentic and
Speaker 1: super cool and.
Speaker 5: Thoughtful, very cool.
Speaker 6: Yeah, and I'll double plus one that with saying that
Speaker 6: devop Stays Denver has been there's a really good community
Speaker 6: behind it, really good group of folks, and their talks
Speaker 6: are awesome and.
Speaker 5: It's just great community.
Speaker 6: If people have not been to their local chapters devop Stays,
Speaker 6: they're they're missing.
Speaker 5: Out right on.
Speaker 1: All right, Matt, would you bring for a.
Speaker 6: I have a book I had I had a hard
Speaker 6: time picking, but I am obsessed with this series called
Speaker 6: Dungeon Crawler Carl h It is a fantasy sci fi series.
Speaker 5: They're on book seven now.
Speaker 6: And you might scoff at the name and you might
Speaker 6: think that that's not for you, And I will tell
Speaker 6: you that I'm nine for ten on friends that I've
Speaker 6: recommended it to and had them go wow, I now
Speaker 6: have a new favorite book that you know.
Speaker 5: It's really consistent. Yeah, yeah, that guy out of my life.
Speaker 6: Fantastic, really witty, really funny. There's a talking cat. You
Speaker 6: will enjoy it if you read it.
Speaker 1: Just the name Dungeon Crawler Carl sounds. It sounds like
Speaker 1: the hero from an eighties video game. That's such a
Speaker 1: cool name.
Speaker 5: Yeah, it's Goofy.
Speaker 6: I think that a lot of people have an issue
Speaker 6: with the name, but you read it, you'll enjoy it.
Speaker 2: It makes me think of this like the hardest video
Speaker 2: game I've ever played, and that's not Dark Souls or
Speaker 2: Ninja Guide, and it's something called Leicester the Unlikely for
Speaker 2: Super Nintendo.
Speaker 4: It's almost like.
Speaker 2: An eighties game. You are literally playing just a regular
Speaker 2: human who has to navigate quite challenging set of circumstances.
Speaker 2: Like imagine you're in a fantasy world and you don't
Speaker 2: have any superpowers and you can't jump high and if
Speaker 2: you fall off a rock you will die.
Speaker 5: That is this game.
Speaker 2: And you get abducted by cannibals and have to like
Speaker 2: steal keys and unwhittle ropes in order to get out,
Speaker 2: and it's it's quite the challenge because there is no
Speaker 2: help at all while you're playing, so you will die
Speaker 2: over and over again.
Speaker 1: Nice.
Speaker 5: Those games were just brutal. Yeah.
Speaker 6: I used to have a I forget what it was,
Speaker 6: one of the handhelds back in you know, when I
Speaker 6: was a kid. I feel like it was made by
Speaker 6: Sega Games anyway. Yeah, the game gear, Yeah, I had
Speaker 6: the game gear.
Speaker 5: I had save.
Speaker 6: I would play a game for ten hours and I
Speaker 6: couldn't save it and I was like, oh my.
Speaker 5: God, I drove me insane. I think that things were
Speaker 5: a little bit different back then.
Speaker 3: With no save.
Speaker 4: But see, this is why you just play cute c
Speaker 4: SIM games where you can't die, Like if you guys
Speaker 4: are just playing Disney Dream like BALI, this is not
Speaker 4: a problem.
Speaker 2: That's pick next week.
Speaker 3: I think I really picked it, but I probably probably.
Speaker 5: Because I want to hear about it.
Speaker 3: It has like my favorite Disney ships.
Speaker 4: It's Malipicent and Hades, and I just I love that pairing.
Speaker 3: It's so great.
Speaker 1: Well, so my pick is going to be kind of
Speaker 1: letdown after that conversation because I'm picking seat covers.
Speaker 3: So I like covers.
Speaker 5: I like seat covers.
Speaker 1: Yeah, so I just got a new set of seat
Speaker 1: covers from a company called Sheer Comfort. S h e
Speaker 1: A are so like shearing a sheet but shere comfort.
Speaker 1: And they've got so many different choices for seat covers.
Speaker 1: And you know, the seats in my truck they were
Speaker 1: getting like mud and dirt and stuff. On them, and
Speaker 1: I thought, I just can't do this to the seats,
Speaker 1: so I bought these seat covers. They're super cool, really
Speaker 1: really well made, pretty easy to put on, look great
Speaker 1: once they're on, and then it's got all like the
Speaker 1: nice features, like they're specific to my model of trucks.
Speaker 1: So like I've got a Ford truck, So it's got
Speaker 1: these little loop pandles that you have to pull to
Speaker 1: get the seats to fold down, so it's got the
Speaker 1: cutouts for that so that that works natively, and it's
Speaker 1: got you know, it's built so that the side restraint
Speaker 1: airbags still work, which may or may be cool at
Speaker 1: some point in my life. But a lot of little
Speaker 1: features like that and just really well built. So yeah, sure,
Speaker 1: comfort seat covers. If you're looking for a set of
Speaker 1: seat covers. And then they know they sent with the box,
Speaker 1: they sent like a product catalog, which kind of shocked me,
Speaker 1: and it's a huge product catalog. So they also make
Speaker 1: in addition to seat covers, they make like full I
Speaker 1: don't even know what you call them. If you wanted
Speaker 1: a blanket for your car truck, they have like shaped
Speaker 1: covers for those, or if you have to put a
Speaker 1: cover on your RV. They make a full custom fit
Speaker 1: cover to fit your RV. Just a lot of things
Speaker 1: that I didn't even know existed that I found out
Speaker 1: because they included the catalog.
Speaker 2: I think, will your pick next week? Is like you're
Speaker 2: already thinking about the McMaster car product, right, Yeah.
Speaker 1: For sure, this is the master the McMaster car catalog
Speaker 1: of seat covers and car wraps.
Speaker 3: But are they well, if it's like sheer, like sharing
Speaker 3: a sheep.
Speaker 1: That is one of the options you can get the
Speaker 1: sheepskin seat covers, you know, go straight back to the
Speaker 1: eighties and put them in your Camaro with the T tops.
Speaker 1: I didn't go that route. I went with a it's
Speaker 1: like almost like a neoprene thing that's not going to
Speaker 1: show any mud or dirt or coffee that I spill
Speaker 1: on it.
Speaker 4: I didn't know people had like well seat covers, And
Speaker 4: now that's a new existential dread for me to have
Speaker 4: that anytime I get into somebody's car, I'm gonna wonder,
Speaker 4: oh no, is this wall?
Speaker 3: And am I going to die?
Speaker 1: But well, I think you're pretty safe as long as
Speaker 1: whoever you're with isn't wearing like a mullet and a handlebar,
Speaker 1: mustache and a camaro. You're probably gonna be okay, that's true.
Speaker 3: I can probably self select for these things.
Speaker 1: Yeah, I think so. I think it's pretty safe. All right.
Speaker 1: Now that I've finished offending everyone on the list, I
Speaker 1: think we've got ourselves an episode. Matt, thanks for joining us. Man,
Speaker 1: it's been great talking to you.
Speaker 4: Yeah.
Speaker 5: It's a really good conversation. Folks appreciate it. Yeah, good questions,
Speaker 5: good topics.
Speaker 1: Yeah. So be sure and check out Matt's website master
Speaker 1: points masterpoint dot io.
Speaker 5: Is that right, Yes it is.
Speaker 1: Yeah. So if you need consulting services or if you are,
Speaker 1: you know, wanting to try your career out, check it
Speaker 1: out and see if he's hiring. Arren Chillian. Thank you
Speaker 1: both for being on the show with me today. Thank you,
Speaker 1: and for everyone listening. Thanks for listening, and I'll see
Speaker 1: everyone next week.