0:06
Hey, I'm Brian Teller. I work in DevOps and SRE,
0:10
and I run Teller's Tech. Ship It Weekly is where
0:13
I filter the noise and pull out what actually
0:16
matters when you're the one running infrastructure
0:19
and owning reliability. If something's just hype,
0:23
we'll call it hype. If it changes how you operate,
0:26
We'll talk about it. Most weeks, it's a quick
0:28
news recap. In between those, I drop interview
0:31
episodes with folks across the DevOps world.
0:34
This is one of those interviews. Today, I'm talking
0:37
with Maz Islam, aka DevOps with Maz. He's a UK
0:41
-based DevOps engineer and puts out really solid
0:45
practical content on both YouTube and LinkedIn.
0:49
Today, we're going to hit the why behind DevOps,
0:51
how to keep leveling up without drowning in tools,
0:53
and what agentic AI and MCPs might mean for real
0:57
teams. So Maz, can you go ahead and introduce
0:59
yourself? Say hi to the podcast listeners. Yeah.
1:02
Hey, podcast listeners. My name is Maz and I
1:05
host my YouTube channel, DevOps with Maz. So
1:08
I'm a DevOps engineer by trade. And yeah, in
1:11
my free time, I like to kind of make content.
1:13
and educate a general kind of LinkedIn audience,
1:16
anyone on social media who kind of works in a
1:19
similar industry and wants to kind of know the
1:21
kind of tutorials and kind of challenges that
1:23
those engineers face and how to overcome them.
1:26
So in short, I'm also an advocate for better
1:28
tech. Awesome. So we can find you, I guess I
1:31
should have mentioned that, sorry. We can find
1:33
you on LinkedIn, Mazerul Islam. He's Mazerul419.
1:36
And then also on... YouTube with DevOps with
1:39
Maz. So yeah, be sure to check him out. He has
1:41
a really good tutorial I just saw on your channel.
1:44
It was about, I believe, like VPC endpoints versus
1:47
NAT gateways, right? That's what you were communicating.
1:49
Yeah. Which is a great topic. It's honestly come
1:51
up in my day job many times. One of those conversations
1:54
around specifically like how to set up networking,
1:56
data transfer costs, right, is always a concern.
1:58
I think that's a really, really awesome topic.
2:01
So for folks who haven't run into your stuff
2:03
yet, what do you do day to day in your job? kind
2:08
of work on like kind of different projects so
2:10
when it comes to for example using kind of aws
2:13
centric so yeah use a lot of aws services such
2:16
as the ecs and as well as fargate specifically
2:20
i do launch and manage my own kind of ec2 instances
2:23
so um yeah i manage kind of all things server
2:26
side to do with kind of setup and configuration
2:28
and also kind of translating all those click
2:31
ops to um finally infrastructures code because
2:34
we know if we can automate it you know ideally
2:36
we should Absolutely, yeah. Less mistakes in
2:40
the pipeline there. And also talking about pipelines,
2:42
also transferring that to kind of get up. So
2:44
implementing CI, CD pipelines and making sure
2:47
that there's all kinds of considerations for
2:49
security and FinOps as well. So just measuring
2:52
how much the costs are for your resources that
2:54
are deployed. So developers at the end of the
2:56
day just have a better experience when it comes
2:58
to developing the apps and deploying them. Yeah,
3:00
absolutely. That's awesome. So what caused you
3:03
to originally start sharing? devops with mass
3:06
i know you've always been on linkedin you've
3:08
been sharing a lot of posts on there um which
3:09
are awesome which are great i'm just kind of
3:11
curious though what prompted you to create the
3:13
channel and and start sharing more yeah so it
3:16
was kind of born from a kind of struggle i guess
3:19
me personally in our in our industry when you're
3:22
in devops you have to kind of wait for a lot
3:24
of documentation um just to figure out kind of
3:27
what the answer is so for example you know i've
3:29
added i made a tutorial on terraform and had
3:32
kind of set up kind of basic uh kind of linting,
3:35
you know, using Terraform format, Terraform validate,
3:38
kind of validate configuration. You know, when
3:40
I was kind of figuring that out, how to do that
3:42
via kind of GitHub Actions, I had to wait for
3:45
a lot of documentation. For me, I feel like simplifying
3:48
it as much as you can is very, very important
3:50
in your mind. And I feel like a lot of the time,
3:53
DevOps engineers were kind of overwhelmed by
3:55
the various kind of tools and stuff and waiting
3:57
for all that documentation. essentially about
4:00
kind of simplifying the concepts and just trying
4:02
to keep uh kind of ideas as simple as you can
4:05
to be honest i noticed that the best kind of
4:07
devops engineers are the ones that can communicate
4:09
their ideas and yeah i think you're only as good
4:13
as your kind of communication uh allows you to
4:15
so i think an important part of that is kind
4:18
of just communicating and learning how to communicate
4:20
that message across and that's kind of why i
4:22
made this channel is to kind of communicate the
4:24
message that you know devops it can be tricky
4:27
but If you can figure out kind of how to wait
4:30
for your documentation and kind of know how to
4:33
be a problem solver at the end of the day, you
4:35
can actually bring solutions to life. And yeah,
4:38
that's kind of inception of the channel. Absolutely.
4:40
I agree with that. We were actually talking pre
4:42
-recording about how even just sometimes training
4:45
gives you better insight and better visibility
4:48
or understanding, I guess, around concepts that
4:51
you had, even just doing it in your day -to -day
4:53
job. I feel like presenting it to other people
4:55
lets you. get to know like different sides of
4:58
understanding. Because again, you get tunnel
5:00
vision over years and you don't necessarily think
5:02
about things from outside the box or from different
5:04
perspectives. So when you have, when you're putting
5:07
yourself in that mindset of someone trying to
5:09
learn something, right, you grow because you're
5:12
thinking about it differently than maybe you
5:14
would in your day -to -day job, just trying to
5:15
complete a task, right? Just getting A from A
5:17
to B. Now you're actually trying to, well, wait,
5:19
if I don't have any of that understanding, how
5:20
do I actually even start at A? What is A, you
5:23
know? Exactly, yeah. it all becomes like really
5:26
tricky very quickly if you're not careful. So
5:29
you always have to be kind of, say, detail -oriented,
5:32
I'd say, for sure, when you're kind of looking
5:34
at documentation and just making sure that challenges
5:37
you, any kind of assumptions you've made, you
5:39
challenge them and kind of just ask yourself
5:41
like, you know, I'm actually understanding what's
5:44
going on here or is there something that I've,
5:46
some line of code that I don't really understand
5:48
what's going on here and I really need kind of
5:50
clarification on that. So yeah, just keeping
5:53
yourself accountable at the end of the day. Absolutely.
5:55
So I'm curious what your thought is when DevOps
5:58
is actually working at a company, right? So we've
6:01
implemented it. We have a team. It's, you know,
6:04
we're still setting stuff up. Maybe we don't
6:06
have an IDP platform yet for developers. We don't
6:08
have like great CICD, but we've started implementing
6:12
some of those first steps. What changes for a
6:14
team when we have DevOps? Like once we've implemented
6:17
that for a team, what changes and what feels
6:20
different on a random Tuesday rather than just
6:21
having like a bunch of engineers shipping code?
6:24
Everybody has their own processes. What does
6:26
DevOps bring to the table? What's your thoughts
6:28
on that? Yeah, so I think that links back to
6:31
kind of the why behind DevOps. So one really,
6:36
really nice book that I've been reading that
6:37
kind of demystified that for me is called The
6:40
DevOps Handbook by Gene Kim. And yeah, it's just
6:43
a really, really good insight into how DevOps
6:45
kind of works in terms of like the business.
6:47
And for me, DevOps means breaking down a boundary
6:50
between security. developers, operations, and
6:53
kind of wider business to make sure that, you
6:56
know, developers are shipping fast in small kind
6:59
of increments, as opposed to kind of large six,
7:01
every six months they're pushing a change that
7:03
everybody knows is going to break, but they all
7:05
kind of figure out. Yeah, DevOps has kind of
7:08
completely changed the landscape. And at the
7:10
end of the day, DevOps only works if everybody's
7:13
kind of implementing it from the ground up. So
7:15
yeah, I think. One quite interesting analogy
7:18
that was mentioned in the book was about kind
7:22
of the factory floor and how DevOps is the application
7:25
of agile methodology to the kind of IT value
7:27
stream. So if you think about, say, kind of lean
7:31
manufacturing, work done in factories, for example,
7:33
previously, you know, work was done in kind of
7:35
large batches. So, you know, you'd have kind
7:38
of like all these dependencies, all these chain
7:40
of dependencies, these tasks from the... would
7:43
have come in for the cost of some other materials
7:44
being on actual factory floor and then kind of
7:47
processing and making like say 50 car panels
7:50
for example if there was a deep if you made 50
7:52
car panels at once and there was a defect in
7:55
any single one of them you have to redo those
7:56
panels all over again and just think about for
7:58
a moment you know at that time they said devops
8:00
you know if there's say a major kind of change
8:05
that you're only kind of releasing every kind
8:06
of let's say six months um if an error were to
8:09
occur you have to go back to your code base and
8:11
change everything about it and so with um lead
8:16
manufacturing and agile methodology is saying
8:18
well why don't we just break something smaller
8:20
pieces let's make like couple of car panels here
8:23
couple of doors couple of windows and then if
8:26
there's an error in any single one of them you
8:28
can just go back and make the change and it takes
8:30
like It will take significantly shorter versus
8:33
if you're making large batches of changes. And
8:36
so just think about that in DevOps, that application
8:38
of that. If we're making incremental changes
8:40
to our code, the developers are making incremental
8:42
changes and just shipping daily. It depends on
8:45
the company, of course, if they're shipping daily
8:46
or weekly, what's kind of ideal there. But if
8:49
they're shipping more often, generally it's the
8:52
case that if there's an error, they can just
8:53
go back and roll back. And that's where the whole
8:56
kind of tooling comes in. And yeah, I'm a strong...
8:59
Believe in that. You know, if we can automate
9:01
some parts of that, make developers' lives easy,
9:03
have a self -service platform, ideally, that
9:06
would be kind of the way forwards. And so to
9:08
answer your question, yes, in Teams, the DevOps
9:11
implementation looks like shipping regularly
9:13
and also ensuring that the boundaries between
9:16
kind of IT security operations and the wider
9:20
business are actually solved and everybody's
9:23
got transparency about it. Yeah, and giving the
9:25
ability for that iteration, right? That ability
9:27
to... yeah to iterate quickly um it's awesome
9:31
so if you're in a like a new org what's one tiny
9:35
change that like you could see let's say for
9:37
like a company it's very new to devops what's
9:39
the change that they could make that may be like
9:41
a big win for them i mean or a win it doesn't
9:44
have to necessarily be a big win but but a win
9:46
that could help early on in their process, if
9:48
they're very, very immature to like DevOps practices
9:51
and they're not ready to do like full, full implementations
9:54
and iterations, like they're still doing full
9:56
big release cycles. Like what's something that
9:59
they could bring early on in that process that
10:02
without having to break everything down, that
10:03
could help? Definitely say bringing in the stakeholders
10:06
very, very early into the conversation. So for
10:09
example, if there's a business change kind of
10:13
proposed, it's important you get kind of early
10:15
feedback on it. as early as possible so if you're
10:18
making kind of changes down the line to your
10:20
kind of pipeline you shouldn't you need to get
10:23
early feedback ideally in order for kind of the
10:26
stakeholder whoever the business leader is to
10:28
kind of see if they're happy with the way things
10:29
are going so having early feedback is just really
10:32
key to that process you know otherwise What it
10:35
looks like is, you know, there's complete mismatch.
10:38
Again, communication is just the biggest thing
10:39
within organizations. Obviously, as you grow,
10:42
you know, it only gets more difficult. Teams
10:44
get bigger. And, you know, there's only kind
10:46
of so much that can be handed off until, you
10:49
know, the delays. So I definitely say ensuring
10:53
you get early feedback from stakeholders is very,
10:57
very important. Yeah, I've definitely worked
10:59
at companies where there was a DevOps team, but
11:02
there wasn't. uh buy -in by leadership really
11:05
on devops agile practices right they were from
11:08
the older older uh shipping you know batch releases
11:12
and not having like mature cd pipelines not having
11:16
iac um all click ops right because they didn't
11:20
see the value they didn't understand the concept
11:22
of slowing down to be able to speed up down the
11:24
road or improve and refine over time. They were
11:27
looking at the, and I'm sure that's true in like
11:29
a startup culture too, right? We want to do ClickOps
11:31
right away to get things, you know, get our MVP
11:33
up. But at some point we need to mature those
11:35
practices. We can't just, you know, cowboy every
11:38
day. So if you had to say DevOps in one sentence,
11:42
what is it really? Like, what is DevOps? I'd
11:46
say just, it's just communication. Yeah, that's
11:49
fair. It's literally just communication because
11:52
before, previously, you'd have all these, the
11:55
IT team, operations team, devs, as well as security,
11:59
they'd all be kind of siloed together and the
12:02
handover process rather, you know, like say,
12:06
for example, if you're working within kind of
12:08
DevOps and you kind of get like a ticket coming
12:12
in to create like additional couple of users,
12:15
you don't know. where this has come from or why
12:17
that is. Let's just say there's a stakeholder
12:21
kind of up within the business who's kind of
12:24
requested something like that and there's no
12:26
kind of transparency or any idea really of how
12:29
or where this kind of came from. So DevOps basically
12:33
breaks down all those communication barriers
12:36
by making sure, firstly, everybody's work is
12:38
transparent. Secondly, ensuring that there is
12:42
a self -service, regular... for developers to
12:48
just develop code. At the end of the day, developers
12:51
just want to get on with producing code and making
12:54
changes to their apps and just shipping. We want
12:58
to make that as easy as possible in the DevOps
13:00
industry. And so I feel like that's the main
13:02
purpose is just breaking down that communication.
13:03
Communication is key, really. Yeah. And I think
13:06
your point around making it easier for developers,
13:09
I think that's at least my understanding really
13:11
behind what... like platform engineering is.
13:14
And obviously, like, right, we've gone from SysOps
13:16
to DevOps to SRE. Now it's platform engineering.
13:20
But I do, there's nuanced differences to all
13:23
of it, right? To all the different titles and
13:25
the different methodologies and ideologies behind
13:27
those different concepts. But I do think platform
13:30
engineering, like the idea is building that IDP
13:33
for development team, letting them be self -service.
13:38
building like a service catalog, making sure
13:40
that they have those tools. And not that DevOps
13:42
doesn't incorporate that, but DevOps is almost
13:45
more, it's almost too wide of an idea of what
13:48
all encompasses. You go to some companies, you're
13:50
just a cloud engineer. You don't actually do
13:52
any quote unquote DevOps day to day work. You
13:56
go to another company, it may be all building,
13:58
you know, backstage and building out that IDP.
14:01
You go to a different company and it may be.
14:03
actually doing like CICD and improving like the
14:06
developer experience and building out those pipelines
14:08
and making them more robust and having better
14:11
status checks so, you know, the PRs can be merged
14:14
quicker and actually speed up that development
14:16
cycle. And that's like what I find at least is
14:19
like it's different for everyone. So it's hard
14:21
to pin down. You could even go back to the whole
14:23
idea that like DevOps is not a title, right?
14:25
It's an actual idea. It shouldn't be a title
14:28
at least. We've lost that war. I certainly, I
14:31
agree with that. I'm a DevOps engineer by trade.
14:33
I get that. But it's just funny to see like the
14:36
evolution of what DevOps means. Yeah. It's honestly
14:40
like, I think in the UK at least that we, it
14:43
just changes from company to company really.
14:44
You end up wearing different hats throughout
14:46
your career. And yeah, it just is a whole Pandora's
14:49
box really, the titles and stuff, isn't it? So,
14:52
yeah. No, for sure. So we both build. training
14:55
for people that are either in DevOps or looking
14:58
to get into DevOps. And so what would you say
15:01
to someone who's either aspiring to be a DevOps
15:04
engineer, maybe they're a back -end engineer,
15:07
maybe they're a front -end engineer and they're
15:08
looking at DevOps, they'd say, wow, I really
15:10
like that side of the development cycle. I want
15:14
to do more with that. What would you tell someone
15:16
as far as like keeping up with tools? Because
15:18
I find keeping up with tools is hard. Right.
15:21
I've been in the industry for like 25 plus years.
15:24
It's still hard because everything changes all
15:26
the time. My last episode was literally about
15:28
like it changed halfway through writing the episode
15:31
because GitHub came out with a new release around,
15:33
you know, like, oh, we're rolling this change
15:35
back now. Right. So what do you say? Like, what's
15:38
your thoughts on that? What do you do to stay
15:40
up to date with tools? What's your thoughts on
15:42
that? I'll definitely say, speak to other people
15:46
within your industry. So just like how we reached
15:49
out to each other today. You know, I, for example,
15:52
when I found out that I did actually know prior
15:55
to this, that I've actually rolled that back
15:57
until we mentioned it. So yeah, it's quite, it's
16:00
quite interesting, really. I definitely say,
16:02
yeah, interact with other people in the industry.
16:04
Networking is very, very key to being updated
16:07
in your industry. Yeah, don't. When you're working
16:11
in this kind of career, you don't want to kind
16:13
of silo yourself. Otherwise, you know, you end
16:15
up in a sort of cave and, you know, it doesn't
16:18
even take a year and you're already kind of,
16:20
your skills are kind of out of date, let's say.
16:22
It's very, very tempting to do that. We all have
16:25
kind of our lives and stuff to get along with
16:27
outside of work. I'd say definitely make use
16:29
of kind of networking opportunities. Let's say
16:31
user groups. I know I attended an AWS user group
16:34
kind of a month ago. That would kind of keep
16:36
updated too. with like, I think they mentioned
16:39
like ML kind of models and how to use IDP. So
16:42
intelligent document processing within lifecycle,
16:45
which I never kind of considered and never knew
16:47
that AWS does. So just go to events, meet other
16:51
people in your industry, whatever that looks
16:52
like, you know, just go for it. Yeah, don't be
16:55
afraid to kind of step out of your kind of comfort
16:57
zone and speak to others kind of similar to you.
17:00
You never know what you might learn. Yeah. What
17:02
would you recommend for someone to do as like
17:03
a first project? Like, let's say I wanted to
17:06
get into DevOps. I maybe know a little bit of
17:09
Terraform, but I don't know a lot. I know some
17:11
YAML because I've used that before for other
17:13
applications. But what would be like a good first
17:16
like GitHub 101 project that I could have in
17:19
my back pocket when I go to my first like junior
17:22
DevOps engineer interview? Yeah, I'd say definitely
17:25
having a kind of any project where you deploy
17:29
an app. and make use of, say, the ECS service
17:32
within AWS. That's the thing. I don't know if
17:35
that's too beginner -friendly or not, that's
17:37
the thing. Yeah. Yeah, I'm thinking I might be
17:42
a bit much, but just to say deploying a simple
17:45
application, maybe making use of hiding a brand
17:49
application load balance, for example, in a public
17:51
subland, keeping your kind of actual app private.
17:55
That will teach you a lot of kind of networking
17:57
fundamentals for sure. And yeah, you'll just,
17:59
you'll be surprised what you learn along the
18:00
way, you know. So you can also, you try and Dockerize
18:03
the application. I think that's very, very important
18:05
to know. Docker is definitely a useful skill
18:08
and trying to build kind of multi -stage builds.
18:10
Yeah. So in summary, just try to Dockerize an
18:13
app and deploy it behind an application load
18:15
balance, I would say. And the ECS stuff, you
18:17
can do that if you want. I think that's a huge,
18:20
huge kind of plus points if you're able to do
18:22
that as well. Yeah. Or just use Docker Hub and
18:25
just just to start. But yeah, no, I'm with you
18:27
because a lot of junior engineers I talk to,
18:31
like so talking to the networking side of the
18:33
ALB that you're talking about, I've talked to
18:35
a lot of engineers where networking is definitely
18:37
the hardest part to learn just because it's not
18:41
taught in school, I guess, as much as it was
18:44
back in the day. And a lot of it's like obfuscated
18:47
from from people's periphery. So you create an
18:50
AWS account, they give you the default VPCs,
18:53
and a lot of people just start using that. They
18:55
don't really understand what availability zones
18:57
are, what ACLs are, how to create like route
19:01
tables, how to deal with like cider blocks and
19:03
cider block collisions, how to build transit
19:06
gateways, right? So you start to get into like
19:08
all the stuff related to the VPC networking wise,
19:11
and like that can feel really daunting. But I
19:13
do agree, like just start with default AWS account,
19:17
take what they give you. The default's fine,
19:19
at least to start. And then really focused on
19:22
like the ALB and building out like the security
19:24
group rules, like you talked about, like knowing
19:26
what a private ALB is, how to set those rules
19:29
so like not anybody can just get to it and understanding
19:32
that. And then you can kind of work your way
19:33
back to the networking side and learn that as
19:39
you go, right? You don't need to know everything
19:40
day one, but you can't know everything day one
19:42
either. It's just not possible. Yeah, exactly.
19:45
And a learning process just, it does take a while.
19:47
And it is, it is the sort of thing where, you
19:49
know, you would encounter an error and you might
19:51
be stuck on it for days even. Yeah. Yeah. So
19:54
it's just. We've all been there. Yeah. You got,
19:56
you got to take your time with that. There's
19:58
not really much else I can say there. Yeah. So
20:00
earlier you were talking about staying connected
20:03
and stay on top of things. And you mentioned
20:05
going to conferences. So we were talking earlier
20:07
in, earlier you had mentioned you went to DataFam
20:09
Europe by Tableau. And. Can you tell me about
20:12
that? Like, tell me about the conference. What
20:14
did you learn? Like, what are some cool takeaways
20:15
from that? Honestly, yeah, DataFam was just,
20:18
it was beautiful. Wow. It was just, there was
20:22
so much I took away from that. Like, you know,
20:26
so I do a bit of data as well. Yeah, I'm trying
20:30
to kind of get to grips with Tableau and understanding.
20:33
So for context, Tableau is a dashboarding tool.
20:36
I can just kind of visualize the data. There's
20:38
all sorts of kind of neat tricks you can use.
20:41
And main focus of this year's event was AI, AI
20:46
enablement. Yeah, because a lot of times AI can
20:51
do our kind of busy work, our boring work for
20:53
us and kind of analyze data behind the scenes.
20:56
And there's a couple of kind of products that
20:58
Tableau has announced. So for example, you have
21:00
Tableau Pulse, Tableau Inspector. There's one
21:02
other one I can't remember off the top of my
21:04
head, but essentially they... query your data
21:07
and tell you, you just give it a prompt, you
21:10
know, tell me about the sales forecast this week
21:13
and it will just dive into your data. Instead
21:15
of you having to kind of manually look up in
21:17
a table, it'll build kind of dashboards for you.
21:20
You don't have to worry about the dashboarding
21:21
part, it just does it for you. And yeah, it's
21:24
just, you just do it from a simple prompt. And
21:26
one thing you could do is also have custom kind
21:29
of MCP server connections so you can connect
21:31
up your own kind of AI agents to it. to run your
21:34
own customization, you can kind of go for that
21:36
as well. So it's really, really kind of powerful
21:38
event and I think paves the way for what a future
21:41
organization might look like, future businesses
21:44
going agentic. And I think it's just a really
21:46
exciting concept, to be honest, that's worth
21:48
exploring. That's cool. So full disclosure, I
21:51
have not played with Tableau too much. I have
21:54
set up Tableau bridges for data teams at organizations,
21:57
but I have not actually gone into Tableau and
21:59
like dealt with like data manipulation much myself.
22:02
Seems like a really cool tool, though. And it's
22:05
interesting because every company, it seems like
22:06
every conference now, Confluent just had a conference.
22:09
It was all AI, AWS reInvent, very AI focused.
22:13
Definitely is where the industry is. And it makes
22:15
sense. I mean, AI is definitely a great tool.
22:17
But I'm just kind of curious, what does an agentic
22:20
org mean in plain English? Like, what is that?
22:23
Yeah, agentic org really is the future of orgs,
22:27
to be honest. Organizations, they embrace AI
22:30
and all its... capabilities that come with it.
22:33
So a lot of organizations, they have a lot of
22:36
admin work, a lot of work that's kind of boring
22:39
that they don't really want to do. And so automating
22:41
it as much as you can, you know, just how DevOps
22:44
engineers automate ClickOps through Terraform,
22:47
you know, organizations want to extend that and
22:50
just whatever we can automate, like I said earlier,
22:53
you know, intelligent document processing, for
22:54
example, a lot of like industries such as insurance
22:57
or financial services, a lot of kind of documents
22:59
to read. There's a lot of kind of manual input
23:02
needed to kind of process that information. So
23:04
automating that is one way to unlock time and
23:09
energy and money as well, which is probably the
23:11
most important thing. Going to the company, to
23:13
the company, the bottom line, improving their
23:14
bottom line through using AI to reduce the kind
23:18
of burden and the cost of the kind of services
23:21
that they need and the time that they need to
23:23
invest to actually build products. So it's all
23:26
about creating efficiencies within organizations.
23:29
And that's what being an agent takes. organization
23:31
means is using ai to effectively leverage the
23:35
capabilities to enhance like all that busy work
23:38
just leave that to ml models really and automate
23:41
that stuff so you can get to work on making more
23:44
important decisions and you know not concern
23:49
yourself with all that manual labor so yeah no
23:52
that makes sense so speaking to using everybody
23:55
use i use ai All day at work, right? Everybody
23:58
does now. Use it on PR reviewing to like look
24:01
at a PR and give constructive feedback. Because
24:04
especially if you're reviewing PRs all day, it's
24:07
very easy to miss something as a human. Whereas
24:09
AI may cache something that you missed. Use a
24:12
cursor to help write code. Use it to help debug.
24:15
If you have an MCP server hooked up that can
24:18
maybe get into like Argo CD. and your kubernetes
24:22
cluster it can easily and quickly read logs quicker
24:25
than i could right and parse them and figure
24:27
out maybe like a root cause for for like a crash
24:30
loop back off or something like that but on a
24:32
recent episode i talked about prompt pwn by aikido
24:35
and how they're talking about prompt injection
24:39
vulnerabilities like in github actions and It
24:42
just has me thinking like, so what are your thoughts
24:44
on like what an agent can run and how we build
24:47
guardrails around that? Because like I think
24:49
AI is here to stay. It's a great tool. And I'm
24:52
not saying we shouldn't use it. But what are
24:54
your thoughts around the guardrails? Because
24:55
like it is non -deterministic, right? So it's
24:58
just a concern, I guess. I don't know. What are
25:01
your thoughts? Oh, yeah. This might be one of
25:03
the areas where I'm just, yeah, I'm completely
25:06
new to this. I've just been, I've been dunked
25:08
into the wall and I guess I'm still trying to
25:10
figure out what that looks like. So yeah, I don't
25:13
really have an answer to be honest. It's not
25:15
an easy question. No, it's not. There's not an
25:16
easy answer for sure. Yeah, I'm not trying to
25:18
put you on the spot because I feel the same way.
25:20
So I've even found that like cursor roles are
25:23
not always applied. You can set cursor roles.
25:26
It may sometimes, especially when a chat conversation
25:29
gets too long or you let it, break its guardrails
25:32
previously in a conversation it thinks that it
25:34
can continue to break its guardrails but like
25:37
it's very scary in that way where ai like you
25:41
can build caverno policies you can build policies
25:43
around code enforcement and i guess that has
25:45
to live outside of ai and then at least right
25:47
now my thought is not letting just ai just run
25:50
everything not letting it just break glass everywhere
25:52
or have complete control everywhere and like
25:55
you would for any service account or IAM role,
25:58
giving it very least privilege, specific permissions
26:01
that it needs, very limited to what it's allowed
26:03
to do and guardrail that as best you can. I don't
26:07
think that's even a great answer. I think that's
26:10
an okay answer that helps some of it, but I don't
26:12
think it answers all the questions either, unfortunately.
26:14
Yeah, I mean, to be honest, I don't think anyone
26:17
should be letting AI kind of take full control
26:20
of full access of their account. I think that's,
26:22
yeah, that. Because I see it on my LinkedIn feed
26:25
weekly. Someone's just given the AI just full
26:29
access to their account and then it's just deleted
26:32
the whole entire home, for example. And it's
26:36
like, how did you get it? Yeah, that's unfortunate.
26:40
Yeah, I've run into some of that myself as well.
26:42
And it's scary. You have to be very conscientious
26:46
of what you let... what you give the AI as far
26:49
as the data and also what you let the agent do
26:52
because the agent may live within the guardrails
26:55
and the pre -prompts that you give it. It may
26:57
not too. So there are, you know, it's a concern
26:59
for sure. So, all right, let's wrap up. Just
27:02
curious if you could, just a couple of quick
27:04
questions. If you could give one person a piece
27:07
of advice for someone that's trying to break
27:09
into DevOps in the upcoming year, 2026, what
27:12
would be that advice? What advice would you give?
27:15
I would. Definitely stay consistent. It's very,
27:18
very easy out there with the overwhelming amount
27:20
of tools. You know, just you feel like you're
27:23
getting overwhelmed and you need like, it's very
27:27
tempting to just want to take a break, to be
27:29
honest. And yeah, it's just, it's a very, very
27:33
tricky, tricky world out there, DevOps, especially
27:35
like given how... far it's come you know there's
27:38
so many different tools like i'm only starting
27:40
to realize how many tools there are every time
27:42
i try and go delve beyond like terraform you
27:45
know i'm for example i'm implementing a project
27:47
right now where i'm using terragram and honestly
27:49
like it's a lot it's a bit more difficult to
27:52
kind of configure but i'm appreciating you know
27:55
that it does with the kind of state file management
27:57
for example you know having a step state files
28:00
and keeping your code dry, it does definitely
28:02
have its benefits. So there's all sorts of tools
28:04
out there that will benefit you during your journey.
28:06
And the main thing is just pushing through and
28:08
being consistent. And yeah, as I said before,
28:10
there's those, you're going to have days, you're
28:11
going to have days literally where you're stuck
28:12
on an issue and you just got to keep on pushing
28:14
to be honest. So yeah, anyone out there who wants
28:17
to break in, you know, just stay consistent.
28:19
Yeah, don't give up. You know, you can take a
28:21
break, no problem, but just make sure you don't
28:24
drop the ball. Yeah. I love Terragrant. I use
28:27
it every day at my job. I was originally on Terraform
28:30
Cloud, started using Terragrunt, separating out
28:33
the state files into different buckets, handles
28:35
that automatically for you. You can do more localized
28:38
module control easier, keeping your code dry.
28:41
Templating with the HCL files is just, it's a
28:44
great addition to Terraform or OpenTOFU, whichever
28:47
you're using. And agree, yeah, stay consistent
28:50
and just be curious, right? Just keep learning.
28:53
So where should people follow you? Let's backtrack
28:55
on that. I know we mentioned at the top, but
28:57
yeah. Just let people know. Yeah. Yeah. So you
29:00
can find me on LinkedIn. So yeah, Masaharu419.
29:04
Yeah. So just for this additional bit of info,
29:07
yeah, I'm currently a DevOps engineer at Codeco.
29:09
So they provide kind of like training and delivery
29:12
in kind of DevOps. to kind of inspire DevOps
29:15
engineers. So it's a really, really good community
29:17
to join. So yeah, I highly recommend it. And
29:20
yeah, I'm on YouTube as well, DevOps with Maz.
29:22
And also I've recently started kind of Instagram
29:24
and TikTok as well with the same handle. Well,
29:26
speaking of handle, I'm trying to get a handle
29:28
on that kind of content. So it's quite tricky.
29:30
So yeah, I'm trying to build a video right now,
29:32
actually. And yeah, it's not easy, you know,
29:35
content creation. So yeah. It's a different world.
29:37
Yeah, for sure. Yeah, yeah. Awesome. Well, I
29:41
appreciate it, Maz. I appreciate having you.
29:43
And I'll link everything that you mentioned in
29:45
the show notes. Thank you so much. No problem.
29:47
Thank you so much for having me. All right. That's
29:50
the interview with Maz. Quick reminder on the
29:53
format. Ship It Weekly is still the weekly news
29:56
recap. And I'm dropping these guest convos in
30:00
between. If you want to catch both, hit follow
30:03
or subscribe wherever you are listening. And
30:05
if this was useful, share it with a coworker
30:08
or your on -call homie and leave a quick rating
30:11
or review. It's annoying how much that actually
30:14
helps the show. We'll be back next week with
30:17
a regular news episode. We'll see you then. Thanks
30:20
for listening.
