Kubernetes is an anti-platform
01:35:42 Share

This is Ship It with Justin Garrison and Autumn Nash, a podcast about everything that happens after Get Pushed. Ship It is brought to you by Fly.io, the home of changelog.com. Launch your apps close to your users all around the world. Learn how at fly.io.

Hey, friends. I'm here with Dave Rosenthal, CTO of Sentry. So, Dave, I know lots of developers know about Sentry, know about the platform, because, hey, we use Sentry and we love Sentry. And I know tracing is one of the next big frontiers for Sentry. Why add tracing to the platform? Why tracing and why now? When we first launched Sentry,

launched the ability to collect tracing data, we were really emphasizing the performance aspect of that, the kind of application performance monitoring aspect, you know, because you have these things that are spans that measure how long something takes. And so the natural thing is to try to graph their durations and think about their durations and, you know, warn somebody if the durations are getting too long. But what we've realized is that

The performance stuff ends up being just a bunch of gauges to look at, and it's not super actionable. Sentry is all about this notion of debug ability and actually making it easier to fix the problem, not just sort of giving you more gauges. A lot of what we're trying to do now is focus a little bit less on the sort of just the performance monitoring side of things and turn tracing into a tool that actually aids the debug ability of problems.

I love it. Okay, so they mean it when they say code breaks. Fix it faster with Sentry. More than 100,000 growing teams use Sentry to find problems fast, and you can too. Learn more at Sentry.io. That's S-E-N-T-R-Y.io. And use our code CHANGELOG. Get $100 off the team plan. That's almost four months free for you to try out Sentry. Once again, Sentry.io.

Hello and welcome to Ship It. I am your host, Justin Garrison. And with me as always is Autumn Nash. How's it going, Autumn? I am almost caffeinated enough to be fun. Got to kick in at some point. Getting there. I've had four glasses of water. I'm probably going to have to pee during this episode. It's cool.

Because this episode is probably going to be long, which is awesome because we have a veteran of changelog. And I was really just jealous of all of the other shows getting Adam to come on and talk to them about everything that he's been doing. And in all of his hot takes about stuff, we were even talking about hot takes already in the pre-show. So Adam, welcome to Ship It. Finally, your first appearance on Ship It. Thank you for having me. Your seventh changelog appearance. When we almost had Adam on and then he didn't, I almost cried.

I don't want to make you cry. That's terrible. I was like, we were going to have so much fun. I feel like I should get like a jacket, you know, like the Saturday night live, like when you post five times or whatever, we should make it all the shows that you got to collect all the shows and you get a special shirt. Yeah. Yeah. Like a Pokemon, you know, when like you get all the certifications for one cloud provider and they give you the golden jacket, Adam needs like the golden jacket, but like with each, like, uh,

show. Podcast. Yeah. Like the like patches. Did you know you can just like buy a gold jacket on Amazon.com? And like I'm really tempted to go just buy the jacket and just go to go to reinvent and just wear it. Just you know I have no certifications but I was like I got a gold jacket.

Yeah, that's true. You weren't even going to tell me that that was possible. You don't follow me on Blue Sky, so it's fine. I do follow you on Blue Sky. I'm just never there, okay? This is my problem as well, Autumn. I want to love Blue Sky. I love everybody that does it. I'm just like... I don't know. It's close, but not quite right. Yeah. You two are just too attracted to the bug zapper light.

And you're like, I just have to be at this blue orb of a thing and I'm going to get shocked. I don't even know if I love Twitter anymore. I don't even know if that's it. Like in LinkedIn is not really that great either. Like it's it's it's also like decoupled and spread out that it makes it hard to be excited about any of them at this point. That is exactly how I feel on them.

like we ruined we had this incredible moment where where all these people were having this like mashup pile conversation and you could really like see the zeitgeist happen in all these communities you were a part of like peripherally you know like and like now i can't because everybody's everybody we're all split up and elon musk's a dick and like all this crazy blew it all apart and i had this conversation with brian cantrell when it was happening i was like

dude, you're going to ruin this for everybody. Like, like we're all going to leave and then it's going to be a real bummer. And everybody be like Mastodon. And then they're going to learn that Mastodon will never scale. And then we'll all leave Mastodon. And then we're going to go to something else. And like, that's here we are. So not only will it not scale, but it's too compartmentalized that you never end up being able to find like Twitter. You could just find something cool that you've never been into. And all of a sudden you're like, Oh,

You could have your whole ADHD hyper fixation, go down a rabbit hole, get other people's opinions on how cool it was. And then, but now we're like, okay, cool. I know I like, I don't know, art or whatever or tech, but now I'm not exposed to new things. Like I loved learning new things on Twitter and meeting new cool people. Algorithms are good for some things. And that is, that is a problem where a lot of people like shift the pendulum swung all the way over and like no algorithms anymore. I want to control this. And I think a lot of the, uh,

like a lot of the culture moved into TikTok, right? Like all the conversation and attention and culture shifted over there. And which is all just algorithm and finding that stuff automatically. But I can't watch TikTok while like about like shady things while my kids are around. So it like really like ruins it.

The barrier to entry and consumption is way too high for something like TikTok. I'm just like, this takes so... You know what I mean? Text-based things. You could be reading the most fire Reddit thread with so much garbage in it and your kid's sitting next to you. And it's fine. Yes! Now I got to go find AirPods and I'm going to lose them. And there's a bunch of 20-year-olds complaining about stuff I don't care about. I don't know. And I'm not actually cool enough. Yeah!

Yeah, I'm not. Also, it keeps making me buy things. I didn't know they had a store. And then like all of a sudden at 11 o'clock at night, I'm buying something I don't need. It's all very upsetting. Yeah. I'm with you. It's not my jam. Not mine either. I want old Twitter back. Can we just make that happen? I was actually saying that I'm saying this to every venture capitalist who listens. Like this is an obvious thing to do. And what we need to do is like you just need to raise money. And the business plan is really straightforward. Twitter.

They open sourced it. Let's just clone it real quick and then change five things. But how is it different? You're like, it's not. It's Twitter. And you'd be like, is it decentralized? You'd be like, no. No. Not at all. It's just the old one. We don't want it. And they're like, is there an algorithm? You're like, yeah. And do you control it? Yeah. And are there threads? No.

Just reply. It gets weird. It's a mess. It's awful. Raise money. Do it. I will come. Oh, man. The threads on Twitter ruined a lot of things. I know. We would. It's just restart Twitter. Call it Twitter or something like that. I'll be one of your founding engineers. The book on Twitter's algorithm is one of my favorite data-intensive application books. Love it. I just saw that X lost 79% of its value. Maybe Elon will sell you the original Twitter domain.

no part of me is the person who should restart twitter but i appreciate i want someone else to do it very much we have faith in you adam thank you yeah also if it's gonna tell me i have to follow someone over and over again at least you have good hot takes instead of like his like leave the cloud that's true like oh my so i made a like startup like uh twitter for like our new startup and it was like the

I keep getting these notifications and I'm like, why am I getting all these weird right wing Elon Musk notifications? It's from my business Twitter that follows nobody. And it's like just dogfooding me, Elon Musk, over and over again and the craziest right wing stuff. And it's never liked a tweet. It's never followed anyone. And it's just these like...

it's just crazy amounts of notification of the most unhinged stuff you've ever seen. And I'm like, tell me you, you know, I mean, I just created an Instagram account for the first time last week to repost some of my videos and it's not much better.

It's not much better. You have an Instagram? No, no. You just need to fix the like – you have to fix your algorithm. That's what my wife said. You have to fix the algorithm. I'm not – like it's like a time investment. Oh, no. Like Instagram is the only thing that hasn't been completely ruined. Like they ruined it a little bit, but it's the only thing that's like holding on for dear life. And it's where old people watch TikToks when we know that they're very fighting good. For real. Like look. I keep seeing all the TikToks I saw from like a month ago. I'm like, oh, there's the TikToks. All the best ones. Exactly.

Exactly, Adam. They're tied and trued and tested TikToks, okay? They're the ones that aren't just made for the teeny boppers who like haven't experienced life yet, okay? Like they're good. That cat does know how to talk to humans. Like it's got a fire soundtrack and not the same like...

TikTok song over and over again. It's all real. Well, there you go. Show over. At some point, we were going to talk about infrastructure and things. Yeah, let's talk about infrastructure. Actually, Adam, one of your other episodes, I don't remember, it was probably one of the interviews, you said you had a hot take that I wanted to ask you about because I think I agree, but you always have a better formulated idea around it.

where they were talking about configuration management was an absolutely great thing for infrastructure in general from

forever ago and you said that overall kubernetes was a negative and i want to i want to learn more about that i mean this is a particularly spicy hot take so thanks for dragging me straight into the straight into the the jowls of i feel like we started with we eased in a little bit like yeah i just jumped into this millennial talk like you eased me in with twitter and then you took me straight here i think okay so let me acknowledge before i get into my hot take that like

lots of people have built lovely things that they are very proud of and that have solved their problems with Kubernetes. And so, and the community, lots of intelligent people who built that stuff that I have a lot of respect for, like good job. So like, let's just let the get out of the way. And yeah,

I think a couple of interesting things happen. So, you know, one is we've had this move from a long time ago. So I would say, you know, for me, it really started with like CF engine in the nineties and, you know, you could probably go back further if Mark was on here, he'd probably tell you like sort of what goes further than that. But, you know, that was the beginning to me of this idea of like,

those declarative semantics. So we want to say is like, here's we're just going to declare what we want the infrastructure to be. And then the system is going to converge. And sort of over time, it's going to figure out how to do it. And it's going to figure out how to deal with transient errors, and all this other stuff made a lot of sense in the data center still makes sense in a lot of ways.

And then as you scale, right, it gets a lot easier to reason about because the system is taking care of more of the complexity of figuring out timing. So, you know, just this sort of repetitive loop, control loop that happens is part and parcel of that puzzle. And Kubernetes is like, in some ways, a very clear example

descendant of that idea where but just sort of cranked up to 11 you know where it's like okay what if everything became these like relatively high level declarations and then we were feeding those high level declarations into this like reactive system which is basically watches on a key value store right and then we wrapped those in controllers that understood how to like do the reconciliation loop

into the world. I promise I'm getting to the hot take. So it turns out that that interface is awkwardly difficult because on the one hand, it's like high level enough to

that it feels like it's just what you should interact with. You know, like there's a deployment semantic and it feels like I should just write it. And then it turns out that actually managing those things directly is not fun. And so then everybody changed their tactics and they were like, well, Kubernetes isn't actually a thing you're supposed to touch. It's supposed to be a thing you abstract. Except when we build these declarative interfaces, what we're doing is building an interface that's very hard to abstract. When we abstract things, we're often doing it because we want to change the

the behavior of the people who are going to then consume the abstraction, right? We want it to feel different. We're using it as a primitive. And so when we talk about Kubernetes as a primitive, we're like, this is a primitive thing. It's like the people talk about it. Like it's the kernel, you know, it's not the kernel, right?

Because you can't actually abstract Kubernetes into a system that feels like anything other than Kubernetes. Because that declarative semantic and all of that logic that lives in those CRDs, it binds so tightly that when you try to abstract it, it just leaks instantaneously. And you can tell. If you use any system that sits on top of Kubernetes, you're like...

Nah. It's Kubernetes.

I think it kind of set back our ability to imagine how the world could be like a decade where a lot of people were just like, oh, we solve this problem now. It's just Kubernetes. And like, we haven't solved that problem. It won't just be Kubernetes because you can't fundamentally build anything new on top of it. Like the best you can do is make it smell like Kubernetes.

Only a little easier, I guess, but not really. I agree because I keep seeing all these platform engineering teams like go build on top of Kubernetes. You're not building on top of Kubernetes, you're automating Kubernetes. You're just building new things to automate the little pieces that are already abstracted. Because there's no possible way to do it. Like if you wanted to change the flow. So think about it this way, like AWS, for as much as the API is a mess,

It has a very imperative API. And if I wanted to change how it works, I can do that because I can stitch together those API calls in a different order. I can change how they feel. I can, I can, there's all kinds of tricks that I can pull. Also the building blocks are small enough that, you know what I mean? Yes. It's like Legos and they give you the small enough Legos that you can make it what you need it to be, which is like the, like, that's the secret sauce. Like Azure has not figured that out yet. And neither has Google cloud. And Kubernetes is like not a useful Lego.

It can do what it does. And that's great. And I can program it to do whatever I want because, and this is the argument I always get into with people who are like, who really love it. They're like, well, just write a CRD. And I'm like, dude, like if the thing I have to do,

is like write my custom controller code in order to change the imperative behavior so that I can then interact with the system at a distance in a control loop like miss me. Like I just don't. Why would anyone do that? And so I think as a direction of research for the industry, I think it's held us back. And I think people are going to catch up to that truth because we're going to start building systems that don't use it and they're going to behave better.

And you won't be able to match them. And that's a huge opportunity in the startup ecosystem right now that is, I think, really underserved because everybody looks at the mass of Kubernetes and goes, how could you possibly compete with Kubernetes? And I'm like, you're not listening to the people who use Kubernetes, where like, if you listen to them, most people who use Kubernetes, they don't love Kubernetes. They love what they built. So if you're like, hey, how you feel about Kubernetes? They're like, well, I built this incredible

infrastructure and it does this thing I need it to do. And you're like, well, how do you feel about Kubernetes? And I'm like, ugh.

And then they unveil their like long list of stuff that bothers them. And like, that means there's an opportunity to actually build a better thing that solves the same problem, but actually allows you to solve it in a way that feels better and that people love in a way that's different than it is now. It doesn't mean Kubernetes is bad. It just means like, this is what happens. There's an evolution of technology ideas come in. We roll around with them and we build new ones. And so like, we're ready for something new there. I just don't know what it'll be. You know, it's funny. Yeah.

we were at scale and it was like, you know, you guys have all these talks about Kubernetes and none of them made me want to touch Kubernetes. But you know, what's funny is like engineers love solving problems and making things easier. And I think the reason why people love what they built on top of Kubernetes because it shows how much you can automate and make pain less, but that's because there was pain to begin with. Yeah. I have the similar conversation when I talk to people about the cloud.

Right. Like any, like, Hey, do you love AWS? Like, no, but look at the thing I built. Right. Like, look at the thing it enabled me to do. And mostly because the thing that either we're used to was an on-prem email system that was like, Oh, I need a VM. I need a disc. I need whatever. Wait six months. Yeah. Give me a ticket. Yeah. Or it wasn't possible for them before. Cause they had no access to any of that technology resources. Like I need a message queue. Like that's going to take me a year just to create one. Right. And so like the cloud in a lot of ways, like I could build these things on it, but like also it,

Again, it's still kind of a mess. You know how we make this all full circle with our Twitter conversation? Okay, wait, hold on. It's going to be a riot. Okay, you know how we always talk about how people make things, like either developers want things to be simple and abstracted so you can get stuff done because sometimes you just want to do stuff, right? Or we get a little crazy and we're like, we want to pick every single like,

Just detail. But sometimes when you're either starting something new or you want to build fast, that takes forever and it's not really useful, right? So you always have the, like... I don't know. What were we talking about last week? There's always some sort of software. Like, oh, the person that was making Linux, but he was making a version of Linux that was simpler so you could use it and adapt it and it's more abstracted. But then you have people who really like to make all those Linux or whatever. That's massive on Twitter. But it's also... People are either...

We either go too far with wanting to be so specific about every little thing when you're like, dude, sometimes I just want to like post or just build something really quick, you know, but like they go back and forth of like, how do we find that medium of like enough control and enough ownership, but not making it painful? Yeah. I mean, I think I think I see a lot.

in that vein is, you know, like we just GA'd system initiative, right? And I was so excited for you. Thank you. It's such a rad idea. I was very excited for me too. And I'm excited for everybody else because they get to use it. But

But in that moment, I knew what the feedback would be, which is there's like a segment of people who see it and they're just instantaneously like, yes, like they understand the primitive. They understand how it's going to work when you think about programming the large. They understand like how it will probably evolve and they're in.

And then there's another set of people who look at it and they're just like, this is hot garbage. It'll never work. Right. And then there's, you know, there's some people who are like, man, maybe, you know, I'll, I'll check back in six months or so. And that happens in every technology, but I don't think we encourage people enough to like get a little weird or,

Because often if you try to get weird, so if you were like, you know, if you said to someone, hey, I'm going to go build a thing that's going to compete with Kubernetes, 99% of the world would be like, that's dumb. And they would have 100 reasons that are all true about why that's dumb. They're like, oh, you're going to compete with Google and Microsoft and Amazon and like Samsung and all these people all at once, Red Hat. Like you're going to compete with all of them. And you're like, well, yeah, that's dumb when

when you put it that way. But at some point, that's how you got Amazon, Google, and Microsoft. But at some point, that's how that happened. And you have to be willing to let people get a little weird. And I think as a community, especially as ops people, because what we tend to love are the... It works or it doesn't. Infrastructure is a little binary. And there are ways to build infrastructure that are objectively worse than other ways. And so we're more prone to that, I think, than most. And I think...

you know, yeah, we need to encourage people to get a little weirder and to build some new stuff. And to what you said at the beginning of this conversation, like the people that built Kubernetes and did all this fantastic work, right? Like don't tie your identity to a technology. Like that's not who you are. Everybody does that though. Like that is engineering, like the engineering culture. Like for one, people will be like, I use this and I work so hard to use this. I'm never learning anything else. Or they want a new flavor of something every week. And I'm like, I'm not doing that every week.

Like sometimes using something old works, but you shouldn't be married to it. It should never be like, I did it this one way and we're never doing it differently. Cause that's when like, when you, so it's like some weird in the middle of trying to find. I think there's a, there's a version of that where like, when I think about myself, like there's a huge number of technologies that I feel like are part of my identity. And some of them I no longer use like Pearl and Ruby. Like I'm a hundred, I'm forever indebted to those communities. They're a part of me.

absolutely and like who i am as a person they influenced what i believe how i think like all this like it's i'm deep and i haven't written a line of pearl in a very long time i haven't written any ruby in a long time i think i wrote pearl actually more recently than ruby which is hilarious but like how did you make that happen i i think i had a refactoring to do inside the code base and uh and i used pearl to do it you know because i knew what to do so i just like pearls good at that

Hey friends, you know we're big fans of fly.io and I'm here with Kurt Mackey, co-founder and CEO of Fly. Kurt, we've had some conversations and I've heard you say that public clouds suck.

What is your personal lens into public clouds sucking and how does fly not suck? All right. So public clouds suck. I actually think most ways of hosting stuff on the internet sucks. And I have a lot of theories about why this is, but it almost doesn't matter. The reality is if like I've built a new app for like generating sandwich recipes, because my family's just into specific types of sandwiches that use Braunschweiger as a component, for example.

And then I want to like put that somewhere. You go to AWS and it's harder than just going and getting like a dedicated server from Hetzner. It's like, it's actually like more complicated to figure out how to deploy my dumb sandwich app on top of AWS because it's not built for me as a developer to be productive with. It's built for other people. It's built for platform teams to kind of build the infrastructure of their dreams and hopefully create a new UX that's useful for the developers that they work with.

And again, I feel like every time I talk about this, it's like I'm just too impatient. I don't particularly want to go figure so many things out purely to put my Sandwich app in front of people. And I don't particularly want to have to go talk to a platform team once my Sandwich app becomes a huge startup and IPOs and I have to do a deploy. I kind of feel like all that stuff should just work for me without me having to go ask permission or talk to anyone else.

And so this is a lot of, it's informed a lot of how we built Fly. Like we're still a public cloud. We still have a lot of very similar low-level primitives as the bigger guys. But in general, they're designed to be used directly by developers. They're not built for a platform team to kind of cobble together. They're designed to be

useful quickly for developers. One of the ways we've thought about this is if you can turn a very difficult problem into a two-hour problem, people will build much more interesting types of apps. And so this is why we've done things like made it easy to run an app multi-region. Most companies don't run multi-region apps on public clouds because it's functionally impossible to do without a huge amount of upfront effort.

It's why we've made things like the virtual machine primitives behind just a simple API. Most people don't do like code sandboxing or their own virtualization because it's just not really easy. There's no path to that on top of the clouds. So in general, I feel like, and it's not really fair of me to say public cloud suck because they were built for a different time. If you build one of these things starting in 2007, the world's very different than it is right now. And so a lot of what I'm saying, I think, is that public clouds are kind of old.

And there's a new version of public clouds that we should all be building on top of that are definitely gonna make me as a developer much happier than I was like five or six years ago when I was kind of stuck in this quagmire. - So AWS was built for a different era, a different cloud era and Fly, a public cloud, yes, but a public cloud built for developers who ship. That's a difference. And we here at ChangeLog are developers who ship. So you should trust us, try out Fly.

Fly.io. Over 3 million apps, that includes us, have launched on Fly. They leverage the global anti-cast load balancing, the zero config private networking, hardware isolation, instant wire guard VPN connections with push button deployments, scaling to thousands of instances. This is the cloud you want. Check it out. Fly.io. Again, Fly.io. ♪

How much of the Kubernetes, like I think that the simplicity of write a CRD, like kind of gives people a disillusion of like, oh, this will be easy. Yeah, nothing is simple about writing a CRD. I've said for a very long time that like people use deployments because they're good enough, right? Like it's a thing that's like, oh, like I could just use this abstraction. I don't need something else on top of it because this is better than what I had before.

And once you have one of those components of Kubernetes that you're using and you're just shipping it, you're not going to write another one. You're just like, well, I'm just going to automate all the other pieces that I don't need in here. In a weird way, like I think sometimes good enough makes sense, but then sometimes it's like, you know. I've been annoyed by the deployment thing forever. Like I had this conversation with Kelsey years ago where I was like, this is not a good enough. It's close to being a good abstraction for deployments, but not enough. And he was like,

well, it should never get better because we never should have written in the first place because like, it's not primitive enough. And I'm like, and I'm like, maybe that's true, man. And also like you did give it to me. And then, you know, there's a bunch of other stuff that I dislike. Like I don't, as I'd like to think about like communities you're a part of, I have a visceral distaste and,

for communities that's who starting position is we're the smartest people who've ever lived. And we're bringing down to you the great wisdom that you have never seen before. That just it, I just, I just dislike it instantaneously. Like the part of me that loves going to like punk rock shows and like likes hardcore, like,

It's just like, no, I'm upset about it right now. My shoulders get higher. Like I just, it bothers me deeply. The last interview I had at Google, like, like eight or 10 years ago, I was like, I will never go back there because I felt that way. As soon as like, they're like you, you have been blessed with coming to our location to the sanctum. Yeah. I think that's a lot of big tech companies now. And we've like brought down to you the good time. And like, it just, that really, um,

It drives me up the wall. And one of the ways that that gets expressed is that when something's not right and you say it's not right, the response tends to be, well, you're just not holding it correctly. Right. If you understood the deep truths we understand, then you would understand that this thing you're saying is wrong. And I get this a lot when I talked about this abstraction thing in Kubernetes. I'm like, have you ever tried to build on top of this thing? It's a nightmare.

And then people are like, well, you just don't understand how it works. And I'm like, no, I get it. I understand how it works. I'm telling you it's a nightmare. And they're like, but not for me. And I think it's because they figured out, you know, like,

I love the video game Dark Souls. I use this analogy a lot and I'm sorry I'm repeating it again kind of but like Dark Souls is a video game that's very hard and it like you know when I took time off between Chef and System Initiative one of the things I wanted to do was like learn to play Dark Souls and I did. It took months and when I finished Dark Souls I felt as good about myself as I felt like when my daughter was born.

You know, I was like, you know, like I had I had achieved mastery, you know, and like I love that video game. And I think people love their infrastructure and love the technology like they love Dark Souls. They're like, no, you don't understand. Like this was hard. You know, I like figured out some junk and then they bring it back. And I just feel like.

Kubernetes is a little infused with that ethos, with that idea that like, no, we've already figured all this out. This is the way it's supposed to work. If you don't think it works this way, then you're a dummy and holding it wrong. You know, it took me months. I passed the Kubernetes documentation because secrets aren't secret. It drives me insane.

But they're not. And all I wanted to do was like put a paragraph in the documentation that was like, these are not secret. And it was like a long GitHub conversation where people were like, wow, do we really have to say that? And don't people? And I'm like, yeah, you really do.

You really do. But why would you argue about documentation making it easier? Like, that's the point where like, you've gotten so with your head up your own butt that like, you're not learning anymore. You're not making it better if you can't take any feedback, you know? I think that's real. And that gets the thing I worry about with myself all the time, right? Like we were joking before everybody started listening to us that like, you know, like I'm on podcasts all the time. And I'm like, I have hot takes and opinions. And like,

I worry constantly about being a person who falls into that trap. You know, like I don't want to be that person. You have to have good friends that will shade you every now and then. Like my friends will like tell you about your whole life and you're just like, well, I love you, but dang. Those are all, those are, those are all of my best friends.

You have to like if you don't have people who will be like that looks horrible on you and never say that in public again, like they're not real friends. Right. I was Metallica broke my heart the last time I saw them because all I could think of was that James Hetfield no longer has real friends because he I love you so much. We had this like it was like two days back to back. Right. And they were like, it's going to be great. No repeat weekend or whatever. So we're in the sofa in L.A., like 100,000 people. Right. Almost everyone who is there was there both days.

This mother****** comes out and says the exact same sentence.

So like, I tell you what's happening. And then the exact and then they just kick into another song. Like, you know, like his banter didn't change between day one and day two. And this was not the first day of the tour. You know, he would this was like day 20 or whatever, like night 20 of the run. So like, if anyone loved him, they'd have been like, dude, you do just you got to say something other than what you said yesterday.

You just, it's not a big reach, just a little. But the thing is, you can't say that to James Hetfield, right? He's James Hetfield. And if you did, he'd be like, they seemed to like it because they did. You know, he was like, so far, how's everybody doing? You know, blah, blah, blah, blah, blah, blah. And the whole place is like, ah! It's probably also been saying that for like 30 years. Yeah, and he's probably been saying it for 30 years. And so if, like, I don't think, I think part of why James perhaps has no one who loves him is because he's,

James can win the argument just by being like, well, but I'm James Hetfield and you are an asshole. Oh, you cut the sound effect

And like, I worry about that all the time about technology and culture. Like we do that, you know, all the time. And like, we put people up on pedestals, we listen to what they say, you know, and it becomes easy to play yourself on TV. And I feel like, especially in technology, like, I'm not sure we do anything that's worthy of playing yourself on TV for, you know, like I get it when you're Hetfield, but like, should Kelsey Hightower get to be James Hetfield? I mean, yeah.

Maybe. I love Kelsey. Kelsey keeps it real, though. Kelsey does. Because Kelsey will be like, don't use Kubernetes. He will tell you. But let's be honest. So did Hetfield for a really long time. I'm not saying Kelsey isn't keeping it real. So like, oh my God, how much am I not shading Kelsey Hightower right now? I like Kelsey Hightower. We're friends. I'm not shading Kelsey. But think about Mark Zuckerberg.

like zuck has had an interesting arc where he's gone from like scrappy and you know giving hot takes to like robot zuck that nobody wanted to hear to now he's interesting zuck because he's like fully embraced his zuckness again and he's like come all the way around and i think that's because zuck has friends no i really think that's true though like if you really want to hit like heights of success especially when you start to get successful like you have to be able to like be introspective and have friends that will be like you're kind of being a

a dick right now. Look at Elon Musk. Nobody tells him no. How many true friends does that guy have left? And I feel like the answer is not very many. Sometimes I wonder back and I was like, was he ever smart or did we just think he was smart? But I feel like he probably was and then people just kept telling him yes even when his ideas were absolute sh**. I mean, I think he's still smart. But it doesn't mean he's not awful. That's true. So shifting gears a little bit,

We're still, we're staying on Twitter this entire time. It's great. System initiative launched. You GA'd the actual service. And I know if no one is listening to this podcast has not heard of system initiative already. Like you, I don't know where you are because it's been going around the news. You've been not only when it was open sourced and kind of out there, I was like, Oh, this is the thing that's different. And people were already talking about now it's like a service, just go consume it. If you want to go play around with it. Yeah.

What did you learn in that? It was like six months or so, eight months that it was like a year from like, this is a thing that people can come and try. And now we have a service that you can consume and actually get your hands on and use. Yeah, that's a good question. I mean, you know, the big one is that I didn't want, I don't want our ambition was not to like make something that's like a little bit better.

You know, like I've had enough time in my career and enough success that I was given the leeway to truly try to build something that I thought would be incredible. And so when you decide to do that,

One hard part is that it's hard to build something incredible without having just a huge pile of challenges in the way. The first version of System Initiative looked a lot like how people think AI agents and infrastructure will work. We built a system that was just basically, how could I build you a working infrastructure from the smallest declaration? So you could say, I want to run a PHP app.

And it would just figure out how to do that for you and then show you what it was. And then you could be like, go do it. And that's how this idea of high fidelity models or whatever got into System Initiative. And it turned out that that interface was awful because you wound up playing, you had to figure out what the right incantation of constraints was that got you to the thing you really wanted. But the models stuck around, you know? And so that became the foundation of some of those things. A lot of what we learned was just,

how high the bar actually is that like you know in order to actually be useful and in order to be powerful enough that you could really use it to solve real complex problems that nobody had ever seen before like you it just has to do a lot the bar is high and so you know you you hear a lot about like

wanting to launch products when they're early and messy and not quite right. And that's all true. And I believe that very much that like, you know, there's people who will understand what it is that you are building and they will love it. And if you find those people early, they'll help you grow and make the product better. That's all really true. But the number one thing we learned in that year was just how high the bar actually was to be like, well, you got to be able to customize everything.

And you got to be able to see those customizations happen sort of in real time. And then you got to be able to share that back with the community. And then we got to be able to vet that. And then you got to be able to update it inside your workspace. And then you got to be able to, you know, create all the policy that you need and build new stuff. And how do you, you know, all these functions run in these firecracker containers and this huge like distributed system. And so how do you make that elegant enough that if you need to install a new tool or a new library, that's easy to do?

easy enough to do, you know? And then how do you like, once you know that that's enough, then you have to like polish that experience so that people can come and use it and figure out how to onboard, figure out how to, you know, we need right documentation so that you can actually go read about how to work the system and how it functions. And then you got to watch all that information. So, I mean, we learned so much, but the big thing you learned in that year was just

how much polish you really did need to put into the experience in order to earnestly say that like, yeah, you could use this today to build production infrastructure and you should, and you'll find things that aren't ready or things that aren't there, but that's the game of building new technology together in public in big open source communities, but you gotta be ready for that too. So that's a lot of what happened. I think, um,

A year ago, we knew what the shape of system initiative was, and I knew we had done enough work and done enough user studies and enough of those sorts of things to know that the basics were there. But that refinement over the course of the last year of like, okay, but is it actually good enough? How much further does it need to go? It was a lot. What was the hardest part? Yeah.

that you weren't maybe expecting to be the hardest part? Like, because you have had a really long career, you know, you've done a lot of things. So like what really jumped at you that you thought, like, I wasn't expecting this part to be so hard. I mean, I didn't expect the whole thing. So like the idea that what would happen is it was better to express the infrastructure through like a living architecture diagram. I was convinced that that was a dumb idea.

It turned out that it's a great idea and it works way better, but like, you know, whoa, because like the history of that design in our, it's not good in our space. It just isn't. And you have to admit it, you know, but it turns out that's because the primitive it was sitting on top of wasn't right. And wasn't integrated. It wasn't because we shouldn't have nice things. It was because they can't be toys. But then once you realize that it can't be a toy, like,

The amount of technical complexity that cascades from that truth is like crazy. We had to build a custom database that like has like custom tiered storage. It's all in memory and then it flushes to disk and then it flushes to actual database on the other side and it gossips the traffic around so that like when you make a change, that workspace snapshot actually gets like gossiped around to other active servers in the cluster so that if you hit it, it's already in memory before you make a request.

Like there's all kinds of crazy stuff we had to do to actually just get to a spot where the system could be programmable and reactive in this way that it needed to be. And like, we didn't see any of that coming, you know, we were like, wouldn't it be cool if it worked like this? And then you just keep going at it and being like, Oh yeah, well that is cool. And it kind of works, but yeah.

It's not powerful enough yet. And then you just keep digging like a, like some kind of weird badger, you know? How much of that, like I, I ran system initiative locally to like play around with in the dev environment of like, Hey, this is, this is how it works. And I was like, this is a really complex system. And it reminded me a lot of like creating my first Kubernetes cluster.

where I'm like, there's a lot of components here that are moving that need to be set up just right. And at some point that complexity led to, I should just pay a service to do this thing. Totally. Right. And like that, it seems like it's going down that route. Like how much of that is like, do you expect people to like,

operate and do system initiative well? And how much of it is just like, I don't want people to ever touch the side of it. They should just consume the front end. I mean, I want people to use it however they want to use it. Like I believe like fundamentally that part of, because I think it's really a foundational technology, like it's a new primitive that we should use to build all kinds of new, interesting stuff on that no one's ever had before. Like I just can't limit the ways that people want to do that.

So, you know, if you're going to do it to compete with me, fine. If you want to run it on prem, let's figure that out. You know, my job, I'm building a business that sells system initiative for money. So like, I'm definitely going to have to run it on prem. You know, I'm going to sell it to governments. I'm going to sell it to huge businesses. They're going to be like, this has to run inside my firewall. It has to run inside this air gap environment. You know, it has to, there's all kinds of stuff that it's going to have to be able to do.

And we'll do that. We could do it today if a customer needed it badly enough or wanted it badly enough and were willing to pay for it. I think over time, all of those different deployment scenarios will...

will become pieces of the product that are easy enough to do. Like there are a lot of moving pieces, but that doesn't mean, you know, we kind of know how to build installers. We kind of know how to think about building those sorts of systems, but I think you need to see, you'll see the community start to show up in some of those ways. You know, right now those questions are all about like, well, how's my business going to adapt to like, should you use SAS or should you BYOC or should you do this or should you do that? Yeah.

Over time, as people use this and learn what it is and really see its power, they're going to come and use it in ways that I don't predict. And we'll learn from each other how to do that, you know? And I'm stoked to see it. But yeah, I think...

it is a complex system. It is kind of great to run a SAS to do it because you know, it's a big, it's a lot better to just like sign up, fill in a profile and then you're in a workspace and you can start automating stuff. That's better than having to like check out the source code, compile it much less think about how you're going to run it in production. Cause it is a complicated system. Right.

And what's your ideal? I came to the live stream for how you're running system initiative on top of ECS. And one of the things that I was curious about and seeing that was like seeing the diagram of all the components, like it's complex. Like there's a big diagram of a lot of stuff that's all connected together in some way, shape or form. But there's gotta be a threshold there of like running a couple EC2 instances or an ASG with a low balancer. I probably don't need system initiative. Doing something that like is fully system initiative oriented

like everything that every component of it to run it as a SAS seems complex to do in one main diagram. And when I, when I look back and think of like the, the enterprise environments I've been in, like, I couldn't imagine like all of Disney plus in a single diagram, right? Like that just, it'd be too much. It'd be bananas. Where do you put the walls? Yeah. Yeah. Yeah. This is the scope. Yeah. Cause it's a great question. I mean, I think one piece of it is let's start, let's see, let's take the part about like, if it's small, maybe you don't need it. I mean,

If you look at what it's like to use system initiative to interact with AWS versus like going to the AWS console to do it, like...

and well you can't like come on you should just come to system you should plug it in and you should just build whatever the little thing is you want you'll be way into the free tier you know you can have a hundred resources for free and we don't count resources like terraform does it's not like a block they're like actual real things that you do in aws so like you can run some real infrastructure here without paying me a dime and you should and it's better and that's

Great. I mean, people have decided that Kubernetes is a better interface than AWS. So we know it's bad. That's what I'm talking about, right? Yeah. People are like, it's going to be great. We're going to, um, anyway. So then the flip of that is, I think that question of like,

We call it the staring at the sun problem internally, which is like, it is kind of amazing that you can see everything. It's also incredibly overwhelming and not necessarily useful. There's a piece of my brain that loves it because it's like, it is so cool that you can see it and I've never been able to see it before. And so that I can see it that way is kind of incredible. What we're building now is essentially like a system of views where

where what you, if you think of all of the infrastructure that's in like a workspace, so like all the stuff you're managing, um,

And then you can create a new view and then decide which things are going to be seen inside that view. So you might build like an application view or you might build a database view or you might build those kinds of things. And then you can link those views together. So each view that you create is itself an asset you can reference. And so imagine like pulling one of them into that diagram and being like, hey, from the application view, click this one and it'll take you to the database layer that you're attached to. And click this one and it'll take you to this other perspective, right? And if you wanted to have that big global view,

of everything all at once you could right you would just put all the components in it and arrange it correctly and now you have a global view that's like the one that we we showed you in that live stream but i think that kind of composition you know that's coming soon because it's it's an obvious thing to do i think but what it has not been obvious is like how do you build it you know so like if you look over the course of the last couple of years you know initially we started out with the idea that there was this like like an architecture layer and then like a component layer and

And you would click through to one or the other. So we're actually like two diagrams stacked on top of each other. And when we put that in front of users, it was a disaster show. Like no one understood.

Like what goes on the architecture layer? What doesn't? What, you know, because like you imagine that it would be like, well, I should be able to like dive down into something. And you're like, well, but what's inside of it? What if you did it on like resources and teams levels? Like, you know how usually you have like teams like for data or platform or you know what I mean? Because I think that's actually really like...

yes, that's overwhelming to see it all. But as someone who's been a solutions architect and an engineer, that's actually like really interesting that you could go big because sometimes people have a really hard time explaining their problems and their solutions, well, their architecture. And it's never like they don't keep it updated. So it's really like that would actually be like really helpful trying to help people. And it's kept up to date just by doing the work. Exactly. That's what I'm saying. That's the goal. And it's how it works now. And yeah, I think, but that's why we wound up with views, right? Because-

You couldn't build a feature that was like, well, there's these five teams. And so those five teams are now, those are the five different views of your data. Like if you do that, you're going to go to, you know, a giant bank and they're going to be like, we have 500 teams. How do you like me now? And so like, instead you have to build the primitive, you know? And so like, but yeah, you're right. That's exactly what it is. So like that view primitive, you can use it to structure that way to slice it in the way that the team needs it sliced.

And it's that game of discovering primitives. That's the product development game. Maybe not teams, but like sections, like, you know how they have it, like, I don't know how to explain it, but different layers of like the way that you're up. Yeah, that's exactly it. And so like, that's where it's heading. And like, in a minute, there'll be a YouTube video that's us like reading out the opportunity canvas and the story map and like for how that feature gets built and

in days, probably next, early next week, probably. I feel like a lot of these, if views are customizable and I can define them, at some point you're just gonna be able to like overlay the org chart right on top of it. And you're like, oh, look, it's the same thing, right? Like these are mirrors. Yeah, and if you want to blow your mind, now think about you have all that data and it's all on this big reactive programmable graph.

Now overlay security policy, overlay financial calculations, overlay compliance obligations, and then start building completely different interfaces for those people to interact with that information. So like, you know, this is the right interface for infrastructure engineering. What's the right one for application deployment? What's the right one for security? What's the right one for finance? And you start building all these different full interfaces over the top of the data. And at that point, it really does look like Unity.

Right. Where like sometimes what you're doing is 3D modeling. Sometimes what you're doing is core engine programming. Sometimes what you're doing is this and different people are all collaborating on the same code base, on the same live assets, all at the same time in order to generate this big, complicated enterprise. And that's the dream. Now, like.

I'm not bringing up AI too soon in this conversation, but I think that the co-pilots and the things that are writing code have made it more simple to get into writing functional code, whether it's good or bad. People will write functional code and they'll ship it and this thing works. And that's lowering the...

the value of a developer that used to do those sorts of things. They're like, "I used to be the one that took these tickets and I wrote that code and I didn't write any tests and I shipped it for production." And in this case, I feel like with this initiative, you're lowering the value or the perceived work that an infrastructure engineer used to have to figure out to do these complex things of like that load balancer connects to this thing, these ASG scale based on these metrics, all that stuff. And it makes everyone

able to jump into the infrastructure game and say like oh here's my change set i can now be the infrastructure engineer i mean kinda except that like the truth is the domain remains impenetrable to outsiders so like can you teach someone the basics sure but do they know you know like do you know why you would choose one load balancer algorithm over another

Like I know because I had to do that. And I was in the era where we invented a bunch of load balancing algorithms thinking they would be better than round Robin. And then we just caused a bunch of interesting failure conditions. Right. Yeah. And two tier round Robin just wins over and over and over and over. Right. Forever. And like hundreds of millions of dollars invested in trying to invent a better algorithm. And we can't. And so like the truth is that the domain is complex, right?

And the other piece here is that what actually happens in at least in technology, but I think history bears this out. If the demand for something is effectively uncapped, if we haven't found the ceiling of its demand, then creating more efficiency does not actually like cause us to have fewer jobs, cause people to be valued less. The opposite happens. So like when you think about the demand for infrastructure, compute infrastructure, you

it is effectively unbounded. We have no idea what the top end of the human appetite for infrastructure technology is. So if we make it better to do, if we make it more efficient to work with it, if we can unlock more of that potential, it's not like what happens is now people aren't in the infrastructure game anymore. Instead, what happens is

we get to build even more of it. We get to specialize even more. We get to see even more what we can build in new and interesting ways because the demand side is still so high. This is why software developers, there's a story around AI that's like, ah, software developers are going to be dead. We'll just ask the agents to do it and it's all going to work out. This is why that's a silly point of view because call me when the demand for software development increases.

has peaked. They keep telling everybody it has, and I'm like, okay, sure. No, just the pay. No, it may be the pay, but even the pay won't because what'll happen is like, it'll, it'll just shift even further into interesting new realms. That's what happens, you know? Um, and I think, you know, with AI, one of the things that's interesting about system initiative and AI is that, you know, AI works best when it's augmenting the expertise that you already have.

And maybe we'll get to a spot where it can do that without our expertise, but today it doesn't. And it's a pretty far future bet to say that it will, you know, we need new technology innovation to get beyond that for now. And I think when you think about system initiative, one thing I like about it is that when you imagine how those agents write code, it's less compelling than if an agent was participating like a player in the game. And so

And so if you think about this multiplayer interface that is System Initiative and these high fidelity models, like it makes perfect sense that you might ask an LLM what it thinks it should do and then have that LLM put them out into the diagram for you and have you interact with that thing like a player.

And then, you know, vet that, vet its choices, right? See immediately whether or not its choices would work or not because the simulator tells you so. And tweak the things that don't make sense and move on. And like that loop becomes very compelling, right? And when you think about infrastructure as code, like it is sort of bounded by that idea that like, well, what it's going to do is write code for you.

But I still have to put it in a pipeline. I still have to figure out if it's right. And the more complexity that gets there, the harder it becomes. And so I'm a believer in the capability of AI to really transform those user experiences. But I think when we look at it through the lens of how's it going to impact infrastructure and the way it's going to impact it is through code, I'm like, hmm, is it? Because that domain's still brutal. Yeah.

It's still really, the feedback loops are still real long, you know? Yeah. Infrared search is code, especially like, I think that's as much as it,

allowed developers to start managing code, it made it harder to get into infrastructure. Like infrastructure became a single player. Like no one else could do this now unless you also write code. Yeah. And well, and if you, if you've ever been the Terraform or the Pulumi person who then tried to get your other developers to write some Terraform and Pulumi with you who were like application developers,

This was not fun. Same thing happened with CF Engine and Puppet. Totally. We learned it with Chef too, right? Chef was great at this. Everybody did this. They were like, now all the developers, they're all developers, they can write the Chef code. And like, no, they can't.

They don't want to. It's not fun. It's not better. And so it turned out the way Facebook did it was right, which is they handed people a small number of Facebook specific abstractions in Chef and people drove those and they were thrilled about it and it was fine. And there was a team of 20 people that maintained those abstractions across all of Facebook. And it was cool. You know?

What's up, friends? I'm here in the breaks with David Shue, founder and CEO at Retool. If you didn't know, Retool is the fastest way to build internal software. So, David, we're here to talk about Retool. I love Retool. You know that. I've been a fan of yours for years, but I'm on the outside and you're clearly on the inside, right? You're on the inside, right? I think so. Yeah, I'd say so. Okay, cool.

So given that you're on the inside and I'm not on the inside, who is using Retool and why are they using Retool? Yeah. So the primary reason someone uses Retool is typically they are a backend engineer who's looking to build some sort of internal tool and it involves the frontend.

And backend engineers typically don't care too much for the frontend. They might not know React, Redux all that well, and they say, hey, I just want a simple button, simple form on top of my database or API. Why is it so hard? And so that's kind of the core concept behind Retool is frontend web development has gotten so difficult in the

in the past 5, 10, 20 years. It's so complicated today. Put together a simple form with a submit button, have that submit to an API. You have to worry, for example, about, oh, you know, when you press the submit button, you got to bounce it or you got to disable it when it's, you know, is fetching is true.

And then when it comes back, you got to enable the button to get, or there's an error, you got to display the error message. There's so much crap now with building a simple form like that. And Retool takes that all away. And so really, I think the core reason why someone would use Retool is they just don't want to build any more internal tools. They want to save some time. Yeah, clearly the front end has gotten complex. No doubt about that.

I think even front-enders would agree with that sentiment. And then you have back-end folks that already have access to everything, API keys, production database, servers, whatever. But then to just stand up retool, to me, seems like the next real easy button because you can just remove the entire front-end layer complexity. You're not trying to take it away. You're just trying to augment it. You're trying to give developers a

given interface, that's Retool, build out your own admin, your own view to a Google Sheet or to the production database, all inside Retool. Let Retool be the front end to the already existing backend.

Is that about right? Yeah, that is exactly right. The way we think about it is we want to abstract away things that a developer should not need to focus on such that developer can focus on what is truly specific or unique to their business. And so the vision of what we want to build is something like an AWS actually.

where I think AWS really fundamentally transformed the infrastructure layer. Back in the day, developers spent all their time thinking about how do I go rack servers? How do I go manage cooling, manage power supplies? How do I upgrade my database without it going down? How do I change out the hard drive while still being online? All these problems. And they're not problems anymore because nowadays when you want to upgrade your database, just go to RDS, press a few buttons.

And so what AWS did to the infrastructure layer is what we want to do to the application layer specifically on the front end today.

And for me, that's pretty exciting because as a developer myself, I'm not really honestly that interested, for example, in managing infrastructure in a nuts and bolts way. I would much rather be like, hey, you know, I want S3 bucket. Boom, there's an S3 bucket. I want a database. Boom, there's a database. And similarly, on the front end or on the application layer, there is so much crap people have to do today when it comes to building a simple CRUD application.

It's like, you know, you probably have to install 10, 15, maybe even 20 different libraries. You probably don't know what most libraries do. It's really complicated to load a simple form. You know, you're probably downloading almost like a megabyte or two of JavaScript. It's so much crap to build a simple form. And so that's kind of the idea behind Retool is could it be a lot simpler? Could we just make it so much faster?

Could you go from nothing to a form on top of your database or API in two minutes? We think so. Yeah, I think so too. So listeners, Retool is built for scale. It's built for enterprise. It's built for everyone. And Retool is built for developers. That's you. You can self-host it. You can run in the cloud. A custom SSO, audit log, SOC 2, Type 2, professional services. Starting with Retool is simple, fast, and easy.

And of course, it's free if you want to try it right now. So go to retool.com slash changelog. That's R-E-T-O-O-L dot com slash changelog.

You know how we're usually like engineers are this, I mean, not smaller picture, but you're like actually doing the thing, right? Like, and then you have a bunch of stakeholders and like product and essays and other people that are doing the big picture. So this initiative would be a great way to bridge the gap to help everybody stay on the same page. Like, I think that would be like, it would help to lower so many, um,

like misunderstandings and like to show the value and like help like relate to the cost. But I also think like, this is also like managed database, right? Like we were like, Oh, it's going to kill DBAs and it's going to be horrible, but it evolved DBAs into being like specialists, solutions, architects, or like consultants or whatever. And you still need those people who know how to do it because people just think they can throw stuff into a database and it never works that way. Right. So I think this is going to evolve the way that like,

engineers work that DevOps engineers work and it's going to be different plus like this is perfect because if you just let AI have the keys to the candy store you don't know what they broke or how to fix it but if you have all these different sections like you know when you play like Ninja Turtles back in the day and you're playing and then the computer's playing and you're like going together you know like you could have like you said AI in a small space that you have now you have system initiative to use it as like the checks and balances and to see what it's doing and

And I think that way is the way that engineers and AI work together. Yeah, I think so too. With extreme checks and balances, but you're using it to be like...

effective and to like work faster, but you're also like, it helps you to still know where the AI is, what's it doing. And how, like, it's like when we, you write smaller chunks of code and you have like tests to make sure like, okay, I broke it here. When you put a bunch of print statements, you're like, okay, this is where the bug is. You know what I mean? I do think about that with the conversation we just had about views. And now imagine that that view constrains the context that you're telling the AI to work in.

as an example. Not just that, but say that you, okay. So say you're using a managed database or database or product from a cloud company or just anything. And you go to your solutions architect and you're like, so sometimes a whole data, like architect and data team will be like, I can't figure this out. And then you're coming to somebody, but we're like, well, we can't, like, we need more information to help you. If you can show us your whole, like, you know what I mean? Like you're going to make it easier for people to work together. And then

Say if you're an engineer manager in product and essays or in a meeting and you're trying to show something to your stakeholders, to be able to have that, to show them and then do demos, this could really enable people to be able to communicate and to collaborate better. Look, your words to God's ears. That's the pitch. You're ready to go. Let's take you to the enterprise. Because they mean...

I mean, that's it though, right? Like that's why we think it's such a big deal. Cause like you don't ever get to skip a step, right? So like system initiative today, uh,

You can use it to replace production infrastructure, but like it needs more assets. You got to be willing to dig in a little, you know, you got to like it's still you got to have a little elbow grease. But like the foundation it's starting from is so good. We're really confident that like, yeah, people are going to show up. They're going to put that elbow grease in there. We're going to figure out what these things are and it's going to compound really quickly. This also goes back to that thing Kelsey was saying about how.

engineers were going to be like forced to be more bigger picture and be better communicators and it's also like i found us uh somebody retweeted it and it was like uh it was basically saying we're going to replace engineers with ai and it was like can you describe like and it was saying that somebody but will only have engineers describing the problem and giving the computer instructions and then somebody was like did you really say that because like that's what they do now that's what engineers do now it was

so funny it was like trying to reinvent the wheel like that's literally what we do now and then you have like the higher like program languages that are like it's like we've been doing this like when you do Python instead of bash or like you're not using C++ and you're using like Java because it's a different abstraction like it's just funny like

You're not getting rid of engineers. We're just changing the evolution again. And this was always the game, right? DevOps happened because we learned that in order to build really great things on the internet, you had to be really closer together between engineering and operations. You couldn't run it the way that we were running enterprises. And SREs. In that time. And those things all evolved because of that recognition that in order to have great things, we had to come closer together to get them.

And then the tooling we built to try to help other people come closer together actually drove us further apart. And so if we really want to fix it, if we really want to make it better, we have to bring people back together again in the workflow. They have to actually work together again. They have to actually come together to do that job.

That collaboration piece, I think, is huge because the way that I've learned throughout my career is just like working next to someone. And back at a data center, I learned so much about resiliency was like, oh, yeah, no, you connect that cable to the switch over there because if this one fails and that power supply goes over here and like being able to like, oh, that makes sense because we can figure out why and how these things are going to fail. And infrastructure as code shifted me to an individual player game.

where I just did asynchronous reviews and no one actually reviewed or ran my infrastructure as code. They're just like, yeah, it looks good to me, right? Like this is past the lint, so we're good. But the learning feed, the feedback loop for learning how to do it was so much harder because I was like, I did a copy and paste that other Jenkins file to then go do it over here because I don't know how to start. I don't want to write Groovy. Like I don't want to write Groovy. This is just a necessary evil.

One of the things that the last time I was excited about a infrastructure diagramming tool was probably eight years ago. I don't remember what the product was called, but I remember reading their white paper and they had this notion of being able to see the history of how the infrastructure has evolved and being able to go backwards in time and say, what has changed here and why did it change or where, who made the change?

Do you see that as a view capability inside a system? Because you have these change sets and you have this way to diff this stuff already. Could I zoom back to six months ago and see what it was like? Yeah, it's actually better than that in some ways, technology-wise. So what's happening here is we have these huge snapshots and they're immutable.

So every change you make, you're actually generating a new immutable image of the entire thing. So like in your head, if you imagine that what we're doing is taking a snapshot of the database every time, that's basically what we're doing. So we can absolutely think about like, well, what's the retention? Like how many versions of that snapshot should we keep and how long? And then those snapshots, we can like you can do deltas.

right? You can be like, tell me what changed between six months ago and today. And like, like all of that is very computable. So like, uh, we have all the data to do that right now. It's like, you can't do it today, but the data is there to do it. And it's built into the design that you will be able to, I think, uh,

Now we're a little more focused on like seeing the deltas between like, hey, I've made this change. Then someone else came in and applied something to production. And now that impacts my change. And you see that all happen in real time in system initiative now. It's like an auto rebasing process.

branch basically which is cool but we can make that even cooler by showing you sort of like what the actual impact is on your change so we can be like hey you changed this component then somebody else changed it in production here's how that changes what you changed and you can sort of see that but yeah over time for sure i think what you're going to get is this this ability to store those snapshots over time and then go back

and see the delta. But what you just described is that System Initiative isn't owning the entirety of who can make changes, right? Like this isn't a lockdown, no one ever goes to the AWS console anymore because System Initiative can react to what happened there.

How much of that do you see, like, is this a company should adopt? I mean, obviously you would want them to 100% adopt this initiative, like everything's here, but that's not practical. It's not where you start. Yeah. I mean, we say it's not practical, but that's how every automation technology worked, right? Like, you know, every Pulumi user, mostly they were Terraform users and then they converted. And lots of Puppet users converted to Chef and there were Chef users who converted to Puppet and there were CF engine users who converted to both. And we destroyed BladeLogic.

Right. Like nobody's buying blade logic anymore. Maybe somebody is going to be like, I use blade logic, but like, yeah, someone's going to comment. Someone's using blade logic, but like you can sort of force those. If the technology has enough compelling value, people will replace it over time. But yeah, our goal is that, you know, we definitely, I lived that experience with chef where like, I didn't love how long the adoption cycles were and how, how all or nothing it felt. And so, yeah, we're hoping that part of that adoption cycle is actually just

You know, it's going to start with just importing the things you already have that you want to deal with.

Um, and then, you know, over time you could track just the resource side of that and be like, well, I can show it to you in a diagram and it's changed, you know, we can see what its resource value is, but it just, then it sort of starts to make sense that like, well, why wouldn't I also manage it through here? Cause it's here and it's easy and straightforward. I think that's probably how that goes. I think there's all sorts of interesting possible futures where you do like automatic discovery of things and, um,

But then there's like a lot of interesting problems with like, how do you lay it out? You know? And like, anyway, there's, there's a lot of interesting stuff hiding inside there, but like. This would also be really good for distributed teams and remote work because you can onboarding new engineers, because now you're teaching them the bigger story. Cause coming into like a huge enterprise or a huge, like.

code base is just infrastructure is really hard. Also like with teams, a lot of enterprises doing open source or like, you know, having internal infrastructure and then external infrastructure or like open source infrastructure and like being able to manage two different kinds of infrastructure is really hard.

So being able to give the top view a bigger picture and then to be able to learn and onboard and say, hey, well, this piece fits here. Half the time, it takes so much research and discovery hours just trying to figure out what your whole infrastructure is like.

One of the earliest like discovery calls we had for system initiative was with a big global bank. And they were like, well, if you could just tell me how many Kubernetes clusters I have, they're like, I pay for that. And I'm like, well, that's a, that's an interesting business model. But like, if we could go to every enterprise and be like, how long does it take you just to make the diagrams to figure out what's going on? Yeah. If you think about like what an enterprise architect is,

today, like there is a real change that can happen here where enterprise architects become like concierges to that complexity, which is what they already are. You know, if you like, if you go to an enterprise architect inside of a huge enterprise, like they're essentially the people that you go to and you're like, how does this how does the bank work? And they can be like, well,

how detailed would you like me to be? And like, you know, they can move really elegantly between those levels of abstraction. And I think ideally you'd be able to express that through something like system initiative so that you could, you could have that mechanism there. What exactly that looks like and how exactly it feels like we got to go through that together as a, as a community of people. Cause like,

It's too big to imagine you could just know the answer sort of from the jump, but like, but I think we can discover from here what all the right primitives are to allow that to happen. Do you know what I mean? Like we can, we can roll around with it together enough to be like, oh yeah, you know, it's cool that I can have views and it's cool. I can link between them. But what I really need is blah, blah, blah, blah, blah, blah, blah. Seeing how people use your software is like a whole nother learning opportunity. So fun. Yeah. Yeah.

This is also interesting on how it could affect tech debt and, like, migrations. And, like, when you are trying to update your infrastructure because having this much insight into it, you could then, like how you were saying, you first find all the different pieces and you put your stuff in there and you're, you know. But then you're like, okay, how can I make this more efficient? How can I save money? How can I make this better? But when you have that type of data, you can really...

have the information you need to evolve your infrastructure. Yeah. And doing that evolution, you could think of doing it as a programmable thing. Like, what are the things that I need as inputs to the transformation that then allow the infrastructure to become something else? So in a not too long future, you could write a component whose job is to take as an input all of the infrastructure you have,

and then programmatically translate it into other infrastructure. Also, observability is one of the ways that people fail so hard in engineering is not even knowing how their infrastructure is working or how their customers are getting things. And this would give you more observability and better monitoring. That's the dream. But also, it would help you to get help better. And a lot of people will...

use consultants for like your database or whatever, or just to get something more efficient, you can now get better help because you have more information to be able to give people in the bigger picture to get better troubleshooting or whatever you need. Where do you think the existing crop of infrastructure as code tools fit in any sort of future?

I mean, nothing goes away. Like we were just joking about blade logic. So, yeah, you know, if someone uses blade logic and listens to this show, please email us. I would love to talk. They for sure do. Like, come on, I want to hear about it. Definitely do. And they would be fascinated to talk to. Yeah, no, but like, you know, I'll use chef as an example because it's it was mine. Like that business is still growing. It's not shrinking. It's getting bigger.

And like a lot of people who are listening to this podcast are probably thinking in their heads, oh, that's like old busted technology. It's legacy already. No, but like, when's the world from a, as a business, it's like continues to kill it. Like it's still doing quite well. It's bigger than it ever was. They're growing, you know, I don't know exactly what percentage of it is in progress is revenue, but you can go read it and it's pretty good. So I don't think that what happens is a technology like system initiative comes along and then suddenly every, like everybody just stops, right?

That doesn't really happen. What does happen, though, is that what's possible changes. And so the infrastructure as code locks in a ceiling of what's possible to build around it because of just how the technology works, how the primitive functions, what are the other things we need to put in around it? It's not just infrastructure as code, right? It's GitOps and CI and CD pipelines. Why is a pipeline the right abstraction for infrastructure?

It doesn't actually make any sense. And like, if you think about it, it makes sense for an application in some ways because we're building an artifact and then we're pushing the artifact somewhere and then we're doing stuff. And so it makes some sense that it's a pipeline, but infrastructure, like that's not how it works. It's not really, it never really has been. It's weird that that's the abstraction we got to, but it makes perfect sense when you say, well, but I define it as code. Code has pipelines. Code goes through these things. It looks like that. All these decisions kind of stem from that one place. And so I think what's going to happen is we're,

As people kind of come to grips with what this technology is and how it's different, they're going to start riffing on what's possible and that is going to snowball. And eventually it'll become the way people think it should be, as opposed to the newfangled way where I have to like convince you that it's going to be better than infrastructure as code. Like it won't take too long before I don't have to convince you. The question won't be, is it better? The question will be how long before I can try it.

what is the you know how long before it's before that wave reaches me you know but it's not because the wave's not coming you know like it happened and it's not up to me really to decide what that is it's up to people who use it right so like other people have to also fall in love with that primitive the way that i have so i don't think it's going to disappear overnight but

But I do think that you can't, you know, I would predict that the first reflexive thing people will do is, and they're already doing it, is sort of looking at it superficially and going, well, what if we built a better UI on top of infrastructure as code? You know, what if we did this? What if we did that? And they'll look at those things superficially. And what they'll learn is what I learned, which is you can't.

actually build the user experience you want on top of that foundation. And, but they'll try literally talk to someone yesterday who was trying to build that. And I was like, you're doing this on top of a Terraform state file. That's right. Like, hold on, like, wait a minute. Like, let's just back up one step here. Let's talk about how that's going to end. And, and, you know, it's going to end badly and, you know, maybe it won't like, I could just be wrong. Like, but it's not like I wanted to do it this way. I didn't start out thinking, ha ha.

I know where the root cause is. Like it wasn't like that at all. Right. I was like, the root cause is that the whole system is messed up. Like it's clearly that the way we put this together is driving the outcomes. And that's why it's so resilient across technology over time. Right. 15 years of DevOps. We're still getting the same mediocre outcomes. We got year one. That's weird. This reminds me of the cloud and the on-prem and the cloud debate too, because first people did on-prem cause that's what you had. Right. Then everybody went to the cloud for everything and

And like we were, but like the cloud's really good for certain use cases and like when you want to experiment and like if you have something that you know exactly what you need. And it's fixed in size and time. Yeah. On-prem is better. But when you're going to experiment or build a new project or, you know, for certain use cases, the cloud is a really good tool, you know? And I think we went through this whole like, oh my God, put everything in the cloud. And then people were like, oh wait, this is expensive. Like, you know what I mean? So I think it's like,

this could also be a great way to like experiment and to learn new things about your infrastructure too. So, yeah. And look, I'm obviously in love with the thing that we've built. So it's your baby. Yeah. So I, so I understand my own bias, but like, I'm never going back.

Like, I'm never going to go back to building systems the way that I built them before. There's nothing you could do to make me go back to writing infrastructure as code and thinking about that as the primitive for how I'm going to do this work ever. I'm never going to do it. And that doesn't mean that it was bad technology. It doesn't mean I don't understand it. It just means that like, well, whatever, I've seen a different future and that's the one that I want and I'm going to go get it.

And then we'll see how many people decide to come along on that trip with me. But I'm going there because I've seen it and I know it's better. With the conversation or the question Autumn just brought up about on-prem and cloud, System Initiative assumes it can programmatically do things. It assumes APIs for your infrastructure.

what do you think is the barrier for the, like, if someone wants to do this on-prem, right? Like I'm like dealing with a SOAP API. I got an SSH in a box over here. Like it's, I don't even think it's the TypeScript, right? Functions and TypeScript is a barrier. It's just like, I don't have access to do something programmatically. Yeah. I mean, look, if you don't, then you don't. What are you going to do? But it was the same thing as people were like, well, I can't put an agent on anywhere. Then I want configuration management. What can I do? And I'm like, you can't.

And they were like, well, what if I used Ansible? And I'm like, how many things do you have? And they're like 700,000. And I'm like, you still can't. Welcome to agents, you know, like, but it doesn't matter what you say to me, like agents are your answer. And you just have to, you're just going to have to cope, you know? And what's cool about it is think about that question. You just ask, I have the soap API I need to use in order to automate my application. Right.

or to deal with my infrastructure because it updates the CMDB that we built in 1998 that has all the data in it. And we use it for compliance and it's the only way anything could work. Imagine trying to wrap your Terraform or your Pulumi so that it writes to that SOAP API and keeps it in like...

Just no, right? Don't have to imagine. Have tried it. Yes. It's crazy. It's crazy, right? Why did Justin look like he still felt the pain? He had a brief flashback. So in system initiative, though, this could actually just literally be a component that takes in the infrastructure, writes to the API,

and reacts to its changes. So like you change a piece of infrastructure, the little component that talks to soap reacts every time fires that function hits the soap API and sends the data over. And like, it really is as straightforward as like writing a function and declaring the inputs that it reacts to. And like, it's going to have a lot of inputs. So it's going to react a lot, but like, fine, that's what you want. Right. Every time somebody does something and applies it to that, that's literally the thing you desire.

And so when you think about expressing it this way as a primitive, it's like, you know, it's so much easier to do. Now, does it mean that it overcomes all complexity or all of the like real gnarly stuff? No, because, you know, I still have to figure out, I still have to figure out where I'm going to run that function. So like, do you have some bare metal nodes and a data somewhere set in somewhere that we can, you know, use a control plane to dispatch a function to that makes the API call? Cause you're going to need that.

And, you know, what exactly is the shape of that API? And like, you know, it's still complicated, but it becomes possible in a way that like, it really hasn't been possible before now. Now, the opposite end of that question is how many of your customers have had to just increase all of their API limits in their cloud provider because they're firing all these functions for all of these changes to do all this stuff that immediately is like... Yeah, nobody yet. Yeah.

Yeah, but even if you had to, though, it would be worth it. I'd be like YOLO. I mean, yeah, nobody's had to yet. But it's an interesting thing I'm worried about. But like, it's not because we're firing, you know, like, like the resource side. So when you're like, tell me what the state of this is, like those limits are pretty high.

And the create limits are kind of what they are. So, you know, like, but a cool thing that happens, like, for example, in your account, you have a limit on the number of elastic IPs you can get in AWS, right? And you don't know when you run out until you hit the API and it tells you that it broke. And so imagine you have a, and you know, if you have a lot of Terraform, it might take 20 minutes for the plan to do its thing or for the apply to happen only to learn that you've run out of elastic IPs late in the game.

System initiative, that Elastic IP resource turns red the moment you put it on the diagram because it has a qualification that hits that API and goes, do I have any left?

And just like tells you there's no more. And so, you know, I can at least stop you. I can tell you immediately, hey, you've hit the limit. Now, there's tons of limits like that in AWS that aren't programmed yet in system initiative. But as we find them, adding that thing is going into this interface, writing a single function, and then hitting a contribute button, which sends it to Paul Stack. Paul Stack reads it, hits a button, and now everybody gets it. And like, you know, it's pretty cool. And that's the way I think it evolves.

I think this is interesting because I'm very like, I want to use AI and I want to have it make my life more efficient, but I'm very like not sure and cautious about it. But I think what your startup has that a lot of AI doesn't is the fact that you have so much

background in infrastructure and that you have these engineers working on something that still gives you enough control but makes your life better and i wonder if that because of the different like podcasts and infrastructure and different work that you've done and people probably have more trust in you than something that has no faced if that will give them more of a confidence to try your product well you know what i mean i do i hope so i mean look here i am doing it right like

I hope that's true. Because sometimes AI just feels like the boogeyman that's coming to get us all, and system initiative doesn't seem like- The boogeyman's not, it's not coming to get you. Infrastructure is an incredibly complex domain, and people do not give it enough credit. And when people talk about what it is, they tend to think of it, like I had this conversation recently with a couple of very luminous people who made their careers in infrastructure, and their perspective is, I never want to think about infrastructure ever again.

And I had to have a conversation where I was like, okay, I get it. Like, how do you think all the things that you use that make it so you don't have to think about infrastructure again? How do they work? And they're like, well, I mean, infrastructure. And I'm like, yeah. So like, it's cool. You don't want to think about it anymore. But like I do.

I think about it all the time. I love this thing. And like, I get that you don't want to think about it, but like, that doesn't mean that we don't need it. That doesn't mean it doesn't work. That doesn't mean it's not necessary. That doesn't mean that, that it's not even more important. Like look at something like oxide and what Brian Cantrell and that company has built where like,

People have forgotten how computers work. Oh my gosh, yes. But Brian didn't forget. And so what Brian and his team could do is reinvent what it means to have computers and data centers because they never forgot how they worked in the first place. And they could overcome all these objections. And it wasn't because they invented, they did invent a lot of net new technology, but the bulk of it they didn't.

But what they did remember was how it worked. And they were unafraid of going back to those foundations and where it didn't make sense ripping it apart in service of that user experience, right? They were like, no, you got to be able to uncreate an oxide rack, plug a power thing in, and it's got to turn on and just work. And if it doesn't work like that, it's not good enough. And so they're like, we got to get rid of the BIOS. We got to get rid of like, there's all this stuff that's in the way of it just working. And so they just ripped it all apart.

And the opportunity we have now in the era of the cloud and all these managed services is that like the people who remember and or learn how these things work in a deep way and fall in love with them will be able to then use those things to create new ways of working and new ways of thinking that will be magical to other people because they can't even fathom that you could still work at that layer.

And it's a real superpower from a startup point of view. Like if you're thinking, listening to this podcast and thinking, should I start a startup? Like if there's weird stuff like that, you love, and you know that other people don't know and love, you can crush it by using that specialist knowledge to like do things that other people think is impossible because people just forget that we built all of this. Like all of this was just normal people like us who just did it over time. It's just the accretion of those people's choices over time. And like,

you already did it. Like we're, we could do it again. We can do whatever we want. And that's so interesting and empowering. Have you been to big enterprises conferences lately? Like that is it's that, but like you times it by a million, like everything is the same AI startup, which is why I think whiz did so good to get that evaluation. Cause going to Google next, everything was the same and whiz stood out because not only did it allow you to be multi-cloud, but it gave you so much observability. And I think that,

What you're doing is like whiz on steroids. Like it's even like it takes that like what they have made

noticeable, but it makes it usable and it's going to be even more successful. Oh, thanks. I hope so. I mean, we'll see, but I think it has every, I think it will. I mean, I think it has everything it needs to do that, but beyond us, it really is. And like one of the reasons I love coming on the changelog and I'm now stoked to have been on chip it. And hopefully I get to be on chip it again someday is that like, I love this thing. Like people who build infrastructure, I'm a person, I love infrastructure best because

like when people say to me, Oh, I'd rather, I don't souls and infrastructure. Yeah. They're like, Oh, I never want to think about infrastructure. And I'm like, are you for real? This is how you know, Adam likes hard things. That's the funnest part of the game because it's this, it's so complicated and it's, there's so many details and they all have to fit together. And I love the complexity of it. And I'm not alone. There's a ton of people like, that's why they, that's why this is the career they gravitate to. And like, I think there's a lot of untapped potential in our people that

realizing that they can take that knowledge and that love of that game and turn it into things that are bigger than they think. Like, like there's real, there's a real game to play here right now. And the fact that people have decided that it doesn't matter, like nothing's better.

then having that point of view where fundamentally you're a little bit of an underdog and people don't understand what the details are. And then you just crack that ball. And like, I don't think I'm alone in being a person who can try to do that. I think, I think across our industry, like now's the time that confluence of like AI, the cloud,

the cloud, Kubernetes, all these things that have been like, oh, infrastructure doesn't matter. It's going to all get abstracted away. You know, like when the cloud happened, we were like, you know, all of it was toil and we were, it was all mud and we were going to get rid of the mud. And now we built it all in the cloud and everybody's like, how do I manage the cloud? I'm stuck in the mud of the cloud. And it's like, yeah, of course you are because it's the domain. It is inherent in the work. And so like the opportunity for us to continue to make those things better is wild because

And there's not enough of us doing it. And so like, I hope more people decide that what they're going to do is like go build some crazy stuff. And like, if you want to go build crazy stuff, like come show it to me and I will, I will talk about it on podcasts. Like I will do everything I can to amplify the crazy. Cause like there should be more of it. Cause the opportunity is so big. I hope that's what comes out of this depressing AI sunk in place of tech right now. I hope it's like,

I'm so excited to see startups that are solving real problems that we actually asked for. Have faith. It is what's going to happen. Because in the end, what matters is what changes people's actual lived day-to-day lives.

Making their lives better. And if it doesn't impact their day-to-day lives, it doesn't matter how good an idea it is. And it doesn't matter how cool the technology was. Like, it has to actually impact people's actual lived experience. We've lost the way of caring. AI is going to do that, but not in the way people think that it will. People are like, oh, the way this is going to impact our lives is by decimating what we do. No, no, no. It's going to change.

It's going to augment the experience of what we're already doing. But if it doesn't, then we won't do it because who's going to use it to do it? Like who exactly is the person who's doing it? But I feel like we're in this weird place where they're not listening to customers. They're not listening to what people want. They're just like, I made this cool thing. And I'm like, that is the breakdown of being good in technology is when you no longer build things for a customer and you're building it for your ego. Yeah.

Here's another hot take for someone that I love. So like Jason Warner from GitHub, from previously GitHub, now Poolside. They just raised $500 million.

to go and build like a cool, a better like AI thing for programming. And, uh, but like even my expression of exactly what it is, is hard. Cause if you go to the website, it kind of tells you, but it sort of doesn't. And then if you want to try it, I like, I could email Jason and be like, let me try it. And he would let me, and that'd be cool. But like, I don't really know what it is. I'm not quite sure. And the reason that he can have that cash is because

we've collectively decided as an industry that this is like a transformative moment. That's going to change the shape of everything. It will probably, but like, will there be winners and losers? Absolutely. All the venture capitalists are making those bets. They're just making them, which one wins. Well, it's going to be the one that people actually use to change their day-to-day life that to, to in the flow of their, their, whatever they're going to go and do.

And if you're an infrastructure person, you should be the least worried about AI because the things that AI needs in order to make those good decisions, that does not exist. Documentation. It just doesn't exist. Which is funny because we're automating our way out of good documentation. We totally are. But like, it doesn't exist. And like, it's really hard to train. You can train it on the code, but the code doesn't mean anything.

And that's like the code. It doesn't tell you enough about whether it's good or bad or whether it works or doesn't. Which is funny because we're going to make a whole generation of engineers who don't know how to do a lot of the like things that they've abstracted away, which are going to make it that much harder for them to figure out what went wrong. And it's going to like...

I don't even know. Well, but it's going to create incredible opportunity for people who do. And so even if that's what happens, because it is what's happening. Like right now, a lot of cloud engineers, we replace source control. We had to rebuild source control on top of this graph system that we built. That's an insane thing to decide to do. And the only reason I didn't think it was that insane was because I remember what it was like before we had source control. I was there. And so I'm like, well, I remember when all we had was CV, when we didn't have CVS.

And then I remember what happened when we did. And I remember when you could read the source code to CVS and be like, that's how source control works. But if you say it to someone who's only ever used GitHub, they're like, what do you mean you rebuilt source control? Source control is air. You can't rebuild air. And you're like, that's not air. It's just stuff. It's like, it's like when you meet a mechanical engineer and

And they like actually like they made a motorcycle or something out of spare parts. And I'm like, what kind of wizardry is that? Yeah. Like you just built a two stroke engine because you felt like it. And they're like, yeah, it was no big deal. It was two hours of work. And I'm like, I could I would die before I built a two stroke engine, you know?

And like, that's what I mean. You gave me hope in technology all over again. The infrastructure people, our people in this era, they should have the most hope. They should have the most opportunity because right now, like they have the most arbitrage between what we know and what the rest of the world doesn't. Guys, Adam just gave us the pep talk that we needed in tech. Get paid. Like so hard. Like, like, like.

I feel like I have a future in tech right now. Cause you do. Also, I've never considered working for a startup so hard. Like I might leave Fang and go to a startup and like build something cool. Cause like, I'm so tired of building. You're really good at the system initiative pitch.

So call me if you get any like spots open, like, cause like it would be so, I just want to solve actual problems. Look, but it's real. And like, whether you, whether you join a system initiative or you start something on your own, like, this is what I mean. Like there's the part of what I've gotten to do in my life is like, is the business side of it. And like the, the business side of this, the, the opportunity, not just for system initiative industry wide, but

It's never been better. Never been bigger open field running for infrastructure startups and for new ideas. You can clean the table. And like, you just have to decide that you're gonna. And yeah, I hope people do because it's so... It's like right there. It's annoying to me. Like a week ago when you post it, I like...

like I shared on LinkedIn and I was like, finally, it's something solving or like, you know, like something I'm excited to use for like, do you miss that? Like everything you just was like, oh, it's another one. Like, you know, like finally I'm like, like. Yeah. That's why I spent the last five years building this one. That's exactly why. Cause I was like, oh, I, I really want that. And if I want it in my life, I'm going to have to build it myself.

And I can. Adam, we absolutely have to have you back on the show in like a year to hear how this has progressed and the things you've learned and the crazy things people have done because that's going to be awesome. Dude, I'm rooting for you. I'm so excited. Thank you so much for coming on the show and thank you for telling us everything from Twitter dumpster fires all the way to hope in the tech industry. This has been awesome. It's a pep talk I needed, Adam. I'm like...

There's hope. I'm so glad because I think it's really true. That's no bullshit. That's the reality. Thank you everyone for listening. And if you haven't tried it already, go look at this initiative. See how it's different than the drudgery you're doing today and how it's different and maybe what it would be doing in the future for you. So really fantastic just to be able to discuss all that and see what we'll do. Thanks, friends.

And yeah, if we can be helpful, you know how to find us. We're easy to find. And yeah, if you have a startup you want to run, like you should, you should shout. Not that I write checks, but like, I'll help you find money. Like, let's go like get crazy. That's awesome. All right. Thank you so much. Bye.

Thanks for listening to Ship It with Justin Garrison and Autumn Nash. Subscribe now if you haven't already. Head to shipit.show for all the ways. Or just search for Ship It wherever you get your podcasts. You'll find us. Thanks once again to our partners at Fly.io, to the mysterious Breakmaster Cylinder for these dope beats, and to Sentry. Use code CHANGELOG when you sign up and save $100 off their team plan.

That's all for now, but come back next week when we continue discussing everything that happens after Git Push.