Scaf: Complete blueprint for new Python Kubernetes projects

00:00 Today we explore the wild world of Python deployment with my friend Calvin Hendricks Parker from 6 Feet Up.

00:05 We'll tackle some of the biggest challenges in taking a Python app from "it works on my machine" to production, covering inconsistent environments, conflicting dependencies, and sneaky security pitfalls.

00:17 Along the way, Calvin shares how containerization with Docker and Kubernetes can both simplify and complicate deployments, especially for smaller teams.

00:26 Finally, we'll introduce Scaf, a powerful project blueprint designed to give developers a rock-solid start on Python web projects of all sizes.

00:35 This is Talk Python to Me, episode 496, recorded Tuesday, January 21st, 2025.

00:43 Are you ready for your host, please?

00:45 You're listening to Michael Kennedy on Talk Python to Me.

00:49 Live from Portland, Oregon, and this segment was made with Python.

00:55 Welcome to Talk Python to Me, a weekly podcast on Python.

00:58 This is your host, Michael Kennedy.

01:01 Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both accounts over at fosstodon.org, and keep up with the show and listen to over nine years of episodes at talkpython.fm.

01:14 If you wanna be part of our live episodes, you can find the live streams over on YouTube.

01:18 Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.

01:25 This episode is sponsored by Posit Connect from the makers of Shiny.

01:29 Publish, share, and deploy all of your data projects that you're creating using Python.

01:34 Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.

01:41 Posit Connect supports all of them.

01:43 Try Posit Connect for free by going to talkpython.fm/posit, P-O-S-I-T.

01:49 And it's brought to you by my new book, Talk Python in Production.

01:53 I've long felt that most guidance and marketing about how we need to run Python apps in production has been overly complex and expensive.

02:01 This book is both a look at the history of Talk Python To Me and an antidote to this overly complex cloud world.

02:07 Read it online and get the full book at talkpython.fm/devopsbook.

02:14 This episode has something unique and special.

02:17 I thought it'd be fun if I could come up with a song that was about deploying code, about Kubernetes, about the cloud, all the different things that Calvin's gonna come on and tell us all about.

02:30 I turned that into a song and I stuck it at the end of the show.

02:33 I wanted to put it at the beginning, but it's three minutes or so long and I think it might take away from getting right into the episode.

02:40 So if you're interested in that, you can check out the song, it's called "Deploy the Dream".

02:45 It's at the very end, almost the end, that lasts maybe another 45 seconds after that.

02:51 And you'll find the link to the standalone song and MP3 file right on the episode page in the link section or in your podcast player show notes.

02:58 I hope you love it.

02:59 It was a lot of fun to create and I think it'll make a lot of you smile out there.

03:03 Quick announcement before we jump into the show.

03:05 I recently completely re-imagined and rewrote the effective PyCharm course.

03:13 So if you wanna be effective with an IDE and use professional tools to build your Python applications, you should give my new and updated course, Effective PyCharm, a look.

03:27 You'll find it at talkpython.fm.

03:28 Just click on courses in the menu at the top.

03:31 And if you were already in the prior version of the course, it's been automatically updated for you.

03:36 So you'll have access to the new course right away.

03:39 Head on over and check it out.

03:41 And if you have one of our everything bundles that gives you access to all of our courses in the library.

03:47 Well, you also have access to this course, assuming the original was in your bundle.

03:52 Thanks to everyone who's taking courses over there and checking it out.

03:54 This is a really fun course.

03:56 I think you'll get a ton out of it if you haven't taken it yet.

03:58 And with that, let's jump into the show.

04:01 Alvin, welcome to Talk Python to Me.

04:03 Great to finally have you on the show.

04:05 What have you been doing all this time?

04:07 - I don't know, not being on your show, I guess.

04:09 I actually was super excited when you asked that I could be on here, This has been like a life goal, at least a goal since ClockPython to me has ever existed.

04:17 >> I really appreciate that. That's very kind.

04:19 Well, it's great to have you on here and I am all about DevOps and deployment these days.

04:23 I think it's another superpower that I think people can really have.

04:28 You've got an idea, you want to deploy the dream as the song that we'll play later, we'll say.

04:34 If you're not familiar with this stuff, it's a huge roadblock.

04:37 I built this thing, but how do I get it up there and how can I keep it running?

04:41 - Yeah.

04:42 - And so what we're gonna talk about is a framework you all have created to make this much more automated and easy and packaged up, if you will.

04:49 - Yeah, I agree.

04:49 I mean, part of the developer experience, not just the deployment story, but how do I make a developer be productive from day one?

04:58 Like I get super obsessed about the experience.

05:01 Like, is it smooth?

05:02 Is it easy?

05:03 Can developers like join your organization and be productive right away?

05:07 Like that's important to me as a owner of a business who produces software.

05:11 We'll start there.

05:13 Who are you?

05:13 What is your business?

05:14 What do you do?

05:15 Set the stage for everyone.

05:16 - All right.

05:17 So my name's Calvin Hendricks Parker.

05:18 I am CTO and co-founder of Six Feet Up.

05:21 We are a Python and AI for good software agency based out of the Midwest here in Indiana, but we have folks all across the country and a few folks across the globe.

05:30 We help impactful tech leaders level up their game.

05:34 Like if you've got an idea and you can see the future, our part of our goal is to make that happen.

05:39 Like we love tackling the super hard software problems.

05:44 The harder the better and the more unique and the more impactful the better.

05:48 Part of our goal has been to do 100 impactful projects by 2033 and those impactful projects are things that are making the world a better place.

05:55 So some of our projects do actually impact climate or energy, done some stuff with NASA on space travel.

06:04 So it's cool stuff like that that the people who work at Six Feet Up get super excited about.

06:09 And like part of what drives me to do what we do every day for sure.

06:12 Yeah.

06:13 And to get to work on space travels.

06:14 Oh man.

06:16 It's like, I'm getting up early today.

06:17 I'm going to work on space travels.

06:18 It's literally rocket science.

06:19 Literally rocket science.

06:20 Yeah.

06:21 How amazing.

06:21 And you've been doing Python for a long time.

06:23 You've been involved since the early days, right?

06:26 Yeah.

06:26 I first adopted or touched Python in literally the year 2000.

06:30 I started working on it.

06:31 I was in a startup in the Bay Area and the guy sitting next to me was like, check out this Python based application server called Zope.

06:39 And at that point in time in my life, I had just graduated college.

06:42 I think I understood the three words in between all the other words that he just said.

06:46 And so that was a whole new world that got opened up to me.

06:49 And so I started out my journey in Python really with Zope as the kind of the first thing that got me in.

06:55 But back in that day, like Zope and BitTorrent were kind of the killer apps for Python.

07:01 Folks remember there were like Zope tracks at PyCon And my keynotes were like around Zope.

07:06 It was the thing.

07:07 And I still attribute that community to really bringing me into Python and getting me engaged.

07:13 It's some of the smartest people I've ever worked with who are part of that open source community who made that a thing.

07:19 And I'm still friends with those people today.

07:20 You know, people like Paul Everett and Trey Seaver.

07:22 And those folks were really part of my upbringing into the Python community.

07:26 And I can't thank them enough.

07:28 That's awesome.

07:29 You know, there's a really interesting fact that was shown at least amongst survey respondents in the PSF JetBrains survey, I can't pull out of it, that, that I would say 40% of the people who are doing Python these days are two years or less into it, which is an incredible statistic.

07:48 I think 30%, 30% or so is this is their first year.

07:51 And then, you know, the rest of the second year.

07:54 So we're amongst the, the rare birds, but the reason I bring that up 25 years later, we're still here doing it.

07:59 Exactly.

08:00 the reason I bring that up is, you know, I suspect people who've been at this for three or four years, maybe don't know what ZOPE is.

08:05 They probably heard the word, but they're like, yeah, is that, is that like a thing that Django does?

08:11 Tell people what ZOPE is like.

08:13 I mean, the, the, the application framework space back in the, in the 2000s was not a crowded space.

08:19 There weren't many options.

08:20 And I think the beauty of what the app, the ZOPE was an application framework.

08:24 It had some interesting opinions.

08:26 One of them being the ZODB, which I still do love to this day, which is an object graph database that enabled you to build applications quickly.

08:36 And I think initially one of their goals was through the web even.

08:40 Like if you remember Z-classes, you could build and rapid prototype through the web in your browser.

08:47 I mean, this is the year 2000.

08:48 This is not last year where people were like, "Wow, cool.

08:51 This is a low-code thing." This was that 25 years ago.

08:54 >> This was ahead of its time.

08:55 - He's way ahead of his time.

08:57 Now, granted, I don't think that was not the future.

08:59 That shouldn't be the future.

09:01 I'm actually hoping to give some conference talks this year about low code, no code, in my opinions on that.

09:06 Especially, I should frame it in my context of Zope and Z-Classes.

09:10 But maybe that's too much of an inside joke.

09:12 I don't know if enough people would even understand what I'm talking about there.

09:16 Because like you said, so many people are new to the community, which I think is awesome.

09:20 I think that shows it's a vibrant, growing community.

09:23 If you're in a community and you're wondering where the new next generation is gonna come from, there's a problem.

09:29 And I don't think Python has that problem.

09:31 Python has an incredible traction with new people.

09:34 And I've always loved it because of the simplicity.

09:37 I love it because the language is predictable in its patterns.

09:41 It's not a cognitive overhead to remember all the various ways to call things in Python 'cause typically they're pretty consistent.

09:48 - Yeah, but Python's slow, we can't use it for stuff.

09:51 (laughing)

09:52 I do not believe that for a second.

09:54 - No.

09:54 If you're doing maybe mathematical simulations or certain types of really, really intense low level things maybe, but as a general application framework, it applies, it's fine.

10:04 Yeah.

10:04 And that's the problem too is that if you go off right now and you ask your ChatGPT or your cloud about like, you know, maybe what are some disadvantages of Python, it's going to mention these kind of broad old opinions about it because it only knows the average of all the knowledge has ever been on the internet.

10:19 And it's learned a bunch of like trash talk as well.

10:23 and which is mostly inaccurate.

10:25 But if you ask it to dig deeper, and someday we'll be able to ask it I think a little more critically, you'll probably dig in and get the truth.

10:31 - Yeah, a bit of a side note.

10:32 I recently, for a couple things I needed, got the Chat GPT Pro.

10:37 Not the paid version, but the insane pro version.

10:39 - Oh, the $200?

10:41 - Yeah, $200 a month, and I laughed at myself.

10:43 Like, this is the stupidest thing I've ever done, but I need it, so I'm gonna do it for a little few days, turn it off.

10:47 It's incredible, I'm not turning it off.

10:49 It's like my side buddy, I can ask anything.

10:53 And it's so good.

10:56 The future is here, it's just not evenly distributed.

10:59 - It's not evenly distributed because it's hard for most folks to have the right mindset, I think, to approach to get that level of value out of it.

11:08 I think you have to know how to talk to it.

11:10 And I've said this before, it's the same problem with people who aren't good at using Google, just plain old search.

11:17 Like, you know, the people who have to say, let me Google that for you, are the ones who understand how to like, use the search engine, you know, well.

11:24 Some people-- - You know, that can be answered in an exact phrase if you

11:27 just say the phrase, just say the phrase, you know what I mean, you know?

11:31 And it's also a mindset, right?

11:32 Like, I started thinking like, instead of this is a cost or something, like, this is like another employee that I can just give jobs and five minutes later, I'll come back and it's done pretty thorough research.

11:43 You know, it's--

11:44 - Yeah, especially with the new scheduling feature, where you can actually schedule tasks to happen.

11:48 I'm getting kind of excited about, everyone's talking about agents, and I know this isn't the AI show we're here to talk about, but I think agents are interesting, but we're not there yet.

11:57 They're about the level of maybe interns and what you would trust them to do for you.

12:01 - Yeah, I totally agree.

12:02 I'm a little worried about what all this stuff is gonna do to the industry

12:06 in a broad sense.

12:07 My main concern is I think it'll sort of carve out that gap between early dev and senior dev, and it's gonna be harder for folks to cross that.

12:15 but it's also an incredible technology and I think it's also silly to pretend it doesn't exist.

12:20 So anyway, you're right, it's not the AI show, but boy is it, is it top of mind for a lot of us, right?

12:25 - Yeah, for sure.

12:26 - Yeah, okay, so let's talk Python deployment.

12:30 Talk some pitfalls, maybe a little bit of Docker.

12:33 How's this?

12:34 - It's a shame.

12:35 - Why did you all attack this problem?

12:37 And I guess setting the stages, where does this fit in your consulting story, right?

12:41 You must need to deliver these applications often in a way that people can continue to let keep them going on their own without you constantly going back. Yeah, there's a there's some pip updates. So we'll take care of that for you.

12:51 Well, and that definitely reaches into the longer tale of the whole story. I think if you go back to the beginning of the story of deployment, a lot of us started out or a lot of us older ones, more seasoned veteran developer folks in a world where if you wanted to deploy your web application, you threw some PHP into a web root. And as long as you had modphp installed, the stuff ran.

13:13 Like you didn't have to think about configuring ingress and egress routes.

13:17 And it was, you know, databases just ran on the same server you were on.

13:21 So you just ran it on local host.

13:22 Like it's the world has changed when it comes to the deployment story.

13:26 But it's because things have gotten more complex and sophisticated because they had to.

13:31 Like we had needs for more sophisticated authentication mechanism.

13:35 We have needs for caching and delivery.

13:37 We have needs for time series data.

13:39 Like, because those opportunities opened up, more sophisticated software gets built, which means it's a little trickier to deploy.

13:47 - Well, looking back, and with your perspective of all this experience as well, and it's something I've seen, every time the technology gets easier to work with, you know, like that used to be 100 lines of code, now it's three.

13:58 You know, we're gonna be out of jobs soon, a lot of people would say, it's like, no, we're just gonna solve bigger, more ambitious problems.

14:04 And that's been the case for so long, and it's not that, well, things got easier, so we're not gonna do it.

14:09 No, every time it got easier, we were able to just think of bigger, more, instead of, we don't need a team, one person can solve this amazing problem.

14:17 But that means, underneath that, there's this mountain, this iceberg of stuff going on, right?

14:22 - Well, and that's where deployment has gotten, I think, hard in a lot of people's minds, is because there is a mountain of knowledge, like there's a giant shoulders that you're standing on that makes that happen.

14:35 And my VP of engineering was complaining to me yesterday, Like, why can't we just, how can we not easily put websites on the internet anymore?

14:42 And it's not that we can't put websites on the internet anymore.

14:45 They just do so much for us.

14:47 Like the complexity and the sophistication and the covers is what's causing a lot of this issue.

14:52 And the person who wrote software is not always the person who deploys software because I think they've just got kind of different mindsets or different ways of thinking about the problems.

15:01 And it's rare you find people who are truly a full stack and do front end to the back into the database, the network, all the layers that are in between.

15:09 And it's nice that services like, you know, the cloud have come about where it greatly simplifies that deployment.

15:16 And that was part of our journey into containers.

15:18 I was resistant to containers probably until 2020 when we did, in 2020 there was a change, obviously, some things happened in the world, but we also

15:30 built...

15:30 - You had more time to be at home and figure out stuff.

15:32 - Right.

15:33 But we also had time to build some software to help us in our little conference we were doing. We put on the Python web conference during the pandemic.

15:40 We actually started the pre-pandemic, but during the pandemic, we took time to write some software to deploy a virtual event platform. And I think containers, at that point in time, I adopted containers and container orchestration because it allowed the developers to think more about developing and less about the deploying part of a sophisticated application like streaming web video, audio mixing, switching, live chats and web sockets. I mean, there's a whole lot of moving parts in something when you're delivering a live video conference experience. And the containers were a nice, like, equalizing layer to allow us to say, I don't care where it goes to, whether it's in Docker Compose or Kubernetes or Docker Swarm, or in our case, we used Amazon's Fargate, because I just didn't want to deal with infrastructure. I just told Fargate, I got some tasks here, some containers, make

16:31 them live, like turn them on.

16:34 Yeah.

16:34 And it sounds like that's for devs as well.

16:37 Yeah.

16:37 And we do-- Not just the infrastructure you're pointing to, but this is, it sounds like you're smoothing the path for the whole team, right?

16:44 Correct.

16:44 That's an opinion I hold that containers are for development as well.

16:48 Like that developer experience, some organizations I've seen, they may be deploying on the Kubernetes because there were operational opinions about deploying into containers, but the developers themselves haven't adopted that fully on their local workstation because it may feel hard until you've got that muscle built up for doing that level of development. That's originally, that's why Scaf came about, to make that development experience just a breeze.

17:14 We focused on how quickly can a developer be productive locally using containers and still have all your tools. It shouldn't feel different than if you were developing with your local Django files on your local file system and you were just running a Postgres instance, you know, out of homebrew, except it's better because now the versions will match what's running in production and you can have five different projects running with five different versions of things because you want to make sure they match your expectations when they go to launch and not be surprised when, you know, the version of Redis doesn't support some new operator because you were one minor version off in your local machine compared to the sandbox and production machines.

17:54 >>

17:54 Yeah.

17:54 I was not against containers, but I was resistant to use them myself because I felt

18:00 like, well, here's another thing to understand, another thing that's a layer between me and my code, and it could go wrong and I don't need it.

18:09 You know what? I'm a believer.

18:11 It is so nice to be able to just say, here's three commands you can run.

18:15 >> Exactly.

18:16 >> Always going to be exactly.

18:17 Another thing that I've done is on my new Macs and stuff, my dev machines, I don't put databases on there.

18:24 Nope.

18:24 Caching.

18:25 I don't even necessarily install Python directly on, you know, as in go to python.org or homebrew or something like that.

18:32 It's, if I want a tool and you know, instead of installing say MongoDB, I can just have a Docker command that runs MongoDB.

18:39 That listens on the same port.

18:40 Yep.

18:40 And it's, it's always up to date.

18:42 And if I don't like it, I get rid of it.

18:43 If I want to change the version of it, I just change the flag somewhere in a file.

18:47 And it's, it's incredible.

18:49 That and UV.

18:50 Yeah.

18:50 Think back to the old, old days.

18:52 and the old days for us, but probably the current state for a lot of people in certain organizations, is you had a large getting started document that you would have to follow top to bottom.

19:01 You know, make sure you get this version of that, make sure you get that version of this, make sure you put these files there, make sure your database is running with these couple extra options because we've enabled some, and maybe we've enabled GIS or some extension to the database.

19:13 If you didn't get all those magic incantations just right and follow the document to the letter, you were having, you know, a long time to get started.

19:21 like it was a struggle.

19:22 Whereas you just tell someone Git pull and then we'll tilt up, in our case for Scaf, we've adopted the tilt management tool, they're running and they can start making, contributing code within an hour.

19:35 That's my goal.

19:35 My goal has always been fresh laptop out of the box, on my desk and be able to contribute like a pull request in an hour.

19:43 - This portion of Talk Python to Me is brought to you by the folks at Posit.

19:46 Posit has made a huge investment in the Python community lately.

19:49 Known originally for RStudio, they've been building out a suite of tools and services for Team Python.

19:55 Over the past few years, we've all learned some pretty scary terms, hyper-squatting, supply chain attack, obfuscated code, and more.

20:04 These all orbit around the idea that when you install Python packages, you're effectively running arbitrary code off the internet on your dev machine, and usually even on your servers.

20:15 The thought alone makes me shudder, and this doesn't even touch the reproducibility issues surrounding external packages.

20:21 But there are tools to help.

20:23 Posit Package Manager can solve both problems for you.

20:27 Think of Posit Package Manager as your personal package concierge.

20:30 Use it to build your own package repositories within your firewall that keep your project safe.

20:35 You can upload your own internal packages to share or import packages directly from PyPI.

20:40 Your team members can install from these repos in normal ways using tools like pip, poetry, and ub.

20:47 Posit Package Manager can help you manage updates ensuring you're using the latest, most secure versions of your packages.

20:54 But it also takes point-in-time snapshots of your repos, which you can use to rerun your code reproducibly in the future.

21:01 Posit Package Manager reports on packages with known CVEs and other vulnerabilities so you can keep ahead of threats.

21:08 And if you need the highest level of security, you can even run Posit Package Manager in air-gapped environments.

21:14 If you work on our data science team where security matters, you owe it to you and your to check out Posit Package Manager.

21:21 Visit talkpython.fm/ppm today and get a three month free trial to see if it's a good fit.

21:27 That's talkpython.fm/ppm.

21:29 The link is in your podcast player show notes.

21:32 Thank you to Posit for supporting the show.

21:34 Do you, when you guys are doing development, do you actually do development in containers or do you just use them to support all of your stuff?

21:42 - No, everything's in containers.

21:44 That was, Scaf primarily, And some people will see Scaf as a deployment tool.

21:49 I see Scaf as a developer experience tool and a deployment tool.

21:52 I covered both ends of that spectrum because everything starts obviously with the developer and an idea and some building some software.

21:59 Well, if they can't build the software easily or they can't collaborate with another contributor on that software, it slows things down.

22:06 So part of what we, you know, that Scaf tool is, it's gonna be able to give you the scaffolding to build out of an initial project.

22:13 Like starting from scratch, you have nothing on the file system, Scaf will build out those initial tools, but then Scaf is a set of opinions, more importantly, because lots of scaffolding tools exist out there.

22:22 I mean, current Scaf is built on Cookie Cutter, but we can move that, we can move those opinions as we change our opinions about the development world.

22:31 So as we build a new project and let that get started, we now can develop locally on containers.

22:39 Like we use Kind for our Kubernetes cluster locally, which is nice.

22:44 and you'd think running Kubernetes might be overkill for a local development environment.

22:48 But the nice part about that is, is like now the Kubernetes manifests, you know, layer nicely.

22:54 You've got a local base layer, a local instance, you've got a sandbox instance or a development instance you may launch into the cloud someplace, or you've got your production layers all right in there using customized, for example.

23:07 - Nice.

23:07 - Yeah, nice part about that is, if my machine doesn't have enough horsepower or memory or disk space to run a specific project that where I need to jump in and help, I can just run that in the cloud.

23:18 I don't, there's nothing saying I have to be running that locally on my own machine.

23:22 All the tooling, all the file synchronization will work just as well if it's running in a sidecar.

23:28 Like if I had a big white box, Intel machine or machine sitting in my, under my desk, I can run that or I can just launch it into a digital ocean or an AWS cloud, doesn't matter.

23:39 - Yeah, absolutely.

23:40 So let's dive in, let's dive into Scaf.

23:43 But before we do, have you seen, I think it was in the last episode, this new AI computer thing that NVIDIA announced?

23:50 - I'm pretty excited about that actually.

23:51 - I'm super excited.

23:52 NVIDIA unveils a $3,000 desktop AI computer.

23:56 And I think it's just, you kind of remote in and run containers on it as well, I'm pretty sure.

24:00 - Yeah, I was excited 'cause I felt like CES, this is obviously launched at CES by NVIDIA on stage.

24:06 And I was excited to see CES have something It was interesting for developers again.

24:11 I feel like CES had kind of gotten boring maybe over the last decade.

24:15 And this was exciting.

24:17 I think that...

24:17 It's got to be all doorbells and TVs.

24:19 Yeah, right.

24:20 Exactly.

24:21 I love home automation.

24:23 Don't get me wrong.

24:24 But there's only so much of that junk I could possibly be interested in.

24:27 This is something I'm very interested in.

24:28 Exactly.

24:29 Well, Jamie out in the audience says, "Totally all in on developing with Guinness.

24:33 Very few tools installed on my Mac, but we're here with you." Awesome.

24:37 Yeah, the important tools.

24:38 Like you've got your IDE, your VS Code, you've got your, you know, you've got your favorite Git visualization tool.

24:43 Like, I mean, those, those are critical to your, your tool chain, your workflow and they should work everywhere.

24:48 They should work just as work alike on every project you're on.

24:50 Yeah, I agree.

24:52 I don't develop containers, but I work with local virtual environments and then like basically try to replicate exactly the same, but all the surrounding stuff, all the daemons and the servers and all that.

25:02 It's all like, so we're at a slightly different stage of our container journey, I believe, We're both far down the path, I think.

25:07 >>

25:08 Much further than we used to be.

25:09 >> Certainly.

25:11 [LAUGHTER]

25:12 >>

25:12 All right. Here we are, six feet up slash Scaf on GitHub.

25:15 >> Yep.

25:16 >> Scaf provides developers and DevOps engineers with a complete blueprint for a new project using Kubernetes.

25:22 We talked a lot about the motivation and so on, but let's start with the beginning.

25:26 You said I have an idea for a project that wasn't well-structured.

25:29 This is a little cookie cutter-ish in a sense, but what it makes is more than just a Python project, right?

25:36 Tell us what we got here.

25:38 - So this started out, if you've ever followed the Cookie Cutter project, there was a Cookie Cutter Django template out there made by Pi Danning.

25:48 It kind of kicked that off and started it.

25:50 I liked a lot of his opinions, but I wanted more to it, or I wanted to change some of them.

25:55 So that was the original, like, kind of kernel of where this started.

25:59 And then we grew a lot more around the deployment story and some of the developer tools so that we could be on Kubernetes.

26:06 We could standardize on Kubernetes as a container platform, so we could launch into any cloud, whether it's a managed Kubernetes or whether you're bare metal and are running like VMs and EC2, or it doesn't matter.

26:17 Because the nice part about Kubernetes is it gives you that agnostic interface to launch new containers.

26:25 I think a lot of people see Kubernetes as complex and used for like container orchestration and scaling.

26:31 But I see Kubernetes as a way, it's an interface, it's an API to allow us to deploy easily.

26:38 So we wanted to focus on things like CI/CD, and could you make that simple?

26:41 So SCAF includes opinions around Argo CD, for example.

26:46 So when you deploy into Sandbox, it deploys the Argo CD operator, and then it sits and watches your repository for changes.

26:53 So anytime you merge to Dev branch, for example, it will release to Sandbox, and then the QA team can go test.

26:59 You don't have to think about it.

27:00 Like you just make a PR, if it gets reviewed and accepted and merged, the release happens.

27:05 Like no one forgets to do the release.

27:07 No one has to do manual steps to do the release.

27:09 Long gone are the days of shelling into a box and doing a Git pull or SPN up in a directory and forgetting to restart some service to pick up those changes.

27:20 Because humans, we're humans.

27:22 We're terrible about repeatability and maintaining and being able to do maintenance type tasks like that.

27:28 We're just not built for it.

27:29 We're built for creative type thinking.

27:31 We should let the computers do the bits are good at, which I feel like that's what some of these opinions are based around is can we automate those pieces away?

27:37 Right.

27:37 It's like a deployment checkbox.

27:39 Oh yeah.

27:40 Checklist and like tech, tech, tech.

27:41 Have we installed this?

27:42 Do you set this version exactly?

27:43 Yeah.

27:44 Yeah.

27:45 Yeah.

27:45 And some, some humans are good at checklists.

27:47 Like there's people who are, that is their thing.

27:49 Like, you know, doctors and surgery.

27:50 Don't take their checks from them.

27:51 Right.

27:52 Like they love their checklists and glad they've got them.

27:55 I feel like people who have gravitated towards software development are craftsmen, kind of artisans around a craft.

28:02 And it's not so much about checking check boxes as it is how do they creatively solve a problem because a lot of the problems they're solving haven't existed.

28:09 If they existed already, they would be solved.

28:11 And what would be the point of us writing any software?

28:13 Yeah.

28:13 And that's why we have that.

28:14 It works on my machine.

28:15 Yeah, totally.

28:16 Program because we don't check the boxes and we're not amazing at making everything work the same, but yeah.

28:24 And this is my goal is the getting rid of the works on my machine.

28:29 Like it should work everywhere the same, exactly the same.

28:32 And you should be able to use your own machine for development.

28:34 Like a lot of I've seen a lot of teams where they have this big central server that's called dev and that's where they all shell into and work simultaneously on a single spot.

28:44 And that just feels fraught with errors and terror to me.

28:49 Yeah.

28:50 You know what it feels like it screams to me is you might end up It doesn't work on my machine.

28:53 It only works on that machine.

28:55 Exactly.

28:56 Even worse.

28:56 It only works.

28:57 I once worked on a research project with a pretty big funding organization and there was a bunch of different contractors, one of them out of Seattle, and we all had to build some pretty complex software team.

29:09 I was on, we built something that kind of coordinated all of them and it was fine.

29:12 Worked great.

29:13 We were all happy.

29:14 The other people will deliver, but there was this one team that had built something on a big, big Linux server and big fat desktop thing.

29:22 Why do I know the size of it?

29:24 Because they had worked on it for nine months and then they tried to get it to run on another, they literally could not get it to run on any other computer.

29:32 And so they put it into the most fragile, or most careful shipping container they could and they drove it from Seattle to San Diego and they set it up in the corner 'cause they literally couldn't get the software they wrote to run on any other system.

29:45 Could you imagine?

29:46 Like, what are you going to do in the next time around?

29:48 What if it breaks?

29:49 - Right.

29:50 - Yeah, that, that, I'm working on a big central server.

29:52 Maybe there's a way to like restore it and stuff, but you could, you could craft your software into a corner on that big server where it's like, well, we're going to move to the cloud.

30:01 Like, no, we're going to keep it on that thing and it better just be enough, you know?

30:04 - Right.

30:05 And how do you onboard someone new to help you?

30:07 Like, you gotta be like, well, be very, very careful.

30:09 There's this one, only one server where it only runs.

30:11 - Oh my goodness.

30:12 Could you, could you not?

30:13 - Onboarding is such a challenge there.

30:15 - Yeah.

30:16 You want to be able to onboard developers like with confidence and they can have the confidence to know that they can make mistakes and they can burn things to the ground and they can try stuff knowing that it's not going to affect like the production machine or even the sandbox machine.

30:29 Like they can experiment with a little bit of reckless abandon because that's how you learn.

30:34 Like you break things.

30:35 In my mind, you break things to learn.

30:37 There's a lot of learning that happens when you get to break things.

30:39 And if you can break things confidently knowing that no big deal, I can just get full or put a branch and delete that branch and start over.

30:46 >> 100 percent. And there's different, there's different layers at which people should embrace that to the maximum.

30:51 They should embrace that in refactoring, reorganizing, right?

30:55 So if I have, if I have Git and I have frequent check-ins, I should be able to go crazy.

31:00 You shouldn't be like, "Oh, don't mess with that." You should be able to go crazy on your code and go, "Oh my gosh, it's better." Or, "That was a horrible idea." Revert.

31:08 >> Get rid of that.

31:10 >>

31:10 And it should not, it should not be terror.

31:12 It should be like, "Oh, let's give that a try.

31:14 I bet that would be awesome.

31:15 And if it's not, we're going to get out.

31:16 Also though, on the containers give you that for your infrastructure locally and in the cloud.

31:21 What if we ran on the newest version of Postgres?

31:24 Yep.

31:24 Let's try it.

31:25 Is that amazing or is it a horrible idea?

31:26 Like, you've got the one server that everyone's using.

31:29 You're definitely, or even the QA server.

31:31 You're like, we're not going to break everyone because there's 10 people who are going to lose their productivity if we screw this up, but I can change a number in a Docker file and try it.

31:40 And I've seen this in action, again, in production, in action, in we have with our own customer stuff where a junior, you know, admin, sysadmin was doing some standard maintenance activity, you know, maybe they accidentally dropped the database.

31:53 But if you have all the things lined up and all the infrastructure, you know, set up in this kind of optimal way, no big deal.

32:00 It's like, no problem.

32:01 Like you go push, you go run the command that like restores the DB.

32:04 Like for example, one of our opinions in here is a cloud native PG.

32:08 So you have options.

32:08 Like we can use cloud native PG in the cluster and that does things like point time restore, recovery, you can be using RDS.

32:16 Those opinions can happen afterwards, but given that the whole thing can be blown away and redeployed in a moment, in literally a moment's notice, gives you a lot of confidence in being able to bring something back from a destructive action.

32:28 - Yeah, absolutely.

32:29 I think we're both so excited about this, we keep getting on tangents.

32:33 I originally would have asked you kind of, how do I get started with this?

32:35 Like, talk us through.

32:36 (laughing)

32:37 Talk us through, like I'm a-- - Oh, you'd like to try it?

32:40 (laughing)

32:41 They give people a sense of like, if they, if they don't, obviously most people don't have this already.

32:46 Like what are they, they want a new project.

32:48 They want it to have this more forward looking.

32:51 Yep.

32:51 So on that structure, yeah.

32:54 On that GitHub page, there's a one-liner you can just copy paste into your terminal.

32:58 I think it's toward the, yeah, it is right there.

33:00 Yeah.

33:00 There's a little, I applaud you for not having the dollar at the beginning.

33:03 Thank you.

33:05 I'm dollar fan, not a fan.

33:06 I'm pragmatic about this.

33:07 Yeah.

33:07 Yeah.

33:08 And that one liner will install a lot of the opinions.

33:12 I've mentioned this before to some people that Scaf gives you all of those kind of cool opinions, cool tools, like neat techniques that as a developer, like it takes like decades to refine and hone and kind of gain into your toolbox.

33:28 Scaf tries to give those to you like right away.

33:30 Like, so it's, for example, it's going to install kubectl and kind and tilt and a couple of other tools if they're not found on your system and it'll use, if homebrew installed, it'll just use homebrew out of the box to do that and it puts it into your home directory. It doesn't, it shouldn't require, you know, one of my goals is not to require sudo anywhere in this process, you know, there's no sudo needed here for that curl command to run. And so it should be less impactful on your system than a lot of other tools, but it gives you a lot of power for what you are installing. So you run that one liner, it will now give you in like your dot local bin directory, a scaf CLI command that you'll be able to run.

34:10 And you can just run scaf and then the name of the project you want to build.

34:14 And it'll ask you some questions.

34:15 So this is the kind of cookie cutter part at that point, is that it's going to ask you, "Hey, do you want to build a Django app with Next.js running?

34:22 And do you want to use Sentry? Do you want to have Celery?" Just some standard questions.

34:26 What mail provider are you going to use?

34:28 So it gives you then on your file system a new, in this case, a Django project.

34:33 I'll talk about some of the future vision pieces of that, but that's what it gives you today.

34:37 It also gives you, in addition to a standard Django project, because you can get a Django project just by running the Django start project, a Django admin start project command, it would blow out a very simple version of a Django project.

34:50 This has more to it.

34:51 There's some opinions about users and sites and some other things.

34:55 But not only that, there's going to be all the Kubernetes manifests for running locally.

34:58 There's going to be Terraform in there for deploying into a sandbox cloud, like on Amazon, for example.

35:03 So if you chose Amazon as your target cloud, There's going to be all these kind of other opinions in here.

35:10 What database we're using, what if we're using Celery, we're going to use Redis, actually we should change that.

35:16 We're changing from Redis over to Valky at the moment as well.

35:21 >> Valky, what is this?

35:23 >> So Valky, V-A-L-K-E-Y.

35:26 >> Close.

35:27 >> Valky, which is the Redis.

35:29 >> Valky, okay.

35:31 >> The Redis for Blake's Code.

35:32 >> Yeah.

35:33 >> Okay. Why this?

35:35 - Just because of licensing changes on the Reddit side of things.

35:38 I think that's another whole, we could do a whole other podcast on just open source licensing and interesting history.

35:44 You know, the Elastic folks did this with ElasticCache.

35:47 I think the Reddit folks kind of were following suit, but then you now-- - I think Mongo did

35:51 maybe a little bit as well.

35:52 - Well, now you've seen the Elastic folks kind of go back on that, heading back toward the more open open source licensing.

35:59 We'll see.

35:59 - I'm sympathetic to, at least some of these, because they built these businesses and the cloud folks are just like, "Awesome, we'll host that for you, thanks." You're like, "Wait a minute, we were hoping to kind of "have some kind of deal." - Yeah, be that.

36:11 - Yeah, yeah, yeah. - That'd be great for you.

36:12 - I can also totally understand, "No, we just want this stuff unencumbered." - Yeah. - It's not that complicated, probably we could probably make this work, and we got together and teamed up, and okay, this is news to me, this is awesome.

36:23 - Yeah, no, it's, again, it's drop-in replacement for the most current version of Redis.

36:28 - I was actually just thinking about doing something with Redis, but I think I might just do a little Norse legend type of stuff.

36:35 Try that out.

36:38 This portion of the talk Python to me is brought to you by a very special project that I've been working hard on for some time, a new book, the talk Python in production book.

36:47 I've long felt that most guidance and marketing about how we need to run Python apps in production has been overly complex and expensive.

36:55 I'm sure you've heard me espouse the ideas that you're not Google, you're not and you're not Netflix to emphasize that the legitimately incredible technology powering these companies can be admired but mostly shouldn't be used as a guide for your own applications and APIs. This book, "Talk Python in Production" is me pulling back the curtain and showing the world how this can be easily done.

37:17 You'll see how and why various technology choices have led us to truly maintainable web apps that can be managed by a single developer, cost a tiny fraction of most cloud-based solutions

37:27 and result in a blazing fast web app built on modern Python. You might be wondering if you need to be an expert in Docker or Linux to benefit from this book. You don't. While having some exposure to Docker or Linux servers helps, the book walks through setting up and managing a modern Docker-based deployment from scratch. Think of it as a guided tour of these technologies with best practices and pitfalls explained along the way. When deploying to the cloud, you often hear that you should just use serverless or other no-touch services. While they can work well, they often suffer from cold start slowness and more importantly, unpredictable bursts of costs if your app becomes popular. In Python in production, we keep these costs low and nearly flat by avoiding dozens of microservices and serverless functions. You won't be blindsided by unpredictable bills if you adopt this methodology.

38:21 Some of the more notable chapters include chapter 4, one big server rather than many small ones.

38:27 Chapter 6, running on Rust Python application servers.

38:31 Chapter 8, visualizing servers and other tools.

38:34 Chapter 14, picking a Python web framework.

38:37 Talk Python in production is available to read online or you can buy the full book at talkpython.fm/devopsbook.

38:44 If you're interested in running professional web applications and APIs in production with high availability and yet keeping things simple and manageable, then please consider the Talk Python in production book from yours truly.

38:56 Read it online or get the full book at talkpython.fm/devopsbook.

39:00 Getting the book is a great way to support Talk Python and keep the show going strong.

39:04 The link to the book is in your podcast player show notes.

39:08 Russ out there asks, "Wagtail?" Not yet. I don't believe we have a Wagtail template, but I'll talk about that in the roadmap. That's coming.

39:19 I guess it's worth pointing out to people that this is sort of at its core Django philosophy, right?

39:25 Currently. We have some other use cases that we want to be able to satisfy with Scaf as well.

39:32 For example, instead of deploying into a cloud and like you've got Argo CD, watching for like continuous deployment type stuff. What if you were deploying an appliance like into someone's data center.

39:42 And there were different concerns around security and updates and adopting updates and how it got updated.

39:47 We want to be able to support that use case.

39:49 We want to be able to, I'd love to be able to support a fully serverless, you know, SCAF lite type environment where maybe we're using Lambdas and DynamoDB and API Gateway to deploy the backend in a totally serverless manner.

40:03 SCAF should be able to support that too.

40:04 It's not there yet.

40:05 That's definitely, that's the roadmap piece for sure.

40:08 There probably is some, I'm not totally up on it, but it's probably some open source Valky equivalent Docker based Lambda type stuff as well that you might be able to say, we want to have a self-contained serverless as part of this.

40:21 - Yeah, for example, the Scaf challenge.

40:25 So if you went to DjangoCon last year, 6PF ran a Scaf challenge where it was to see how fast you could basically run and get a running Django project on your machine in Kubernetes, running locally, ready to develop.

40:36 The winner did it in 26 seconds from running Scaf to Django, actually ready to respond to HTTP requests.

40:45 Wow.

40:45 That backend that tracked it was all done in Dynamo, Lambda, and API Gateway using the SAM framework.

40:53 And so on Amazon, there's the serverless application framework that they've got called SAM, which is really nice because you can run it all locally.

41:01 You just do SAM serve or whatever, SAM start, and it spins up containers locally, you spin up your Dynamo container locally.

41:09 So I had the whole thing running on my own machine, much in a way that's why I like about Scaf because it all runs locally, it all is contained and I can play with it, I can destroy it, I can make mistakes, and then when I'm ready, I make a pull request.

41:22 >> Yeah. One of the things that I'm always apprehensive about is building apps that have to have lots of Cloud services constantly active, and not just because I want to be able to say, work in a coffee shop with poor internet connectivity or on an airplane or something like that. But also I feel like there's probably some leakage. I mean I just heard an ad on some podcast about it for a company that whose job is to go and look at all the AWS or Azure stuff you're doing that you might have left running and is costing you $10,000 a month. People just forgot about it.

41:52 You know they'd be like, "Oh, let's try this." >> I think you should say that. We've had that.

41:56 >> Oh really? Tell us a story.

41:57 >> Yeah, that's another reason for parts we're adding into SCAF around compliance and cost controls.

42:04 I'm a big fan of an open source tool called Cloud Custodian, which is a event-driven Cloud compliance tool.

42:11 If you haven't checked it out, Cloud Custodian is a really great tool for compliance, but also fin ops.

42:19 Making sure your Dev instances aren't running 24/7 when they really only need to run probably eight hours a day, they don't need to run on weekends.

42:25 Cloud Custodian can shut those things down.

42:26 That's something we're adding into SCAF right now, is some minimum set of things.

42:31 like make sure any cloud resources you get deployed are properly tagged.

42:35 You know, are they tagged with an environment like production or development?

42:38 Are they tagged with a cost center or whatever your policies may be, but that will help you avoid those kinds of instances where we had, for example, someone spun up a spot instance.

42:48 Well, if you're not familiar with Amazon, you can request spot instances, which are kind of excess EC2 VMs that are hanging out.

42:55 And if someone releases one, you can pick it up and use it cheaper.

42:58 And they're typically meant to be used temporarily.

43:00 but you request them and they come asynchronously to you.

43:03 So you could go into your console and request one, and if it doesn't come right away, you're like, "Shoot, that didn't work." And you could take off, you know, go get a coffee and get lunch, and then totally forget you requested the spot instance for a giant GPU, whatever.

43:14 - And then it's ready.

43:15 - Yeah, and then it'll show up later in the day.

43:18 And if you don't go and turn it off, you'll pay for it for the month, which was $10,000 for one of them, once that happened to us.

43:24 So putting in place the fact that if someone did spin up an instance like that, Cloud Custodian would be watching for it, and we'd shut it down within a day if it didn't follow whatever your policy is for starting up new kinds of instances.

43:35 - That's really cool.

43:36 We're learning about a lot of cool open source tools here.

43:39 This is great.

43:39 - And that's why they're all packaged into SCAP because not everyone knows about all these things.

43:43 So we're trying to take our kind of cumulative six feet up journey of 25 years of being on the internet and deploying software and developing software and packaging those opinions into like one spot where it's kind of like someone took our brains, collective brains, and put them into a code repository and now we can deploy and develop like we've been doing

43:59 it for 25 years.

44:01 - Yeah, it's like, well, that was a really sharp edge.

44:02 Let's see if we can come up with that.

44:03 - Oh my gosh, yes.

44:04 (both laughing)

44:06 - Somebody's like, guys, sorry, but there's a big bill.

44:11 - There was a big bill.

44:13 Look, I'll give a shout out to Amazon.

44:15 I contacted them and they did refund us for that accidental big bill.

44:19 They're generally pretty good about it if you make that mistake once.

44:22 Now, you gotta make sure you show them, you can demonstrate to them, you've put in place things to not have it happen again.

44:26 - Okay, 'cause you might pay for it again.

44:28 - Yeah, I honestly work in the cloud, it's super scary in that regard, you know, when it's overly automated.

44:34 So, one of the things, speaking of deployments and all this that I do when I'm working with my Docker stuff is I'll set up a Docker compose file, that's kind of my zen right now.

44:42 - Yeah.

44:43 - And in there you can set deployment limits, like this container can only use so much CPU, more significantly for me usually is like, this container can only use one gig of RAM, even though the server's got 16, tell it it has one.

44:55 And the reason that I think that's super useful is, something goes crazy or starts using too much memory or something like that, you could say, "Oh, there's something going on here without it taking down everything else." And there's other things, especially databases. They're like, "Oh, I've got 16 gigs. I was just going to load everything into memory because that'll be more efficient." Like, no, no, no, you're sharing this with everyone. Could you just load the indexes into your two gigs? That would be good, right? Is there stuff like that here?

45:19 Yeah, exactly. And our opinions on that are in the Kubernetes world. You can be able to put in resource limits and priorities.

45:26 This actually also literally happened to us.

45:29 Again, all of our experience you get to benefit from.

45:32 If you aren't careful with Kubernetes.

45:34 >>

45:34 I think every one of these that have a little double dagger thing, you click on it.

45:38 >> That's totally right.

45:39 >> Here's the story why this is here.

45:41 Here's the story why this is here, because that's the truth.

45:44 If you don't use resource limits on Kubernetes, they will absolutely stomp on each other.

45:49 Kubernetes is an amazing orchestrator and it will do exactly what it's told.

45:52 And if you've told it that this doesn't have limits, it will give it all the things all the time.

45:57 And you can run into a situation, for example, if you're using cloud native PG, your database is in the cluster, which means it's orchestrated by the cluster.

46:04 If you don't give it any limits and you're running multiples and you do a backup, the resources when you do a backup go up.

46:11 Yes, 100%. Yeah.

46:12 If you do, it basically like scans through all of the data.

46:16 And all the things.

46:17 Why is it using three gigs? It was using just one.

46:19 Oh, because I asked for a full backup.

46:21 >>

46:21 Well, and I tell you what it'll do is it'll consume all the resources on one node and then it'll fail over, orchestrated, it'll fail over to the second node and then use all the resources on the second node and then it'll corrupt your database and crash the whole thing.

46:33 Now, if you put in the resource limits and the priorities, because what it should do is it should go off and be like, there's a lot of Django instances running that I don't need to be, I can kill those first.

46:42 I can orchestrate smartly for you only if you smartly configure it.

46:47 >> Right. Here's my goal is to not let this get out of control.

46:50 help me with that. Don't just feed it everything.

46:53 - Yeah.

46:53 - Yeah, it's interesting. A lot of these servers are like, "We could do better if we could just take it, "we could load up more and pre-cache more." But they don't work well together like

47:00 that.

47:01 - Right, yeah. I mean, they're greedy.

47:04 They're gonna try and take the resources they need to do the job they need to do, but they can be told to be less greedy.

47:10 And Kubernetes is how we do that.

47:12 - Yeah, more importantly, they can be forced to be less greedy.

47:14 - You need to stay in line.

47:16 (laughing)

47:17 - So what you got? You're not getting more.

47:18 All right, let's talk through the building blocks here.

47:20 You mentioned a couple of them, but there's a big long list of things that I think is gonna be pretty interesting to people.

47:27 Started with Django.

47:28 - Yeah.

47:28 - And then let's go down the building block.

47:30 When I make an app like this, it has an opinion, it looks like as well.

47:33 It's not just a vanilla Django app.

47:35 - Correct.

47:36 Yeah, you could be doing asynchronous tasks, so that's why there's a Celery opinion in there.

47:40 Like we, you know, if you've got a project, you know you're gonna have jobs in the background.

47:43 Sure, let's get Celery installed.

47:46 If you're doing something with a fancy front end React, where our opinion is really to use Next.js. And if you install Next.js, you'll get like the strawberry GraphQL stuff out of the box, which is kind of nice and Apollo on the front end, if the Next.js is also chosen. So some GraphQL opinions have been made and the plumbing laid to make it just work, which is kind of hard sometimes. If you're diving into a new technology like React and GraphQL, it's nice to have some opinions and to have them pre-wired up for you. So you can just just kind of follow the pattern that's already been laid for you.

48:20 Okay. I'm told that Next.js is really, really popular.

48:23 Yeah.

48:24 Tell us about what is Next.js.

48:26 Yeah, I mean, Next.js is a set of opinions around React.

48:30 Much in the way that, for example, like Zope and Plone were opinions around how to do a Python web framework.

48:37 Next.js is kind of a packaging of some opinions about how I would deploy and write React applications and keep them up to date.

48:45 For anyone who's done a React application, you can start with the standard React demo application.

48:51 But from there, you start adding on it.

48:53 Again, I'm definitely not the TypeScript, JavaScript front-end person, but dependency spaghetti mess will happen very quickly in this world, or can happen very quickly in this world, which will lead you into a spot where it's really difficult to upgrade your React application to get all the dependencies upgraded.

49:13 and there's security vulnerabilities and issues you need to be aware of and performance things.

49:17 So you want to make sure you can stay on top of those versions.

49:19 And Next.js is basically a set of guidelines and opinions that should help guide you down a more happy path.

49:25 And that's why we chose it.

49:26 I think even the React folks tend to suggest using Next.js instead of just React on its own because you get those opinions and should have an easier time keeping things up to date.

49:36 Yeah, I know the JS stuff feels like it's so complicated, but it's again because we're

49:40 asking more and more.

49:41 People have high expectations of the web applications that they interact with on a daily basis.

49:48 It's just a fact of life that people expect, have expectations about how things are going to behave and the experience they're going to get.

49:54 Yeah. They're like, Gmail's cool.

49:56 Google Maps is cool. Can ours do that?

49:58 Like, you realize this is a static website.

50:04 You're the developer behind that?

50:06 Yeah.

50:06 And then if we keep going down this list, I mean, we've standardized on Postgres.

50:10 and that's historic.

50:12 We probably 15 years ago used MySQL.

50:16 And that was back in the days of MySQL silently dropping data, on you.

50:21 but I don't think those You got enough.

50:23 I mean, you got enough of your data kept. There's a lot.

50:25 That's exactly what it was. So we, we switched to Postgres and haven't looked back. and there's just a lot of exciting things happening there. So if you're not on Postgres, I highly

50:33 recommend it. Good, good, good bet there, because if you look at the surveys and stuff, like The majority of people are doing that, especially if they're doing relational databases.

50:42 It's Postgres and then you better justify why you're not using Postgres.

50:47 >> Then if you're going to run Postgres and you're running Kubernetes, you're going to want to have some kind of an operator to manage it for you.

50:53 If you want to have high availability, you want to have data backups, and that's what Cloud Native PG gives you.

50:58 You can back up into S3 buckets, or you can back up into, you name it.

51:02 There's multiple kinds of targets that are supported, but it manages all that hard complexity for you.

51:06 If you've ever set up Postgres replication and high availability on your own and had to deal with all the wall files and moving them around and backing them up, it's a sophisticated beast, a complicated, sophisticated beast and no one wants to deal with that.

51:21 And that's what Cloud Native PG does for you.

51:22 It gives you UI and a way to configure it and away you go.

51:26 - And then after that, we have Valky.

51:27 - Yeah, Valky.

51:29 Which is our Redis drop-in replacement.

51:32 If you're not using Redis in your Django apps, you should be.

51:34 even if nothing more than just the Django template cache, I would turn that on.

51:39 We've been using Mailhog for our email locally.

51:41 So this is a local developer tool.

51:44 Allows you to simulate email being sent off of your development instance without actually sending email anywhere.

51:50 - So it's a little bit like mocking email.

51:52 - Yeah, yeah, it's super nice.

51:53 It runs an SMTP server, it gives you a web UI.

51:56 It looks like real email, it gives you an inbox so you can basically see what your end users are gonna see.

52:03 Argo is the CI/CD product, but the open source GitOps.

52:07 So it watches your repositories, kind of tracks the status of the deployments.

52:12 - Okay, so you basically pick a prod branch or something like that and you push the prod then magic happens.

52:17 - Yeah, Argo does the magic behind that.

52:19 And you can see that it also gives you a bit of a insight into your cluster, you know, what's running, what's being deployed, what state they're in, you know, it handles all the like blue green, you know, rollout of new code, new pods and new containers into your clusters.

52:35 It's, yeah, I can set up a QA cluster as well.

52:38 Yep. Right. Just pick a different branch and have it watch that. Right.

52:41 But that's what we do. So inside the SCAF built skeleton you get on your file system, you're going to have a Kubernetes manifest directory that has a base set of manifests, which are, this is what's needed to define the deployment and the services and all the bits.

52:57 And then each environment, for example, like the sandbox environment, has an Argo running that'll be watching for sandbox changes, and the production environment will be watching for production changes. Another thing we standardize on here that's not listed is things like sealed secrets. So you can check in your secrets to your Git repository for sandbox, for example, but the only machine on the planet that can decrypt them is the sandbox instance, because you actually use the sealed secrets operator to do the encryption. And the only The only way it can be decrypted is if those things are sitting in that cluster, in the sandbox cluster or in the production cluster.

53:30 So what's nice is the sandbox cluster cannot decrypt the production secrets.

53:34 So you can have, obviously you want to have different secrets for production than you do for sandbox.

53:39 So you can have least privilege.

53:40 You know, developers have access, maybe more unfettered access to sandbox, but they may have more limited access on production.

53:46 And tools like sealed secrets and customize and Kubernetes manifests and sealed secrets actually make all that work.

53:52 Okay.

53:53 Yeah.

53:53 And that's, that's news to me as well.

53:55 This one, I love it.

53:56 I do something similar with my things as well.

53:58 Like I know a lot of people have huge environment variable definitions of all their, I'm like, yeah, you just, you just need one value that unlocks the other, you know, highly encrypted stuff.

54:10 Now for, for someone actually asked a question I'm getting ready to answer, which is about external secrets and services for those things, local development, we've have an opinion around using one password for all of our secrets management, whether it's like passwords for websites or API keys, or in this case, development environment, database passwords, development environment, you know, secrets, like Django has a secret, Django secret in there, things like that. Those are actually, in our case, environment variables. And we use the one password command line tool to only decrypt them ever in memory. So when you run like the Django start, or like the anytime you run the Kubernetes cluster locally and kind, it will feed those environment variables via the config map into your cluster so that it can access the database in the cluster locally. So even locally, you have a long, random, unknown password to you that is actually stored in one password. So if you want to go use your, I use Postico as a GUI for accessing my local Postgres, I can use that. I can actually feed the data from one password and actually access my services. So locally using one password and environment variables and config maps. But when going to sandbox, we just use sealed secrets on sandbox and production for mostly cross-platform consistency. You could be using, you know, SSM parameter store on Amazon or secrets manager on Amazon, but then that won't work on Google or won't work on Azure. And so we just standardize around the sealed secrets for ease of deployment to any cluster in any platform anywhere.

55:43 Yeah, the one password new CLI stuff and SSH.

55:46 So nice.

55:48 Secret provider, whatever you call that thing.

55:50 Yeah, it's super nice.

55:51 Yeah, if you've not turned on the SSH keys for your 1Password CLI, I have no secret keys, no SSH keys, no API credentials.

56:01 I have no secrets on my file system unencrypted.

56:04 They're living in 1Password and 1Password proxies that access when needed.

56:08 Yeah, that's pretty neat.

56:09 I feel like I should maybe embrace that more.

56:11 I embrace 1Password a lot, but there's more.

56:13 Especially when you're working on multiple projects and multiple environments and you want to, again, have that least privileged access.

56:21 You don't want to have one key to rule them all.

56:23 You want to have keys to get you access to Sandbox, keys that can get you access to production, and you want to be able to give only certain people access to those production keys and only certain people access to Sandbox keys.

56:32 And we actually do that with, so we're a Microsoft 365 shop.

56:36 We use Microsoft's Entra Directory service, which is their Azure Active Directory product, and we use security groups.

56:43 And so based on what security groups or what project you're working on, gives you access to only certain vaults inside of one password, gives you access to only certain accounts inside of Amazon and those kinds of things are all wired up to our, our single sign on platform.

56:57 Yeah. Very nice.

56:57 Traffic.

56:58 Traffic's just an ingress controller. it's like a load balancer type thing.

57:02 Yeah. It's a load balancer kind of cloud.

57:04 If you rethought about a web server and it was cloud native and containers and understood clusters like Kubernetes clusters, this is what traffic is.

57:13 I see.

57:14 So maybe a better analogy would be like IngenX or yeah.

57:19 Yeah.

57:19 I mean, I think we all grew up, we all grew up on IngenX and made it do all the crazy reverse proxy things like traffic is the one born in the cloud native world version of that.

57:29 Now IngenX has their own ingress controller as well that they've re rewritten to be more cloud native.

57:35 That's just what traffic is for us.

57:36 cert manager again, handling things like TLS certificates and renewals and you name it, cert manager, make sure.

57:43 How's that different than Let's Encrypt and Certbot and things like that?

57:48 I mean, it's really similar in those cases.

57:50 I think actually Certmanager, I think, is using Let's Encrypt under the covers.

57:54 I could be wrong on that one.

57:55 Maybe more cluster focused because that could be a real challenge.

57:58 Well, because a lot of the, again, another beauty of Kubernetes that I don't think a lot of people talk about is the operators.

58:04 These are like, you know, extensions or plugins to the Kubernetes cluster that give you superpowers to do things like make sure the certs are always, you know, renewed, make sure the latest code is always deployed.

58:14 Make sure the database is highly available and backed up.

58:17 Make sure, you know, that's what these operators do in the Kubernetes world.

58:21 Is there like just plugins to your cluster that give you these extended capabilities?

58:25 And that's what CertManager is, it's another one of those.

58:27 So, and that handles the certificates and grass routes.

58:30 That's all like kind of traffic CertManager certificates.

58:32 It's all, yeah, it's all together.

58:34 All together.

58:35 Won't give you the certificate unless it can prove that certificate, that domain routes back to that thing.

58:41 And yeah, it's great, but it does get a little complicated in Docker already.

58:45 And then I can imagine auto scaling blusters that gets thrown away.

58:49 You want it all just to work.

58:50 Yeah, you don't want the certificate expired.

58:52 Warning, danger, do not proceed to this website.

58:54 Oh, no.

58:55 All right, we got Prometheus in the house.

58:57 Well, and Prometheus and Grafana are kind of together here.

59:00 It's nice to have a observability, be able to see stats and trending data, to be able to make decisions on how you're scaling or handling load.

59:08 It's hard to predict sometimes what a service is going to do when you go deploy it to real users.

59:14 Real users have an uncanny knack of pushing buttons and making things happen that produce lots of crazy edge cases.

59:22 - Right, this part was slow, so I just kept pushing the button.

59:25 Like, you know, it's how much more load you're putting.

59:26 It was really slow, 'cause I couldn't handle it.

59:28 - And you'd prefer that you know about these problems before your users report them to you.

59:34 So tools like Prometheus and Grafana and Loki.

59:38 So Loki specifically is log aggregation.

59:42 Prometheus is going to be a lot of metrics.

59:44 And we combine those all into like Grafana dashboards.

59:46 The trick here is, you know, you want to be able to get all the data, but then you got to make something meaningful of the data.

59:51 And so we try to put in some, you know, default dashboards that give you that.

59:57 If I was stuck on an island, what was the one screen of information I might need to make a business decision about what's happening here type view of things and not overload you with too much information.

01:00:07 But you want to be able to dive deeper and see, oh, you know, when the database backup kicks in, the IO all of a sudden goes crazy. And that's why we're seeing a dip in here.

01:00:15 And that's why there was a failover. Like, be able to trace back those things without data is impossible. And you only again, because we're in a clustered world and there's lots of interdependencies and these things can scale out, you could have many, many nodes running these tools, you got to have some way of getting a, I hate to say it, a single pane of glass. I'll put that out there.

01:00:36 I can see my entire business in a single pane of glass. It is humming smoothly.

01:00:42 Yeah, I'm sure all the IT folks, they all just cringe to like, "Oh my God, he just said it." Some

01:00:48 people cringe and say, "Yes, they're speaking my language." Out there, my goal in the audience, the Media Cube from EPS is all of the pre-configured dashboards for Yeah, it's out of the box.

01:00:58 Yeah, yeah, yeah, yeah, definitely.

01:01:00 I mean, there's there's so many good example dashboards under Fanta that it is no reason not to be using this for durability.

01:01:07 And this is like the table stakes, like you better start here and you better just do it.

01:01:10 But a lot of people deploy an app and then they they I mean, how many times have you worked within a developer and you're like, well, if something's wrong, I can't figure out why.

01:01:18 And the first thing you tell them, I guarantee you, Michael, the first thing you tell them to do is did you look in the logs?

01:01:22 And they're like, no, I didn't look in the logs.

01:01:24 I'm like, well, that's the first thing I do is go look at the logs.

01:01:26 Yeah, that's the second thing you tell them.

01:01:29 What's the first?

01:01:29 First thing is, do you have logging?

01:01:32 [laughing]

01:01:33 True, okay.

01:01:34 Yes, I have it.

01:01:34 Okay, did you look at them?

01:01:36 Fair enough.

01:01:36 I was about to ask you though, like, do you have, do you have logging set up in this?

01:01:40 And do you have like Log Guru or do you have Logbook or do you just do Python logging or what's the

01:01:44 story?

01:01:44 Yeah, I mean, we're using containers, so things should be set up to log as we would expect them in Kubernetes.

01:01:51 So it's kind of like the if you've ever looked at the 12 factor app, you know, there's opinions about how logging should happen.

01:01:58 That's what we adhere to is that logging should end up in a natural spot where it's easy for us to aggregate with tools like Prometheus and Grafana and actually then action and do something with them.

01:02:07 So we typically have another SSH into other machines to see, well, what's this thing doing? What's that doing?

01:02:13 And that's one thing I want to have no SSH into these clusters.

01:02:17 Actually, one of our deployment opinions here is using things like Talos Linux for our Kubernetes deployments.

01:02:23 Talos does not have a SSH shell enabled.

01:02:27 Talos Linux has the ability to launch Kubernetes clusters.

01:02:30 So you can use kubectl to manage your Kubernetes, but then you have the Talos CTL to manage Talos.

01:02:36 There's no reason to shell into a box.

01:02:38 It's just another security surface that you can now get rid of.

01:02:42 >> Yeah. Very interesting. There's a couple of these single-purpose Linux distributions out there that are really, really cool.

01:02:48 >>

01:02:48 We've evaluated quite a few, And this is the one we picked.

01:02:51 I liked its opinions.

01:02:52 I liked its approach.

01:02:53 I like the community that's behind it.

01:02:55 One thing when you're picking a lot of these software tools is you need to look at the communities.

01:02:58 You need to see how active they are.

01:02:59 You need to understand, is this going to be a viable project, you know, five years from now?

01:03:03 'Cause these are opinions you'll pick now and you'll have to live with potentially a long time.

01:03:07 - That's a great point.

01:03:08 Is this going to be your hobby project that you're going to have to keep it running for

01:03:11 everyone else?

01:03:12 Or is this thing got a life of its own?

01:03:14 'Cause I don't need another hobby.

01:03:15 - Yeah, exactly.

01:03:16 We want this to be for real.

01:03:18 Yeah.

01:03:18 Let's do one more shout out of all the building blocks here.

01:03:21 Sentry, you know, long time sponsor, friend of the show.

01:03:24 Yeah. So again, observability tools like this, especially when it comes to like tools like Sentry or even DataDog and New Relic, we just happen to pick Sentry because I like, again, like the community.

01:03:36 I like the people who are behind that tool.

01:03:38 I can't tell you how much time a tool like Sentry has saved us when trying to diagnose and debug performance issues.

01:03:45 I know it has lots and lots of features it can do, But when you're looking at a stack and you've got a n plus one performance issue going on with your database queries and its integrations with Django, its integrations with Redis and Postgres, just make tracking down that kind of stuff so much easier.

01:04:02 We again, I'll go back to that 2020, 2021, when we launched Loud Swarm as a virtual event platform space.

01:04:08 being able to deliver the schedule to a React application quickly as it's changing throughout the day was actually a big performance challenge.

01:04:17 And Sentry highlighted exactly where the problems were.

01:04:20 And then we just implemented a simple Redis cache that took us from 90 second generation of the schedule down to like milliseconds.

01:04:27 And that was because we were able to pinpoint the issue really, really carefully and really, really close to a Sentry.

01:04:32 It just, it bubbles up your problems and now you just go pick off the low hanging fruit.

01:04:36 Yeah, that's awesome. I've also used it for error monitoring stuff and it's, I'm more than one, I know I say this on the show for some of the ads, but more than once, and this is not an ad, but I've certainly gotten an error and it's got all the variables of not just the stack trace, but actually the variables of what user ran into problems and all sorts of stuff.

01:04:53 And I reached out to multiple people, said, I see you ran into this problem. I'm really sorry. I fixed it. Give it another try. And I'm sure that's a creepy experience in one way, but also you're like, geez, that doesn't happen very often.

01:05:04 But you know, like, well, I fix it and I know who it is.

01:05:06 I might as well tell them like, hey, sorry, you hit this.

01:05:08 Yeah.

01:05:09 One tool we've not mentioned here that is not in this list that I think is super important to our staff stack is Tilt.

01:05:16 That is the local Kubernetes management tool of choice that we have picked.

01:05:21 And if you've not played with Tilt, we've gone through different tools along the way.

01:05:26 There was one called Scaffold and I can't remember the other ones we tried.

01:05:30 There's numerous ones out there who basically sit in this space and try and solve this problem.

01:05:35 But the killer feature for Tilt was two-way sync between your cluster and your local machine.

01:05:41 So again, if you're running locally and using Kine, you probably don't notice anything because Tilt is watching your file system, synchronizing your files into the Kubernetes cluster for you to work, but it also does the reverse.

01:05:51 One of the key bits I wanted was when you do a compilation of your requirements for your project, you're running Django and you've got a whole set of requirements, if you get into some trickier things, like around the data science world, there may be things that compile differently on macOS than on Linux, than on Windows, because they use some slightly different dependencies.

01:06:11 That can be tricky when you're working in a container world.

01:06:14 So you want to make sure you're doing your pip-tools compile, well, via UV, but your pip-tools compile in the container, in the target environment of where this is going to be deployed and built, because you'll get different results if you ran that pip-tools compile on your Mac, as opposed to into the Linux VM or Linux container.

01:06:29 - Yeah, that's true.

01:06:30 >> A platform specific wheels.

01:06:33 >> Yeah. So tools like Tilt makes sure that I can run my thing in the container, and the result of it synchronizes back to my file system, and then I check that into the repository.

01:06:42 That was a key bit there.

01:06:44 Again, it has a lot of other cool things, nice UI.

01:06:47 If you fire up Scaf, at the very end of it, it'll tell you, "Congratulations, you got a new project on your file system.

01:06:53 CD in your project and just type Tilt up." You type Tilt up and you hit space bar, I think it is, and it launches a web browser with all the status of all the containers that are running locally.

01:07:03 You can see all the logging, you can tilt watches for changes to your local file system for the code, tilt watches for changes to the Docker files.

01:07:11 If you change the Docker file out from underneath tilt, like while you're developing, say you're adding a new layer, a new dependency or something that's needed in Docker and not in your Python, tilt will rebuild the container immediately for you.

01:07:22 Like without you having to do anything, like you just kind of, you just code along and tilt keeps up.

01:07:27 - Wow, that's awesome.

01:07:28 - Yeah.

01:07:29 setting your unit has to run on every save.

01:07:31 >> Exactly.

01:07:32 It is. It's fast.

01:07:34 Sometimes you barely even notice.

01:07:35 Like if you're working in a very late layer in the build, those builds can happen really, really quickly because most of the stuff is cached.

01:07:42 Just notice of opinions.

01:07:44 We've really tried to finally tune all the caching in the Docker files and all the layers so that these images build fast, they build slim, they use caches.

01:07:54 So if you're running locally, it's going to cache things locally in your file system.

01:07:58 you blow things away and start over again, it doesn't take forever to download all the stuff.

01:08:01 It should be pulling from your local cache.

01:08:03 - Yeah, that's a big shift when you're doing container type stuff.

01:08:07 - Oh, man, 'cause some folks may have a not great experience with containers because of the size of some of these things and because they're not effectively using caching.

01:08:15 This is a game changer.

01:08:16 - Right, it 100% is.

01:08:17 And just maybe potentially just reordering or splitting up commands could make - Oh, yeah.

01:08:22 - 10x difference in speed.

01:08:25 - Well, and you were the one who convinced me to switch over to UV inside their container builds as well.

01:08:30 And that absolutely sped things up.

01:08:33 Speed is a feature.

01:08:33 I know you had that interview with Charlie, and that was one of the things that came out of that, but it's stuck in my head is speed is a feature, and I take that everywhere with me.

01:08:41 - Yeah, that's awesome.

01:08:42 It's a cheat code for sure.

01:08:43 It's like, oh, we've hit it three, 10 times.

01:08:45 Let's try that, that's awesome.

01:08:46 And then, yeah, you can layer on more caching on top of that and make it even more ridiculous.

01:08:52 All right, I think that's probably it for the time to talk through this.

01:08:54 What a cool project you got here.

01:08:56 Let's close it out with a roadmap.

01:09:00 - So we've got a lot of things coming.

01:09:02 One of the big ones is a big shift from using Cookie Cutter, which I've mentioned already, to using Copier as our underlying templating product.

01:09:11 The big benefit-- - Tell people what Copier is, yeah.

01:09:12 - Yeah, so Copiers, like Cookie Cutter, actually is a drop-in replacement for Cookie Cutter.

01:09:16 You can use your Cookie Cutter templates you've already built with Copier, but now you can actually modularize them and upgrade them.

01:09:23 So one of the problems with Cookie Cutter, was it was kind of one and done.

01:09:27 Like you blew out your template onto the file system, you've got your code. That's the last time you would touch cookie cutter.

01:09:33 But if new opinions come around, which we're constantly adding new opinions to SCAF about how we do dev and how we do deployment, you would want those to roll back into old projects that had been built with that same tool.

01:09:43 Copier enables this.

01:09:44 Copier now allows us to rerun against an existing project and adopt new opinions that have been made from the source template. And that's another change we're making is we're actually allowing Scaf to have multiple template types.

01:09:58 So right now, the Scaf kind of runs in a full stack Django app mode.

01:10:03 We're going to have the Scaf Lite version, which may be serverless.

01:10:06 We're going to have the appliance mode, which would enable not using Argo CD, for example, but different ways of updating.

01:10:12 We'll have opinions that are not Django necessarily.

01:10:15 They may be more data pipeline versions of your apps.

01:10:19 And so those will be templates that can be updated and and redeployed and kept up to date with Copier.

01:10:24 That's cool. Yeah, I can see a whole idea, a whole concept of this for ML workloads and science

01:10:29 workloads. And we don't actually need a web app. Exactly.

01:10:32 What we need is data ingestion and intel and we want results, either a notebook or just something in a database on the other end of them.

01:10:39 Yeah. Yeah, that's a big, that's a big deal. And that's another thing that is included in Skap Opinions is the CI pipeline, the GitHub actions, Bitbucket Act, you know, workflows or whatever their CI thing is called. Because those Those are important, those need to be there day one, 'cause they're so hard to tack on later, or you just get busy and you don't tack them on when you should have.

01:10:58 - Yeah, it's good to have all this experience and all these rounded off rough edges put together in one box for you, very cool.

01:11:06 All right, well we're certainly out of time, Calvin, so how about, we've got two things to close this out, unlike normal.

01:11:13 So let's close it out with a final call to action.

01:11:15 People are interested in SCAF.

01:11:17 - Yeah, they should definitely go to-- - Should I go to Starrett?

01:11:20 - Yep, go to Starrett.

01:11:20 log in apparently. Yeah, go hang out, go to the 6github/scaph GitHub repository. It's a one-liner to install. I would love to hear your feedback, you know, any feature requests, you know, any bugs you find. We've worked really hard on ironing out a lot of those issues over the last year as we kind of pushed toward DjangoCon last year. It's amazing and mind-blowing to see how fast you can get a Django project up and running on your own machine with Kubernetes in the mix. Maybe people a little background information, like they're like, I heard of Kubernetes.

01:11:54 What do I do with it?

01:11:55 Like you got good resources for them to Oh, on YouTube, there's an excellent YouTuber. Her name's Nana. So if you just search Nana and Kubernetes, she does an incredible job of explaining Kubernetes to everybody.

01:12:12 Yeah. I believe it's Nana Codes. Yeah. Technical Nana.

01:12:16 Yeah.

01:12:16 Yeah. She's awesome.

01:12:17 She's really good. Yeah.

01:12:18 She's really good.

01:12:18 She's really good.

01:12:19 a great way of explaining these kind of deeper technology things.

01:12:23 That's literally where I went.

01:12:24 I was like, I need to know more about Kubernetes.

01:12:26 I went and watched her videos.

01:12:28 I met her in person.

01:12:28 She's actually an AWS hero.

01:12:30 And she was at reInvent a couple of years ago.

01:12:32 And just again, superhuman being doing this for the love of technology.

01:12:36 Actually, I can give a shout out also to one of the people in the chat.

01:12:39 Michael Levin is also a prolific YouTuber on Kubernetes.

01:12:44 Oh, no kidding.

01:12:45 Okay, I'll put a link to his channel as well.

01:12:47 Awesome.

01:12:47 All right, well, Calvin, thank you for being here.

01:12:49 It's been awesome.

01:12:51 I can't tell you how excited I was about the opportunity.

01:12:54 Yeah, it's been super fun and I was excited as well.

01:12:57 So much so, so much so that I've made a theme song for this episode.

01:13:02 I'm not going to play it on the YouTube live stream version.

01:13:04 It's just the logistics of that are a little bit challenging.

01:13:07 But I'll put a link in the YouTube description in a day or two.

01:13:11 And when this show comes out, it's going to be at the end.

01:13:14 And so if you're listening through the MP3 version of your podcast player, be sure to listen to the end.

01:13:18 There's gonna be a-- - Get ready to crank it up.

01:13:20 - Yeah, so here's the thing.

01:13:21 If you like Linkin Park and that style of music, you're gonna love it.

01:13:24 If you hate Linkin Park, maybe call it a show.

01:13:27 Anyway, it's gonna be super fun.

01:13:29 We'll put, let's deploy, or deploy the dream at the end.

01:13:31 It'll be a great theme song to round things out.

01:13:34 And with that, Calvin, thanks for being on the show.

01:13:35 - Awesome, thanks, Michael.

01:13:36 - Yeah, bye.

01:13:41 (gentle music)

01:13:41 (dramatic music)

01:14:11 Every line in the repo, a key to set us free And now we break through on Talk Python To Me!

01:14:18 Deploy the dream Shake the ground under your feet Surge forward in the stream Python code is moving heat With Talk Python To Me We ignite the synergy Let's tear down walls, let's own the scene Deploy the dream ♪ Deploy the dream Shake the ground under your feet Search forward in the street ♪ Python code is moving heat ♪ With talk Python to me We ignite the synergy ♪ ♪ Let's tear down walls ♪ ♪ Let's own the scene ♪ ♪ Deploy the dream Shards of GML swirling in the night ♪ ♪ Argo CDs overhead guiding by its light ♪ ♪ We watch the pipeline triggers ♪ ♪ Silent countdown clock ♪ ♪ From dev to prod, we're unstoppable stock ♪ ♪ The logs are rolling in, Prometheus can see ♪ ♪ Our metrics rise like signals, a living symphony ♪ ♪ Mailog sends illusions to the test in the sky ♪ ♪ While Sentry's capturing errors with an all-seeing eye ♪ ♪ We commit, we build, we test once more ♪ ♪ Containers racing onward to the cloud's front door ♪ ♪ Resilience in the code, watch the pods come free ♪ ♪ The stage is set now on top, Python to May Deploy the dream Shatter limits that confine A brand new scheme Pushing progress down the line We're unstoppable now Calvin's leading strategy Let's break the mold, let's rewrite souls Deploy the dream Deploy the cap Offtense beat and build dealing intensity ♪ I see the server lights blinking in the distance ♪ ♪ Code commits illusion smashing with persistence ♪ ♪ Dive deep into the backlog we're forging the path ♪ ♪ Docker image at the ready time to feel the wrath ♪ ♪ Python in my veins blueprint on the screen ♪ ♪ Dev to stage to prod no in between ♪ ♪ We scale up, scale out then break the routine ♪ ♪ This is talk Python to me ♪ ♪ A new reality ♪ Toss the girls belt, belt them ♪ ♪ No code left behind ♪ ♪ We share the knowledge so all devs can find ♪ ♪ A way to unify the spark ♪ ♪ A chance to break free ♪ ♪ Join Calvin, Hendrix, Parker ♪ ♪ Let's make history ♪ Deploy the dream ♪ ♪ High voltage in our core Evolve the theme We're unstoppable once more ♪ Untalk Python to me ♪ ♪ Our voices ring in synergy ♪ Now let's ascend ♪ ♪ Let's set this free ♪ I dream

01:17:01 the dream This has been another episode of Talk Python to Me.

01:17:31 Thank you to our sponsors.

01:17:32 Be sure to check out what they're offering.

01:17:34 It really helps support the show.

01:17:36 This episode is sponsored by Posit Connect from the makers of Shiny.

01:17:40 Publish, share, and deploy all of your data projects that you're creating using Python.

01:17:45 Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.

01:17:52 Posit Connect supports all of them.

01:17:54 Try Posit Connect for free by going to talkpython.fm/posit, P-O-S-I-T.

01:18:00 This episode is brought to you by my new book, "Talk Python in Production." I've long felt that most guidance and marketing about how we need to run Python apps in production has been overly complex and expensive.

01:18:12 This book is both a look at the history of Talk Python To Me and an antidote to this overly complex cloud world.

01:18:19 Read it online and get the full book at talkpython.fm/devopsbook.

01:18:24 And to level up your Python, we have one of the largest catalogs of Python video courses over at Talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in sight. Check it out for yourself at training.talkpython.fm.

01:18:40 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:18:45 We should be right at the top. You can also find the iTunes feed at /itunes, the Google play feed at /play and the direct RSS feed at /rss on talkpython.fm. We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:19:07 This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.