Transcript: Advanced Deployment - Katie McLaughlin

I'm Carlton Gibson, joined as ever by Will Vincent.

Hello, Will.

Hi, Carlton.

And with us this week we've got Katie McLaughlin, who's a developer advocate at Google Cloud, and we've really got her on so we can grill her about Cloud Run, Google's new exciting, easy deployment thingy bop.

How are you, Katie?

It's great to come back.

I mean, I I got invited back.

This is strange.

Woo.

I do apologize.

My mum was ill and it was all anyway.

We won't discuss that.

But uh it's good to have you back on the show.

So as I said, we've we've I've been hearing about this thing called CloudRun.

Now we talk a lot on the show.

Every week deployment comes up on the show, and it's always a bit of a pain.

And I've seen a few tweets go by and say, Oh, Cloud Run is, you know, it's kind of nice and easy.

So could you tell us a bit about it?

And we'll, you know, perhaps we'll discuss that and see how it goes.

Right.

Instead of having to deploy your own Kubernetes cluster, you can deploy on a cluster that already exists.

And all you have to worry about is I want this image to run on this service.

And it can be as simple as that, or it can get a whole lot more complicated.

And for Django, it needs to be a little bit more complicated, but I have um shaved this yak for you.

And so a lot of the stuff I've been doing with Cloud Run in the last, oh gosh, I've been at Google now a year.

So um, yay!

Happy anniversary.

Um I have been working on making Django and legacy databases on serverless deployments easier to use.

Legacy databases on blah blah blah blah blah.

So you're talking about Postgres, right?

I need I need Postgres to run my Django.

Yeah.

Yeah.

You've got the Django ORM, right?

Which is

So you kind of need a relational database to get that all to work.

Um so you can click these things together.

You can set up a cloud run service and connect it to your Cloud SQL database, and then you can connect to your cloud storages and you can throw in some secrets management in there and a bit of automation with the cloud build, and you can get yourself a full Django.

If if I'm if I want to play around with it, what's the simplest way I can get it to work?

Um if you jump on my GitHub, I have a couple of services up, including a service that I wrote last year for my PyCon US talk in Cleveland, which is Ich as a Service.

So it's github.com slash glassenslash IHEN AAS.

Links in the show notes.

But there's a great big button there that says Rud on Google Cloud, and you click it and it'll deploy on Google Cloud for you.

Okay, so that's cool.

Um right, so but there's moving parts there, because you've talked about uh a database.

So Cloud SQL is like a hosted, because this is where it always comes out.

So everyone's got like, I don't know, a hosted runtime.

So I can stick it on a Rocal, or I can stick it on Azure, I can stick it on App Engine, which is Google's older hosted runtime, right?

But I need a database, I need my Postgres instance.

So I can spin one of those up quite easily.

You can click button get Postgres database, and then by adding a add cloud SQL instances parameter onto your run deploy script, you can connect the two things together.

Yeah.

Okay.

And would and would you say for playing around like I can scale I can spin up a Postgres night a really small one and I can scale it all the way up?

Because I'm a big fan of managed database services.

Yeah.

Take take take my money.

re paying money because then you're actually getting backups of your data.

Your production database lives in one place.

Make sure that it's secure and make sure that it's saved.

Why is that?

And it's the switch between two different databases there.

You specifically do not want to have developers accessing your production database, and you want to have a completely isolated local development environment.

So moving between the two is a context switch.

But with sufficiently configured uh Docker Compose configurations, you can make the two work as if they were wherever.

So you have the same web image running locally with a Docker Compose or running in production.

Using 12-factor apps, you just have environment variables that are populated either by your Docker Compose file or by secrets, and you can develop locally and develop and and and see that same developed code in production without any major changes.

So you have to use Docker though to use this, right?

So this is where it gets a little bit complicated, and I apologize if I'm getting any of these.

It's out there.

Every week, okay, every week it comes up.

But containers are a really good idea.

Containers are basically a packaging mechanism.

Do you remember Java back in the day?

I try not to.

I've heard of it.

Yeah.

A Docker container or any container is just a tarball.

Yeah.

Now, Docker is the brand name of that.

But now there are so many different containerization platforms and daemons and such that people still use Docker like you would Kleenex or Xerox.

But in essence, Cloud Run allows you to deploy containers.

And one of the mechanisms, especially if you're running locally, the most easy-to-use mechanism to create images to then run containers of is Docker.

And specifically Docker on Mac or the Docker Desktop app.

But on Cloud Run, it's using a different containerization platform.

It's using its own sandboxing so that containers can't interact with each other.

It's using OCI standard image components, but it's still a standard, so you can use whatever tooling you want for your containers.

You can use Packer, you can use all other sorts of stuff, but colloquially we still call it Docker.

And it'll probably still stick around because Docker was the first to really popularize containers.

And you like talking about packaging up and a Docker being just a sort of uh a Docker image being just a kind of tarboard.

Like we talked about the App Engine before, where you used to used to literally zip your files up and upload a zip file to Google and they'd unzip it and put it in the right place and it would run.

How would you is is App Engine still around or is it

It is what would you App Engine is older than most people might think, but it is very much one of the original platforms as a service.

You had to configure your project in a specific way with specific configuration files that would automatically get read in that t zip file and go, oh, okay, these are the configurations you want.

CloudRun is part of infrastructure as a service.

So you have a container, and the container has been programmed to do stuff as opposed to a specific configuration file that's only for App Engine.

You can take that same container and run it on CloudRun Manage, you can run it on Anthos, you can run it in your own GKE cluster, you can run it in other clusters.

And not just that, but how I found Cloud Run in all of this is I still don't know Kubernetes, and I don't have to know Kubernetes.

I have this wonderful line.

Oh, if you need to speak to someone from Google Cloud about Kubernetes here, let me introduce you to Kelsey Hightower.

Because the the trouble with this kind of modern um containerization movement is it gets ever more complex, the kind of things you need to know.

So you started off, you used to, I know FTP some stuff in the right place, and it all worked.

And then you know we had tools like Fabric and tools like Ansible and it then Terraform and then you know Kubernetes, and it's like ah, there's too much, too much, too much.

I can't learn all of that.

Yeah.

So one is on your IHAAS repo.

I was um for some reason I was I looked at the Docker um file and saw you using Alpine, and I was like, how do you use that with Django?

And then I realized it's a Flask app.

But I'm curious your thoughts on Alpine versus Slim versus full, because so full is the full big Python with all the standard library and all these things.

Alpine is the smallest version, Slim gives you a couple extras, but Slim gives you uh the Psycho PG binary driver thing that works with Postgres SQL.

And I believe you can't use it Alpine Alpine with it without some tweaks.

Um so my question is do you just default to Alpine and then when stuff breaks, add things to it?

Or because this is one of the challenges of using containers is they get really big really fast.

And so you have to be a bit mindful about what you're shoving in there, even your Python version.

This is something that I was asking, and I found out why, and now I want to share it with the world.

So you've got your full Python images, which are going to be based on a full install of Ubuntu with all the development packages you mostly need to get anything working in the Python standard library.

The slim version uninstalls a bunch of that, so it's a smaller image.

They're both base Ubuntu, or Debian, or um Buster, like there are Slim versions of that.

Alpine is a completely different base operating system with a completely different implementation of how C is compiled.

And so there are going to be issues if your Python packages haven't been compiled to the type of C that you're using.

So Alpine is good if you don't have any complex C dependencies if you're using just Python stuff or stuff that already has compiled source packages.

Yeah, I did I didn't know that.

Slim is I I was just trying to look it up.

I didn't look it up, you know, 300 and Alpine is half that.

But that makes interesting.

Okay, so it's just yeah, it's just a completely so Slim is just none of the standard library, and Alpine is a whole separate beast.

I just I'm sorry, I'm trying to find the Docker file.

Um, it's sitting somewhere on the Docker Hub somewhere.

I'm sorry, this is this is terribly nerdy.

But if you want if you wanted to shall image, you'd if you you know, if that was your concern, you'd start from Alpine and you'd you'd layer on the dependencies that you needed.

I'd start with Slim.

Right.

There's the that is Flask.

EHA as a service is a stateless application.

It has no state, no database, it uses pillow for image manipulation, and that's it.

I don't need any of the more complex requirements.

I don't need your uh Postgres binary such, I don't need complex bits in the standard library, I don't need development dependencies.

So I can use Alpine for that particular part.

For my Django as a service that I've created on Cloud Run, I use the Slim image because that has enough for me to get going, but it doesn't include the things that I don't use.

Okay, well I feel a bit better because I recommend Slim in my Django for Pros book, and um since it says pros in the title, I'm always like, I want to make sure it's still accurate.

It's just a case of this is all open source stuff, and Alpine is newer and has less coverage, basically.

I I knew about Slim, and then I think it was Jeff Triple that was like, why aren't you using Alpine?

I was like, what is Alpine?

That that that'll be helpful for people though to understand the differences because it again to Carlton's point, it's another layer of I

You get a tutorial, you you get it, and you get your app up and running, but then when you try and turn your app into a production thing, you you kind of coming back to this database thing.

And you've said something about um having a compute SQL instance, and you don't want to just spin that up from the cloud deploy to cloud run button because that's cost, whereas the you know, cloud run can be free um at low levels.

But it it strikes me that the same thing happens if you whichever platform you're on, you need this managed database instance, and so you can spin that up.

You can have that running, and that you probably might do by hand because it's a one you've got one of those for your account, and you can host multiple databases there.

I mean, you know, bigger accounts obviously they'll do more, but you can kind of treat that as a pet.

And then on top, if you've got that up and running and you know the configuration details, then you can spin up these these kind of cattle instances of this service or that service and that service, and as long as you've created the database on your Postgres server, it'll all just work nicely.

What do you think?

They can you can have a uh datastore and JAGNI, I think it was pronounced.

There was a talk in uh Hungary PyCon uh DjangoCon.

Budapest.

There was a talk in Budapest about getting Django working on App Engine with data store, which is not a relational database.

And so the things that had to work around to get the ORM to work in that setup were enough to fill an entire conference talk.

But that database, that data storage mechanism does not have an ongoing cost.

Um the free tiers and the paid-for tiers are an ongoing debate about um ease of access versus actual costs involved in providing the services.

All that aside, CloudSQL does not have a free tier.

Neither does um Azure Postgres, neither does RDS, which is Amazon's, like they're all it's all a cost.

Yeah.

Yeah.

And then for production, you have a completely separate instance.

Yeah.

And then you have to talk about media and um building and deployment pipelines and CICD and all the rest of the things that go into any mature Django project deployment.

It's not just Django.

Yeah, everybody has to serve static files eventually.

That's the leap, yeah.

Like, I can deploy a Cloud SQL database with cloud storage, with Cloud Run, and it could be running anything in the container.

It could be running Rails.

It doesn't matter, still uses the same components, still a deployment.

It could be running Django Wagtail, Django CMS, Rails, some bespoke Haskell CMS.

It could be running anything in there, but it'll still use the base components.

Yeah, yeah, yeah.

That's good.

I mean, we've got our migrate and our collect static helpers, which means that we don't have to worry about things like manually applying SQL commands during a maintenance period and all the rest of that.

But we still need to worry about things like your database schema changes when you run migrate, when there are migrations pending.

How do you handle that?

And all these other things, which

Jacob Catlin Moss gave a really good talk about the complexities of just static migration at PyCon.

Yeah.

I I reference his talk, I reference your talk, Carlton, in my what is deployment anyway talk links in the show notes.

Um blushing.

Oh, the things that you can see if you're lucky enough to get asked on this podcast.

If I just walked up to you and said, Why should I use serverless?

What's a good example of an application that serverless is perfectly suited for as opposed to going the traditional route?

Serverless applications have image manipulation.

It is something stateless where you ask it to do a unit of work and it will return a result for you.

There's no need for a database, there's no need for any sort of file backing, it's just here is an image, give me back the thumbnail.

Here is an image, turn it into a cross-stitch chart, which is what i is.

It is basic stateless image manipulation.

Yeah.

I often say, well, if if you want, you know, like an Uber app, anything that's real, you know, I try to think of real-timey examples, and those aren't perfect ones, but people can sort of understand that it feels like I don't know if it's the best example, but I think I say, like, well about Uber, you know, it's pinging back and forth constantly, it's following the car.

That's a good example where you want something more than traditional Django can give you.

But for the simplicity of listeners, yes.

But I know if I said that in a room full of people who knew better than me, they would gently correct me.

And that's fine.

Um this is

I say things and he corrects me.

There's a whole bunch of infrastructure grey beard issues where this stuff has been previously regaled to the system administrators and DBAs of your where the length of your beard is a good quality to have.

Now that things are more accessible, the communities need to ensure that they are more accepting of newcomers and beginners and such.

So a whole bunch of the things that I've done to learn is hopefully not what other people have to do to learn.

Yeah.

Which is why I present here is what is deployment, here is what you know, here is what we'll build on.

You have to spend 15 years reading the system administration handbooks and you know, learning every esoteric this and that.

It's difficult, it's hard.

Um for beginners, you've mentioned a thing called Terraform a couple of times.

Just tell our listeners what Terraform is.

So you could do a deployment where you say gcloud SQL instance create, gcloud database instance create, gcloud gcloud, gcloud, all these CLI commands.

Or you configure a Terraform manifest which you say run this.

And instead of you having to do things in a certain order and wait between steps, Terraform will go, okay, I can create the cloud storage bucket and the instance at the same time, and then once the instance is done, I can go and do the database stuff, and then you run it, and then if something changes and you run it again, it'll go, oh, this is what's changed.

It also allows you to store your infrastructure as code.

It's infrastructure as code.

Terraform happens to be one of the infrastructure as code options out there.

There's Puppet, there's Ansible, there's a few others out there, but Terraform happens to be one of the ones that I'm using at the moment that has really great Google Cloud support as well as other provider support.

So I have an example Django application, which has eight steps to be able to deploy it manually, and then step nine is, and here is the Terraform I created earlier.

Yeah, good.

And we'll we'll link to that.

What's the name of it?

Carlton, do you remember my wonderful application that I built for ORM the sequel, this talk that I gave at DjangoCon in 2018?

When I wrote that, that was around trying to describe SQL and migrating that into ORM code.

I did not deploy that myself.

That was using a platform as a service.

I didn't know how to deploy Django by myself until after I wrote that talk.

So I've taken that sample application and done all the work to deploy it manually using infrastructure as code, using managed databases, using all that, and then I put together in a sample application, which is it'll be linked in the show notes.

It is Django Demo App Unicodex, and it is an official repository on the Google Cloud Platform GitHub, which I'm very proud of because it makes me look super professional.

But the tutorial that was accepted for PyCon 2020 is let's build ourselves a serverless Django deployment, and that is the source code, which is here is the steps that you need to do to create the backing services to create this.

Here is the demo application that has things like an admin action that requires right access to the cloud storage assets.

It's got things like a file that will do the build migrate deploy steps for you.

It's got secrets management under the hood, it's got all these other bits, and there happens to be a click button get Django deployment.

It's just not as a cloud-run button because infrastructure reasons, but it is a Terraform apply.

That's how you teach infrastructure.

Well, that's how I think you should teach infrastructure.

Saying here is one we prepared earlier is different to working through it.

And it's completely different to the prerequisite for this tutorial is 15 years of data center maintenance.

Yeah, no.

I've used Terraform a bit and I've played with it and I can see, but you know, I've already got these Ansible playbooks, so I keep crafting those, but it is very much this case where you kind of come to understand something, and then you by putting it in a playbook or in a manifest, you've got it forever then, and then it's just a quick command to do that again.

I could have done this in Ansible, I've used Ansible, I could have done it in Puppet, I've used Puppet.

I happen to choose Terraform because I think that that is the most supported, most shared thing for this serverless space.

And I could spend the time to translate these playbooks, these Terraform manifests into Ansible playbooks.

In theory, it shouldn't be too hard.

The talk that I I'm one of those fancy people that had both a talk and a tutorial accepted for PyCon, and then PyCon isn't really happening, but it is happening.

So I have all these ideas and I haven't had a platform to share them yet.

Yeah.

If you already have any experience in any of these technologies and they happen to map well with Django, use that.

If you want to learn a particular technology because it's a hobby project, choose that.

Otherwise, start looking at what other people are using.

And this is how we end up with world-class Postgres support, because everyone chooses Postgres, because everyone else has chosen Postgres, and then we build on the Postgres features, and so Postgres has a lot more support in Django than MySQL.

You could use MySQL if you happen to work at a place that has an exceptional crew of MySQL administrators, then use MySQL.

It does not make sense to use Postgres in that instance.

The same arguments could be made for using any particular cloud provider, any particular infrastructure as a service.

Use what knowledge you already have access to, unless you want to try something new and then go for it.

The success criteria for a hobby project is you have made a thing, but you have also learnt so much.

Yeah.

And that means your website is up, and that means you have everyone knows how to keep it up.

So you have to converge on standards.

You don't have to, but one thing that's nice is if you are working in a professional environment, sometimes you spend weeks, months on something, and you you just feel like I'm speaking for myself.

What what am I even doing?

But then if you can build a side project for two weekends and actually get up there, you're like, oh, like I actually can sort of program because I've just spent it's helpful just for that reason.

Not to mention, of course, you learn something and then maybe it turns into something else.

But the realities of professional coding is you're just in the bowels and dealing with choices you didn't make.

And I can't even imagine what it's like at a place like Google.

I'm just thinking of startups I've been at, so

Outside of Google, people have barely heard of this stuff.

But Google is big enough that it's its own ecosystem.

Well, I guess then that would be the difference, is that it's there's ways to learn it internally as opposed to being thrown into the deep end in a startup environment where there is no hand holding.

And this is why things like sufficient documentation, sample applications, this is how I kickstart myself in smaller projects.

Um, my work in the developer advocacy and developer relations team.

I work more in the open source tooling that users use, that developers use.

I'm working for external developers, and my job title is developer advocate.

I am advocating for developers externally.

You see me in a DjangoCon and you ask me about this feature in CloudRun, and I think, oh, why hadn't we thought of that?

And I'll go and make that happen for you within the best of my ability.

Asterisk, asterisk, asterisk disclaimer.

But I advocate for developers, and so I use the tools that developers use.

And I see the rough edges and I see how we can improve products, and I make sure our documentation's up to date so people can get started quicker, and hopefully my products are the ones that are the happy side project stuff instead of the oh, I've spent two weeks and it doesn't work stuff.

I thought, and maybe others feel this way, but that in developer advocates, because we were talking before we came on air about without going to conferences, you and your peers are still just as much, if not more busy.

There is this idea that your job is to give talks when, as you said, it's really so much of it as the opposite, is to go to these conferences to talk to developers, take that perspective, and then feed it into your emp your company and try to change it that way instead of just the other way.

I hadn't really thought of it that that way.

That makes more sense to me.

We now get to work together, and Aja had this amazing thread a couple of days ago now, talking about how developer advocates, even though they don't have conference stages anymore, we are still busy, if not busier, than what we have always been.

Because the public-facing stuff that you see, even for somebody who just does talks, is just scratching the surface the amount of work we do.

So I am, even though I'm not traveling to conferences and talking on stage anymore, I am in meetings with product managers, I am writing friction logs, I am doing bug reports, I'm putting in pull requests to fix things.

I am working behind the scenes to make things better, even though you're not seeing me on a stage right now.

I forget, did were you uh in an advocate role before, or you were more pure engineering?

But I'm also drawing on my more than a decade of developer experience any time that I sit in with a meeting with a new human being.

Um I guess that was the broader question.

Like, did you have a sense that this the things that you spend your time on were the things that you would spend your time on?

I mean, you knew about the conferences part, but all the rest of it

It's always more complicated than that.

But in essence, I it is not a 100% travel job.

I am not always at conferences, even though it might appear to be.

I am advocating internally and externally.

I am working with Google engineers and external engineers and customers and clients and enterprises and all manner of people just to try to make things better.

Well, I wanted to ask about the lunches, right?

You work at Google.

I heard I heard the lunches of something else.

Is that true?

We used to have a sales rep and we would go there just for the lunches.

There's nothing to talk about.

They're just like put bigger ads in your site.

Like, how about we get lunch and talk about it?

But I also worked from home for a while before getting the free lunch, and it is a corporate cost that has been managed to the point where they save so much money by making sure that engineers don't have to go off and find their own lunch or bring it in from home.

Oh, the the cafe in the the New York office.

Oh my god.

I mean, hello, I'm back.

Yeah, yeah, no,

that's what I want.

So if you've got a jet some for the show notes, we're gonna have um the the get started with cloud run, the here's your Django project example, here's your one with full Terraform script.

We're gonna have all those examples in the show notes.

My tutorial has turned into let's let's embark on this big three-hour thing.

No, we're just gonna run through the GitHub because like it's like I'm just going to do a here is the GitHub tutorial, but have it like running it running it through with you as my tutorial and links all in the doobly-doo.

Um, what other links were there?

Arja Hamily's tweet, definitely.

Um, tweets to the Py Gotham talk, tweets to your talk.

You were both in the footnotes for my deployment talk, by the way.

Uh oh, what do we do?

What did I do?

Yeah, yeah, yeah.

Um then um I specifically referenced the deployment episode of Django chat.

There you go.

Very nice.

Yeah.

No, it's like we all learn from each other.

Yeah.

And I've learned so much from like I bought your book, Will, and I learned stuff from it.

Um I think you said something about learning something during it, and I was like, ah, okay.

I just I just mush things together and they sometimes work.

Um I think

If you look it up, I think that is the definition of a Django developer.

Um I will say though that one of the things I've been able to contribute back with all my talk about deployment and stuff is I've actually got some documentation commits that have been successfully merged that improves the landing page for deployment on Django Project.com, which I'm pretty proud of.

It's like go go to where the developers are, fix the documentation.

Like if you found that something's wrong, then getting on your soapbox isn't gonna see it.

It's that it might just be kind of old in that it was created.

Exactly.

And we are only as good as what we put out into the world.

And I apologize for calling it wrong.

It is merely no longer best practice.

Yeah, it is it is still accurate, but it could be improved upon.

Yeah, and that's what I'm saying.

And that's

Yeah.

Yeah.

And yeah.

How do you explain the patterns to someone who's learning all this stuff for the first time?

Because it's easy enough to say, well, there's prototype, there's something in the middle, and then there's just huge chasm of who knows what, and then you're in pr professional land.

Is there a way to break that up and and give a sense of what that looks like?

Um that's something I've been thinking a lot about going forward, because I'd like to narrow that chasm, but the reality is that jump to professional land, it's like at what point does it become totally subjective?

And at what point do you say, well, we could broadly agree you probably use Gunicorn or you can use white noise, but then we hit a certain point and then it's just like everyone's different.

Like, how far can I take people up the Django specific curve and say you probably are gonna use these before we get custom land?

That's something I'm thinking about, anyways.

In the context of my Django X starter project, you can go take a look.

Because I hold back so much in that project.

I don't want it to be cookie cutter, which is fantastic, but it's a different beast.

I want it to be something you can learn from, but it means there's 20, you know, half the packages that are in the Django for Pros book, and there's another 20, I would add, if it was my personal starter project that I was spinning up for clients.

You've hit the nail on the head.

Links in the show notes, but there is part of the Django documentation that has not changed for at least a decade now, hidden in the how-to of static files deployment serving static files in production.

Every production setup will be a little bit different.

Every single production setup I have ever seen has been different.

The reasons are many and varied, but every single production setup has been a little bit different, which is why we need these options of choice.

But as Carlton said earlier, it used to be that you would copy files up to an FTP site, you'd do some a database SQL script, and then you'd restart your web server.

Deployment is updating the code, making some possible database updates, making some possible static updates, restarting your web server.

That is deployment.

How you go about that is more than a talk, more than a podcast.

There are multiple conferences about little small aspects about this.

The second last slide of my talk lists topics that I did not cover that each are their own conference.

It's sort of like you it's almost like a like I had a fantastic professor teaching me accounting of all things who he would answer every question, but he would say as an aside.

So like I will answer this question, but I don't expect you to know it.

And I really love that distinction of like answering it, but just making clear, like, this maybe is not what you need to know right now.

I'm not gonna hide things from you, but I'm not gonna overwhelm you on purpose either.

But this Django tutorial has so many asides, so many little edge cases, that I had to write a code lab recently, and it's like, oh, I'm not allowed to have all these asides?

Okay, but how can I teach things without story time with Katie?

And there are so many different ways to tell these stories.

My Unicodex tutorial is one way to tell this story and to teach infrastructure.

Hopefully by the end of it, you get the sample application deployed, but if you've learned just one thing new, then my job is done.

It's uh quite a bit harder, but I think more helpful to say, here is this broad problem, let me try to go to the building blocks of it.

I will mention our solution, but I'll provide some insight onto this general problem that exists in our space as developers.

Those are the I mean, selfishly, those are the kind of talks I like to see, and I think those are But those are rarer because those are a lot, it's a lot hard more work to take those extra steps and pull yourself out of you know your own uh day-to-day stuff, which is in which is super interesting too, but to try to generalize it and perhaps come to ideas around, well, why do we do it this way?

There is so much that can be said on these topics, and I always err on the side of every production setup will be a little bit different.

Because no, I have this wonderful line at some point during my talk where I say, every production setup will be a little bit different.

Hopefully I've taught you something, but the worst case is if I've suggested something that doesn't work for you, don't do it because I'm not gonna be around after this talk is finished.

You're the one that's gonna have to maintain this, so you have to understand what it's doing, and you have to do what's right for your system.

Because I'm not an on-call engineer anymore.

I can tell you all manner of things that you should be doing, but I also have an obligation in my heart to make sure that I'm not telling you things that are gonna wake you up at 3 a.m., which is another talk that I've given.

All my talks meld into each other.

There'll be an anthology one day, and you'll be able to trace the timeline of what I've learnt through all these different talks through the years.

They all blend into each other.

in the morning.

this morning before there's other reasons.

Is there anything else ways people to get in contact with you?

Yeah, like I am contactable on Twitter.

My email is really easy to find.

Um I am always approachable at conferences when we are all able to go to conferences again.

Depending on when this podcast hits your wonderful ears, dear listeners, whether this be a past recording that you've listened to or fresh off the press, I have a talk up there called What is Deployment Anyway?

And a tutorial called Deploying Django on Serverless Infrastructure.

Okay, super.

Um thank you so much for coming on for teaching us, teaching me about many of these terms I just heard about and and then learning about yeah, learning about Alpine and Slim too.

That's sort of blowing my mind a bit.

And so thanks for coming on.

It's really good.

You never stop learning.

And don't beat yourself up just because you don't know, because no one knows everything.

Thank you for having me on again.

We'll see you in a year.

Bye bye.

Bye.