Ship It Conversations: Erik Osterman of Cloud Posse on Terraform Modules, IaC Frameworks, Atmos, Internal Developer Platforms, AI Agents, and Why Conventions Matter More Than Ever

Transcript

AI can write a lot of infrastructure code now.

But if every team organizes Terraform differently,

names resources differently, handles authentication

differently, and reinvents the same deployment

patterns, faster code generation does not necessarily

mean better infrastructure. That is where conventions

start to matter. Because the real leverage is

not just getting AI to write HCL faster. It is

giving it a framework, a golden path, and enough

context to know how your organization actually

works. I'm Brian Teller from Teller's Tech, and

this is Ship It Weekly.

Welcome back to Ship

It Weekly, where I filter the noise and focus

on what matters when you are the one running

infrastructure and owning reliability. Most weeks,

it's a quick DevOps, SRE, platform, cloud, and

security news recap. In between those, I do conversation

episodes with people building and operating these

systems. Today, I'm joined by Erik Osterman,

founder and CEO of Cloud Posse. Cloud Posse has

published more than 180 public Terraform modules.

And Erik also hosts their weekly DevOps office

hours. We talk about what makes a good Terraform

module, why infrastructure as code needs stronger

conventions and frameworks. And where tools like

Terragrunt, Crossplane, Backstage, and Cloud

Posse's Atmos fit. We also get into internal

developer platforms. Why self-service does not

have to mean another no-code abstraction. And

how AI changes the equation when your infrastructure

already has consistent patterns, agent skills,

and clear deployment workflows. All right, let's

jump in.

Erik, thank you for joining me. Awesome.

Thanks, Brian. Happy to be here. I love to talk

shop about all these topics. So let's just dive

right in. Yeah. So before we started recording,

we were talking a little bit about Cloud Posse

Terraform modules that you all have. And we were

talking a little bit about the industry changes

towards AI development and bug bounty programs

and that sort of thing. I'm curious to hear your

perspective on that. And if you've been affected

at all by... by the AI slop that has been hounding

open source initiatives. We've been following

it pretty closely. I mean, seeing what has happened

with curl and it went from hate to love, kind

of. There's been a lot more, I would say, security

researchers coming around and poking and prodding

at things with different levels of experience.

I would say the one bad run-in we had, and I'm

not going to name any names partially because

I can't remember. But there was some security

young startup out there that came out and tried

to say that one of our modules was insecure and

therefore used by hundreds of other modules that

were therefore also insecure because one of the

Go tests was using a package with a CVE. But

Terraform doesn't even run Go tests. So it was

just brain dead stupid. That was the worst run-in,

I would say. Other than that, I would say we

are pretty AI-friendly, accepting lots of pull

requests that have co-committers from Claude

and Cursor and other. And if anything, it just

makes things easier to review. Have you seen

an influx over the last year? It's hard to say

exactly. What we've seen is a steady stream of

pull requests still coming through to all of

our repositories over the past year. But I would

say it's fairly down from, let's say, the heydays

of 2021 when there wasn't any other really mature

alternative to using open source. We're not delusional

in the sense that companies these days aren't

using AI to write infrastructure as code, as

they should be, as we are using it to write our

own modules. I think that doesn't invalidate

open source. If anything, it just shows the resiliency

of open source that it takes on different value

at different phases. So when you're creating

these modules, how do you decide what becomes

a module versus what stays a pattern or example?

Yeah, it's a good question. And an interesting

thing about that is we, you know, so we started

the company in 2015. And from 2015 to 2021, I

would say we were adding like dozens of modules

every single month. But the rate at which you

can develop modules is faster than the rate of

new services being developed. So at this point,

you know, it's pretty stable. We aren't releasing,

you know, 50 new modules a year or anything like

that. So we have a pretty opinionated approach

to Terraform, take it or leave it. But the idea

is that all the modules should work well together.

And the first thing there is that there needs

to be a consistent naming convention, consistent

interface to how they work. So interoperability.

And then they shouldn't be so small that they

wrap a single resource because then it's just

unnecessary abstraction. Shouldn't be so large

that you have a hundred inputs because you can't

test that many permutations. So there's a happy

medium or happy balance between that and that's

what you'll see in a lot of our modules. We like

to think that they turn a concept that is pretty

relatable, like what is a VPC, into a declarative

module resource that you can provision easily.

But one of the opinionated things that we've

done differently at Cloud Posse, for example,

is keep the subnet architecture separate from

the VPC because there are lots of different strategies

for how you construct your subnets. Just one

example of how we've thought about it. One of

the biggest confusions that we get from our community

is what is the difference between a root module

and child module? A good interview question also.

So yeah, what is the difference? So in Terraform,

a child module never has state. And that's the

simplest way. So you have a root module. That

root module can invoke any number of child modules,

but you don't embed one root module inside of

another. So the root is kind of where you run

Terraform. But it's amazing how often these concepts

are conflated and not clear, even by practitioners

who've been using Terraform for a while. If they're

operating in a mature environment, they maybe

never started from scratch. Let's say you were

to start it all over again today. Is there any

different framing or philosophy that you'd have

around that? You know, I go back and forth. I

have a constant inner dialogue about some of

these things. And, you know, there's a love-hate

relationship with Terraform. And there's a

love-hate relationship with IaC. And some of these

things, I just wish they could be simpler. And

then when you go look at the alternatives, you

realize that it... It's hard. And here's what

I mean. I think what are the main contenders

today for infrastructure as code, IaC? So you

have CloudFormation. Honestly, my understanding

is CloudFormation dwarfs everything else in terms

of adoption within the side of AWS. Even though

in my echo chamber, nobody uses CloudFormation.

They wouldn't be caught dead with it. Then you

have Terraform, of course, and you have Pulumi.

Pulumi is interesting because they've had staying

power. They've survived. There have been a few

other upstarts that have come around. And we

also know like CDKTF, that failed as a project.

I think it's now spun up as a fork. And there

was another project that came up, Winglang, that

tried to create a whole language based around

being interoperable with cloud and local development

and so forth. Didn't work. So we have these three

staying powers. Then the FOMO I have is... Should

we be instead moving over to something more like

Pulumi and TypeScript or picking the language

du jour of our choice? And I keep coming back

to, I think it makes a lot of sense maybe inside

of a enterprise where they might have more standardization

on one or so languages. But even then, I don't

know if the value is there. Let me explain. So

the problem is with a formal IaC language like

Pulumi, through TypeScript is that you have unlimited

possibility and that creates so much variation

in how the infrastructure is provisioned and

managed and so forth. And sometimes constraints

are healthy. you converge on a few necessary

patterns. And I think that's what's led to HCL's

dominance in IaC. Because it's limiting, it's

led to greater interoperability because of the

module ecosystem. You see so many, there are

tens of thousands of modules out there, conservatively

speaking. And it's because of that that it works.

But you don't really find CloudFormation libraries

or architectures out there in the same capacity.

Or if they are, they were meant to be forked.

They weren't meant to be embedded and reused.

And I can't speak to Pulumi what the health of

the ecosystem is of supporting kind of architectures

around Pulumi. Maybe practitioners would say,

well, you don't need it. Yeah, I would say the

majority of use cases I've seen for CloudFormation

is for vendor-specific setup for IAM or a vendor

control that needs setup. And I mean, that is

one of the beautiful things about CloudFormation,

let's be honest, is that you can represent an

architecture in a single document, lob it over

to the API, and it materializes those resources

and reconciles it, which is nice. I've often

thought about this, like, what I would love to

see is an endpoint that speaks like the Kubernetes

protocol. But the fact that it's Kubernetes or

anything else, I don't even need to know that.

It's an implementation detail. I want something

where we can declaratively describe what our

architecture is in resources that is as convenient

as Kubernetes without... Any of the overhead.

I never want to have to think about updating

a controller or deploying a new version of an

operator, spending, you know, one week, a quarter,

updating 16 clusters a month, a year, basically,

just upgrading clusters. I don't want that. So

I want the convenience of CloudFormation with

the power of a Kubernetes manifest to manifest

infrastructure. So do you use Crossplane? Well,

no. So this is an interesting one. For a long

time, I had FOMO on Crossplane as well. And

speaking to its strengths, from my perspective,

where the FOMO is, I mean, it's pretty elegant

when you have. If you can assume that you have

a cluster that is managed by other people, so

other people's problems, OPP, and all I have

to worry about is I have a Crossplane endpoint

and then I can manage everything else that way,

then it sounds kind of nice. I still have concerns

about understanding what infrastructure is changing

and what I would manage under a Crossplane.

And let me explain. This gets down to the internal

developer platforms topic that we want to talk

more about. I think one thing that's so glossed

over is that you have basically layers of infrastructure.

Crossplane solves, and it's very important.

but a very small sliver from our perspective

of what it takes to operate at scale on AWS.

And what does at scale mean? It's thrown around.

Let's talk, you know, enterprises that operate

with hundreds of accounts or at a minimum dozens

of accounts. You have a complex network architecture.

You have an IAM architecture. You have a DNS architecture.

Managing TLS certificates is even just a challenge,

right? So at the point you have the privilege

of only worrying, about how you deploy these

cute little things on top of Crossplane. Yeah,

that sounds pretty good. How are you solving

everything else? And you're not doing that with

Crossplane. No, that's a fair point. Every implementation

of Crossplane I've seen typically has Terraform

as the setup of the actual cluster and everything

beyond that, like at the application level is

maybe Crossplane. But yeah, it's a chicken egg

problem. You still have to start somewhere. Yeah.

Yeah. But before you have the cluster, Well,

before you have Crossplane, you need the cluster.

Before you have the cluster, you need a network.

Before you have the network, you need the account

and you need the IAM. And then you need, well,

if you're having networks, you need a network

architecture. And in order to be able to do anything

with the cluster to access it, you need a DNS

architecture. And then how are you delegating

the zones and where is that zone going to reside?

And then it just, it spirals so quickly. And

it's so convenient when somebody else has to

worry about all of that. I've spent, it's pretty

nuts in this era of specialization, right? I've

spent the last 11 years of my life at Cloud Posse

focused on zero to one. Just how do you go from

having no AWS infrastructure to getting ready

to deploy all your stuff on top of Kubernetes?

And that has brought an interesting perspective

to things that you can spend a whole life, virtually

a career on just cold starts on AWS. Yeah. I

say that with humility. So you had mentioned

IDPs. Are you using IDPs? Do you find those useful?

And do you have a platform team that manages

that? Yeah. And what that means, I think, will

mean different things to different people. So

let's qualify this. We're not talking identity

platforms, but internal developer platforms here.

And there's been, you know, the OG on the block,

let's say, would be maybe Backstage. If we're

talking about internal developer platforms, there's

some commercial offerings. There's a company

that spun off doing Backstage service and others

as well. But this is an area, like if we're talking

zero to one, this happens after one. And so we've

been a little bit less focused on like helping

companies adopt something like a Backstage. But

here's what I think is often misunderstood.

It is easy enough to ClickOps up that Kubernetes

cluster and then, you know, deploy the Helm chart

and you are up and running. You got Backstage

and now let's get to business. But I mean, if

we're building something that's going to have

lasting value for the company, it is, I don't

know how to say it. It's like getting the, what

do you call it? The outside of a car without

any of the machinery, without the frame and starting

there and then saying, we will add in. the frame,

the motors, the wheels later, rather than starting

from the foundation and building up on top of

the pan and putting things on. So that's, yeah,

that's the most important thing, I think, is

you got to get the framework in place that enables

you to deploy software of which Backstage is

just one and an enabler for other things or other

capabilities that you choose to have. The teams

that I see that do that, though, Like effectively,

like they often have teams whose problem is Kubernetes

and that's what they're managing or their problem

is managing that IDP because it ends up being

a big investment. So where it works is in enterprise.

Yeah, Spotify also says like six to eight developers

full time. I mean, realistically, you're not,

yeah, you're not, you don't have the manpower

to run that. And yeah, we... I mean, we see this

all the time, right? Like, look, I love Kubernetes

as much as the next person who loves Kubernetes.

But I've always taken this standpoint. We never

recommend Kubernetes to a company that doesn't

first come to us saying they want Kubernetes

because you have to kind of opt into the pain

and understand the trade-offs. So when it comes

to that, why I bring that up is kind of like,

well, you got to know what you're signing up

for when you're trading. You're enabling a lot

of team members by committing to maintaining

this one centralized platform. And centralization,

well, we've learned what that does. So are a

lot of your customers, do they have like a monolithic

application? Or do they already have that microservice

architecture set up? Or is it a split? It is.

We've seen everything. We've seen everything

from people running a large monolith on a Kubernetes

cluster. It's like, and why? To, you know, overly

architected microservices architectures, which

is kind of like just asking for pain because

they're not at the scale where that makes sense.

And I remember what I was getting to is like,

we take a lot of our guidance. I mean, us as

an industry, as practitioners, we look at the

giants and what they do, right? And that's where.

Kubernetes came from and that's where network

defined architectures and that's where Backstage

and all these things came from. And they made

a lot of sense when you are at that scale, but

they don't necessarily make sense at the starting

point. So we see, I would say the biggest pattern

that I've seen lately is teams adopting a

poly-mono repo approach where they having a strict

poly repo approach where you have one service

per repo has has its challenges when you start

having hundreds of repositories and managing

that at any scale in organization to the extreme

opposite, the Google-style monorepo where you

have a thousand services inside of one repo and

the cognitive load that comes along with that

I can acknowledge the beautiful things that can

also happen with a monorepo. But a lot of teams

also don't have the sophistication to operate

things like Bazel the way that Google does. Therefore,

where I'm seeing is a really nice hybrid model

where you have a number of repositories in an

organization with a collection of services that

are loosely related to each other and don't have

tight couplings across. Because you never want

to have two services tightly coupled across two

different repositories or you're in deployment

hell. Good point. Okay, let's shift gears. So

one of the things that you had mentioned to me,

I think, before we scheduled this was you said

that the majority of work is now generated with

AI. And it works because you have strong IaC

frameworks, conventions, and golden paths. What

changes made it real? Yeah, this is a sore point

for me. I spent a lot of time thinking about

it, a lot of time lamenting about it. How teams

manage infrastructure as code today? It's not

new. I mean, I've been at this for 11 years and

even then it wasn't new. 11 years is a long time

for a language to exist. And let's look at every

other mainstream language today being used for

software development that is being vibe-coded

at what I like to say in vibe years, like moving

really fast. And they have frameworks. Nobody

starts a modern project in JavaScript unless

for like some weird fundamental like philosophical

reasons, and that project probably isn't going

to see the light of day. They start with React,

they start with Next.js, they start with Rails

or Django, or, you know, the list just goes on and

on and on, because frameworks give a convention

to the team to operate. And that includes

documentation. It includes nomenclature, how you

refer to things, concepts, strategies, best practices,

design patterns, and the list goes on and on

and on. Yet our community within IaC has a purity

test when it comes to Terraform that we don't

use wrappers or no, we just got to write vanilla

Terraform. But it's a lie to themselves and it's

a lie to the organization because nobody ever

does. When you only think of Terraform, it doesn't

actually do anything. It provisions a resource,

but it doesn't handle how you are going to promote

that resource, how you're going to reconcile

it that it was actually deployed, how you are

going to scale it up across multiple team members,

how you're going to lay things out on the file

system, how you're going to manage the state,

are you going to have lots of different state

files, how you're going to... And then once you

realize that you're going to need to solve some

of these problems, and if you've already committed

to a path, well, you got to go back to basics

and re-engineer it. So what we have is all these

teams working concurrently on the table stakes

of what it is to do infrastructure and reinventing

the wheel over and over and over and over and

over and over and over again, and just writing

HCL because you don't get anywhere. So where

I'm going with this is we as a community need

to gravitate towards frameworks, just like

you have in real languages. And to say that Terraform

or HCL is just a configuration language is, I

think, insincere these days. You have loops and

iterators and modules and call modules and interpolations,

and it gets complicated real quick. So we need

conventions and we need frameworks. And this

is where we've kind of... gravitated towards

at Cloud Posse, we started back in 2019-ish working

on a project called Atmos. Atmos is... an IaC

framework. It's based on open source. It's what

we invest in. And it brings those conventions,

you know, project layout structures, handling

how you do authentication, handling how you install

your toolchains, handling how you do versioning,

handling how you do software promotion, all these

things that everybody has to figure out. We've

published and well documented exactly how to

do that. So this is what I think we as a community

need to do. Not necessarily our project. Look,

there needs to be competition. Somebody else,

please start a competitor. But if you're not

in the business doing competition, just use Atmos.

Well, that was kind of the idea with Terragrunt

to a degree. I mean, right, they were trying

to solve some of the fracturing of state files

and being able to automate some of that, keep

things DRY. But it didn't solve every problem

either, though. It is. So Terragrunt is an excellent,

they were the OG way. Once you started doing

any sort of serious Terraform, you quickly reached

for Medium and said, somebody must have solved

this. And then you came across Terragrunt and

you found that. And I think they've offered a

tremendous amount of value for a long time and

provided the community ways to do some of these

things. What I still challenge is that they

don't provide idiomatic ways of organizing and

architecting infrastructure, at least to the

degree that I think is required. So how do you

solve, how do you architect? This is why like

every week, there are like 10 posts on Reddit.

How do I organize my infrastructure for

multi-account? Over and over and over and over and

over and over and over again. And the answers

are the same. And from our perspective, always,

always incredibly inadequate. As a company who

spent 11 years only focused on cold starts. So

this is what we call design patterns and how

you organize your projects for AWS is slightly

different from GCP, is slightly different from

Azure and so forth. But there are really nice

golden paths that eliminate the thought process.

And this is the other thing that I love about

frameworks, and we'll tie this back to AI here

in a second, is that when you have a proper framework,

it reduces decision fatigue because you just

follow the conventions that are in place. This

comes down to how you name your resources. Highly

recommend you have a naming module or a naming

provider that gives you programmatically consistent

names. You just got to plug in the fields and

your resource names are always the same. It's

not like, is it prod cluster region service or

service cluster region prod? It just normalizes

and standardizes that. And then, well, which

folder do I put this in or where do I put? All

of that is handled by the framework. Here's the

beautiful thing. When you adopt a framework,

especially one like Atmos that has an insane

amount of documentation and conventions, and

every AI model now has been trained on it, it's

pretty amazing because you can literally ask

it just to build you out an architecture in a

conventional framework-esque manner. So how

do you organize your components and folders?

How do you organize your configurations for those

components? How do you install your tools? How

do you handle authentication? And this has been

one of the realizations we had over the past

year is that every team needs to solve how you

even get your tools installed. And that's different

whether you're running in GitHub Actions, whether

you're running on Linux, whether you're running

on Mac or Windows. How do you get Terraform,

OpenTofu, AWS CLI, all those things? There's

a different way to do it. And that leads to inconsistency

and a lack of reproducibility. Frameworks give

you reproducibility. You'll know you'll have

that when your pipelines become boring because

they run one command and everything is handled

by your framework. Authentication is another.

Before you can even run Terraform, you need to

be authenticated. And Terraform, yeah, it can

do some role assumption based on your ambient

credentials, but that's pretty weak. As a human,

I need to integrate with single sign-on and

log in that way. Maybe I need to break glass

with an IAM user. In GitHub Actions, I need to

exchange an OIDC token for my AWS credentials.

And then I need to rinse and repeat that for

Windows, Mac, and Linux. And then if we're

multi-cloud, oh my God, let's start this project all

over again and do that for Azure and do that

for GCP. And these are just the table stakes

to get started with running Terraform. So a framework

should handle that. And that's what Atmos does

too. So Atmos normalizes authentication, works

with all of these things and gives you just the

credentials you need to run Terraform. So now

you can have your local skill files in your repos.

You can use a framework like Atmos in each one

of your application repos. And when your team

goes to do anything, they can just talk with

their, I heard a great term, their ADE. There's

no longer IDEs, right? It's ADEs, Agent Developer

Environment. So these days, you know, you have

your vertical tabs on the left with all your

sessions and different worktrees, but you're

just conversing with, you know, Claude Code or

Codex, et cetera, and manifesting the infrastructure

you want. This is what's so cool. Now you have

a framework, you have your skills, all of these

things you can, and this is what we're doing

at Cloud Posse every day now, is we're just conversing.

and having the infrastructure built, running

it through the pipelines that are in place, and

it works. It's awesome. So I've attended a couple

of DevOps office hours and heard the project

growing over time. It sounds interesting. I haven't

had a chance to actually use it in production

because every company I've worked at is kind

of locked into what they've already implemented.

Yeah, that is true. Is there a good migration

path? Yeah, that's a great question. So historically,

we've had a really bad story on that. And if

anybody listening has tried Atmos in the past,

they might have realized that it was hard to

do in a brownfield environment. One of the things

that we've really invested in in the early days

of Atmos was programmatic consistency. And that

is a double-edged sword. If you are in an environment

that is not programmatically consistent, from

naming conventions to tag conventions to how

things are organized, it used to be incredibly

painful to use Atmos because it tried to enforce

conventions where there were none. Well, over

the past year, and I have a graph somewhere,

it's just insane. If you look at, you can barely

see the activity on Atmos compared to the activity

we've had in the last year. because of the influence

of AI. And with that has come a tremendous investment

in developer experience. So now it works really

well in brownfield environments. We've helped

companies have existing Terragrunt architectures

adopted into the Atmos framework. We've had companies

who had just their hodgepodge scripts and things

like that, want to bring it into Atmos. Now you

can do that and benefit from, here's the thing,

adopting a framework won't magically turn, is

not a silver bullet. If you have an inefficient

application and you just load it into Next.js,

it isn't going to be magically scalable, right?

You have to build it that way from the scratch.

However, you can bring it in and build everything

new that way. So now you have the benefit of

a consistent way of developing what you had.

But without rocking the boat too much and doing

that. And then building out new things in a way

that makes service-oriented architectures a little

bit easier. Now, we haven't talked about that,

but this is really what we're doing when we're

doing Terraform these days. A lot of companies,

when they get started, when they do Terraform,

they have a monolithic infrastructure code base

with Terraform. One root module with dozens and

dozens of child modules maybe and instances of

those and factories of child modules inside of

a root module. But this is the equivalent in

application development of having a monolith

because every change, that whole thing is deployed

as a unit in a container and shipped out. But

in service-oriented architectures, notice I'm

not saying microservices. Microservices is an

implementation of services-oriented architectures.

You break that in, break that apart. How you

break it apart, that depends on the company.

We like to say the things that typically change

by themselves are good candidates to break out

into their own services. And then now if you

use a framework like Atmos, you have this option

of starting to peel things out of this monolithic

Terraform root module that you have into individual

services that have their own lifecycle. And then

they can start to share states between the monolithic

core where you started. We like to call it your

heritage environment. And then into your individual

services. Very cool. Okay, so wrapping up, one

thing you had also mentioned was self-service,

enabling self-service without adding layers

of abstraction and no-code platforms. What does

that look like at a real org? Yeah, yeah. I guess

there are three things that I really love about

AI as an engineer. One is I never need to worry

about merge conflicts anymore. Those are handled

for me. So in terms of a team environment and

collaboration, you can move a lot faster, step

on toes, and just have the AI resolve those merge

conflicts. Refactoring became a lot easier. So

the cost of making certain mistakes is less.

Not zero, but is less. And team enablement. So

if I had to solve it once... We have as a practice

internally, every new service that we develop,

every new application we develop, it comes with

its own skills. And if someone's not as familiar

with this, there's an open standard. Go to

agentskills.sh or .io. I forget which one it is. And this

is basically what Claude pioneered, but has been

embraced by every major ADE out there. The ability

to have these markdown files, basically. And

it used to be that WikiOps was pejorative, but

now it is a sign of a healthy project because

the agent can follow those things. So getting

back to your point here, how this enables platform

teams. Now, make sure you have a step one, pick

a framework. Ours or someone else's. Step two,

codify your agent skills. Step three, solve how

you are going to do your. Code reviews, because

as you open this up for more developers to contribute,

you're going to be buried under code reviews

and PR reviews. So you have to solve that and

then solve your deployment process so those are

painless and they just go up. And that is the

replacement for these no-code platforms. I

think that was the other point I was going to

say. The saving grace of AI is that I don't need

to rely on a no-code platform. I want code as

an artifact. I want it to meet me where I am

in my agentic editor, and I want the power of

the MC... Oh, dude, that's the other thing we

haven't even talked about, but MCPs. I know there's

some FUD out there that MCPs are dead and that

you just need CLIs. They are not. They serve

a specific purpose that will make a lot of sense

once you start using them and save on your context

and your tokens. But like MCPs for AWS, MCPs

for your telemetry, MCPs for your exception tracking

and your logs, MCPs for any of your internal

services. And you put those things together with

agent skills in a service repo that you deliver

to your users, and they are up and running in

no time. It is just magical to see these things

come together. Yeah, no, for sure. I have developed

a lot of MCPs, as many as I can, just because

the more context you can give and the more authentication

paths that you can give to your AI, the better

information you'll get back. So yeah, totally

agree. And the enablement it offers, right? It's

enabling the developers because I mean, most

developers I know, the reason why they write

something from scratch is they just didn't want

to have to ask for help. So if you meet them

where they are in their editor before they start

writing from scratch and they give them the skills,

give them the MCPs, my gosh, they're going to

move really fast and blow through your token

budgets. For sure. So where can people find out

more about you, more about your projects? Yeah,

we are very visible, very out in the open. Of

course, there's cloudposse.com, which is our

commercial site. It talks about some of our commercial

reference architectures that we do using our

framework. There is our project called

atmos.tools, which is where we talk, where we have

all the thorough documentation on our framework

for IaC. I didn't mention, but like we handle

Ansible, Packer, Terraform, Helmfile, and more

types of components are supporting, are coming

out for that as well. And on LinkedIn, of course,

we'd love to connect with anybody on LinkedIn,

linkedin.com slash in slash Osterman. And you'll

find me there. Awesome. I'll leave links for

all those in the show notes as well. Erik, thank

you so much for coming on. Really appreciate

it. Thanks, Brian. I had a great time. That was

my conversation with Erik Osterman, founder and

CEO of Cloud Posse. The biggest takeaway for

me is that AI makes conventions more valuable,

not less. If every team has a different Terraform

layout, naming scheme, authentication flow, state

strategy, and deployment process, AI can absolutely

generate code faster, but it is still generating

into chaos. Where things get interesting is when

those decisions have already been made. There

is a framework. There are known patterns. Authentication

works the same way locally and in CI. Resource

naming is predictable. Teams know where components

belong and how changes move through the pipeline.

Now, AI has something consistent to work with.

I also liked Erik's point that Terraform itself

does not solve all of infrastructure as code.

It provisions resources, but teams still have

to figure out everything around it. State, promotion,

authentication, repository structure, tooling,

and how different environments fit together.

Every organization ends up solving those problems

somehow. The question is, whether you intentionally

adapt conventions or slowly build your own undocumented

framework without calling it one. And that connects

directly to self-service. Maybe the future is

not another portal hiding infrastructure behind

more buttons. Maybe self-service is giving engineers

a well-defined framework, good documentation,

agent skills, MCPs, and the ability to work through

the tools they already use. The code still exists.

The architecture is still reviewable. But the

amount of context that somebody needs before

they can contribute gets much smaller. So my

takeaway is to use AI to eliminate the repetitive

parts, but give it structure. Standardize the

decisions that do not need to be made over and

over again. Build conventions that both humans

and agents can understand, and make the paved

road good enough that people actually want to

use it. You can find Cloud Posse, Atmos, Erik's

work, and DevOps Office Hours through the links

in the show notes. Follow or subscribe to Ship

It Weekly wherever you listen, and find previous

episodes at shipitweekly.fm. Thanks for listening,

and I'll see you later this week.

Ship It Conversations: Erik Osterman of Cloud Posse on Terraform Modules, IaC Frameworks, Atmos, Internal Developer Platforms, AI Agents, and Why Conventions Matter More Than Ever

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Additional Links

Show Notes

👤 Guest

More from Ship It Weekly

Cloudflare Saves 100TB of RAM, AI Drives Server Prices Up, AWS Adds a Fourth London AZ, Route 53 DNS Self-Service, AKS eBPF Routing, Go 1.27, and the Danger of Hidden Infrastructure Assumptions

Ship It Conversations: Ned Bellavance of Ned in the Cloud on DevOps Beyond the Buzzwords, Terraform, AI, the Future of Infrastructure as Code, and Why Fundamentals Still Matter

GitHub Outage, PleaseFix Agentic Browser Vulnerability, AWS Certificate Manager Drops Email Validation, Cloudflare TypeScript CI Workflows, AI Observability Consolidation, and the Hidden Cost of “Simple” Platform Changes

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

Get the next episode in your inbox