Ship It Weekly Transcripts

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. But 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 joined by Eric Pate. He's a cloud and DevOps engineer. He has a background in building and running enterprise web and ERP systems. And he has a really grounded approach to leveling up through hands -on projects. Eric? First off, Brian, thanks for having me. I appreciate it. Yeah, no worries.

I'm excited about this conversation because my DevOps journey. Definitely hasn't been a straight line. I come from a software engineering background. I have spent years building web applications. And I must say that at some point in my career, I realized I was fascinated about cloud technology and how things run in the cloud beyond just shipping code, you know. I'm looking forward to sharing what has worked for me.

What hasn't and hopefully a few lessons that can help someone else who is on a similar path as me. I appreciate it. That sounds awesome. It's interesting because I started as a developer, I guess, too. I worked...

Tech support but then I did some like early web development and kind of jumped into devops kind of a lot of the same way a different industry but um a lot of the same way you did so that's very exciting exactly brian so can you just tell us who you are and what you do day to day well like I said I'm a cloud and devops engineer with expected in AWS, Linux, CI, CD automation, containerization, infrastructure as code.

Basically coming from a software engineering background. So I principally develop web applications and then ship through cloud technology. And yes. Oh, that's very cool. And so what system, I guess most of the systems, are they AWS based like most of the cloud systems or? Yes, they are. So coming from my previous background. All right, so we develop PHP -based applications.

And previously, we host the applications on web servers, not cloud platforms, so to speak. But then with the advent of cloud technology and the thing in Android cloud, there has been the need to migrate from traditional deployment methods to cloud technology.

What made you realize when you were doing this full stack web development, what made you realize that writing code is only part of the picture and you wanted to dive into DevOps as well? Right. So let me say this, that I found myself more curious about modern methodologies and technologies around code deployment and how applications scale and remain reliable in production environments. Yes. Very cool.

Being a developer to touching DevOps stuff? Was it like networking, CICD, just AWS, Linux? Like what was the part that you found to be the hardest? Well, Brian, that's a great question, Brian. How does LevelUp for me, I would say, was familiarizing myself with key DevOps concepts and with the stack of technologies that come with it, I .e.

Source code management using Git, package management using Docker, building CICD pipelines.

Using tools such as Jenkins, GitHub Actions, container orchestration using Kubernetes, you know, mastering cloud services on platforms like AWS, Google Cloud, and also, you know, getting a grip on infrastructure as code, you know, using Terraform Ansible, and of course, implementing continuous monitoring and observability with tools, you know, such as Prometheus, Grafana, and things of the sort.

I must say that, you know, beyond that, tools also another hardest level level up for me was the shift shift in mindset all right the mindset shift I .e you know moving from let me say I know how this process works on my local host to how how that same process behaves in production at scale Now, that's a big jump.

You know, that's a big jump, which requires grit and a lot of hands -on experience, hands -on practice, and also a grip on the technology that you're working with. Yes, Brian. Yeah, those are two really good points. A, there's just a lot to know. When you talk DevOps, that is just such a wide breadth of tools and technologies. And then the other side of it, yeah, testing locally, great, it works.

Then you scale that up to 10 ,000 users, 100 ,000 users, a million, completely different complexities than you're going to have running that locally. And things are going to show up that you didn't even think of when you were down in the 10, 100 early user stage. Exactly, Brian. Yeah. So was there anything that clicked first for you or were there things that took longer than expected as far as like learning like AWS?

Because like speaking of like DevOps being wide, AWS has a ton of different technologies and a ton of different.

Ways of doing the same thing so is there anything like in particular that maybe clicked earlier or or was harder to learn over time that's a great question again brian I would say this that um what really clicked for me was realizing that um devops sits at what what what I will call the intersection of you know software engineering and systems thinking and business impact what you're doing ultimately and largely impacts on business decisions.

So I enjoyed solving problems like, why is this deployment failing? Or why does this service degrade and that's a load? And how do you, or how do we automate this so it never breaks again? You know, that shift in mindset, just from writing features to owning the process, owning the system, owning reliability and delivery.

You know actually pulled me in yes so so that's it for me now brian what let me add this that what didn't click for me like you said earlier all right was the sheer breadth and depth of new tools and technologies I had to learn you know you you you are not dated with lots of of of tools and technologies to learn technologies in respect of cloud in this respect of networking You need to know the ins and outs of Linux, the ICD pipelines, observability, you know, it can feel overwhelming, really overwhelming.

But early on, I tried to try to learn everything at once. And that I would say was my mistake. All right. You need to progress slowly. You need to trust the process, follow along slowly. So progress really accelerated when I focused on the fundamentals and learned. By building, you know, and breaking things on my home lab. Exactly. Yeah, that's a good point.

So yeah, just focusing on one area and then building on that. Exactly, right. So looking back at your background, you've worked on enterprise grade systems for big organizations. What changes when it's not a side project, kind of like we talked about earlier, running locally in dev, what changes between that and like mission critical, like enterprise grade systems? Like what are some things maybe you have to worry about?

Um that you wouldn't in a local development environment all right so brian my my first instance in deploying a mission critical application was a voting was an online voting system okay for for a school cool and yes and you can imagine that the system works fine on your machine And then the moment you have to go live or go or deploy on production, all right, the results you are getting is entirely different.

Users are trying to access the system and they cannot. And you know, elections are contentious matters and that you cannot afford to let your users lose trust in your system. And so for me, that was a great learning curve for me. You really have to be prepared for such instances that you need to have some virtual environments where you can literally test what you have built and you want to deploy.

So for some mission -critical systems, I have been privileged to work with teams that have deployed online voting systems. We have deployed some enterprise resource planning platform for institutions like the food. An agri -organization of the United Nations, the Ghana office to be specific. So that platform encapsulates everything to make their business processes work efficiently.

So there are modules on procurement, modules on human resource management, modules on financial management and things like that. These are mission -critical systems which you can't afford to let them fail. Yeah. So for me, they have been a great learning experience for me practicing on or working on these systems. Yes, Brian. So what did that era teach you that actually helped you in DevOps now?

Like reliability mindset or like working with stakeholders or like change management? What was the most valuable, I guess, part of that? Brian, you literally mentioned everything that was a learning experience for me, right? From system reliability to change management.

It was a great learning experience for me that for users, once your system is unreliable, it's not available, it's not giving them the expected results, they begin to lose trust in the system. And then also the change management process is very critical and very important. There has to be user acceptance. Be user accepted.

You need to tag them slowly and make sure that they learn or they get comfortable with the system. And so lots of sensitization, stakeholder engagements, lots of consultations. All right, you run campaigns, you run some communication campaigns here and there to ensure that there is some... There is user acceptance, all right?

There's user acceptance because no matter how good your system is, if users do not accept the system, the system is 100 % bound to fail. Yeah, that's very true. Very true. Okay, so switching gears, you posted about your home lab on the go, which I believe was a Mac mini. I'm just curious, why that approach? Why a Mac mini? Mac mini, all right.

So let me just say this, that I purchased, This Mac Mini just some time ago. And I said to myself, well, why don't I just turn this into my home lab? Dedicated specifically for practicing, you know, and for honing my tech skills. So I own a laptop and I also have this home lab dedicated specifically to... Practicing my, my DevOps skills. And so with this, this platform, I am not afraid to break things down.

All right. For sure. Yeah. To feel in the, make all the mistakes. All right. To, to, um, what should I say? To make all the mistakes that, that you need to make while, while, while learning as well. Yeah. So this home lab is, is dedicated. To help me practice my DevOps skills and also to hone my tech skills as well. Very cool. So are you doing like Docker, pipelines, monitoring, like break -fix? Exactly.

So just last night, so I decided to containerize a static version of my website. All right. So I Dockerized the website, all right, built the image on that platform. All right. I pushed that Docker image to Docker Hub, right? And then I went on also to run the Docker run command, right? So which literally converted the image to a container.

And then I ran the application from the web browser, you know, to local host port 8080. And that gave... So I used that home lab, all right, to practice writing of Docker files, all right, CICD pipelines, constructing my Docker Compose files, you know, building my Jenkins files.

And so you would be seeing a post for me very shortly detailing the process that went through and containerizing the static version of my website. Very cool. So basically that home lab helps me practice without guardrails. All right. Make the mistakes. All right. Do my debugging in there. Build Docker images. Run Docker images. Run Jenkins files. You know, build my Jenkins files. Run CICD pipelines.

Push my image to Docker Hub. Pull from Docker Hub. Things like that. Very cool. Well, I'll look forward to that post. And I think, I think that just goes to show you that you don't need fancy hardware either for a home lab.

Just take what you take, whatever you have or, or what you've used previously, or, you know, if you have an old Mac mini or whatever, you don't need, you don't need like a big rack and stack server set up. Like you don't need a bunch of fancy machines. Exactly, Brian. Exactly, Brian. So shifting gears a little bit from the home lab, and we talked about this at the top too a little bit, but I'm just curious.

So we talked about how the tools are endless, right? You have Terraform, Kubernetes, Jenkins, Prometheus, Grafana, Ansible. How do you choose, how do you personally go by choosing what to learn next? All right. So this has been my structure. All right. So I begin with source code management. All right. So the basics for me is very critical. You need to be familiar with the basics.

You need to have a stronghold on the basics, which is Linux. All right. So things to do with Linux commands, mastering bash scripting are very important and very, very, very, very critical because at the core of DevOps is Linux. You cannot be a DevOps engineer. And not no Linux. Linux is very critical. So I focus on the fundamentals, which is Linux.

And then I move on to source code management tools, you know, like Git. And then I progress into package management using Docker, right? And then I progress to CICD pipelines using Jenkins. So the idea is how do I use automation, all right, to build? The Docker image and then push it to a repository. All right. Okay.

And then from the Docker, from the CICD pipelines and practice, all right, so I move on to the cloud platform. All right. So that now after pushing to the Docker repository, all right, it has to be pulled onto your cloud platform. Now we have cloud services also that can serve us as your... Your Docker repository. All right. So the various cloud platforms have services that can serve as, you know, Docker repository.

And then I move on to learning infrastructure as code. All right. But in between that one, so from Docker to the cloud platform, my process would be to learn Kubernetes next. And then after learning Kubernetes, you learn Terraform. Okay.

Or infrastructure as code so basically terraform ansible and then you move on to to to implementing continuous monitoring and observability with you know tools like prometheus and grafana gotcha so so so for me that has been my structure well some people have their structure.

But for me, at the heart of DevOps has been to learn and show that you get the fundamentals right and show that you have a good grip on Linux and then you progress from there. And then learn the entire, through the process, learn the entire pipeline and follow it through. It sounds like, right? Exactly. Exactly, Brian. Exactly, Brian. So what are your thoughts on certifications versus like...

Doing your own projects what do you think is more valuable well for certifications let I would say this that's a very dicey dicey matter yeah it is that's a dicey matter right well here is it hands down I'll see real projects would always make the big difference for anyone right certifications and courses will help build structure but running real you know, setting up CICD pipelines, deploying to cloud infrastructure, breaking things, monitoring them, fixing things, you know, that's where everything clicks.

That's where everything clicks, yes. So certifications help, all right? Like I said earlier, certifications and courses would help you build structure. But, you know... Hands down, I would say real projects would always make the big difference. Real projects and hands -on projects will make the real difference. Because you have to fail, right? You have to learn to fail and be okay with that.

You have to learn to fail. You have to learn to fail. You have to learn to fail. For me, there have been several times where I have just tried to organize a Docker Compose file. As basic as getting it to run successfully. Brian, and it's been a challenge. And so I put that file down, go to sleep, come back the following morning, and it starts to end. And surprisingly, things begin to click for me. All right.

And then when you realize that you made mistakes, oh, I made the mistake here, I made the mistake there, I made this mistake. Just two weeks back, all right, one Docker Compose file that I wrote just wasn't working. Only for me to realize there was a dash, a dash I had introduced somewhere that shouldn't have been there. And it's been a great learning experience for me.

So I would say that hands down, real practice and real projects would always make a difference. Yeah, I agree with that. I think, yeah, I think certifications, boot camps have their place, but as a foundational, a structure school, same thing, but you need that hands -on learning. At some point you need to actually dive in. Be comfortable with failing because that's okay. Like, you know, it's okay.

You're going to stumble a little bit and that's okay. So wrapping up a bit, what's one piece of advice you would give someone trying to break into DevOps in 2026? Where should they start? What should they do? All right. So what I would say is this, that let me say this, that I would just say, focus on depth and not hype. Focus on depth and not hype. So I...

I have found out that employers, you know, care more about how you think and solve problems, right? How you think and solve problems than knowing every tool there is, all right? How you think and how you solve problems, all right? Because at the heart of that all, that is what DevOps really is. Simplifying things, automating processes, and then shipping code faster and efficiently.

All right and so how you think now my my my other advice would be this that consistency would always beat intensity all right that consistency would always beat intensity you don't need to learn everything in three months you need to show up steadily all right you you need to show up you need to have a routine if you tell yourself that you would dedicate two hours each day to learning devops do that You need to show steady progress.

You need to build. You need to document. You need to reflect. You need to repeat. And it's okay to fail. It's okay to fail. Do this repeatedly. And I would say also that slow down and be consistent. You don't need to master everything overnight. Just show up. Build something small and keep going. And also one thing I would say also would be this. Learn to share your journey, all right?

Learn to write, learn to post, learn to talk about what you are learning because it's only through that process that it reinforces your knowledge. It creates visibility as well. And then opportunities often come from when people see the way you think and not just what's on your resume. The way you think, the way you solve problems, the way you handle challenges. That would be for me, Brian.

Yeah, I agree with that a lot. All right, so where should people follow you and what should they check out? All right, Brian, so people can follow me on LinkedIn and then also my personal website, which is ericpatty .com, ericpatty .com. I'm also on Facebook and also on Instagram. And so I'm primarily on LinkedIn and I have a website, ericpatty .com. Yes, Brian. Awesome. Appreciate it.

Well, thank you, Eric Pate, for coming on and being on Ship It Weekly. I really appreciate it. Thank you, Brian. It's been great. Thank you. All right. That's the interview with Eric. 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 episode was useful, share it with a coworker or your on -call buddy and leave a quick rating or review. It's annoying how much that stuff actually helps the show. We'll be back next week with the regular news episode. We'll see you then. Thanks for listening.

Thank you. 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 hype, I'll call it hype. If it changes how you operate, I'll break it down in plain English. Most weeks, this is a quick news recap.

In between those, I drop interview episodes with folks across the DevOps world. Happy holidays. Merry Christmas, all that good stuff. It's the day after Christmas, so if you're listening while hiding from your family, checking one thing real quick, I respect it. Quick piece of housekeeping, the new site is live at shipitweekly .fm. That's where I'm putting links and show notes. Also, I'm looking for interview guests.

If you're building real infra or platform stuff and you want to come on for a chill conversation episode, hit the email on shipitweekly .fm. If you've got war stories, even better. And one quick ask before we start. If the show has been useful, hit follow or subscribe wherever you are listening. And if you've got 10 seconds, a rating or review really helps way more than it should.

All right, three main stories for today. First, Cloudflare wrote up how they built an internal maintenance scheduler on workers. This is real platform engineering. Memory limits. Data modeling, query optimization, caching, Parquet for historical analysis. Second, AWS databases are now available directly in Vercel marketplace. It's a quiet shift, but it's a big one.

Devs can click button real AWS databases from inside Vercel, but you still have to own governance, billing, and the blast radius. Third, there's an open source project from AWS called Team. Temporary Elevated Access Management, and it's built around IAM Identity Center. It's approval -based, time -bound access. This is one of those everybody wants it, few implement it cleanly problems.

Then we'll do a lightning round, and we'll close with Mark Brooker's What Now? Handling Errors in Large Systems. Let's get into it. Cloudflare has a really good post on how they built an internal maintenance brain on workers. The core problem is kind of obvious once you hear it.

When you run infra at their scale you cannot rely on humans to remember every dependency and every weird routing rule and every if these two things go down at the same time a customer special setup gets wrecked scenario so they built a centralized scheduler that treats maintenance like a set of constraints like we must always have at least one of these routers active or this customer pins traffic through these data centers, so don't take all of them out at once.

The fun part is how they got it working within worker's limits. Their first naive approach was basically load everything into one worker. All the relationships, all the product config, all the metrics, then compute constraints. And even in proof of concept, they hit out of memory errors. So they took a step back and said, okay. Workers have limits. We can't treat this like a giant in -memory analytics job.

We need to only load the data that matters for the specific maintenance request. If you get a maintenance request for your router in Frankfurt, you probably do not need to load Australia. You need the dependency neighborhood around that router.

That pushed them into graph modeling they describe constraints as objects and associations basically vertices and edges routers are objects pulls are objects and the dependencies are associations and then they built a typed association interface so the constraint logic stays simple but the backing implementation can get smarter over time then they flip their data fetching style instead of pulling down huge responses and filtering locally They started doing targeted requests through the graph interface.

They claim response sizes dropped by 100 times in one spot. That's huge. Also, it's the exact kind of win you get when you stop shipping your entire dataset into your app layer just to throw most of it away. Of course, that created the next problem. Sub -request limits. They traded a few massive requests for a ton of tiny requests. And then they started breaching sub -request limits.

So they built a fetch pipeline with request deduping, a small LRU cache, edge caching via caches .default, and sane retry and back off. After tuning, they were seeing about a 99 % cache hit rate on those fetches. That's wild. And it's It's also how you make something like this survive at scale without tuning your internal APIs into a creator. Then there's a super relatable metric story.

They use Thanos for Prometheus queries, and they call out what a lot of teams do by accident. Ask for everything. Get megabytes back, parse JSON into single -threaded runtime, then filter most of it out. That's basically self -inflicted pain.

Instead they use the graph to find the specific relationships first then issue much more targeted thanos queries they say average response size went from multiple megabytes to about one kilobyte in one case so the theme of this story is stop dragging huge blobs of data into your application just so you can toss 99 of it and then they bring it home with historical analysis real time is one thing historical is a different because now you're scanning months of data to see if your logic is actually safe and accurate.

They talk about how Prometheus TSDB blocks are not really designed for object storage access patterns and how that turns into a lot of random reads. So they adopt a parquet conversation layer for historical data. Columnar format. Better stats, and you can fetch what you need without slamming object storage with random IO. Takeaways you can steal even if you're not Cloudflare.

If you're building platform brains like schedulers, deploy orchestrators, policy evaluators, you will hit limits. Memory, CPU, API quotas, request fanout. You win by changing the shape of the problem, not brute forcing it. Graph interfaces are a cheat code for dependency -heavy domains. And targeted queries plus caching plus backoff is still undefeated.

All right, let's move from Cloudflare did adult engineering to developers can click -button databases. AWS announced that AWS databases are now available on the Vercel marketplace. The headline is simple. From Vercel, you can provision and connect to Aurora Postgres, Aurora DSQL, and DynamoDB in seconds. And here's the part platform folks should not ignore.

The onboarding path is basically create a new AWS account from Vercel with some starter credits. So the dev experience is you're already in Vercel. You click a thing, and now you have a database, and the app is wired up. That is great for Velocity. It is also the kind of thing that bypasses governance if you don't get in front of it. Even the AWS side is legit.

You still have to deal with who owns that AWS account long term. Is it inside your AWS organization or is it an orphan account that exists because Vercel made it easy? How do SCPs apply? How do guardrails apply? How do you do tagging and cost allocation so finance doesn't show up later asking why there are mystery accounts? What does networking look like? Are public endpoints acceptable?

Do you need private connectivity? Do you have a VPC strategy that fits Vercel -first teams? What's your audit baseline? Cloud trail? Config? Detective controls? All the boring stuff. Also, Region selection matters for data, residency, and latency. It's not just pick whatever. Vercel also hinted this is evolving.

They're talking about coming soon support for provisioning into an existing AWS account, not just a new one. If that lands cleanly, that's the version I'd actually want as a platform team because now you can meet developers where they are without losing governance. So the takeaway, if your dev platform can create AWS resources, your governance has to meet it there. The database is easy.

The ownership model is the hard part. All right. Story 3 is about access, which matters even more once you have more accounts and more surfaces. TEAM stands for Temporary Elevated Access Management. It's an open -source solution built around AWS IAM Identity Center. The pitch is basically approval -based, time -bound elevated access to AWS accounts.

Users request elevated access for a specific period of time, with a reason. Approvers approve or deny it. If approved, access is granted. When time expires, it is automatically removed. That automatic removal is the whole point. Because most orgs fail here. Someone gets admin just for this incident, and then it stays for months. Privilege creep becomes the default. Team also leans into auditing and visibility.

Who requested what, who approved it, when it expired, plus session logging. How I'd frame it. This is not your break glass story. Break glass is the world is on fire and we need access right now. It should be rare, noisy, and heavily monitored. Team is the daily, I need admin for 45 minutes to do this legit change workflow.

If you want this to actually work culturally, approvals need to be fast enough that people don't route around it. And the default permission sets need to be sane so elevation is actually meaningful, not just ceremony. If you are already on IAM Identity Center and you've been hand -waving we should do JIT access, team is at least worth a look.

Even if you don't adopt it, it's a good reference for what time -bound elevation can look like without building everything from scratch. Alright, time for the lightning round. GitHub Actions improved performance on the workflows page. Small change, but if you live in Actions, you'll feel it.

Big workflows render better now, lazy loading, and you can filter jobs by status so you can just see failures or in -progress stuff. During an incident, this is a real quality of life upgrade. Next, the weird one, Lambda managed instances. This is basically run Lambda functions on EC2, but AWS manages the lifecycle of those instances for you. It's meant for steady state workloads and specialized compute needs.

It also changes concurrency and execution assumptions a bit. So you actually need to care about thread safety and shared state in ways you might not with regular Lambda. Interesting, slightly cursed. But I get why it exists. Atmos quick hit. There's a Cloud Posse Atmos issue where vendoring a component with an invalid URL triggers a weird GitHub username prompt.

I'm mentioning it less because of the bug and more because Atmos is clearly turning into a bigger workflow ecosystem now. CLI, dev containers, IDE integrations, the whole thing. And last, k8sdiagram .fun. It's a free Kubernetes diagram builder that can also generate YAML for common resources.

I would not blindly apply auto -generated YAML to prod, but for teaching, prototyping, or explaining architecture to humans, it's actually super handy. All right, let's close with the human story, because this ties into everything we just talked about. Mark Brooker wrote a post called, What Now? Handling errors in large systems. It's basically an interactive error handling game.

You decide whether a system should crash or keep going when something goes wrong. And then he explains his take. The key idea is simple. And it's something we forget all the time. Error handling isn't a local decision. It's a global property of the system. We love to argue about one line of code. Should this crash? Should this retry? Should this be best effort?

Mark's point is, that decision only makes sense if you understand the architecture around it. He asks questions like, are failures correlated? If the same bad input can hit every node, crashing can amplify the blast radius. Can a higher layer handle the air? Some architectures are designed to tolerate a few crashes. None are designed to tolerate a ton of crashes continuously. Is it actually safe to keep crashing?

Is it actually safe to keep running? Sometimes continuing means silent corruption, which is worse than a crash. Then he ties it to blast radius reduction. Cell -based architectures, independent regions, isolating failures so you don't have a single mistake become a global outage. That connects to today's stories perfectly.

Cloudflare's scheduler exists because humans will guess wrong sometimes, and the systems need to prevent correlated failure. The Vercel Marketplace DB story is a new surface area. The failure modes aren't just technical, they're governance and ownership failures. And team is literally about reducing the risk of one person with standing admin turning a mistake into a disaster. So yeah.

If you want a good mindset going into next year, stop treating air handling like a code style preference. Treat it like architecture. All right, that's it for this episode of Ship It Weekly. We covered Cloudflare's maintenance scheduler on workers and the platform limits force better design lessons. AWS databases inside the Vercel marketplace and what that means for governance and blast radius.

And team as a practical path to time -bound elevated access with IAM Identity Center. If you got something out of this, hit follow or subscribe wherever you are listening. And if you can, leave a quick rating or review. It's annoying how much that helps the show. Links and show notes are on shipitweekly .fm. And one last reminder, I'm looking for interview guests.

If you want to come on and talk through real DevOps or platform work you're doing, hit the email on the site. I'm Brian. Thanks for listening. Happy holidays. And I'll see you next week, which is technically next year.

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.

Hey, I'm Brian. This is Ship It Weekly by Tellers Tech. If you're new here, I've worn the DevOps, SRE, and platform engineering hats over the years, and I do some coaching on the side. This show is me skimming the noise and pulling out what actually matters when you're the one running infra and owning reliability. All right. This week's theme is pretty obvious. Your CI is a dependency.

Vendor pricing models are shifting under your feet and AI is getting shoved into pipelines in ways that create entirely new failure modes. Let's start with GitHub. So GitHub announced a pricing change for actions that would have added a cloud platform charge to self -hosted runners in private and internal repos. Not compute, you still pay for your own compute.

This was basically GitHub charging for the orchestration layer and the control plane side of actions. People freaked out loud and fast. And GitHub came out and said they're postponing that billing change while they reevaluate. So the story isn't they're charging now, the story is they tried to charge, got major pushback and hit pause.

Important detail though, they're still moving forward with reducing hosted runner prices in 2026. So GitHub is still actively tuning the economics of actions. They're just not ready to light up the self -hosted runner fee just yet. Then because timing is hilarious, GitHub hosted action runners had an incident yesterday. I'm not even bringing that up to dunk on them. It just reinforces the point.

Actions is not just CI. GitHub is part of your delivery control plane. When it's down or degraded, a lot of companies basically lose their ability to ship, deploy, or recover cleanly. So here's the platform lesson. Even if the fee is postponed, this is your warning shot. GitHub wants to monetize actions like a platform product. Not a free feature. If you own CI CD, now is the time to get your house in order.

Start measuring actions minutes by repo and by workflow, especially the expensive ones. The long integration suites, the run everything on every PR pipelines, the stuff that's there because it's always been there. Then go hunt down dumb minutes, not even because you're scared of pricing, but because it's usually a straight win anyway.

Faster PR feedback, fewer queues, less flakiness, lower compute costs, and less why did this run 12 times noise. Also, write down your GitHub is sad plan, like literally. If GitHub Actions is down, what can still happen? Can you still deploy a hotfix? Can you still promote an image? Can you still roll back? Or is your plan basically, we wait and refresh the status page?

Even a tiny break glass path is better than chaos. All right, let's go from GitHub pricing whiplash to HashiCorp pricing whiplash. So HashiCorp is finishing the transition off of the old legacy free plan for HCP Terraform. The legacy free plan hits end of life on March 31st, 2026, and orgs get moved to the newer free tier. That newer free tier includes unlimited users, but it caps at 500 managed resources.

And that managed resources limit is why this is suddenly a big deal for real teams. Because 500 resources sounds like a lot if you're thinking workspaces, but it's not workspaces. It's actual managed infrastructure objects. If you've got a couple of EKS clusters, they're node groups, IAM roles, policies, security groups, route tables, DNS.

Plus supporting stuff plus a few environments, you can hit 500 way faster than you think. So the takeaway here is not HashiCorp is bad or everyone panic, it's you need to know your numbers. If you're using Terraform Cloud or HCP Terraform, go find out. Are you still on legacy -free? How many managed resources you actually have today? And how fast that number is growing?

Then decide what your reality -based options are. Maybe you're fine and this doesn't matter. Maybe you need to clean up old stacks and dead environments so you stop paying for zombie infra and zombie state. Maybe you need a paid tier because you're not a hobby shop. Or maybe you do want to move away. But do that as a controlled migration, not a March 2026 emergency where your pipeline turns into a pumpkin.

This is the part I keep coming back to. Platform work is interestingly vendor economics work, not just Kubernetes and Terraform syntax. You need a basic plan for what if the rules change. All right, now we're going to take the your pipeline is a dependency theme and add AI to it. Which is where things get extra weird. There's a write -up from Akito about what they're calling prompt pwned.

This is basically the prompt injection meets CI CD story. Here's the pattern. Teams are wiring AI agents into GitHub actions or similar pipelines. The agent reads issues, PR descriptions, commit messages, logs, test output, and then makes decisions. Maybe it opens a PR. Maybe it posts a comment. Maybe it runs scripts. Maybe it has tools. The problem is, a lot of that input is untrusted. PR text is untrusted.

Issue bodies are untrusted. Commit messages can be untrusted. So if that untrusted content goes into the model prompt without guardrails, an attacker can basically smuggle instructions into the agent. And if the agent has the ability to run commands or use privileged tokens, you've created a new kind of supply chain exploit. It's not run untrusted code. It's run untrusted text through a system that has hands.

So what do we do about it as platform folks? Treat AI agent inputs like you treat user input in an app. Sanitize, filter, don't just shove raw PR bodies into prompts. Keep the agent's permissions brutally minimal. If it doesn't need write, don't give it write. If it doesn't need cloud creds, don't give it cloud creds. If it's running in CI, don't give it a token that can do anything interesting.

And if the agent generates commands, don't auto execute them like, well, the robot said so. This whole space is new enough that a lot of people are still in the, this is fun phase. We're already entering the, this is now a security boundary phase. All right. One more main story, and this one is classic security hygiene.

There was a report that Home Depot had an exposure that allegedly granted access to internal systems for about a year. Not trying to pile on them, big companies have weird internal sprawl and stuff slips. But the reason I think it's worth mentioning on this show is because this is the exact kind of incident that happens in a lot of orgs, just smaller and quieter.

Usually it's some variant of, a token was exposed somewhere it shouldn't be. The token had way more access than it needed. Nobody noticed for way too long. Detection and response was slower than it should have been. And even if you rotate creds, the bigger question is, how did it get there? And why did it have that much power? So what can you actually take back to your team from this? Secrets should expire.

If you can't expire them, they should at least be rotated on a schedule that doesn't require drama. If it's a long -lived credential that can't be rotated, that's a smell. Assume exposure will happen. Design the blast radius like it will. If a token leaks, what can it do? One service, one environment, or is it basically welcome to the kingdom? And lastly, detection.

How quickly would you notice a token is being used from a weird place? Do you even log that in a way you can query? Do you have alerts? Does anyone own those alerts? A lot of orgs treat secret scanning as nice to have. It's not. It's one of the simplest ways to prevent a year long, how is this still alive story. All right. Let's do a quick lightning round. CDK for Terraform.

CDK TF is officially sunset and the repo is archived. If you're using it, you're now in fork or migrate territory. The official guidance is basically synthesized to HCL and move on. Bitbucket is doing cleanup of free, unused workspaces. If you have dead orgs or old workspaces that nobody touches, you don't want to wake up to surprise deactivations or deletions. Inventory your SaaS, it's boring, but it's real.

And SourceHUD is proposing pricing changes. I like mentioning this stuff because it's a reminder that even the indie dev tolling world is under cost pressure. Different scale than GitHub, same underlying reality. Infra costs money, and pricing models eventually shift. All right, quick human moment before we wrap. This week is a good example of something nobody is really talking about. Platform whiplash.

Like GitHub floats a pricing change, everyone scrambles, then it gets postponed. HashiCorp shifts plan definitions and suddenly you're doing math on managed resources. Meanwhile, teams are wiring AI into CI pipelines, and now you're responsible for weird new security boundaries you didn't ask for. None of this is hard tech in a fun way. It's mental load. It's context switching.

It's the quiet stress of realizing your job isn't just keeping systems up. It's also keeping your org from getting surprised by vendor changes. So if you're the person who owns CI, IAC, or platform reliability, here's a thing I've started doing that helps. Make a tiny platform watch list. Not a big roadmap doc, just a running note with three columns. What changed, what it breaks, and what we're doing about it.

And the bar for what we're doing about it can be small. Sometimes it's literally measure action minutes or check our Terraform managed resource count or write down break glass deploy path. Because what burns people isn't one big outage. It's a constant drip of little, oh by the way, changes that all become your problem. So yeah, if this week felt like chaos, it's not just you.

Put it in a lightweight system so your brain doesn't have to hold it all. All right. So the vibe this week is GitHub and HashiCorp are both messing with the economics of the platforms a lot of us depend on. AI agents are being wired into pipelines in ways that create brand new attack paths. And security stories like the Home Depot one keep reminding us that the boring basics are still the basics for a reason.

If you got value out of this episode, please subscribe wherever you are listening. Seriously, it helps. And if you know the one person on your team who always ends up being the prod is weird detective, send it to them. I'm Brian. This is Ship It Weekly by Tellers Tech. Thanks for hanging out and I'll see you next week.

Hey, I'm Brian and this is Ship It Weekly by Teller's Tech. Quick heads up before we get into it, my voice is a little rough this week. I've been fighting a cold, so if I sound like I've been yelling at Kubernetes for three days straight, that's why. All right, here's what we're talking about this episode. First, IBM is buying Confluent.

That's right after the HashiCorp deal, so we'll talk about what that means if you're on Confluent Cloud, running Kafka on -prem, or trying to pick between Confluent, MSK, and do -it -yourself. Second, there's a nasty React vulnerability people are calling React2Shell. It's a 10 .0 RCE, it's been exploited in the wild, and if you run platforms for front -end teams, this absolutely involves you.

Even if you've never touched React. Third, Netflix wrote up how they consolidated a big chunk of relational databases onto Aurora Postgres. They saw up to a 75 % better performance and solid cost savings, and they simplified their fleet. We'll talk about what's real there and what's marketing. In the lightning round, we'll hit...

Open Tofu 1 .11, some Terraform tips from the trenches, Ghosty going non -profit, and a pair of tools around spec -driven development with AI. And we'll wrap with a human story from your brain on incidents, about what big incidents actually do to people and how to make that less awful. Let's start with the big acquisition, IBM and Confluent. So IBM is buying Confluent for a very large pile of money.

They already grabbed HashiCorp earlier, and now they're adding Confluent, which is basically Kafka as a product, with managed clusters, connectors, governance, all the stuff around the core broker. If you zoom out, this looks pretty intentional. HashiCorp gives them a control plane story, terraform, vault, console, all the infrastructure lifecycle pieces.

Confluent gives them a data plane story, real -time streams, feeding analytics, and AI systems. From IBM's point of view, that's great. From your point of view, this should trigger some questions. If you're a Confluent Cloud customer today, I'd be asking, what's the realistic time window where pricing and packaging stay roughly the same? 12 months? 24 months? What's the path if that changes?

And we suddenly don't like the new world. Are we comfortable being on HashiCorp tools and Confluent and whatever IBM does for AI all from the same vendor? If you're not on Confluent but you've been evaluating it, this changes the comparisons with MSK and self -managed Kafka a little bit. On the plus side, IBM has deep enterprise relationships and is very good at, let's say, long sales cycles.

That might mean better integration with big company identity, governance, on -prem stories, all of that. On the minus side, Every time a company like this gets acquired, there's a non -zero risk of focus shifting to bundle this into everything instead of make the core service amazing.

If you're on MSK or self -managed Kafka right now, I don't think this is an immediate you chose wrong moment, but it is a reminder to check your own vendor concentration. If the same company controls your infra control plane, your secret management, and your streaming backbone, you should at least have some kind of exit plan on paper.

Not because you're going to use it tomorrow, but because you really don't want to start thinking about migrations the week after a pricing email lands. So the homework here is simple. If you use Confluent anywhere, write down what Plan B looks like. If you don't, decide whether this acquisition makes you more or less likely to adopt it in the next couple of years.

And maybe keep an eye on what IBM does next in the infra -AI space, because they're clearly not done shopping. Alright, let's talk about something more urgent. React to Shell. React2Shell is one of those vulns where the score is 10 out of 10, and unfortunately, that's not an exaggeration. Very short version, React server components use a protocol called flight to talk between client and server.

There's a bug that lets an attacker send a malicious payload through that protocol and chain it into a remote code execution on the server side. So this is not someone can mess up your CSS. This is someone can run arbitrary code on whatever is hosting your react server components. Why should you care if you're just the platform person?

Because a lot of modern front end stacks are now front end plus service side piece deployed as containers into your Kubernetes clusters or your app platform. Those pods are part of your blast radius. If they get popped, the attacker is one cube CDL away. From the rest of the cluster, or one IMDS hop away from credentials. Patches are out in the ecosystem. Next .js and others have shipped fixed versions.

React has guidance, the usual wave of advisories. But there is real exploit traffic in the wild already, and cloud providers and security vendors are seeing this used to drop loaders and pivot deeper. So what do you actually do as a platform SRE person? First, assess inventory. Figure out which services in your world are using React 19, React server components, Next .js with RSC, that kind of thing.

If you don't know, this is a good week to ask app teams some annoying questions. Second, patch tracking. Make sure those services are on the patched versions of their framework. This is one of those we're doing an emergency patch even if the sprint board doesn't like it weeks. Third, guardrails.

If you have a WAF, check whether your provider has shipped React to Shell rules and turn them on in at least monitoring mode, ideally block mode for the exposed endpoints. Same thing for IDS, IPS, or runtime security tools. Fourth, egress and privileges.

Double check the egress posture of those front -end services if an attacker does get code exec, how easy is it for them to phone home, hit IMDS, pull other secrets, or talk to internal services that they really shouldn't? You don't need to become a React expert. You just need to treat this like what it is. A serious server -side RCE that just happens to be writing in on a front -end stack.

All right, let's move from everything is on fire to how one of the big kids is evolving their database story. Netflix published a case study about consolidating a big chunk of their relational database fleet onto Amazon Aurora Postgres. The headline numbers, they quote, are up to 75 % better performance and almost 30 % cost savings for some workloads. Now you should always be a little skeptical of round numbers.

But the pattern is pretty familiar. They had a bunch of self -managed Postgres clusters scattered around. Each one had its own tuning, its own backup setup, its own failover behavior, its own on -call expectations. Over time, that turns into a huge operational tax. Moving to Aurora gave them a few things. Managed failover and backups instead of writing and maintaining that themselves.

A more uniform story for observability and performance tuning. The ability to simplify sizing and auto scaling in a more consistent way. From our side of the fence, the interesting question is not should we be Netflix? It's where do we get outsized value from letting the cloud provider manage more of the boring stuff?

If you have a handful of big, weird Postgres clusters with very tight latency requirements, very custom extensions, or unusual replication topologies, self -managed might still be the right call. But if you have 30 or 50 little to medium Postgres instances that all need roughly the same reliability story and none of them are super special snowflakes, something Aurora -like starts to look pretty attractive.

The trade -offs are similar to what we just talked about with Confluent. You're consolidating onto one managed platform. You get reliability and lower ops overhead at the cost of more vendor lock -in. There's no free lunch there. The takeaway I'd want people to get from the Netflix piece is not, oh, cool, Aurora is magic.

It's you should occasionally step back and ask if the way you're running your databases is still the right shape for the scale you're at now. If you built a fleet of hand -tuned clusters back when you had five apps, that might not be the right model now that you've got 100. All right, let's knock out a quick lightning round. First up, Open Tofu 1 .11.

Open Tofu keeps moving quickly, and 1 .11 brings some nice language features. There's an enabled meta argument you can use on resources and modules to conditionally include things without the old count equals zero hacks. And there's support for ephemeral values, so you're not forced to jam every intermediate into state forever. I'm not going to go line by line through the changelog.

But if you've been Terraform curious about Open Tofu, this is a good excuse to try it out on a small non -critical stack and see how painful or painless the migration is. At minimum, be aware of it so you're not surprised when someone on your team says, hey, can we standardize on this instead? Next, a Terraform tips post from Rose Security that I liked. It's one of those small things that add up articles.

Stuff like using one instead of bracket zero bracket, when you really expect a single value, shaping variables as objects with optional attributes, so you're not passing around random maps, that kind of stuff. This is the kind of post I'd quietly drop into your Terraform channel or internal docs, and then steal ideas from the next time you touch a core module.

You don't have to refactor everything at once, but tightening up the patterns over time does pay off. Third lightning item, Ghosty Going Nonprofit. Ghosty is a GPU accelerated terminal emulator that's gotten really popular and Mitch Hashimoto announced that it is now under a non -profit umbrella instead of being a commercial product in waiting.

I'm not going to pretend that this is a pure DevOps story, but I do think it's interesting to see a dev tool with this much traction explicitly choose a non -profit ownership model. After watching things like Terraform's license change and all the drama around OpenCore tools, it's kind of refreshing to have a core tool say, nope, this is going to be community governed.

And last lightning item, spec -driven dev with AI. GitHub released SpecKit, and there's also a project called OpenSpec from Fission. Both are playing in the same space. Instead of just prompting your AI assistant with, hey, write some code, you start with a structured spec that says what you're building and how you'll know it's correct. And then you let AI generate plans, code, and tests anchored to that spec.

From a platform perspective, I think this is the only sane way AI is going to touch infrastructure at scale. Imagine a spec for new service on our platform, or standard Kubernetes app, or new CI pipeline, and then the assistant uses that spec to generate Terraform, Helm, and policy that fits your patterns. We're not there yet in most shops, but watch this space.

It's way better than let the bot randomly edit production yaml. Alright, let's talk about incidents and brains for a minute. For the human bit this week, I want to pull from an article called Your Brain on Incidents. It's about what major incidents actually do to people, not just systems.

If you've ever been on a multi -hour call where everything is breaking and the pager will not shut up, you already know the feeling. Tunnel vision? Bad decisions, snapping at teammates, that sort of thing. The article talks about cognitive load and stress responses in a pretty approachable way.

When you're in an incident, your brain is juggling a ton of context, logs, dashboards, Slack, tickets, leadership asking for updates. On top of that, if you don't feel safe saying, I don't know, or we need to slow down, your brain goes into pure defensive mode. That's where blamey cultures make everything worse.

If every mistake gets dissected in the most painful way possible, people will hide information during the incident and the postmortem. You lose exactly the insight you need to get better next time. So what do you do with that as an SRE or platform lead? One, Be explicit about expectations during big incidents. It's okay to say we're going to pick one hypothesis at a time and we're allowed to be wrong.

It's okay to say someone needs to be the scribe and someone needs to tell leadership to wait five minutes for an update. Two. Design your incident process so it takes some load off of the humans. That could be better run books, better dashboards, or just a clear template for how to structure a Slack channel during an event.

Three, in the review, focus more on how people reasoned under pressure and less on who typoed the command. You want people to feel safe saying, I was fried and I misread the graph, because that's how you find systemic fixes. And maybe most importantly, remember that people have a limited number of massive incident nights in them before they burn out. That's not a moral failing, that's just biology.

All right, that's it for this episode of Ship It Weekly. We talked about IBM buying Confluent and what that means for streaming and vendor risk. React to Shell and why a React Vuln absolutely still belongs on your platform radar. And Netflix moved to Aurora Postgres as an example of rethinking your database fleet. In the lightning round, we hit Open Tofu 1 .11.

Some Terraform cleanup ideas, ghosty going non -profit, and spec -driven development with AI instead of free -form prompt chaos. And we closed with your brain on incidents, and a reminder that your systems aren't the only thing taking damage during a bad outage. I'm Brian, this is Ship It Weekly by Teller's Tech, thanks for bearing with the cold voice version of me.

I'll drop the links for this episode in the show notes and I'll see you in the next one.