Ship It Conversations: The WHY Behind DevOps, Upskilling, and Agentic AI (with Maz Islam)

Transcript

Hey, I'm Brian Teller. I work in DevOps and SRE,

and I run Teller's Tech. Ship It Weekly is where

I filter the noise and pull out what actually

matters when you're the one running infrastructure

and owning reliability. If something's just hype,

we'll call it hype. If it changes how you operate,

We'll talk about it. Most weeks, it's a quick

news recap. In between those, I drop interview

episodes with folks across the DevOps world.

This is one of those interviews. Today, I'm talking

with Maz Islam, aka DevOps with Maz. He's a UK

-based DevOps engineer and puts out really solid

practical content on both YouTube and LinkedIn.

Today, we're going to hit the why behind DevOps,

how to keep leveling up without drowning in tools,

and what agentic AI and MCPs might mean for real

teams. So Maz, can you go ahead and introduce

yourself? Say hi to the podcast listeners. Yeah.

Hey, podcast listeners. My name is Maz and I

host my YouTube channel, DevOps with Maz. So

I'm a DevOps engineer by trade. And yeah, in

my free time, I like to kind of make content.

and educate a general kind of LinkedIn audience,

anyone on social media who kind of works in a

similar industry and wants to kind of know the

kind of tutorials and kind of challenges that

those engineers face and how to overcome them.

So in short, I'm also an advocate for better

tech. Awesome. So we can find you, I guess I

should have mentioned that, sorry. We can find

you on LinkedIn, Mazerul Islam. He's Mazerul419.

And then also on... YouTube with DevOps with

Maz. So yeah, be sure to check him out. He has

a really good tutorial I just saw on your channel.

It was about, I believe, like VPC endpoints versus

NAT gateways, right? That's what you were communicating.

Yeah. Which is a great topic. It's honestly come

up in my day job many times. One of those conversations

around specifically like how to set up networking,

data transfer costs, right, is always a concern.

I think that's a really, really awesome topic.

So for folks who haven't run into your stuff

yet, what do you do day to day in your job? kind

of work on like kind of different projects so

when it comes to for example using kind of aws

centric so yeah use a lot of aws services such

as the ecs and as well as fargate specifically

i do launch and manage my own kind of ec2 instances

so um yeah i manage kind of all things server

side to do with kind of setup and configuration

and also kind of translating all those click

ops to um finally infrastructures code because

we know if we can automate it you know ideally

we should Absolutely, yeah. Less mistakes in

the pipeline there. And also talking about pipelines,

also transferring that to kind of get up. So

implementing CI, CD pipelines and making sure

that there's all kinds of considerations for

security and FinOps as well. So just measuring

how much the costs are for your resources that

are deployed. So developers at the end of the

day just have a better experience when it comes

to developing the apps and deploying them. Yeah,

absolutely. That's awesome. So what caused you

to originally start sharing? devops with mass

i know you've always been on linkedin you've

been sharing a lot of posts on there um which

are awesome which are great i'm just kind of

curious though what prompted you to create the

channel and and start sharing more yeah so it

was kind of born from a kind of struggle i guess

me personally in our in our industry when you're

in devops you have to kind of wait for a lot

of documentation um just to figure out kind of

what the answer is so for example you know i've

added i made a tutorial on terraform and had

kind of set up kind of basic uh kind of linting,

you know, using Terraform format, Terraform validate,

kind of validate configuration. You know, when

I was kind of figuring that out, how to do that

via kind of GitHub Actions, I had to wait for

a lot of documentation. For me, I feel like simplifying

it as much as you can is very, very important

in your mind. And I feel like a lot of the time,

DevOps engineers were kind of overwhelmed by

the various kind of tools and stuff and waiting

for all that documentation. essentially about

kind of simplifying the concepts and just trying

to keep uh kind of ideas as simple as you can

to be honest i noticed that the best kind of

devops engineers are the ones that can communicate

their ideas and yeah i think you're only as good

as your kind of communication uh allows you to

so i think an important part of that is kind

of just communicating and learning how to communicate

that message across and that's kind of why i

made this channel is to kind of communicate the

message that you know devops it can be tricky

but If you can figure out kind of how to wait

for your documentation and kind of know how to

be a problem solver at the end of the day, you

can actually bring solutions to life. And yeah,

that's kind of inception of the channel. Absolutely.

I agree with that. We were actually talking pre

-recording about how even just sometimes training

gives you better insight and better visibility

or understanding, I guess, around concepts that

you had, even just doing it in your day -to -day

job. I feel like presenting it to other people

lets you. get to know like different sides of

understanding. Because again, you get tunnel

vision over years and you don't necessarily think

about things from outside the box or from different

perspectives. So when you have, when you're putting

yourself in that mindset of someone trying to

learn something, right, you grow because you're

thinking about it differently than maybe you

would in your day -to -day job, just trying to

complete a task, right? Just getting A from A

to B. Now you're actually trying to, well, wait,

if I don't have any of that understanding, how

do I actually even start at A? What is A, you

know? Exactly, yeah. it all becomes like really

tricky very quickly if you're not careful. So

you always have to be kind of, say, detail -oriented,

I'd say, for sure, when you're kind of looking

at documentation and just making sure that challenges

you, any kind of assumptions you've made, you

challenge them and kind of just ask yourself

like, you know, I'm actually understanding what's

going on here or is there something that I've,

some line of code that I don't really understand

what's going on here and I really need kind of

clarification on that. So yeah, just keeping

yourself accountable at the end of the day. Absolutely.

So I'm curious what your thought is when DevOps

is actually working at a company, right? So we've

implemented it. We have a team. It's, you know,

we're still setting stuff up. Maybe we don't

have an IDP platform yet for developers. We don't

have like great CICD, but we've started implementing

some of those first steps. What changes for a

team when we have DevOps? Like once we've implemented

that for a team, what changes and what feels

different on a random Tuesday rather than just

having like a bunch of engineers shipping code?

Everybody has their own processes. What does

DevOps bring to the table? What's your thoughts

on that? Yeah, so I think that links back to

kind of the why behind DevOps. So one really,

really nice book that I've been reading that

kind of demystified that for me is called The

DevOps Handbook by Gene Kim. And yeah, it's just

a really, really good insight into how DevOps

kind of works in terms of like the business.

And for me, DevOps means breaking down a boundary

between security. developers, operations, and

kind of wider business to make sure that, you

know, developers are shipping fast in small kind

of increments, as opposed to kind of large six,

every six months they're pushing a change that

everybody knows is going to break, but they all

kind of figure out. Yeah, DevOps has kind of

completely changed the landscape. And at the

end of the day, DevOps only works if everybody's

kind of implementing it from the ground up. So

yeah, I think. One quite interesting analogy

that was mentioned in the book was about kind

of the factory floor and how DevOps is the application

of agile methodology to the kind of IT value

stream. So if you think about, say, kind of lean

manufacturing, work done in factories, for example,

previously, you know, work was done in kind of

large batches. So, you know, you'd have kind

of like all these dependencies, all these chain

of dependencies, these tasks from the... would

have come in for the cost of some other materials

being on actual factory floor and then kind of

processing and making like say 50 car panels

for example if there was a deep if you made 50

car panels at once and there was a defect in

any single one of them you have to redo those

panels all over again and just think about for

a moment you know at that time they said devops

you know if there's say a major kind of change

that you're only kind of releasing every kind

of let's say six months um if an error were to

occur you have to go back to your code base and

change everything about it and so with um lead

manufacturing and agile methodology is saying

well why don't we just break something smaller

pieces let's make like couple of car panels here

couple of doors couple of windows and then if

there's an error in any single one of them you

can just go back and make the change and it takes

like It will take significantly shorter versus

if you're making large batches of changes. And

so just think about that in DevOps, that application

of that. If we're making incremental changes

to our code, the developers are making incremental

changes and just shipping daily. It depends on

the company, of course, if they're shipping daily

or weekly, what's kind of ideal there. But if

they're shipping more often, generally it's the

case that if there's an error, they can just

go back and roll back. And that's where the whole

kind of tooling comes in. And yeah, I'm a strong...

Believe in that. You know, if we can automate

some parts of that, make developers' lives easy,

have a self -service platform, ideally, that

would be kind of the way forwards. And so to

answer your question, yes, in Teams, the DevOps

implementation looks like shipping regularly

and also ensuring that the boundaries between

kind of IT security operations and the wider

business are actually solved and everybody's

got transparency about it. Yeah, and giving the

ability for that iteration, right? That ability

to... yeah to iterate quickly um it's awesome

so if you're in a like a new org what's one tiny

change that like you could see let's say for

like a company it's very new to devops what's

the change that they could make that may be like

a big win for them i mean or a win it doesn't

have to necessarily be a big win but but a win

that could help early on in their process, if

they're very, very immature to like DevOps practices

and they're not ready to do like full, full implementations

and iterations, like they're still doing full

big release cycles. Like what's something that

they could bring early on in that process that

without having to break everything down, that

could help? Definitely say bringing in the stakeholders

very, very early into the conversation. So for

example, if there's a business change kind of

proposed, it's important you get kind of early

feedback on it. as early as possible so if you're

making kind of changes down the line to your

kind of pipeline you shouldn't you need to get

early feedback ideally in order for kind of the

stakeholder whoever the business leader is to

kind of see if they're happy with the way things

are going so having early feedback is just really

key to that process you know otherwise What it

looks like is, you know, there's complete mismatch.

Again, communication is just the biggest thing

within organizations. Obviously, as you grow,

you know, it only gets more difficult. Teams

get bigger. And, you know, there's only kind

of so much that can be handed off until, you

know, the delays. So I definitely say ensuring

you get early feedback from stakeholders is very,

very important. Yeah, I've definitely worked

at companies where there was a DevOps team, but

there wasn't. uh buy -in by leadership really

on devops agile practices right they were from

the older older uh shipping you know batch releases

and not having like mature cd pipelines not having

iac um all click ops right because they didn't

see the value they didn't understand the concept

of slowing down to be able to speed up down the

road or improve and refine over time. They were

looking at the, and I'm sure that's true in like

a startup culture too, right? We want to do ClickOps

right away to get things, you know, get our MVP

up. But at some point we need to mature those

practices. We can't just, you know, cowboy every

day. So if you had to say DevOps in one sentence,

what is it really? Like, what is DevOps? I'd

say just, it's just communication. Yeah, that's

fair. It's literally just communication because

before, previously, you'd have all these, the

IT team, operations team, devs, as well as security,

they'd all be kind of siloed together and the

handover process rather, you know, like say,

for example, if you're working within kind of

DevOps and you kind of get like a ticket coming

in to create like additional couple of users,

you don't know. where this has come from or why

that is. Let's just say there's a stakeholder

kind of up within the business who's kind of

requested something like that and there's no

kind of transparency or any idea really of how

or where this kind of came from. So DevOps basically

breaks down all those communication barriers

by making sure, firstly, everybody's work is

transparent. Secondly, ensuring that there is

a self -service, regular... for developers to

just develop code. At the end of the day, developers

just want to get on with producing code and making

changes to their apps and just shipping. We want

to make that as easy as possible in the DevOps

industry. And so I feel like that's the main

purpose is just breaking down that communication.

Communication is key, really. Yeah. And I think

your point around making it easier for developers,

I think that's at least my understanding really

behind what... like platform engineering is.

And obviously, like, right, we've gone from SysOps

to DevOps to SRE. Now it's platform engineering.

But I do, there's nuanced differences to all

of it, right? To all the different titles and

the different methodologies and ideologies behind

those different concepts. But I do think platform

engineering, like the idea is building that IDP

for development team, letting them be self -service.

building like a service catalog, making sure

that they have those tools. And not that DevOps

doesn't incorporate that, but DevOps is almost

more, it's almost too wide of an idea of what

all encompasses. You go to some companies, you're

just a cloud engineer. You don't actually do

any quote unquote DevOps day to day work. You

go to another company, it may be all building,

you know, backstage and building out that IDP.

You go to a different company and it may be.

actually doing like CICD and improving like the

developer experience and building out those pipelines

and making them more robust and having better

status checks so, you know, the PRs can be merged

quicker and actually speed up that development

cycle. And that's like what I find at least is

like it's different for everyone. So it's hard

to pin down. You could even go back to the whole

idea that like DevOps is not a title, right?

It's an actual idea. It shouldn't be a title

at least. We've lost that war. I certainly, I

agree with that. I'm a DevOps engineer by trade.

I get that. But it's just funny to see like the

evolution of what DevOps means. Yeah. It's honestly

like, I think in the UK at least that we, it

just changes from company to company really.

You end up wearing different hats throughout

your career. And yeah, it just is a whole Pandora's

box really, the titles and stuff, isn't it? So,

yeah. No, for sure. So we both build. training

for people that are either in DevOps or looking

to get into DevOps. And so what would you say

to someone who's either aspiring to be a DevOps

engineer, maybe they're a back -end engineer,

maybe they're a front -end engineer and they're

looking at DevOps, they'd say, wow, I really

like that side of the development cycle. I want

to do more with that. What would you tell someone

as far as like keeping up with tools? Because

I find keeping up with tools is hard. Right.

I've been in the industry for like 25 plus years.

It's still hard because everything changes all

the time. My last episode was literally about

like it changed halfway through writing the episode

because GitHub came out with a new release around,

you know, like, oh, we're rolling this change

back now. Right. So what do you say? Like, what's

your thoughts on that? What do you do to stay

up to date with tools? What's your thoughts on

that? I'll definitely say, speak to other people

within your industry. So just like how we reached

out to each other today. You know, I, for example,

when I found out that I did actually know prior

to this, that I've actually rolled that back

until we mentioned it. So yeah, it's quite, it's

quite interesting, really. I definitely say,

yeah, interact with other people in the industry.

Networking is very, very key to being updated

in your industry. Yeah, don't. When you're working

in this kind of career, you don't want to kind

of silo yourself. Otherwise, you know, you end

up in a sort of cave and, you know, it doesn't

even take a year and you're already kind of,

your skills are kind of out of date, let's say.

It's very, very tempting to do that. We all have

kind of our lives and stuff to get along with

outside of work. I'd say definitely make use

of kind of networking opportunities. Let's say

user groups. I know I attended an AWS user group

kind of a month ago. That would kind of keep

updated too. with like, I think they mentioned

like ML kind of models and how to use IDP. So

intelligent document processing within lifecycle,

which I never kind of considered and never knew

that AWS does. So just go to events, meet other

people in your industry, whatever that looks

like, you know, just go for it. Yeah, don't be

afraid to kind of step out of your kind of comfort

zone and speak to others kind of similar to you.

You never know what you might learn. Yeah. What

would you recommend for someone to do as like

a first project? Like, let's say I wanted to

get into DevOps. I maybe know a little bit of

Terraform, but I don't know a lot. I know some

YAML because I've used that before for other

applications. But what would be like a good first

like GitHub 101 project that I could have in

my back pocket when I go to my first like junior

DevOps engineer interview? Yeah, I'd say definitely

having a kind of any project where you deploy

an app. and make use of, say, the ECS service

within AWS. That's the thing. I don't know if

that's too beginner -friendly or not, that's

the thing. Yeah. Yeah, I'm thinking I might be

a bit much, but just to say deploying a simple

application, maybe making use of hiding a brand

application load balance, for example, in a public

subland, keeping your kind of actual app private.

That will teach you a lot of kind of networking

fundamentals for sure. And yeah, you'll just,

you'll be surprised what you learn along the

way, you know. So you can also, you try and Dockerize

the application. I think that's very, very important

to know. Docker is definitely a useful skill

and trying to build kind of multi -stage builds.

Yeah. So in summary, just try to Dockerize an

app and deploy it behind an application load

balance, I would say. And the ECS stuff, you

can do that if you want. I think that's a huge,

huge kind of plus points if you're able to do

that as well. Yeah. Or just use Docker Hub and

just just to start. But yeah, no, I'm with you

because a lot of junior engineers I talk to,

like so talking to the networking side of the

ALB that you're talking about, I've talked to

a lot of engineers where networking is definitely

the hardest part to learn just because it's not

taught in school, I guess, as much as it was

back in the day. And a lot of it's like obfuscated

from from people's periphery. So you create an

AWS account, they give you the default VPCs,

and a lot of people just start using that. They

don't really understand what availability zones

are, what ACLs are, how to create like route

tables, how to deal with like cider blocks and

cider block collisions, how to build transit

gateways, right? So you start to get into like

all the stuff related to the VPC networking wise,

and like that can feel really daunting. But I

do agree, like just start with default AWS account,

take what they give you. The default's fine,

at least to start. And then really focused on

like the ALB and building out like the security

group rules, like you talked about, like knowing

what a private ALB is, how to set those rules

so like not anybody can just get to it and understanding

that. And then you can kind of work your way

back to the networking side and learn that as

you go, right? You don't need to know everything

day one, but you can't know everything day one

either. It's just not possible. Yeah, exactly.

And a learning process just, it does take a while.

And it is, it is the sort of thing where, you

know, you would encounter an error and you might

be stuck on it for days even. Yeah. Yeah. So

it's just. We've all been there. Yeah. You got,

you got to take your time with that. There's

not really much else I can say there. Yeah. So

earlier you were talking about staying connected

and stay on top of things. And you mentioned

going to conferences. So we were talking earlier

in, earlier you had mentioned you went to DataFam

Europe by Tableau. And. Can you tell me about

that? Like, tell me about the conference. What

did you learn? Like, what are some cool takeaways

from that? Honestly, yeah, DataFam was just,

it was beautiful. Wow. It was just, there was

so much I took away from that. Like, you know,

so I do a bit of data as well. Yeah, I'm trying

to kind of get to grips with Tableau and understanding.

So for context, Tableau is a dashboarding tool.

I can just kind of visualize the data. There's

all sorts of kind of neat tricks you can use.

And main focus of this year's event was AI, AI

enablement. Yeah, because a lot of times AI can

do our kind of busy work, our boring work for

us and kind of analyze data behind the scenes.

And there's a couple of kind of products that

Tableau has announced. So for example, you have

Tableau Pulse, Tableau Inspector. There's one

other one I can't remember off the top of my

head, but essentially they... query your data

and tell you, you just give it a prompt, you

know, tell me about the sales forecast this week

and it will just dive into your data. Instead

of you having to kind of manually look up in

a table, it'll build kind of dashboards for you.

You don't have to worry about the dashboarding

part, it just does it for you. And yeah, it's

just, you just do it from a simple prompt. And

one thing you could do is also have custom kind

of MCP server connections so you can connect

up your own kind of AI agents to it. to run your

own customization, you can kind of go for that

as well. So it's really, really kind of powerful

event and I think paves the way for what a future

organization might look like, future businesses

going agentic. And I think it's just a really

exciting concept, to be honest, that's worth

exploring. That's cool. So full disclosure, I

have not played with Tableau too much. I have

set up Tableau bridges for data teams at organizations,

but I have not actually gone into Tableau and

like dealt with like data manipulation much myself.

Seems like a really cool tool, though. And it's

interesting because every company, it seems like

every conference now, Confluent just had a conference.

It was all AI, AWS reInvent, very AI focused.

Definitely is where the industry is. And it makes

sense. I mean, AI is definitely a great tool.

But I'm just kind of curious, what does an agentic

org mean in plain English? Like, what is that?

Yeah, agentic org really is the future of orgs,

to be honest. Organizations, they embrace AI

and all its... capabilities that come with it.

So a lot of organizations, they have a lot of

admin work, a lot of work that's kind of boring

that they don't really want to do. And so automating

it as much as you can, you know, just how DevOps

engineers automate ClickOps through Terraform,

you know, organizations want to extend that and

just whatever we can automate, like I said earlier,

you know, intelligent document processing, for

example, a lot of like industries such as insurance

or financial services, a lot of kind of documents

to read. There's a lot of kind of manual input

needed to kind of process that information. So

automating that is one way to unlock time and

energy and money as well, which is probably the

most important thing. Going to the company, to

the company, the bottom line, improving their

bottom line through using AI to reduce the kind

of burden and the cost of the kind of services

that they need and the time that they need to

invest to actually build products. So it's all

about creating efficiencies within organizations.

And that's what being an agent takes. organization

means is using ai to effectively leverage the

capabilities to enhance like all that busy work

just leave that to ml models really and automate

that stuff so you can get to work on making more

important decisions and you know not concern

yourself with all that manual labor so yeah no

that makes sense so speaking to using everybody

use i use ai All day at work, right? Everybody

does now. Use it on PR reviewing to like look

at a PR and give constructive feedback. Because

especially if you're reviewing PRs all day, it's

very easy to miss something as a human. Whereas

AI may cache something that you missed. Use a

cursor to help write code. Use it to help debug.

If you have an MCP server hooked up that can

maybe get into like Argo CD. and your kubernetes

cluster it can easily and quickly read logs quicker

than i could right and parse them and figure

out maybe like a root cause for for like a crash

loop back off or something like that but on a

recent episode i talked about prompt pwn by aikido

and how they're talking about prompt injection

vulnerabilities like in github actions and It

just has me thinking like, so what are your thoughts

on like what an agent can run and how we build

guardrails around that? Because like I think

AI is here to stay. It's a great tool. And I'm

not saying we shouldn't use it. But what are

your thoughts around the guardrails? Because

like it is non -deterministic, right? So it's

just a concern, I guess. I don't know. What are

your thoughts? Oh, yeah. This might be one of

the areas where I'm just, yeah, I'm completely

new to this. I've just been, I've been dunked

into the wall and I guess I'm still trying to

figure out what that looks like. So yeah, I don't

really have an answer to be honest. It's not

an easy question. No, it's not. There's not an

easy answer for sure. Yeah, I'm not trying to

put you on the spot because I feel the same way.

So I've even found that like cursor roles are

not always applied. You can set cursor roles.

It may sometimes, especially when a chat conversation

gets too long or you let it, break its guardrails

previously in a conversation it thinks that it

can continue to break its guardrails but like

it's very scary in that way where ai like you

can build caverno policies you can build policies

around code enforcement and i guess that has

to live outside of ai and then at least right

now my thought is not letting just ai just run

everything not letting it just break glass everywhere

or have complete control everywhere and like

you would for any service account or IAM role,

giving it very least privilege, specific permissions

that it needs, very limited to what it's allowed

to do and guardrail that as best you can. I don't

think that's even a great answer. I think that's

an okay answer that helps some of it, but I don't

think it answers all the questions either, unfortunately.

Yeah, I mean, to be honest, I don't think anyone

should be letting AI kind of take full control

of full access of their account. I think that's,

yeah, that. Because I see it on my LinkedIn feed

weekly. Someone's just given the AI just full

access to their account and then it's just deleted

the whole entire home, for example. And it's

like, how did you get it? Yeah, that's unfortunate.

Yeah, I've run into some of that myself as well.

And it's scary. You have to be very conscientious

of what you let... what you give the AI as far

as the data and also what you let the agent do

because the agent may live within the guardrails

and the pre -prompts that you give it. It may

not too. So there are, you know, it's a concern

for sure. So, all right, let's wrap up. Just

curious if you could, just a couple of quick

questions. If you could give one person a piece

of advice for someone that's trying to break

into DevOps in the upcoming year, 2026, what

would be that advice? What advice would you give?

I would. Definitely stay consistent. It's very,

very easy out there with the overwhelming amount

of tools. You know, just you feel like you're

getting overwhelmed and you need like, it's very

tempting to just want to take a break, to be

honest. And yeah, it's just, it's a very, very

tricky, tricky world out there, DevOps, especially

like given how... far it's come you know there's

so many different tools like i'm only starting

to realize how many tools there are every time

i try and go delve beyond like terraform you

know i'm for example i'm implementing a project

right now where i'm using terragram and honestly

like it's a lot it's a bit more difficult to

kind of configure but i'm appreciating you know

that it does with the kind of state file management

for example you know having a step state files

and keeping your code dry, it does definitely

have its benefits. So there's all sorts of tools

out there that will benefit you during your journey.

And the main thing is just pushing through and

being consistent. And yeah, as I said before,

there's those, you're going to have days, you're

going to have days literally where you're stuck

on an issue and you just got to keep on pushing

to be honest. So yeah, anyone out there who wants

to break in, you know, just stay consistent.

Yeah, don't give up. You know, you can take a

break, no problem, but just make sure you don't

drop the ball. Yeah. I love Terragrant. I use

it every day at my job. I was originally on Terraform

Cloud, started using Terragrunt, separating out

the state files into different buckets, handles

that automatically for you. You can do more localized

module control easier, keeping your code dry.

Templating with the HCL files is just, it's a

great addition to Terraform or OpenTOFU, whichever

you're using. And agree, yeah, stay consistent

and just be curious, right? Just keep learning.

So where should people follow you? Let's backtrack

on that. I know we mentioned at the top, but

yeah. Just let people know. Yeah. Yeah. So you

can find me on LinkedIn. So yeah, Masaharu419.

Yeah. So just for this additional bit of info,

yeah, I'm currently a DevOps engineer at Codeco.

So they provide kind of like training and delivery

in kind of DevOps. to kind of inspire DevOps

engineers. So it's a really, really good community

to join. So yeah, I highly recommend it. And

yeah, I'm on YouTube as well, DevOps with Maz.

And also I've recently started kind of Instagram

and TikTok as well with the same handle. Well,

speaking of handle, I'm trying to get a handle

on that kind of content. So it's quite tricky.

So yeah, I'm trying to build a video right now,

actually. And yeah, it's not easy, you know,

content creation. So yeah. It's a different world.

Yeah, for sure. Yeah, yeah. Awesome. Well, I

appreciate it, Maz. I appreciate having you.

And I'll link everything that you mentioned in

the show notes. Thank you so much. No problem.

Thank you so much for having me. All right. That's

the interview with Maz. Quick reminder on the

format. Ship It Weekly is still the weekly news

recap. And I'm dropping these guest convos in

between. If you want to catch both, hit follow

or subscribe wherever you are listening. And

if this was useful, share it with a coworker

or your on -call homie and leave a quick rating

or review. It's annoying how much that actually

helps the show. We'll be back next week with

a regular news episode. We'll see you then. Thanks

for listening.

Ship It Conversations: The WHY Behind DevOps, Upskilling, and Agentic AI (with Maz Islam)

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

More from Ship It Weekly

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

Get the next episode in your inbox