Ship It Conversations: Evan Phoenix of Miren on Deployment Pain, Terraform, Waypoint, and Better Defaults for Small Teams

Transcript

Deployment was supposed to get easier. We got

cloud platforms, containers, Kubernetes, Terraform,

GitOps, internal developer platforms, and now

AI agents that can generate code faster than

most teams can review it. And yet, for a lot

of teams, shipping software still feels weirdly

painful. Not because people do not know how to

deploy. Because deployment is where all the hidden

complexity shows up. The app stack, the runtime,

the registry, the secrets, the networking, the

database, the cloud provider, the rollback path,

the weird internal Jenkins job nobody wants to

touch. And for smaller teams, that can be brutal.

They do not always need every knob Kubernetes

gives them. they do not always need a giant platform

engineering program. Sometimes they just need

a clean way to build, deploy, get logs, roll

back, and move on. So maybe the future of deployment

is not more flexibility. Maybe it is fewer decisions,

better defaults, and picking the right opinions

to outsource. 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 actually matters when you are the

one running infrastructure and owning reliability.

Most weeks, it's a quick news recap. In between

those, I do conversation episodes with people

who are building platforms, running infrastructure,

organizing events, and thinking through where

this industry is actually headed. Today is one

of those conversations. I'm joined by Evan Phoenix,

CEO of Miren. Evan previously worked on Terraform

Enterprise and Waypoint at HashiCorp. And he

also built Puma and Rubinius. We talk about why

deployment is still painful. What teams keep

getting wrong when they try to simplify it. And

why small teams may not need more knobs. They

may need better opinions. There is also a good

thread in here around Terraform. OpenTofu, Terragrunt,

Waypoint, platform abstractions, and what happens

when tools make users do too much homework before

they get value. We also get into AI because yes,

AI can generate infrastructure code, but when

that generated deployment setup breaks, who is

on call for it? And does anyone actually understand

why it was wired together that way? So if you

work in DevOps, platform engineering, infrastructure,

developer experience, or you have ever stared

at a deployment system and thought, why is this

still so annoying? This one should be worth your

time. All right, let's jump in. Today, I'm joined

by Evan Phoenix. He is the CEO of Miren, previously

worked at Terraform Enterprise and Waypoint at

HashiCorp. and he built Puma and Rubinius. We're

talking about why deployment is so painful and

what teams keep getting wrong when they try to

simplify it. Evan, thank you for joining me.

Oh, my pleasure. Glad to be here. So walk me

through your history in tech. It's kind of interesting.

I'm curious. How did you land where you are now?

Well, I'm old enough that I graduated from college

right after the bubble burst. The dot-com bubble

burst. And so a lot of my career is actually

informed by lack of opportunity post bubble bursting.

I did all kinds of crazy interviews trying to

just get any job. I almost wrote web Perl

for many interviews and stuff like

that. I couldn't get anything. And so I end up

working for like a tiny ISP in Seattle. And then

from there, I kind of just. was sort of scrapping

i was like you know i met a guy in a hallway

and he told me about this company he's working

at and so i went to lunch and the lunch turned

into a job interview and i worked at that company

for a number of years and so like i didn't have

any a moment where it was like oh there's this

big thing and so i kind of was jumping around

and the other out the other part of it was i

started doing open source work in the late 90s

at this point. And I did it all the way through

college and then into my first few jobs. My first

few jobs were, I was working at a three -person

ISP. So I wasn't programming. I was like, open

source is what I had for programming. And so

I did that for a long time. And then I actually,

the company I was working for in Seattle at the

time was spinning down. I had a Ruby project

and I actually got. hired by Engine Yard, for

people who remember Engine Yard from the Ruby

days, and to basically work on Rubinius, my Ruby

implementation, and then also help out with sysadmin

work. And I kept ignoring the sysadmin work and

just working on Rubinius. And so they were like,

I'll just do that. So I got to work on my open

source project for like five years. They just

basically paid me. It's like living the dream.

And so like that. sort of balance like working

on open source and then finding a job and finding

interesting things and working on open source

has been this sort of constant thing and then

it it carried me through many jobs it carried

me into uh a startup that i had before HashiCorp

and then HashiCorp is a great sort of like job

and open source thing that carried me all the

way through that and then my current venture

Miren is a similar sort of thing it's like job

and open source and all kinds of things and so

yeah it's been that's the that's the short long

version Very cool. So my first job was, to date

myself to a degree, was doing dial -up tech support.

Yeah. Me too. That was the ISP. Yeah. I did dial

-up tech support. I did DSL tech support. And

then we were putting wireless antennas on people's

houses around Seattle. For long range. Yeah.

It was sort of long range. But yeah, directional.

Yes, yes. But big antennas. That was actually

how I got the, how that guy in the hallway talked

to me was because I was carrying a giant antenna.

And he was like, what is going on here? And I

explained it to him. He's like, we should have

lunch. And then, yeah, one thing or another.

But yeah. That's awesome. So where does Miren

fit in? What is Miren and how does it fit into

the ecosystem? So, I mean, it's a software deployment

system. It comes out of me constantly feeling

like we are always struggling with deployment

systems, right? Like people, I have... People

have lots of great ideas and especially now with

coding agents, you know, getting an idea out

there and getting it like, oh, my gosh, I got

this idea and I want to put the code together.

And then you have to figure out, like, how do

I give this to somebody? How do I let somebody

else use this? It's always like it breaks you

completely out of your rhythm. And so the like

one of the original ideas was like, how do we

integrate deployment? actually into sort of the

software development life cycle right so that

it's like it's not this thing where like i spent

all this time and now like oh god now i got to

deal with deployment but it's like oh deployment

is part of that i go through a deploy i can get

the logs it feels like it's part of the process

and so i i've worked with Kubernetes i worked

with Nomad i worked with lot most of the AWS

products to do deployment and i felt like They're

always missing something. And I wanted to feel

like I had my own things to say about where that

fit in. And the first cut of it is a self -hosted

piece of software. So it's open source. You go

and you run it wherever you want to run it. And

so that makes it very accessible. That opens

the doorway to lots of different people who have

different needs. You want to data sovereignty.

You want, oh, I'm really cost conscious. I want

to run it in one particular way. And one of the

big things. to do it for us was like, hey, you've

got this open source. You can run the deployment

system on your laptop. You can just deploy to

your laptop. And then when you're going and you're

deploying to production, it's the same. It's

exactly the same. And so you've got all of these,

all of your rhythm about how do I do it and how

do I work is exactly the same. And so now you

become that much more comfortable with the system

and then you can sort of grow with it. That's

awesome. That's great to hear. Okay, so. Why

is deployment still such a mess after years of

platforms and abstractions? Why? What's going

on? Yeah, I mean, it really is the final boss

in some ways of software. I think that it has

to do with a few different things. I think that

if we all were working in sort of one stack.

one system, I think it would be a lot simpler.

I don't think we'd be as happy, but I think that

deployment would be simpler. And because then

there would be just fewer knobs. There'd be,

you know, like all the, you know, if Java, maybe,

maybe not. I mean, it's not like Java beans really

solved all of the problems of the, you know,

like the late 90s, early 2000s. But there are

so many different shapes that an application

comes in. And some of that are just within the

stack. One JavaScript app could be completely

different and have a completely different profile

than the next one. But then you multiply that

matrix by all the different stacks and all the

different things. And now you've got sort of

a giant 3D cube of different ways that an app

can behave. And I think that deployment systems

try to say, OK, I want to do I want to give the

power of all of these things all at once? And

if so, I have to let you configure every possible

thing on here so that I can have every possible

stack here, right? And sometimes they're like,

well, that's really too difficult. Most people

are in this one quadrant. Let's actually focus

on the kind of apps that look in this shape,

your HTTP apps, request times under a second,

whatever it might be. And great, let's sort of

focus on that and try to distill down the needs

and the function and that kind of thing and make

it better. I think that, I do actually think

it's better now than it used to be. I actually

think there was a time where it was. better than

it is now also but like it's just because of

the number of variables that come into it and

then what each platform each platform wants to

have a unique say on it right so they want to

say like oh well we've got this cool load balancer

and so you should lean on the load balancer and

now i'm like okay i gotta learn load balancer

and i gotta learn all this kind of stuff right

and so or uh you know AWS is like great for like

oh we've got these AWS specific services to like

make your app work in this one way of these different

shapes and so it's the the amount of configuration

the amount of of of functionality that you want

to sort of eek from the platform too you think

ai helps us bridge that gap better i mean in

some ways yes in some ways because it's really

good ai is really good at if you could if a platform

can explain itself The AI is really good at being

like, okay, great. The platform works like this.

I'm going to basically match the app to the platform,

right? So the platform can have a bunch of different

things it does well, things that it doesn't do

well. And the AI can say like, okay, I'm going

to make the app work. You wanted this platform.

Great. I'm going to plug you into it. The inverse

is also true, although I don't think we're seeing

it that much yet. The app exists as this thing,

and the AI is like, great, let me find the deployment

platform that fits this. I don't think we're

seeing that quite yet, maybe eventually. I do

think it's making it better. Okay, so you've

lived through multiple waves of this will fix

it. What did people misunderstand about Terraform

Enterprise early on? You know, we were constantly

trying to figure out the shape of it. There's

a whole Conway's Law situation with Terraform

Enterprise, right? So we were constantly trying

to help people figure out the shape of like,

what should their repos look like? So in other

words, like, should it be like there's a repo

called Infra and it has like a thousand modules

that are basically going and configuring all

these different things. And every time anybody

changes anything, we have to run a plan that

basically touches like, you know. 1 ,500 resources

or something like that, right? Do you want that?

Or do you want like, oh, well, I want my, like,

should it be tiered? So it's like, okay, the

load balancers are a module, a thing, there's

like infra -loadlb, and that's just the load

balancers. And so it was, and I don't know that

Terraform really ever figured this out. even

to this day, if I'm honest. But people were constantly,

that was the big question. We had white glove

service at HashiCorp at one point that was

like, how do I organize my Terraform modules,

right? In a way that's like, that I can apply

them quickly, that reduces the blast radius,

all of those sorts of things. And so I think

that was a really interesting thing that, and

that wasn't Terraform Enterprise specifically,

that was Terraform writ large. I think Terraform

Enterprise was a, The first version of Terraform

Enterprise was the one that I worked on where

it was for people who wanted the experience of

having a platform that ran Terraform for them,

but they needed to have it sort of inside their

silo, whatever that meant. And so we went through

a few iterations where basically it was just

like a – big machine like we scaled it vertically

inside the actual instance and then you would

just it would just run Terraform on on instance

and it was a like so many products when you see

how the sausage is made underneath you're like

this is all we're doing you know like it was

a little bit that in a good way because it basically

made it made the product easy to manage and and

simple and stuff like that like we were constantly

like stripping things out and taking things out

and like you know at one point the product was

dependent upon RabbitMQ and we're like, no, we

need to like tear, like slice this down. Like

that's too big of a complexity for a thing that's

just running on a single machine. And so. Is

that for like worker queues? Yeah, for worker

queues. Because that was, so at the time, this

is Terraform Enterprise is a product before

Terraform Cloud, which is a weird sequencing

because we had Atlas at the time, which was the

thing that predated HCP which was like our

all-in-one platform and uh Terraform Enterprise

existed as sort of a side thing to atlas and

then atlas eventually gets broken apart part

of it became Terraform Cloud we still have

uh Terraform Enterprise and so that rabbit mq

part came from the original vision of atlas yeah

believe it or not i was an early uh customer

to Terraform Enterprise yeah i we so probably

much like a lot of the customers we we had a

pci HIPAA requirement where we needed to have

state files managed locally. We needed to make

sure that everything was self -contained and

then eventually move to Terraform Cloud. Did

you use it in the... You weren't at desk.com,

were you? It was not, no. Was it a forms company

at the time? There's three shapes of Terraform

Enterprise. The first, the shape number one was

only ever seen by like two customers. Oh, okay.

One of which was desk.com when they got bought

by Salesforce. And then the second one was the

AWS only Terraform Enterprise where we basically

shared an AMI and a bunch of Terraform for you

to run it. That was shape number two. Okay. And

then shape number three was a rewrite that I

did, which made it basically Docker -based. And

then you can install it anywhere. I forget the

name of the application that it was built on.

Replicated. Replicated, yes. I remember going

through and dealing with weird Docker IP address

allocation issues. All the time, yes. So yeah,

I guess it was version three. But yeah, it was

a good product. We eventually moved to Terraform

Cloud. And then I think they've since, I don't

know what the company does now. It was a few

years ago. But it got me excited about IaC because

at the time, and this is going to cause a lot

of people to cringe, I was at a company where

we were using Ansible with no state. We were

just using Boto3 to manage infrastructure, some

CDK stuff. So going from that to Terraform was

a huge jump. More recently, the problem you were

describing earlier, just about how do you manage

state files, how do you manage environments,

how do you manage modules, I feel like Terragrunt

has really tried to answer that problem. I don't

know that they've answered it well, to be honest

with you, but I think they've tried at least

to answer some of that dry issue. Yeah. I mean,

they were around right when I was at HashiCorp

because the Terragrunt has been around for maybe

not 10 years, but quite a while at this point.

Yeah. And they had this idea of like, how do

you slice your Terraform and we'll basically

like put it in different shapes. And they were

very successful at basically saying, we're not

going to let you like Terraform in some ways,

let you do anything, let you put files wherever

and let you organize it. However, in Terragrunt

was like, what if I just put like a corral, like

I put like a little, like a little. guard around

this thing you can't do all this stuff it's just

like it's going to work like this and and that

is very powerful from a workflows perspective

because now people are they're having to comport

themselves maybe to this smaller feature set

but they're also not having to think as much

because they're basically being like no it works

like this like i'm supposed to supposed to put

it in these boxes we think about that a lot about

that at Miren because Part of it is what do you

want someone to have an opinion about? Like Terraform

made you have opinions about like file structure

and stuff like that. Right. Terragrunt is all

about like, OK, well, let's not like people have

an opinion about all of these things. Let's just

make those opinions for them and we'll just tell

them what they are. And then they're not having

to go around, go about, figure out, like, should

I have an opinion about this? Like a lot of people,

when they would start using Terraform, they're

like, but just can you just tell me what the

right pattern is? And they're like, well, like,

did you do that? or does it think this or what you

know whatever and so uh they would we would sort

of force them in some ways to have an opinion

about stuff that they didn't really want to have

an opinion about that's fair so where do you

think OpenTofu sits in that opinionated stack

against Terraform Terragrunt yeah at least whatever

other alternatives there are well i think open

tofu is the result of two specific things obviously

number one was a license change without a question

no no no question right but i think that the

second one is part of it which is that the backlog

of potential features for Terraform that we're

sitting in PRs or sitting in issues that the

Terraform team was like no we're not going to

do that no we're not going to do that and so

the the uh The license change catalyzed people

to be like, okay, well, I want a different thing.

And then it got runway because it was like, well,

look at all these PRs. Look at all these really

cool features that Terraform team never wanted

to do that will just do those things, right?

And so now it's like it's growing all these different,

growing in this sort of different direction because

of that, right? It might still exist even if

there wasn't all those features, but I don't

think it would have had the legs that it has

had. if it didn't have that second part, right?

And I think that what's interesting is that I

was at HashiCorp during the creation of OpenTofu.

So we were talking about it and we were trying

to figure out what it meant. And what was interesting

is that OpenTofu was taking on these features

that Terraform was rejecting. for good reason

right so there was a lot of interesting features

there's encryption encrypted state management

was one of the big things that OpenTofu took

on that Terraform was like don't do this do not

like the reason that they didn't do it for the

longest time was because like we we run the math

and if you do this what you end up doing is that

you create like this other big hairy availability

scenario that is now i want to do stuff and now

i've lost the keys to do stuff and now i can't

do anything i'm sort of like really dead in the

water and so they were like an advocate for like

do it a different way right they had all these

different things and so and again like maybe

that's an example of where Terraform was like

actually don't let people do everything they

were trying to sort of rein in the the sort of

field of opinion and and in some ways OpenTofu

is like even wider like now you can do all these

things and maybe some of them are good ideas

but at least people are trying them out so well

in secrets probably shouldn't be in state right

or anything too sensitive or if it is i mean

lock it down otherwise but but maybe that's the

answer like i'm sure they were pushing like Vault

and like using yeah that was really that was

that part of it was really interesting because

that was the sort of the evolution of how of

your state files as definitive reproducible data

right so like one of the reasons early on in

Terraform that Terraform would end up having

secrets inside of it was because they were like

look like the state file needs to be the thing

the the the the jewel that you can use to recreate

whatever you need right and so they they were

like you should put secrets in your state file

because you want to do this and the other thing

and then what they sort of realized over time

was that like that's a that's a hard position

to to have defense for when Terraform depends

on a jillion other APIs. And so it's like, okay,

well, if it already depends on all these other

APIs to work anyway, can't you just make secrets

an API that you have to depend on? And then that

became a thing that they sort of moved towards.

In my opinion, they didn't move towards it. quick

enough like in other words i i always felt like

hey if you're gonna have secrets just make make

a secrets part of Terraform Cloud and let secrets

live there your state files can basically just

like not have secrets in them no matter where

you are you can just sort of outsource the secret

management part to Terraform Cloud um that was

kind of the idea with variable sets though right

i mean yeah whether it's exactly right that's

exactly right yes that's exactly right but it

could have been at a deeper integration level

no right so yeah for sure So what did you learn

about what devs want versus what they think they

want when it comes to tools like Waypoint? Yeah,

well, Mitchell and I started Waypoint in 2019,

which was an interesting time to start a new

product because right in late 2019. And I think

that the thing that we were really focused on

was a control plane. for backend deployment systems.

So it would be like you would talk to Waypoint,

and Waypoint would go off and do things like,

oh, to do that, I need to build a container.

Let me go build a container. And then, OK, great,

I will do this, and I will do this other thing,

and I will do this third thing. And the idea

was it was just a pure workflow engine for deployment.

And it farmed out all of its backends to do different

things. And one of the things that I learned

working on that was You're asking a lot of someone

who wants to use this thing to say it doesn't

do anything until you do all of this homework

first. Right. It was a lot of homework to get

to get Waypoint running. And that kind of sucked.

Right. Like from just from a usability perspective.

But it also it wasn't great from like we're working

on a perspective. One of the things that we we

found out that was like a like a really big hurdle

was people. people would get to the point where

they're like, oh, like, oh, I just saw this on

a system and it can run, it can build Docker

containers. And that part was easy because we

would just say, also run Docker on the same machine

that you want to run Waypoint. Like that was

sort of, we could easily pave over that. But

then they'd be like, okay, now I want to deploy

this to ECS. And we'd be like, okay, well, you

got to go. You have to go configure, like, container

registry, and then you've got to push it to the

configure push to push the container registry,

and then you've got to tell the container registry

over here to pull. And it was like just that,

just getting over the, like, where does this

image go was a leap. It was a big hurdle for

people to get over. Sometimes it was too big.

Like, they wouldn't even get past that point.

And so we worked on it to try to. to pave over

it. One of the things that I did was I made it

so that if you were using, let's say, ECS as

an example, we would automatically configure

a repo inside AWS's OCI registry to push those

images to. So we would kind of just try to pave

over that as much as we could. But the learning

experience I took away from it was like, a pure

workflow engine, it's not enough product. It's

not enough unless there's this really complicated

thing that people are doing that you're like,

I want to come in and I want to just revolutionize

this one segment with a workflow engine. Great.

But deployment wasn't that. And what they really

needed was they needed answers. It didn't need

to be all the answers, but they needed a lot

of answers that were already set in stone at

the beginning. So when I was going to deploy

stuff, I was like, it just deployed. It just

did the thing. And part of that comes out of

the idea of like. again, from HashiCorp that

we learned was people wanted us to have opinions,

right? They really wanted HashiCorp's opinions.

They want to say like, well, okay, well, like

great, it's Terraform, it's Vault, it's Nomad,

but how do I set it up? Like, what's the best

way? All this kind of stuff. They'd constantly

be asking for our opinions, even though we had

these sort of generic tools. And so the takeaway

that I took from it was like, well, let's just

build a really opinionated tool, right? Let's

go in and say, hey, we've got opinions. We've

been working in the field for all this time.

We've got opinions about how this stuff should

work and what it should do and how it should

feel and what the primitive should be. And we

think that if you agree with those things, you

will really like our thing because it just does

all those things, right? It's sort of really

defining that in -group of people who want something

that looks and feels in a specific way. And so

we... When we were working on Miren and from

Waypoint, we took that opposite approach. We're

like, let's just build all the pieces. Let's

build the thing that builds stuff. That builds

the thing that deploys it. Let's not tell people

where stuff's being stored, where the images

are. Let's just make that not a problem at all

that people have to think about and worry about.

And that was a big takeaway from Waypoint, right?

Waypoint, it never really got traction and it

really got its legs underneath it. Partly, I

think, because it didn't have enough opinions.

It didn't have enough opinions about how someone

should actually use this thing. And then just

because of things that were happening inside

HashiCorp at the time, it ends up sort of

migrating over to HCP and then it migrates away

from deployment entirely. It migrates basically

to a Terraform front end. And it wasn't doing

deployment at all towards the end. It was sort

of misnamed in my opinion. But yeah, that was

the big takeaway from those Waypoint-as-deployment

system days. Very cool. So, OK, jumping back

to Miren. And I don't want to turn this into

a product pitch, but I am curious what what I

do want to understand is what you're trying to

fix and like what's broken for small teams trying

to ship. What tradeoffs are you making to keep

it simple? Yeah, I mean, I think that I'll start

on the first one, right? Like what is the what

makes Miren sort of interesting is that. And

where do people and small teams hit problems,

right? I think that as I've been looking at deployment

tools for years, you sort of have stuff that's

really good for a single developer. Like, oh,

I've got Docker on a machine somewhere, and I

just SSH stuff to it or whatever, right? And

then there's sort of a gulf. And then you have

like, OK, well, I want like a Kubernetes -based

thing that's sort of eaten most of the market,

right? There's not really much in that space

for like, actually, I'm a team of five people

that really just wants to like, that are application

focused. They're just like, I just want to ship

an application. I want to be able to deploy it

30 times a day if I need to, right? And there's

kind of not a lot there. There's a number of

products that try to take what Kubernetes is

and build facades and things inside Kubernetes

in order to get. back to sort of this middle

ground of like a thing that would feel good for

a small team. But what small teams always run

into is now you have not this much stuff, like

from Kubernetes to where they were, but like

this much stuff, my arm is way over there because

now it's like, it's not the, if something goes

wrong, it's not necessarily in this top layer.

It's basically somewhere deep inside the Kubernetes

stack of like your stateful pod had got evicted

because the memory pressure was too high, whatever

it is. Right. Yeah. And, we didn't want people

to have to worry about that because that team

of five people, they just want to deploy stuff.

They want to get in the groove of deploying.

They need something that really is getting out

of their way that just works the way they need

it to work. The question was, how do you build

something that isn't going to have a bunch of

landmines, right? Like a lot of the deep Kubernetes

stuff that's really important for big teams are

landmines for small teams. And the answer was

like, let's just strip it away. Let's just keep

stripping stuff away until we get to something

that feels like it's the right size for a small

team. And that meant like, yeah, it's not Kubernetes

-based at all. We were like, we're stripping

that away entirely. We're like, okay, what's

the right? what's the right primitive like containers

are still the right primitive again you feel

see where Docker is you see where people are

writ large containers are still that thing but

then it was like okay great let's say containers

as a primitive and let's just start building

on top of them and so there's things that miren

does that Kubernetes does thousands of times

better right that's no question right but i think

that A lot of the things that Miren does, you

could do with Kubernetes, but Miren does it out

of the box. And with Kubernetes, you have to

become like a pretty decent Kubernetes expert

to do. Like the simplest one that I can give

you is we do a scale to zero application deployment

by default. I have a really good reason for doing

that is because you're going to run this on a

machine, your own computer somewhere. And if

it's an app that only is used once every month,

don't run it. Don't run it. Just let

it run the one time a month that needs to run.

Like don't take up resources running it,

you know, for all 29 other days. And you can

do that with Kubernetes. There's a bunch of Knative

stuff. There's a bunch of pieces that you can

sort of layer on top of Kubernetes in order to

do that. But now you become an expert in a layer

on top of Kubernetes instead of. It's just a

thing that does the thing by default, right?

And so it becomes a question of those trade -offs,

right? Like we don't do as much as Kubernetes,

obviously, but the things that we do do are designed

specifically to do in that way. And we think

that those are the right trade -offs to make

for your teams of like one to 20 is really sort

of the sweet spot that we target. So what kind

of applications or workloads or problem statements

do you see customers bringing to Miren? What

do they come to Miren for that they wouldn't

go to Kubernetes for? Yeah, I mean, they come

to us a lot of times. The ambiguity around the

Heroku situation is one reason people come to

us. And they're like, I don't really want to

take on, I really want a system that just does

the system the right way. I don't want to become

an expert in how to layer a deployment system

on top of Kubernetes. That is like all all the

helm charts and all the things and keeping up

on all the versions and all that kind of stuff.

They're like, I don't want that. I don't have

the time or the team size to do that. But I want

a thing that is that just just works. Like what

we think about it, we think about ourselves as

being application focused and workflow focused.

So people come to us and they're like, hey, I

just want to deploy my stuff. We're like, great.

That's what we do. We deploy your stuff for you.

You know, we we support. specifically because

this is where 90 % of the workload is now. It's

like we're supporting HTTP applications, you

know, out of the box as the first class thing,

because that's where people are, right? We have

stuff for other, we sort of started to layer

on things for non -HTTP stuff, but like the bulk

of our focus has been on how do we run HTTP based

apps really well and quickly. And so. Where do

you think deployment and IaC tooling goes next?

Especially. with AI speeding up code changes?

Yeah, I mean, I think that people, one of the

things people ask me is like, is Miren in danger

of having an AI just code something to use AWS

that works the same way? And I think the answer

right now is no. But I think that even in the

longer term, it's probably also no. And here's

my take. You can have an AI go through and code

you up a deployment platform in the same that

feels similar to the way that Miren feels today

on top of AWS. It could, you know, those AWS

graphs, it's like all the different services

wired together. It could do that. It could wire

all those services together. Is it on call? Is

the AI on call when one of those things goes

wrong? What happens when the AI... is looking

at it again after a month of it working and is

now trying to figure out something is wrong and

it's looking at it again. It's like, this doesn't

make any sense. Who set this up? I'm actually

going to delete all these things and rebuild

it from scratch. You're like, oh my God, don't

do that, right? And so there's not the discipline

in order to do that. Now, again, I think people

will be like, well, maybe the AIs will get that

discipline. Yeah, I mean, then you're effectively

hiring an SRE to just build that up. And the

question is, is that a good use of your time

and or money? right to to have an SRE spend all

their time trying to balance AWS services you

know on one hand uh for some people maybe it

is uh i would i think our bet is that it's not

you know like it's just not it it doesn't make

sense in the the larger frame of things and so

The other point about AI and IaC is that one

of the things that we've seen is we've sort of

pointed AI at our tooling and said, hey, go deploy

this thing, is that our surface area is very

small, but very obvious for deployment. And so

the AI gets it right every single time, right?

Because it's kind of nothing to get wrong. It's

like, hey, I see that I can set config variables.

I see that I can do deployments. I see that I

can do rollbacks. I see that I can get status.

Great. So the surface area the AI has to interact

with is small enough that it just doesn't get

it wrong. Right. Because it's like there's not

a bunch of ambiguity about what is actually going

on. And then, you know, the AI knows that like

what doesn't know anything. But the API knows

that behind all of that is the machinery that

keeps all that stuff working in the shape that

the API is made to work from. And so, I mean,

I wonder like. what we're talking about here

is abstraction levels. I don't think abstraction

levels are going to disappear as AI gets better.

It's going to build new abstraction levels. And

then you're basically like, okay, great. That

abstraction level is done. We're good. We're

solid. Now I can go to the next one. And the

question is, do you, and this was the case for

Waypoint way back in the day. People build deployment

systems at their companies very commonly. And

the thing that we would always hear when we first

was working at Waypoint was that, I got halfway

done building this cool ass deployment system.

And then my boss told me, hey, knock it off.

Go back to the thing that actually we do as a

company. And so then they'd have this half built

deployment system that is just kind of a hunk

of junk because it never got finished. And then

they have to just suffer. with it for years.

And they're like, how come the deployment system

is so weird that you have to like stand on one

leg and shake a thing above your head in order

to make it work? And it's like, well, because

none of that was supposed to be there. That was

all supposed to be paved over. But we never got

enough time to finish it because we're a mortgage

writing company. Right. So like building a deployment

system never made sense. And so I think that

that's still true when people are. applying AI

to AWS resources. It's just like, you're, you

just needed a thing to work. You didn't need

any of those other pieces. We want to be, we

want to basically as Miren be a person who has

opinions. You want to basically buy our opinions.

You want, we want, you want to outsource your

opinions about how this is supposed to work to

us. And then we'll just give you a thing that

works. Oh, that makes sense. Yeah. I, I fell

into the same trap. I think with Jenkins, like

most people do. Oh yeah. Me too. You know, you

didn't have time to. to fix it. And it was a

house of cards. It just works. So you just left

it alone. Right. Don't touch it. Yeah. Yeah.

No better to, to yeah. Go to a company that can

give you the opinions around the stack. You pay

for that, pay for that. You pay for that service

that they're going to maintain. Yeah. I mean,

I have, I know people who, uh, who pay for AWS

consultants because, and then they're there,

that's the same thing. Right. And, and in some

ways, uh, you know, they're, you're paying for

that person's opinions. So. Okay, so wrapping

up, what's one industry belief about DevOps or

platform engineering that you think is just wrong?

I think that people fall into the trap of, I

guess it's not DevOps. I'll say what I was going

to say, which is, yeah, I was going to say that

I think that people fall into the trap of feeling

like, oh, I can't. i shouldn't rewrite that i

shouldn't do how about my own version of this

that and the other thing and i think that um

it's a double -edged sword of basically being

like oh don't ever always use this one version

of this thing um even though it does no most

of it doesn't do what we want but this one little

slice does right i think that people should be

more uh willing to say I'm going to do the thing

that works best for me, and I'm going to do 5

% of what the other thing does, but it's going

to be the 5 % that I want and now I can own.

It's sort of like the industry did a lot of hand

-wringing around dependencies about 10 years

ago, about how big your node_modules should be

and all that kind of stuff, right? I think we're

running into it again now with supply chain.

And so I think that having your own versions

of the things that fit just what you need, it's

way underrated. So yeah, no, that's fair. I agree

with that. Evan, where can people find more about

you? You have sOCIals? Yeah, yeah. You can find

me on Bluesky. I'm evanphx.dev on Bluesky.

We have a Miren Discord. If you want to hit

that up, that's at miren.dev/discord.

Yeah, that's probably the main two places he

says. Awesome. Appreciate it. Thank you so much,

Evan, for coming on. Really appreciate it. Absolutely.

Thanks so much. All right. That was my conversation

with Evan Phoenix from Miren. My biggest takeaway

from this one is that deployment is painful because

it sits at the intersection of everything else.

It is not just run the app. It is build the app,

package it, push it somewhere, wire up the config,

expose the service, watch the logs, handle rollbacks,

and make sure the next person can understand

what happened. And every time we try to simplify

that, we usually move the complexity somewhere

else. Sometimes that is fine. Good abstraction

hides the right things, but bad abstraction hides

the thing until production is broken. And then

suddenly, the team that didn't need to know Kubernetes

has to understand pod eviction, node pressure,

ingress behavior, registry auth, and whatever controller

is angry three layers down. I liked Evan's point

that small teams often do not need the biggest,

most flexible platform. They need something with

a smaller surface area that handles the boring

parts well. That does not mean Kubernetes is

bad. It does not mean Terraform is bad. It just

means flexibility has a cost. Every knob is a

decision. Every decision becomes something to

support. And eventually, the platform becomes its own pile of work. The AI

angle makes that even more interesting. AI can

generate deployment code. It can wire together

cloud services. It can probably build something

that works for a while. But is AI on call? Does

the team understand what it created? Does the

next person know why those decisions were made?

That is why good abstractions probably matter

more, not less. A small, clear deployment surface

is easier for humans to use and easier for AI

to interact with safely. So the practical question

is not always how do we build the most powerful

platform? Sometimes it is how little platform

can we get away with while still shipping safely?

I'll have links to Evan, Miren, the Discord,

and anything else we mentioned in the show notes.

If you enjoyed this conversation, follow or subscribe

to Ship It Weekly wherever you listen to podcasts.

You can also find the show notes and links over

on shipitweekly.fm. Thanks for listening, and

I'll see you later this week.

Ship It Conversations: Evan Phoenix of Miren on Deployment Pain, Terraform, Waypoint, and Better Defaults for Small Teams

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

👤 Guest

More from Ship It Weekly

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

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

GitHub Actions Hardening, Airbnb Config Rollouts, Cloudflare Rust Restarts, ECS Managed Daemons, and Terraform Access Controls

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

Get the next episode in your inbox