Have you ever thought about getting your small product into production, but are worried about the cost of the big cloud providers?

Or maybe you think your current cloud service is over architected and costing you too much?

Well, in this episode, we interview Michael Kennedy, author of Talk Python in Production, a new book that guides you through deploying web apps at scale with right sized engineering.

This is Talk Python To Me, episode 531, recorded November 26, 2025.

Welcome to Talk Python To Me, a weekly podcast on Python.

This is your guest host, Christopher Trudeau.

Follow me on bluesky, where I'm trudeau.dev.

You can follow the podcast or this week's guest on Mastodon, @talkpython for the show and @mkennedy for the guest, both on fosstodon.org.

And keep up with the show and listen to over nine years of episodes at talkpython.fm.

If you want to be part of our live episodes, you can find the live streams over on YouTube, subscribe to our YouTube channel at talkpython.fm/youtube and get notified about upcoming shows.

Look into the future and see bugs before they make it to production.

Sentry's Seer AI code review uses historical error and performance information at Sentry to find and flag bugs in your PRs before you even start to review them.

Stop bugs before they enter your code base.

Get started at talkpython.fm/seer-code-review.

And it's brought to you by Agency.

Discover agentic AI with Agency.

Their layer lets agents find, connect, and work together.

Any stack, anywhere.

Start building the internet of agents at talkpython.fm/agency spelled A-G-N-T-C-Y.

Michael, welcome to Talk Python To Me.

You know, I looked it up.

You've been on the show more than anyone else.

But in case there's new listeners, tell us a bit about yourself.

Incredible.

Good to be here with you, Christopher.

A bit of a turn of the tables, I would say.

And it's, you know, long time listeners, I'm sure they know all the little details because I work them in here and there.

I think that's kind of fun to just make things personal.

But I've also said this on the show, and I'm sure it's a surprising fact that you know as well, but over half of the people in the Python space have only been here for two years.

Yeah, I keep seeing that stat.

Yep.

That's crazy, right?

So even if people, you know, I told this story about my background five years ago, like those people weren't here, like half of them.

So crazy, crazy stuff.

All right, so my backstory, I was, I thought I would be a mathematician.

I studied math.

stuff like that in college, was working on my PhD, started doing a bunch of work with silicon graphics, mainframe, supercomputer type stuff so that I could do my math research.

And I realized, wow, this programming stuff is way more fun than math.

How do I change gears?

And so that was like 1998, 99.

Haven't looked back.

I've been programming since then and super fun, a couple of languages and around 10, 11 years ago, started Talk Python, year after that, quit my job.

Made Talk Python my full-time job.

Started offering courses as well.

That's something that people don't necessarily know.

That sometimes they'll ask, well, what do you do for your job, actually?

I'm like, well, we're doing it.

So anyway, that's me.

A super, super fan of Python.

Super fan of programming.

Every day I wake up just like, wow, how awesome is today?

Look at all the new stuff that came out that we learned that we can do.

Like new libraries, AI stuff these days.

Yeah, there's always plenty to talk about.

It's incredible times.

It's incredible times.

And you've added a new trophy to the mantle, I guess.

You've written a book.

I have written a book.

You know, that's a little bit, I'll put it this way.

It's not something I ever saw myself doing, but I'm really excited that I did.

And yeah, it took, I spent a couple of months properly writing it.

You know, I really put in my energy in and like all projects, you think you're about done.

Yeah, that first 80% is nothing like the last 80%.

No, and the last 5% is long.

You know, and it's not just the book.

It's like, okay, well, where am I going to sell it?

Okay, well, Amazon, and then I'll self-publish, or do I use a publisher?

You end up self-publishing it, but then you're like, how do I?

You know, all these things you learn for the first time.

Like, how do I get it into Amazon to sell even?

And there's a bunch of decisions.

I can tell you, even with having taken the publishing route, it's no easier.

It's just that it goes dark for two months and then all of a sudden it's like, you need to do this by yesterday.

So yeah, it's not necessarily an advantage either way, I think.

Yeah.

Yeah.

Yeah.

I was really on the fence and I thought, look, let me just try this myself.

I got a few podcast listeners.

I can let them know about it.

An audience helps.

I honestly think it was probably the right choice for me.

And for those who haven't come across it yet, do you want to give us the one paragraph version?

Yeah.

So the book is called Talk Python in Production.

There are other books that are, I'm pretty sure one is called Python in Production or other things about how do you get your Python app into production.

But this is Talk Python in Production because it's sort of a dual role storytelling vehicle.

Obviously it's nonfiction, it's a technical book.

But the idea was, let me tell not a generic story of how you might run some of your Python code in production, mostly APIs, web apps, databases, like that kind of stuff, right?

not a general story of that but my story right i i've been on this journey of not complete noob but pretty significantly lost getting my original python app out into the world to pretty confident running stuff in i think a simpler than usual way in a good way right i one of the things i really

liked about the book is it's not quite changing gears but you you do a nice mix of sort of the decision making process versus the here's exactly what i did um and so you get a little bit of both and and honestly the decision making process is something i find often isn't there in a lot of work uh you know your your standard blog post is always well and then and then add exactly this to exactly this file um but i think i really really sort of enjoyed the and and this is what i tried and this is this is why i changed and you're very kind of humble about it like it like a lot of folks who write this kind of content it's thou shalt do this and you're like this is the way i've told you yeah yeah this worked for me and uh yeah so so i really like the fact that you've you've kind of blended that in what what made you decide to do this like that what there so you said

you didn't really have the itch to go down the path so uh what i'm not sure i didn't have the itch i just didn't think that it was something i was capable of ah i see okay you know what i mean not not that i didn't think if i literally took two years of my life and went into like a cabin the rose style or something i could come out with a book i'm pretty sure but given all the constraints of like i have a family and i gotta keep top python running like in that sense i didn't I didn't think I would be able to do it, but.

- Yeah, it's perseverance more than anything else, I think.

Yeah, yeah, for sure.

- Exactly.

So, yeah, go ahead.

- Sorry, go ahead.

No, no, go ahead.

- You know, so why did I write it?

Two reasons.

One, I think it's an interesting story, and I thought people would enjoy hearing it, like the personal side that you mentioned a little bit.

I thought people would appreciate that.

And maybe more significantly, I feel like a lot of the advice out there in the tech space in general, but for now we're focused on like, how do I deploy my app sort of like Python plus DevOps type of thing.

But I think a lot of the advice out there is a little bit of a flex in the sense that, oh, look at this, we're using these seven services and then this technology, and then we're auto scaling it with that.

And then we have these logs pumped over to this other thing.

You're like, whoa, okay, that's kind of cool.

But a lot of people who just have an app they just want to go from like it works on my machine to look what I made they see that and go I can't do that you know what it's not for me it's just like I can't spend $500 on this infrastructure and I don't feel worthy if I don't have all you know like completely geo distributed redundant databases and like you don't need that you know what I mean and people keep asking me like hey Michael can you give me some advice I'm like well not that and finally I'm like let me just tell the story you know and so that was a big motivation you see it in industry a lot

it's sometimes referred to as you know resume based architecture right like it's a do we need this or is this because i'm trying to learn it um and i think there's always that oh some of it's aspirational right i we will be netflix and so you know we need to be on every continent and all

the rest of it and uh right right it's it's very aspirational it's like i'm going to build this app And the reason I'm building it is it's going to take off.

And that day when the hockey stick hits, I'm ready.

Yeah.

You know what I mean?

There's also a, you know, I think there's a lack of recognition of the cost of both in energy and money, energy as in human effort.

I'm not talking about electricity, of the next 1%, right?

So like getting from 90% uptime to 95% uptime costs something.

getting from 95 to 96 costs more than that and getting from 96 like and once you're getting into like the four nines five nines thing and then you know cloud flare goes down and you're all screwed

anyways right so it's so it's so ironic it is 100 ironic that you take all these steps and you employ all these services and it's the complexity of those services that went down like yeah you know this show will come out in a couple of weeks, but we're just on the eve of basically three weeks of important things going down.

First AWS, then Azure, and then GitHub.

And also, and then Cloudflare, so let's put that as four, within three weeks, right?

And the AWS one was like, the reason it went down is DynamoDB had some sort of DNS problem.

Even if you're not using that, the thing you're using, Like Lambda depends upon DynamoDB for itself to work.

So it was just like a cascade of kabang, right?

And that's a little bit of this complexity.

Like the more complexity you buy in, even if it's not yours, it is yours in a sense.

Yeah, yeah.

And there's always humans involved, right?

So there's always fallibility somewhere, right?

Although one of the arguments I have seen recently in response to the Cloudflare outages, the good news is if you're, you know, I saw some articles that were like, well, you shouldn't be dependent on Cloudflare.

And I saw the counter articles were basically, you know what, when half the internet's down, no one's hassling you that your app is down because half the internet's down.

So there is an excuse when it isn't your fault.

So yeah, anyways.

That is true.

And you don't see what Cloudflare saved people.

Yes.

Right?

I'm not using Cloudflare.

I actually use bunny.net.

But CDNs make it possible for your app to survive these spikes in ways that they very well may not with without and certainly the ddos type of stuff that they protect

against well and i use it simply for certificates like google decided everyone shall be https even my sites that don't need it and rather than try to figure out automation for let's encrypt has gotten a lot better but when i first started it it was like and i need this and i need this and i need this and then the cron job could go down or it's like or i can stick cloud fire in front of it and I never have to think about it ever again, right?

So yeah, there's a little bit of value that way.

Yeah, there definitely, definitely is.

Another thing I want to kind of bring back a little bit is that you opened this segment on.

You said, like I shared the human side of the story in kind of a humble way.

Like that was certainly something, that was one of the main goals, like I said.

I think it's just a continuation of the podcast, right?

I started the podcast 10 years ago and I'm like, when I got into Python, there were no Python podcasts.

there had been but there were none at the time and i'm like there's all these cool libraries i want to hear the stories and the humanity and you go to the documentation and you're like cool technology sterile as can be and the reason technology is interesting is not just because there's an api i can call this but it's like it's a journey and it's a story and it's so i just

wanted to do that again in the book it's all problem solving right and and there has to have have been a problem for someone to want to solve it, which means there's going to have been people involved in trying to figure out what that is.

Yeah.

I think a lot of people maybe, I don't know,

I shouldn't speak for people.

It seems to me though, like a lot of people, they look at a technology and they think, they just assess it as a dry, sterile sort of thing on its own.

That was created in a context, right?

Why was celery created?

Not just so I can send events to it and like, you know, add more complexity and asynchronous, it solved a real problem.

And if you, if you hear and you understand and you, you follow that journey, you're like, I see this is where this come from and why it exists.

Then you can decide, is it for me?

Right.

Well, and, and I think doubly so in the, in the open source space, because like this is all volunteer work.

And so knowing a little bit about who's doing what and, you know, humanizing that a little bit.

Right.

Their motivation.

Yeah.

And it's also easier to be grateful, right?

Like this isn't some soulless corporate machine.

There was a reason behind this and a driver behind it.

This portion of Talk Python To Me is brought to you by Sentry.

Let me ask you a question.

What if you could see into the future?

We're talking about Sentry, of course.

So that means seeing potential errors, crashes, and bugs before they happen.

Before you even accept them into your code base.

That's what Sentry's AI Sears code review offers.

You get error prediction based on real production history.

AI Seer Code Review flags the most impactful errors your PR is likely to introduce before merge using your app's error and performance context, not just generic LLM pattern matching.

Seer will then jump in on new PRs with feedback and warning if it finds any potential issues.

Here's a real example.

On a new PR related to a search feature in a web app, we see a comment from seer by sentry bot in the PR.

And it says, potential bug, the process search results function can enter an infinite recursion when a search query finds no matches.

As the recursive call lacks a return statement and a proper termination condition.

And Seer AI code review also provides additional details which you can expand for further information on the issue and suggested fixes.

And bam, just like that, Sear AI Code Review has stopped a bug in its tracks without any devs in the loop.

A nasty infinite loop bug never made it into production.

Here's how you set it up.

You enable the GitHub Sentry integration on your Sentry account, enable Sear AI on your Sentry account, and on GitHub, you install the Sear by Sentry app and connect it to your repositories that you want it to validate.

So jump over to Sentry and set up Code Review for yourself.

Just visit talkpython.fm/seer-code-review.

The link is in your podcast player show notes and on the episode page.

Thank you to Sentry for supporting Talk Python and me.

Inside the book, you've added a couple of things that are a little sort of non-standard, like the audio reader briefs and the galleries.

You want to give a quick rundown?

And speaking of motivation, what motivated you to include those things?

- So let me describe what they are first, 'cause they are weird, but they're weird in a good way, I think.

So if you go to the book, my vision was somebody's gonna be reading this, very likely on a Kindle, and if I go and put really nice diagrams, pictures, whatever, how good is that gonna look in a Kindle paper white, black and white, you know what I mean?

Like how hard is that going to be to read?

I think it's gonna be hard is what I decided.

And so what I ended up doing is I said, okay, How can I make it better for people so that when they want to work with code, it's not trapped inside your Kindle or your iPad, Apple Books or wherever you read it, but it's super accessible, right?

So what I did is I created some things I called galleries, and there's a code gallery, a figure gallery, and a links gallery.

And these are just like, they're kind of like an index of those things.

So like the links one just says, hey, here's all the URLs that we talked about in chapter 10 or chapter 11.

and just the sentence that contains them.

So instead of trying to go back through and flipping through the book, like, where was that thing they talked about, right?

Like, no, you just go to the gallery and you click on the chapter or you just do command F.

There it is, you know what I mean?

And also for, especially for the figures, like it has like 2,000 or 4,000 by whatever level pictures that you're not even allowed to put into like a Kindle book.

They're like, no, we're going to redo those, rescale those images for you down to something fuzzy, right?

So if you want to read like little tiny texts, I put it there.

So that's the galleries.

And I was just maybe a little bit more backstory here is when I wrote this, I've worked with other type of editing things, any tools.

I'm just like, I need to write this and I need to get this done in a super fluid way.

So I'm just going to write in Markdown.

Right.

Just writing in Markdown.

And so what I did is I, of course there's book publishing things that you can put Markdown into and so on.

But I'm like, I'm just going to write one markdown file per chapter and then write some Python program to assemble that in interesting ways.

Right.

And then turn that into an EPUB or PDF or Kindle or whatever through something called Pandoc.

Are you familiar with Pandoc?

I've heard of it.

Yeah.

If you go and look, for people who don't know what Pandoc is, if you go look at Pandoc, it has right on the web page, it has this like fuzzy thing on the right.

It's like gray fuzzy.

You know, what is that?

this thing on the right shows you all the formats that go in and all the formats that could come out and it's it's insane like you can't even the line is just the lines connecting the graphs of these things it's just a black blob like i could put a haddock uh a haddock document whatever that is it convert that to a doc book four right i mean it's insane okay so what i did is i built this Python, simple Python thing that reassembles Markdown in certain ways and then feed the final thing that it built into Pandoc to get the different ebook formats.

Right, right.

Okay.

But then it occurred to me, like, so I didn't start out with these gallery type things or other stuff, but I'm like, well, this is just Python against Markdown.

Surely I can start pulling out all the links and pulling out the images and then writing them somewhere else and then just committing that to GitHub.

So once, you know, it's kind of just the standard story of Python or programming in general, but I think it's extra common in Python.

It's like, I started solving the problem with Python.

And once that was in place, it's like the next block and the next thing is just like, that's easy now.

And that's easy.

And these three things are also easy.

Let's just do that and just keep adding to it.

So that's where they came from is one, wanting to make sure people had a good experience with like code resources, pictures, and so on.

But also it's just kind of following the lead of like, hey, let's just keep going.

Well, and it's one of the beauties of an ebook.

If dead tree copies, those things cost money.

And so it's like, oh, I've got a great idea for six more appendices.

And that's when you start going, oh, wait a second.

I'm not going to add 300 pages to a 200 page book.

Yeah, exactly.

With an ebook, you can go, oh, yeah, here, we can make this referenceable in a couple different ways.

Right.

Yeah.

It's like it duplicates the images into, you know, maybe 20 more pages or something, but it's an ebook.

Who cares?

Exactly.

Yeah.

Yeah.

So, you know, over the history of the show, I think I've become familiar with your AI journey.

And recently, it sounds like you've bought.

It's your fairly big proponent.

That being said, there's still a Made by Humans logo inside.

Yeah.

So I'm going to put you on the spot.

Do you believe in it or not?

Do I believe in it or not?

So why made by humans?

Yeah, it's a really good question.

So I think there's a weariness of content generated by AI or assisted by AI meant to attract attention and build authoritative feelings about a thing.

when that authority or that skill set is not necessarily yours.

And that I still very much do not like.

If I wanted to create a blog, I mean, I guess I could do it.

It'd be a fun experiment, I guess, in sort of an evil way.

Like, what if I just go create a completely random blog and I just have chat just bust out an article twice a day, every day, of the thing that's on the top of Hacker News or something?

You know, just like, you could do that.

And actually, it might even be interesting.

I don't really even know.

but I don't want it.

I don't want that.

Right.

And for this, I wanted to share my story, not have AI create a book that has bullet points of my story.

Right.

Right.

Yeah.

So for me, it was important to like write this.

I wrote it a hundred percent by Michael, right.

It took me a lot of work.

People's, I know like it got posted on like Reddit and I think hacker news somewhere.

There was a bunch of comp and they're like, Oh, this thing is definitely just AI generated.

I'm

felt not AI generated to me.

If it makes you feel any better, I've had actually comments pop up on some of my video courses claiming that my voiceover was AI.

So that's just the world we live in now.

It's the world we live in and there's not a lot you can do with it.

So just kind of put a little bit of a pushback against that.

I did put like a prefix sort of thing and a label that says made by humans.

And you know, what's really funny is I don't know if I can actually find that section.

I don't think I can on just the web part, but I made a picture.

Maybe I did.

Humans?

No.

Anyway, I made a picture that I drew.

I literally, I'm a big fan of Pixelmator Pro.

I went into Pixelmator Pro and I drew it.

And they said, proof that this is AI generated.

Look at that stupid made by humans graphic.

It's clearly AI generated.

It would be way better if it wasn't generative.

Yes.

Okay.

So how do I square that with me actually being quite a fan of AI stuff these days?

Like I'm, let's do like a looking back and then looking forward.

So let's go back 30 years.

I'm also a fan of using editors that when I hit dot, tell me what I can do with that function, class, variable, et cetera.

So I'm not constantly in the documentation, right?

Does that make me not a programmer?

I don't think so.

I'm still writing code.

I'm still thinking architecture.

I'm just not in the documentation constantly.

And honestly, I maybe don't memorize every little function and field of everything in the standard library, right?

It's fine.

That's not where our time is best spent.

And I feel that way about AI programming.

I think there's a lot of, there are pitfalls and there are worrisome aspects of it.

But you can use some of these agentic AI tools these days to think in so much higher level building blocks.

Think of like, I'm working in a function and I'm writing this part.

or I'm working in design patterns.

And I can think of these big sort of concepts.

Well, with this AI stuff, you can just say, what if we had a login page?

Oh, we have a login page.

Now, what other building block do I need?

Like the building blocks are so big and sort of non-critical software, non-super important software becomes so much cheaper than before.

You're like, I wish I had a little utility or app that would do this, but it just definitely doesn't justify two weeks of work to have it.

Like, what if it was a couple of prompts and half an hour?

Like, yeah, well then I'll have it.

You know what I mean?

And you can, that is transformative

for how we work.

Yeah.

So much of coding is boilerplate, right?

So if we can figure out how to make that easier, then why not?

Right.

And I haven't got there with it myself.

I don't know whether I will.

I'm definitely a little more suspicious of it than you are, but I copy and paste code all the time.

And it's not like I'm like, oh, I have to hand tune that.

No, it's like, well, I got to copy something that does that.

- Yeah, let me give you a concrete example because I think it's easy to talk in generalizations and people are like, well, that's not for me, a bunch of AI slop, which is fair.

But I'll give you an example of one thing I'm like, this was just such a nuisance and I'm gonna fix it.

So when I first built Talk Python, the website 10 years ago, Bootstrap was all the rage, not modern Bootstrap, like old Bootstrap, right?

Which they've completely redone the way that you have to structure your HTML and CSS completely, incompatibly, several times since then.

And until very recently, until this summer, every time I wanted to add a feature or an aspect, like for example, this whole section that hosts the book, I wanna add that, well, you know what I had to do?

I had to go write like 10-year-old Bootstrap.

And I'm like, I hate it so much.

There's so much nicer tools I could be doing this.

but there's 8,000 lines of HTML and almost as many CSS.

Does it justify me rewriting that much UI so that I can feel a little bit better and use a little bit nicer UI tooling?

No, it definitely doesn't.

And so for a couple of years, I'm like, oh, I wish I could do something else, but it's not worth it.

And then I was sitting on my porch, little back area with my computer in the summer, hanging out, I'm like, you know what?

I bet Claude could do it.

Hey, Claude, rewrite all of this site.

make a plan and rewrite it, move it from Bootstrap 3 to Bulma, which is like simple tailwind, and just completely do it.

Four hours later, the whole thing was redone, like 20,000 lines of edits.

Wow.

Done.

And it wasn't perfect.

I had to go, you messed up a little bit here.

And actually, that was right, but that doesn't look good anymore.

So could you actually just make it look, you know what I mean?

But I mean, it was like half a day.

That work was done.

Right.

And that is a different level.

No, it would have been weeks to a month.

And it's the worst kind.

It's like, okay, here's how the grid system used to work.

Let me restructure the HTML.

Oh, you lost a div?

Whoopsie.

Now how are you going to untangle this?

You know what I mean?

Like really, really not good stuff.

And you can just turn these tools on it.

And I'm like, you know, love it or hate it.

That is a skill and a power and a tool that is unlike things we've had before.

And so when I started having some of those kinds of experiences, I'm like, all right, I need to pay attention to this.

I honestly think a lot of these AIs and LLMs, they're kind of copyright theft and other types of things.

And there's the environmental aspect and all that.

But the thing is out of the box.

Pandora is on the loose, right?

So given that you're putting your head in the sand, it's not going to make it go away.

Should you use it or not?

It's a very powerful tool.

And so that is what I'm excited about, but I'm not excited about when I go to YouTube and I see a video and you can just tell that it's a voiceover plus some general, or I go to read a blog and you can tell that it's like, they didn't even put enough energy into like, they spent less time writing than I have to read it.

That's not right.

There's something going wrong here.

- Well, as with all tools, we'll figure out what works and what doesn't work.

Those 8,000 files that you're talking about though, those are 8,000 files you have and built over time.

I suspect- - Lines, by the way, not files.

- Lines, I'm sorry.

- I think it's a couple hundred files probably.

so, but, so that might be something that folks listening aren't really aware of, right?

Like, you're not just the, you know, the podcasts and the courses, but you're the guy behind the engineering behind all of it.

So why, you know, why do that?

Why not, you know, Squarespace or something along those lines didn't exist when you came out, but you get the idea.

Like what, what, what, why spin it up yourself?

How did you, how did you get there?

So it's a good question.

When I started, there were places I could have gone and hosted the podcast.

You know, they were very unappealing.

Not in the sense, like, as a consumer of it, like, they put your show there.

They were really ugly.

And they would do things like, next to your show, here's some other shows you might like.

You're like, no.

No, I don't.

I just got people to come to my page.

You're sending them away.

Like, don't do that.

Right.

But those sites are like Squarespace or whatever, and they're hosting a bunch of them.

And so they want engagement on their platform broadly.

They're not for you.

So initially I thought, well, plus I don't have a ton of experience writing Python code.

And if I'm going to do the podcast, the more I can get my hands on this stuff, get experience.

So I just sat down and really in like three days, I wrote the Talk Python website.

I'm like, I'm doing it this weekend.

You know what I mean?

I had a job at the time.

So I'm like, I got to do it.

It's a long weekend.

We're doing it.

And so I just sat there and cranked it out and really got a really good appreciation for building all the way to the end, you know, like not 60% or following a demo, but like, no, here's a fully working app and all the little nuances.

But then honestly, that's like the genesis of this, the story that is the book is, well, now how do I get it out there?

I built it.

It's fine.

It works great here locally.

Now, like, where do I take it?

Right.

And a lot of places said, well, you just fire up your Linux terminal and your SSH.

And I'm like, these words are making me very nervous.

I need them to not do that.

I need you to stop saying that.

Don't forget to swing the chicken over your head.

Exactly.

So I actually started in Python Anywhere, even before Anaconda owned them, which was the selling point was you go to your browser.

You, I think you give it a get URL, or maybe, maybe you go into a terminally do a get plot.

I can't remember how it worked 10 years ago, but it was basically you go to the webpage, you type in your domain, you get a terminal, which is basically an SSH connection, but in the terminal, and then you give it some commands and then they manage it for you.

And I'm like, okay, I don't really have to know any Linux.

I just have to do the two things that says in the terminal.

And then they keep it running and they, they do the SSH key, the SSH certificates, the DNS, that i'm like this i can do this and i got it going there and i was really proud and i ran i ran talk python on basically python anywhere and sqlite for like six months first six months but then it occurred to me that python anywhere is not really intended to host production level applications and it occurred to me when i got an email from them one day again this is pre-anaconda and what it said was we're going to be down for four hours as we do some maintenance that's not going to be the best look for my podcast which is just now starting to gain some traction and getting a lot of people talking on social media and saying hey there's a new podcast you should check it out i'm like the four hours are not making me psyched like i understand that things might have to reboot they might be down for 30 seconds but hours and hours seems a little like this is not really what they intend this for it's like for hobbyists to put up a thing and i probably don't

belong there anymore and once you shifted why not aws or azure or something like that so

So I looked around and I went to DigitalOcean.

So I'd done stuff with both Azure and AWS.

A little part that I left out about this web journey is I had actually run some pretty big websites in both AWS and Azure, but they were Windows-based.NET type things, right?

So literally GUI sort of configuration hosting them or platform as a service.

And I don't know, I looked at both of them, especially Azure at the time, I'm like, "Well, this is complicated," and like unnecessarily so, and I'm afraid I'm trading one level of complexity for another, and also really expensive, like no joke expensive.

The podcast, like in terms of people viewing the pages, is nothing insane, I mean, it's certainly popular, but it's nothing like, how are you gonna handle that?

But the amount of traffic the podcasts and courses do in terms of video and MP3s and even XML, Like I think Hawk Python ships about a gigabyte of, no, a terabyte of XML.

Think about a terabyte of XML every month.

Like it's basically a distributed denial, a DDoS, and a welcome DDoS attack, because you'll think how many podcast players are out there going, got a new one, got a new one, got a new one, got a new one.

And each one of those requests is like a meg of XML or more.

You know, it's like, got a new one, got a new one certainly the courses and my bill was well over a thousand bucks and just bandwidth right and then I looked at DigitalOcean and I'm like oh you mean it all that bandwidth is free it's included you get like terabytes of free traffic with DigitalOcean or Hetzner or some of these smaller ones and I'm just like yeah this is better like I don't know what I don't know what this stuff for is here where they charge you know a hundred dollars a terabyte yeah just to ship stuff around it's crazy

I have found, particularly professionally, it's like, oh, you're going to charge me for how many DNS lookups there are.

That doesn't seem like something I can predict.

Yes, I know.

And quite frankly, if it reaches a certain level, I need you to turn it off because something's gone horribly awry.

This portion of Talk Python To Me is brought to you by Agency.

The Agency, spelled A-G-N-T-C-Y, is an open source collective building the Internet of Agents.

We're all very familiar with AI and LLMs these days, but if you have not yet experienced the massive leap that agentic AI brings, you're in for a treat.

Agentic AI takes LLMs from the world's smartest search engines to truly collaborative software.

That's where agency comes in.

Agency is a collaboration layer where AI agents can discover, connect, and work across frameworks.

For developers, this means standardized agent discovery tools, seamless protocols for interagent communication, and modular components to compose and scale multi-agent workflows.

Agency allows AI agents to discover each other and work together regardless of how they're built, who built them, or where they run.

And they just announced several key updates, including interoperability with Anthropics, Model Context Protocol, MCP, a new observability data schema enriched with concepts specific to multi-agent systems, as well as new extensions to the OpenAgentic Schema Framework, OASF.

So are you ready to build the internet of agents?

Get started with Agency and join Crew AI, LangChain, Llama Index, BrowserBase, Cisco, and dozens more.

Visit talkpython.fm slash agency to get started today.

That's talkpython.fm/agency.

The link is in your podcast player's show notes and on the episode page.

Thank you to the agency for supporting Talk Python and me.

There's certainly areas where the cloud can go like sideways.

In the book, I mentioned a story about Kara, I believe.

And that was this project that this woman, I think in Hong Kong or South Korea, I'm afraid I can't remember which, I think it's South Korea.

Anyway, created this.

she's a photographer and really hates ai generated art so created this service that would say hey give me a piece of art and i'll tell you if it's ai generated or not or something vaguely like this and her thing took off in the app store and was like number six and her cloud bill at versell was ninety six thousand dollars in a week right as not as a business just as a human who built something

fun as a side project like oh my yeah and in fairness to a lot of those tools they tend to have ways of saying, please limit this and do that.

Yeah.

They're not the default.

And if you're not thinking about that problem and protecting yourself, you know, you'd, you'd kind of hope that it would be the other way around.

It should be, yeah, you know, here's your cap.

And if you want more than that, you need to do something about it.

Yeah, absolutely.

And to their fairness, they did send her a message saying your bill is going way higher than you might expect.

And she didn't look at her email or something, but still.

And so one of the things that really appeals to me is when you choose something like a Hetzner or a DigitalOcean or something, and you say, I'm going to pay for the server.

You're like, okay, that's $40 I'm committing to.

Maybe double that, you know, whatever.

But the bandwidth is basically free or it's included, right?

But for 40 bucks, it feels free.

And then it's only going to cost as much as it costs.

You might have to go, oh my gosh, it's too much traffic.

We're going to have to deal with it.

but it's the upper bound of those systems these days is so high.

It is so high that we, you know, back to that aspirational thing that you mentioned, right?

Like the chances that you blow past what a $50 server can handle, you're going to be really, really popular with the SaaS or something.

You were joking earlier about SQLite.

It's gotten so much better as well.

And I'm not saying it's the answer to everything, But I could probably come pretty close to running your site now too.

Like it's scary between the processor improvements and the improvements in the software.

It's made a big difference for that kind of stuff.

It takes very, very little hardware to handle something that's pretty, pretty impressive.

Yeah.

So I think the title of chapter four is one of my favorites.

It gives a little hint as to what approach you took.

The title is Docker, Docker, Docker.

so what approach did you take you know what i was really not wanting to do docker on genuinely i mean

that and so what i did when i originally switched over to some vms i'm like okay the story i'm told of what the cloud is you know i bought the aw the ec2 story well we've got all this extra capacity oh instead of getting like really expensive heavy metal you know big metal sort of servers you get a bunch of small ones and they're kind of like cheap and you just make them throw them away whatever right so I went and made a bunch of small servers in in DigitalOcean I think I had eight servers at one point and I thought this is gonna give me lots of isolation if I got to work on this one thing it won't mess with that and what I realized is they're interconnected enough like that really I end up just having to reboot eight servers in an orchestrated way than managing I'm like this is just worse I gotta patch eight servers instead of one now because this is not better so how do I end up with docker docker docker I I realized that it would be better to just have one server and basically stepping back just a little bit.

Like, what if you could completely isolate yourself from almost all the complexity of the cloud and all of their services and all that junk and just say, I have a place where I can run apps that's got enough capacity that I can just keep throwing more apps in there if I want.

And it doesn't have any tie in with the specific APIs and services of a particular provider.

So I said, well, what if I just get a big server and I just run all my apps in there?

And if I want a database, I put the database there.

If I want like a Valkey caching, I can put a Valkey caching and things like that.

And that's sort of as much autonomy as I can exert on running something in the cloud.

It's almost like I went and got a big machine and stuck it in my closet.

But that's insane because you get million dollar networking equipment and, you know, failover.

But that doesn't mean you have to go fully pass managed database, this other service.

Like you could just say, just give me a Linux machine where I can then go do my, do my, my hosting and all my apps and let them party and talk to each other and stuff in there.

Right.

So then I thought, well, I don't have all these little servers for isolation.

I'm not really sure I want to throw all this random stuff together, like completely just in the same soup in that one big server.

And by the way, the big server right now that it's running has eight cores, 16 gigs of RAM, and costs $30.

Right.

It comes with two terabytes of four terabytes traffic, something like that.

Lots.

$400 of included bandwidth for $30.

So I said, well, what if I took that over?

I think autonomy is a big motivator of this whole journey as well.

Like, I don't want to be tied into all these different things.

I just want a space where I have reliable compute and networking and Linux, and I can just do whatever.

So then I said, all right, well, I better figure out some of the stuff with Docker just so that there is some isolation of all the different pieces living in the same space.

So I forced myself to learn Docker and what it occurred to me was, Oh, Docker is just writing down in a file what I would normally have to type in the terminal to make the thing happen.

Except for I put run in front of the command or copy instead of CP and I

get a repeatability and, and, and someone else has packaged a bunch of this stuff.

so you don't have to do it yourself.

Exactly.

And I'm like, okay, I don't know what all my concern was about because it's not much more complicated.

One of my concerns was sort of monitorability.

Like if I just go there and I just create a bunch of virtual environments and run my code, I can actually go and see the source code.

I can see the config files.

I can see where the logs are being written and I can sort of manage it through SSH.

And I thought, well, if I put a bunch of disconnected Docker things together, that's going to be challenging.

And I realized actually, not really.

like if you set it up the same you could still tail all the logs and you can you can ssh into the containers if you really have to you know look at something running inside them like what is the process actually i don't know what does it do how much memory is it using relative to other stuff

but and i also talk about a bunch of tools for monitoring them yeah so how has that changed over time like you started with some fairly bare bones you've got you've got some extra tools what what's What does that evolution look like?

Well, I used to rely more on whatever the cloud provider, DigitalOcean or Hetzner, offered.

You know, they always have like a metrics section.

So I can go see, well, what's the CPU doing?

What's the memory looking like over time?

And that works okay.

And if you've got one app that you're running there, you're like, okay, well, that must be how much memory the app is using.

But right now, if I go to Talk Python and I ask, I think there are 27 different containers running, which you can't ask how's the server doing.

I know very much.

You know, it really matters much more.

Well, it's busy.

I get it.

But which one is the problem?

Which one is busy?

Which one's using all of them?

So I started to look around and there's actually a bunch of recommendations that I have for the book.

So one of them, the first one I used was this thing called Glances and Glances is excellent.

And by the way, Glances, the way they talk about often getting it, I think, where do they talk about installing it here?

Probably is often like apt install glances or something like that, right?

But a lot of these tools even have Docker versions.

If you share the volumes and sockets just right, they function just the same.

So you could say Docker run glances XYZ and it doesn't even install, it doesn't even touch your one big server that is kind of like your building space.

So it leaves it a little more pure, right?

So glances is super cool.

And what it does is it gives you this really nice dashboard of what's going on with your app, like your server.

How much memory is being used?

How much CPU is being used?

How has that been over time?

Has there been like extended spikes and so on?

And one of the things that's new to Glances, and I don't think it's in this picture that's on their home screen.

I'm pretty sure it is not.

Oh, no, it is.

It just, mine is inverted because I have so many.

It has a container section.

So when you run it, it actually shows you not just the processes, but also gives you a performance, memory, IO, etc.

for all the running containers and their uptimes and those kind of things.

So this is super cool.

So you construct a certain Docker command and then you have this running dashboard that just goes.

So this is the first thing that I started with and I really like that.

But then I also found something called BTOP.

Are you familiar with BTOP?

No, I haven't used this one.

Oh my gosh, BTOP is incredible.

This is so good.

it's really something.

Zoom in on it.

So this gives you moving graphs over time of all sorts of things.

It shows you graphs of network, inbound, outbound traffic.

It shows you the CPUs.

It gives you a breakdown of like, here's all the different distributed work across your eight CPU cores and over total.

It's really something else.

And so this one is really nice.

You can configure the UI a lot to show and zoom in on disk activity or whatever.

This is really a nice way to view it.

And again, when you run all these Docker containers, they feel like they're super isolated and tucked away.

And from their perspective, they are.

But when you look in the process list here, it just shows the process that Docker is running.

So I have all my web apps and APIs and stuff setting a process name.

So instead of just Python, Python, Python, Python, Python, it'll say like, talk Python, Granian Worker 1, talk Python, Granian Worker 2.

Versus indexing service daemon.

And then when you look into any of these tools, you can see, oh, exactly what is busy.

And those are actually the names inside of Docker, but they still surface exactly like that to all these tools.

One of the things you said kind of hit home for me, like it was subtle and it kind of moved on, which was like, if you interconnect it correctly, right?

Like if you get the files and sockets going, this goes smoothly.

And I think it's one of the things you've done very, very well in the book is sort of through that, like, as you talk about the different Docker configurations, like, okay, well, this is why we're putting this here rather than in the container, this is going to be shared.

And, you know, and, and there's, and the reason for this, I assume some of that was experimental.

You just sort of over time, you kind of went, oh, okay, wait, I need that somewhere else.

Yeah.

Or, or was it, you know, did, was there somebody's knowledge that you, depended on a lot there?

How did you get there?

How, how organic was the journey?

the, I would say half and half, like some of it, for example, the glances stuff, I just found when I went looking for it, that there was like ways to install.

And I said, it just said, Oh, you could just install it by running this Docker thing.

And it's like a big, long command.

And I'm like, Oh, that's cool.

Because it doesn't matter how long the command is, what I would do is I'll go into my dot ZS HRC and say alias glances equals paste.

And then I saved that somewhere.

And I never I couldn't tell you what it is at all I just know it has to like do a yeah it has a few things so it can like look back into the host to see you know what's running and so on um yeah so a lot of it was was like that and then some of it was definitely you know two whole days of like why won't that talk to that let me build it again let me do some more devote you know what I mean and eventually like okay all right but once you get it kind of dialed then it's once you get a little bit of it working it's a blueprint you just like again again again so so you seem to have taken a bit of

a like a heavier weight approach here you're just it's it's everything in the kitchen sink that that implies that it's not the right amount but it's counter to some of the advice that's out there uh sometimes folks talk about you know wanting to have things as minimal as possible why why what you've done versus the other how how how are they wrong can we start a flame war on the internet you

Let's do it.

Let's see how many, Michael, you're wrong.

I can get into the YouTube comments.

Actually, please, that's not a challenge.

So here's the deal.

I want, especially at the beginning of this journey, when I was like, I want as much comfort and visibility as I can get in these containers and other areas.

You know what I mean?

And I wanted to make it as close to, if I just set up a VM and just, you know, uv, V, ENV, and just roll from there, right?

So what I did is I said, okay, I could try to go for like the super slim Docker image, or I could just get like a basic Docker image, but then put, you know, I put like, oh, my Z shell and ZSH on it, right?

Does that need it?

No, you could use SH, but do you know what happens when you use SH and you go in there?

It's a brand new start.

It doesn't remember anything you've ever, any command you've ever run, it doesn't give you any help.

You know, you hit tab, it doesn't tell you nothing, right?

You're like, oh gosh.

But if you use like, oh my Z shell, it'll show you, hey, what version of Python is your virtual environment activated in?

And I can just hit command R and see, you know, filter all my history and I can hit get tab and it'll auto complete all the get commands that I forgot what I was supposed to use because I'm freaked out because the site is down and how do I fix this?

I mean, I wouldn't actually be in the container for that, but a lot of times you're in there kind of exploring because you're like, it's been fine for six months, but I need to see something.

And so in the book, at least in the beginning, I recommended to people that they install some of these tools that you might install into your own terminal to make you feel more comfortable.

So that my assumption is you're kind of new to Docker.

You're feeling a little uncomfortable.

Like who cares if it's another hundred megs on your hard drive?

You're not shipping your app to Docker Hub.

You're not going to take your web app, probably.

It's not a reusable component.

You've got your source code and you want the thing to just run here.

You're not shipping it.

So whoever wants to run, you know, indeed.com can just Docker pull that and run it.

Like it's, that's not what it is.

And in that context, you're not so worried about the space.

And there's a couple of tips that you can use for like really, really fast build times, right?

So I mean, like container build times for me are like seconds, a few seconds, even though, you know, there's 250 pip install packages for Talk Python training, you know, build times, and build time is also installing Python, right?

You could make these things fast, so it's not like a huge impedance, but I think for people who are new to it, having something other than just sh, not even bash,

you're a lot better off.

So that's what I promoted.

And I think it's, you know, it kind of comes back to sort of the thesis of the book as well, right?

Which, which is right for you.

so, you know, if you are going to be running a thousand of these spread across a whole bunch of different cores, then yeah, if you optimize this, that might change your cost framework and everything else.

Well, right.

Or if I was, if you're 27, if you're 27 on eight CPUs works fine, then, you know, go for it.

You know, why, why, why get in your own way?

And that advice is not like, this is why I really emphasize the context sort of thing, right?

Is this advice is bad if your goal is to ship a container to Docker hub so that people can self host your open source thing.

You don't want that to have extra crap that they don't need.

But when there's only one of them for your machine and you're building it and you're managing it, you know, make it as comfy and helpful as possible.

That was my philosophy.

The, the structure of your site is, it has a lot of different pieces to it using different technology.

You spend some time talking about like static sites and using static sites for part of it versus, you know, Python applications and those kinds of parts.

How did you end up here?

Like oftentimes the answer when you're looking at this kind of stuff is, well, I need a CMS for everything.

And then I will try to figure out how to square peg my round hole of a CMS or whatever.

So how did you end up with a collection?

Well, you know, like many things that start simple,

And you're like, well, just one more thing.

So I tried, I'd kept pretty much the same web framework across all my different sites thinking, okay, that's, I'm going to just pick one and go with it.

I think a lot of people do that.

You know, there's people who are like, I use Django.

There's people, I use Flask and so on.

And then just slowly over time, you're like, really, this is, this part is really a hassle.

I'd be a lot better off if I made that part served through the CDN or why am I, you know, One of the things that I see a lot, and it doesn't drive me crazy, but I'm just like, yeah, it's probably not necessary, is a lot of people in technology X.

For us, that's Python.

It could be JavaScript.

It could be.NET, whatever, right?

People who work extensively in that and have a lot of their identity tied into that, like I do and others.

Like, I'm a Python developer, right?

So if I'm going to choose a tool, like, let's say, a CMS or a static site generator or something like that, I'm going to choose the Python one.

I'm a Python person like okay but are there better options out there than the Python ones for what you're trying to do because are you going to extend this tool no then what do you care of

what it's written in right your operating system is not written in Python it's written in yeah yeah yeah C or I'm not going to use this word processor because it's not written in Python

exactly so I have to go back in no I need a new service like it doesn't you don't see it you don't have to work with it you don't care and so I ended up a little bit with the mish match of just trying to say like what are the best tools like for example for the blog and some of the other static elements i've used hugo which is written in go it's like okay i type the command the command hugo you know and it it does its thing i don't really care what it's written in the templating extension is a little bit annoying but um i kind of just went around and said okay well what what do i think would be the best fit to make to make my life easy not to reinforce my identity as this type of

of developer or that type of developer you know yeah it's um the one of things you know i'll show my own stripes here and and you can defend your beloved flask if you like but having come from the django side uh some of the things that you've kind of learned organically here are forced on you in django um so when you so so when you when you like the instructions for putting together a production site are, and you will run this command and it will move all of your static content over here.

So like your mental model, when you come from that side is, oh, my site is actually built of these, at least these two different things.

And I think coming from Flask, you might've sort of that, that discovery might've been a little more organic.

You might not have been forced into it immediately, but once you've come to that realization of, oh, wait, I have these pieces and I can use something like Nginx to tie it all together, that means, well, then I don't have to figure out how to use a CMS for this thing that's very unnatural for a CMS.

I can just mount it under slash blog and it'll work fine, yeah.

Yeah, Django is very powerful.

It definitely is.

And I actually talked a lot about that in the book,

which evaluating web frameworks.

But I would say before we, if we're going to that, but before we do, I think your point about using Nginx to piece them together, things together or caddy or traffic or whatever it doesn't matter like some front end web server

they all do it yep yeah is so often people think i have this python app let's say i have a django

app so i want to add a cms to it what could i possibly add is it static content well maybe what you should add is hugo i don't know i'm just making this up right like it might actually be a bad option but well hugo is not a python thing so how do i put it into my django app i mean they're very very different in the way they work so they don't really go that super well together if you were to like how does one literally source code wise go into another but if you just made like a hugo site or other static site however you make it and then put it on the same server and then in nginx when you say if you go to this domain slash docs it goes completely over here and if it goes anywhere else it goes just to django and all of a sudden from the outside it looks like a very cohesive single thing with just different sub urls but you get to choose the best technology for the static bits and you get to choose the best technology for your dynamic data-driven bits and that is all just done by configuring the front-end web server that you don't even have visibility to in python and i think that that's a big mental shift but it's like those kinds of things that bring a both the flexibility to make these choices and the simplicity to not try to jam them together

there's a uh there's a a third-party library for django that i use once in a while which is called distill and it's a static site generator based on django so say you had your url was like books you know it's books slash one book slash two book slash three well you tell distill i want book and i want all the possible queries of this number and it will generate the results as static so even when you've got a dynamic site you can actually carve off the static portion and then have that fed straight out of nginx and if it isn't if there's no actual dynamic content on the page and if it only updates when the database updates or something like that and you can do it nightly like this gives you all sorts of other options and you know to come back to your my eight processor whatever's well the static sites are almost free you do not even need that you don't even need it it's nothing so like you can scale way down and have an absolutely mammoth site just by properly

fine-tuning what's dynamic and what's static yeah you could go to millions and millions of requests if you just converted all that stuff to static and then put the x the extra resources css image javascript etc on a cdn yeah like i mean that is like almost web that's like web on easy mode right there because you it can't go down unless the server literally almost almost can't yeah i mean Let's not say we're in the eve of like, are we in the eve of a fifth going down?

But I mean, like it can't go down because the code is wrong or there's a race condition or you're out of memory.

Like it's really close to just if, if the, if the web server is up and you put a CDN in front of it and then it's not even necessarily that it's like the CDN has to go.

You've got to have a cloud flare level incident.

Yeah.

And, and fully distributed in often cases.

Right.

So people in, you know, in continents, other than where you are based are getting fantastic load times because it's cached locally for them.

Yeah, I just want to give a little shout out.

I'm going to give a little shout out to Bunny.net.

Like, I know people are all about Cloudflare, but this is a cool European company that focuses on privacy, has some really nice features.

The pricing is great.

And they have, you go here, go to the CDN.

They've got somewhere way down here, you know, like 119 different places, including all over Africa.

And this is just super, super cheap for traffic.

Nice.

Yeah.

So I wasn't, earlier there, I wasn't intending to force a fistfight.

And, you know, we're on the opposite side of the continent, so that would be a challenge when I, Jango versus Flash, go.

But, you know, I think one of my favorite chapters was actually chapter 13, which was titled Picking a Python Web Framework.

I really liked the nuance of this.

It's unusual for folks to sort of reveal their reasoning.

And honestly, I think, like, because I had no intention of tomorrow going and using Docker, the Docker chapters were interesting because I like to see how other people do things.

But like I could grab the picking a Python web framework, pull that chapter out and hand it to almost any of my students.

Right.

Like it's this, you know, how do I make these kinds of decisions?

How is this different?

Why do I think about these things?

And so often the content on this is really just religious war.

And you've done like a really, really good job there of just sort of conveying this, you know, hey, here are pros and cons for each.

And this is why I picked this.

And so I really, really liked how you, how you covered that.

Thank you so much.

What you, I guess it's maybe the answer is obvious, but, but why?

Like you were fine.

You were just doing configuration file after configuration file and then a little bit editorial.

What, what caused you, what, what was the emphasis for the impetus for spicing it up a little?

Well, I mean, I think it's an important part of the journey is, is picking a technology to run your code on.

So there's actually a couple of places that I kind of have that like I have that for I'm trying to create a term because I don't think we do a good job of disambiguating it from from like engine X of Python, like production app servers, like where your code runs, I think these a little more disambiguation, I'm talking like granian, unicorn, those kinds of things.

Vercorn, Uveacorn now, all those places you run your Python code.

So I kind of went through a debate on those from Michael's context, right?

And then I did the same for Python web frameworks.

And it was, you know, I told the story of the bootstrap and how I just, every time I have to write new code, I'm like, here we go.

I'm in the relic, right in the relic code.

I kind of felt the same way for, so everything was based on Pyramid and I loved Pyramid and I still have a lot of respect for it.

The reason I chose Pyramid in 2015 was when I went to the Flask page, it said, you may potentially be able to use Python 3, but we are not supporting it and we don't recommend it.

And I'm like, wait a minute, didn't Python 3 come out in 2008?

That's like seven years later.

You know what?

No, I'm not doing that.

I'm starting this project beyond this problem and I'm not going back to be in the, you know what I mean?

As they've since obviously moved on from that.

So Flask was out.

I looked at Django and I thought, I'm really like a microservice guy.

I really want to use Mongo.

A lot of things were not quite good fits.

They actually would be better fits now, right?

Even then.

Yeah, no, if you want to do Mongo, that's, yeah, that's almost a deal breaker.

Yeah.

Yeah, I know.

Almost.

And so I'm like, all right, well, maybe not Django.

Well, you had a pyramid.

They're like, we are trying to embrace the latest standards.

We're Python 3 first, et cetera, et cetera.

And I'm like, all right, I'm gonna give this a chance, even though it wasn't as popular, like this is great.

And I used it for eight years, seven years, something like that, it was really good.

But things evolved over time, right?

Like Pydantic came out and Pydantic was great.

What's a really nice way to talk to the database with Pydantic, Beanie, okay?

So I can do Beanie and I can do Pydantic and wow, what a really nice, clever way to write databases.

And oh, Beanie's all async only, Pyramid's synchronous only.

When was the last commit to Pyramid?

Oh, it was two and a half years ago.

Chances that it gets async support are low 'cause that was just like a minor bug fix.

You know what I mean?

It's just like, it's fine.

Open source projects, they ebb and they flow and they come and they go.

But I'm just like, I should really move this forward to something that feels like it's active, right?

I mean, stuff in the web makes me nervous.

I'm always just, did you put a port open on the internet?

Well, that's scary.

- Yep.

And so a framework that felt like things were not on top of it as it could have been made me nervous.

To be fair, I don't know that they had any security incidents or very, very few because it did so little, right?

It's not like it had a bunch of admin pages or something where there's like accepting input, but still, still same reason.

So I'm like, I really want to use these more modern tools, typing, async, identic, et cetera.

And I kind of would not like to continue building on something that feels like it's no longer being supported.

And similarly, you, with chapter 13, sort of that, you know, the different thought process there.

You also provide chapter 15, which is a retrospective on Hetzner, which is the hosting provider that you chose.

and again, I think it's pretty clear.

I think I've said it three different ways.

My favorite stuff in the book really is sort of this, you know, that the little, the little, insight into Michael's brain, right?

Like how did he make this decision and how happy is he with these decisions?

Right.

I think that's the stuff that's, that's, globally applicable to a reader, which is nice.

so you've, it's now even a few months further on with Hetzner.

So you, you still happy?

Any regrets yet?

Yeah, no, no regrets.

It hasn't been absolutely a hundred percent smooth.

Let's see.

I could tell you how long it's been if I can get past all the ads.

There we go.

So I actually blogged about this.

And yeah, so it's been about a year, I guess.

No regrets.

I would say if people are out there looking around, to me, it really, and you want to follow the philosophy of Michael, like carve yourself a space out in a multimillion dollar data center that doesn't have anything to do with it.

And you just run your code in your own space.

DigitalOcean and Hetzner are the two ones.

And I did DigitalOcean for a long time.

When Hetzner came out, I thought they just had some really interesting appeal.

I started seeing a lot of people talking about them.

And they are a German company.

And they were just in Europe.

And I'm like, I love Europe, but the majority of my customers are in the U.S.

So what is the best place for my server?

Probably the east coast of the United States, because that serves the U.S.

really well.

But then it's like one hop across the ocean to all of Europe as well.

So it's still really fast from there and so on.

So I didn't want to move my server to Europe when I felt like being closer to the US was more important.

Not so much because I needed to manage it.

I could SSH to wherever, but just East Coast to the US.

And then they're like, hey, we have two new US data centers.

One near Virginia, right by the US East 1, the infamous AWS US East 1.

And the other one actually in Hillsborough, Oregon, just down the street from me, which is funny.

Yeah, it's like I could drive to it in like 20 minutes, which of all places in the world is relatively close.

So I went and looked at it and I said, let me just check it out.

And the prices are super cheap.

You get a little bit less support and I think a little bit less top tier data center than DigitalOcean, but the prices are like insane there.

Like I said, eight core server for 30 bucks.

You know, that's insane.

And when I first signed up, that came with 20 terabytes of free traffic.

Wow.

Which is about $1,700 out of AWS.

Right.

Included in your $30 bill.

You know what I mean?

Like, oh my gosh.

Yeah.

So yeah, I talk a lot about it in the book, but yeah, I went over and moved my stuff over there and it's been good.

I've had one incident where the machine that it was on died.

The one big server, wherever it was, it died and they had to move it, which blows my mind, they were able to hot relocate it to another server.

But the problem is it has an external, like a 300 gig external drive, and that didn't move location.

So all of a sudden, a lot of the IO operations were much slower 'cause they weren't close to the server anymore.

- Right, right.

- Why, why did my Docker builds take two minutes?

They used to take about three or four seconds.

I cannot figure it out.

And I wrote them, they're like, no, we've tested it.

There's no problem.

I don't care what you say, there's a huge problem.

eventually there's like we moved it again it's fine and then it was fine right so you know if

if folks are looking for something slightly lighter weight and this is going to sound like a commercial i'm just a happy customer i don't know sponsorship or whatever but i use opal stack with a lot of my clients um what do you go opal stack opal um yeah and you wouldn't go full docker with it um but but they do give you access full SSH to the box.

And they've got a neat little sort of packaging thing.

They don't support a lot of things, but if you've got like Django or Flask or static files for Nginx or whatever, you hit a couple of buttons in the dashboard and it spawns it up.

But a lot of tools like that, it spawns it up and then you're not allowed to touch it.

What they do is create all the entries in the directories and then you can SSH into the box and get at the files themselves.

So I find it's a nice little compromise between the two.

It would not scale to what you're doing.

But if folks are looking for a relatively inexpensive thing to experiment with, I find it's a nice little stopgap.

Yeah, that's awesome.

I'm always interested in finding those types of things.

This one is new to me.

This is cool.

Yeah, this is I'm trying to remember there was a site I used to use.

It got bought.

The half of the founders went, we don't want to be bought and took their baseball bat and created Opal Stack.

So I used to be a client of the original and followed them along.

So yeah.

Cool.

And very happy with like the service as well.

They're like you open a ticket and things are very, very human, which is nice in this day and age.

You usually, I'm usually expecting to talk to a bot.

You're getting about as much support as you get out of Gmail.

Yeah, exactly.

Google Docs, which is done.

Another thing worth a shout out here is sort of an alternate way of working with Docker and Docker Compose directly that I propose in the book is something called Coolify.

Are you familiar with Coolify?

No, this one I don't know.

Yeah, this is super interesting.

So what this does is it knows how to run Docker, Docker Compose, but it also gives you all sorts of easier ways.

So if people look at what I'm proposing, they're like, no, Michael, too complicated.

This is interesting because what it gives you is it basically gives you your own private Heroku or Netlify or Vercel or Railway, or you can go in, I don't know how to find it, from here, but you can also go in and say, let me find any self-hosted app.

- Okay.

- And they've got hundreds of them in there.

And then you just type in the name and say, install this set of Docker containers as a Docker compose file into my server.

So you could create the one big server, which is your own space in someone's cloud.

And then you can install this or you can pay them five bucks a month and they'll actually manage the server, manage the deployments, do like rollouts of new versions of your app.

stuff like that right it sounds like it sounds like it makes it way easier right it actually makes it it's like two steps forward 1.8 steps backwards right because you know instead of using dot env files you've got these like a ui to enter a bunch of environment variables and the saving of them is weird and you're like oh i forgot to press save on these three even though i saved the page i mean there's just right right it's it promises more ease than you would think and i'm not necessarily switch i do like i've played with it some i'm not saying i would switch to it given a choice but it does it does ease you in it's a little bit like python anywhere like i'm sure when i started there were things that could have gotten in my way but the stuff the support that it gave me made it possible for me to feel like comfortable and get going i feel like this might be an option for people who care.

Right.

But let me give you an example.

For example, I could go install an app that has Postgres, Valkey, and the web app.

If I, then I just click install that from wherever self-hosted definition that comes from, it creates those three containers.

And then on the container setting through the image setting, I don't know really how you think of it.

I mean, they're not, I guess it's image sort of, you can go to the web part and say, and just use this URL and it'll automatically do the SSL generation as part of that.

Then you go to the database, the Postgres thing, you say, oh, and make backups for me daily and store them in this S3 compatible storage.

And that kind of stuff is a lot of extra when you're doing it yourself and you just go check those boxes.

So that's the one point forward, that's the two forward, but then there's the step back.

Yeah.

Yeah.

Well, and that tends to be also what makes people nervous, right?

So like that, and that's, you know, I still use managed database simply because I don't want to have to think about it, right?

Like it's like, yeah, okay.

I'm perfectly fine with pointing my app at a managed database and let somebody else think about backing it up and all the rest of it.

Yeah.

Yeah.

You know, one thing about managed databases that I don't like, and I can't speak to all potential hosts of them, but certainly some of them, some well-known ones, some names I've already said, if you get a managed database there, that database server is listening on the public internet.

I very much do not espouse having a database listening.

Yeah, it has a password, but I mean, that's that database.

I'm always worried about what is in the database.

That's interesting.

I've never thought to even check that.

And on my setup, not only is it not listening on the internet, it's not even listening on the host there's like a private docker network that only things right in the docker shared docker network can even know about or see the data you know what i mean so there's yep it's it's less likely to fewer holes but i have to make backups and if i don't it's bad if it goes down it's real bad so and it did one time this year i was down for like 10 minutes about a hair out there goes

- That was your sixth nine, yes.

- Exactly, I know.

So the problem was just for people who wanna benefit from my suffering and not suffer themselves, is I did not, on the Docker pull for the database image, I didn't pin it to a major version.

And so it upgraded and then it said, well, you have old data in your file system and we're not gonna upgrade it for you automatically.

So we're not gonna run.

I'm like, why is the database server not running?

It just, and it was like a weird update.

It was like 8.2.1 that broke.

Well, why?

Point one.

Surely, surely a bigger number needs to be like, this will never run again.

Anyway, you know, you find the stuff out the hard way, but yes.

Well, yeah, that that's the negative, not using a managed database.

Yes.

Yeah.

Yeah.

Cause you have to deal with some of that kind of stuff yourself.

Yeah.

So I thought we would wrap up by reviving an old tradition.

I have two questions for you.

What is, what, what, what is your development environment?

and what library are you excited about?

So the development environment right now is a mix of Cursor and PyCharm for sort of editing.

And despite this very detailed conversation about Docker, I don't use Docker very much locally for development.

I just use virtual environments.

And I want to give a shout out to Hynek, who I had some back and forth about when I was writing some of this stuff that gave me some really good ideas.

And he has a really good article, which I referenced in the book, about you just use virtual environments.

Keep everything consistent, right?

That's an interesting debate that we don't have time for, but it's very fun.

So uv, I'm a huge fan of uv.

- Particularly in Docker, that makes things that much faster.

- Yeah, because you can just say in your Docker, it used to be you're like, okay, well, I gotta use Docker and I need to use Python.

So let me use the official Python distribution for Docker because I need to have Python.

And then, well, that excludes 99.9% have all the other things you could build upon that already have something that's harder to manage set up for you, right?

But in your Docker file, you just say, run uvvenv-python3.14, you've installed Python 3.14 in two seconds.

And it's cached, right?

It's like, yeah, it just, it makes it so much faster and so powerful, but also just in general, right?

Like it's unified so many tools that I like that are just, it's all there together.

And then library, oh my goodness.

- Now you know how it feels

like i know how it feels and now i didn't warn you on purpose i love it i love it so there's there are a bunch of ones i've been playing with lately and i'm trying to think which one i've i've used i don't really have a great answer to this chris i'm i'm afraid to say i would say let's keep it let's keep it flowing with some of the vibes that we had here i would say let me give a shout out to set proc title which there you go sounds insanely silly like the goal of that is so in your process and your Python process and I actually use this on a bunch of different things in your Python process you can say set proc title dot set title and you give it the name of whatever you want your process to be so why does that matter when you pull up all these tools like glances be top or others anything that looks at processes basically instead of seeing Python Python Python node node node postgres postgres postgres at least the Python ones now have meaningful names and you might be thinking well Michael that much production, useless to me.

No, it's good for development too.

Have you ever had the idea, like I wanna know how much memory my process is using.

Is it using a lot or a little?

So you pull up, you know, activity monitor, task manager, whatever, you see Python, Python, Python, you're like, oh man, I know my editor's using one of these or whatever, but which one is it?

- And if you're using the right terminal, it'll change the terminal's title too, because most terminals respond to the proc name.

Oh, that's a very nice touch.

Yeah.

Okay.

Yeah.

So, but if you, if you do that in development, if you just set the name of your process to be like, you know, my utility or whatever the heck you call it, right.

Then when you go into process management tools, like even just for Mac or windows or whatever, you'll see it and you can see how much CPU is it using?

Is it using a lot of RAM?

If you've got to end task it, like we now have another way reason that this is something we've got to do all the time is the, sometimes the agentic AI things go mad and they start a bunch servers and then they lose track of them and then you can't run anymore because it says um port is in use you're like but where like something in that stream of text that shot by for five minutes it started one and then it left it going but then you pull it up it says python python python and like well i don't want to kill the other thing that's running you know what i mean and so it also gives you a way to kill off your ai abandoned stuff that it went mad on so there you go setting

a process name might save you a reboot.

There's your little nugget to take away from the podcast.

Exactly.

It's a package with one function, but it's a good one.

Excellent.

Well, thank you for having me on.

This has been fun to sort of reverse the tables on you.

It's been great.

Yeah.

Chris, thank you so much.

I really appreciate it.

And always great to catch up with you.

Bye.

It's been fun to be here.

This has been another episode of Talk Python To Me.

Thank you to our sponsors.

Be sure to check out what they're offering.

It really helps support the show.

Look into the future and see bugs before they make it to production.

Sentry's Seer AI code review uses historical error and performance information at Sentry to find and flag bugs in your PRs before you even start to review them.

Stop bugs before they enter your code base.

Get started at talkpython.fm/seer-code-review.

Agency.

Discover agentic AI with agency.

Their layer lets agents find, connect, and work together.

any stack, anywhere.

Start building the internet of agents at talkpython.fm/agency spelled A-G-N-T-C-Y.

If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTMX, and even LLMs.

Best of all, there's no subscription in sight.

Browse the catalog at talkpython.fm.

And if you're not already subscribed to the show on your favorite podcast player, What are you waiting for?

Just search for Python in your podcast player.

We should be right at the top.

If you enjoyed that geeky rap song, you can download the full track.

The link is actually in your podcast player show notes.

This is your host, Michael Kennedy.

Thank you so much for listening.

I really appreciate it.

I'll see you next time.

Thank you.