Transcript: Advanced Deployment - Katie McLaughlin

Hello. Welcome to another episode of Django Chat, the weekly podcast on the Django web

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

Hi, Carlton.

Hello, Will. 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 since we can grill her about Cloud Run,

Google's new, exciting, easy deployment thingy-bop. How are you, Katie?

I'm great Carlton it's great to come back I mean yeah I got invited back this is strange

you're our first repeat guest yeah well I missed you last time I'm afraid I do apologize my mom

was ill and it was all anyway we won't discuss that but 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 cloud run now we talk a lot on

the show every week deployment comes up on the show and it's always a bit of pain and I've seen

a few tweets go by to say, oh, Cloud Run, it's kind of nice and easy. So could you tell us a

bit about it? And perhaps we'll discuss that and see how it goes. Right. Well, Cloud Run is one of

the newest options for serverless things in the cloud, specifically Google Cloud, and it's hosted

containers. 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 dango 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 hang on you just said that was a big sentence legacy

databases on legacy databases on serverless compute right okay so you're talking about

postgres right i need i need postgres to run my django yeah yeah you can use graphql you can use

these no sql things but postgres is pretty cool still i'm just saying you've got the django orm

right which is yeah yeah 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. Is there a button I can click that does all that for me? Yeah, that was

my question. If I want to play around with it, what's the simplest way I can get it to work?

There is. 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 as a service so it's github.com

slash glasses slash ih hyphen aas links in the show notes but there's a great big button there

that says run on google cloud and you click it and it'll deploy on google cloud for you fantastic

okay so that's cool um right so but there's moving parts there because you've talked about

a database so cloud sql is like a hosted because this is where it always comes down so everyone's

got like i don't know a hosted runtime so i can stick it on a roku 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 yes 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 right and that's quite easy yeah okay and would you say for

playing around like i can scale i can spin up a postgres and a really small one and i can say

all the way up because i'm a big fan of managed database services managed databases are so good

as someone who used to have to spend an insubordinate amount of time

trying to maintain them, having someone do that for me

and paying them for that is like short, done.

Take my money.

Because it's backups and updates and everything.

And maintenance and yeah.

And funny you should mention all this stuff

because I have just recorded my PyCon talk,

which is what is deployment anyway,

where I talk about the virtues of managed databases

and all other sorts of wonderful deployment stuff,

where I mentioned that managed databases

are probably the only thing you end up having to pay for

in a serverless setup

because everything else has a free tier.

But your managed database,

it's really, really good that you're paying money

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

Yeah, I was going to say backups, yeah.

Yeah, like your code is going to live on your laptop.

It's going to live on GitHub.

It's going to live on GitLab.

it's going to live in multiple places your production database lives in one place make

sure that it's secure and make sure that it's saved yeah and that's something that maybe because

i deal with beginners all the time i still to this day get questions of you know i added stuff

locally in my django app and then i don't see it live why is that and it's the switch between

two different databases there yeah it's environment isolation 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 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 see that same developed code

in production without any major changes so a couple of things you mentioned there thinking

of carlton so you have to use docker though to use this right you don't have to so this is where

it gets a little bit complicated and i apologize if i'm getting any of these benefits of docker

i've got this reputation now it's being anti-dog i like dog it's out there it's out there is there

is there a previous episode that i should have listened to to hear more about this every week

every week it comes up i'm not commuting at the moment so i apologize that i haven't been

listening as religiously as i once had that's okay that's okay but containers are a really

good idea containers are basically a packaging mechanism do you remember java back in the day

i tried not to i've heard of it when you package up and release a java application

you're sending around dot jar files yeah they're just zips a docker container or any container is

just a tarball yeah it's just a collection of files that does stuff 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 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 okay and you like talking about packaging up and docker

being just a sort of a docker image being just a kind of table like we talked about app engine

before we 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 app engine still around or

is it it is definitely around 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 zip file and go, oh, okay, these are the configurations you want. Cloud Run 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 Cloud Run Manage. You can run it on Anthos. You can run it in your

own GKE cluster. You can run it in other clusters. And that's what's so nice, I think, the portability

of doing the container approach. Yeah. 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. Right. That's the trick.

oh and i'm absolutely okay to say this 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 that's the nice thing right because the the trouble with this kind of modern um

containerization movement is it gets ever more complex that's 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 Terraform.

And then, you know, Kubernetes is like, ah, it's too much, too much, too much.

I can't learn all of that.

And you shouldn't have to, which is why, like, you could spend the time to create a resilient, robust, multi-node, high availability Postgres cluster.

Or you can pay for one.

Yeah.

Same with Kubernetes.

So I have two nerdy questions for you.

so one is on your ihas repo yeah 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 postgresql and i believe you can't use it alpine with it without some tweaks

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 i'm so

glad you asked this question. 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

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.

Interesting. Yeah, I didn't know that.

I mean, because the quick and dirty I took away was that the standard Python Docker image is like 700 megabytes or something like that.

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

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 so it's not not the standard library 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 that's fine but if you want if you want a small image you if you know that was your

concerned you'd start from alpine and you'd layer on the dependencies that you needed

i start with slim i would start with slim right and yet you're using alpine here

ah so that particular one is flask there's that is flask e 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 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.

right 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

hang on this pro is using alpine what's the matter

so you can it's just a case of this is all open source stuff and alpine is newer and has less

coverage basically yeah it's i first heard about alpine i i knew about slim and then i think it

jeff triplett was like why aren't you using alpine it's like what is alpine geez it's like half the

size like so okay good that that'll be helpful for people though to understand the differences

because again to carlton's point it's another layer i wanted to come back slightly to this

idea about um database because i think i think deployment quite often looks kind of simple 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 can't 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 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

there's a reason why graphql and nosql databases exist because they do not require

the infrastructure that something like postgres does they can you can have a data store and

jagni i think it was pronounced there was a talk in uh hungary pycon uh django con 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.

Right, so you can spin that up whenever.

So, you can spin it up whenever.

The free tiers and the paid-for tiers

are an ongoing debate about ease of access

versus actual costs involved in providing the services.

All that aside,

Cloud SQL does not have a free tier.

Yep, neither does Azure Postgres,

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

Yeah.

But with sufficient database manipulations, you could have a development project, like a Google Cloud project and Azure project with one Postgres instance, and then multiple databases where the developers have access to only one database, multiple databases in an instance.

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

You can set all this up, but this is where it gets difficult because that's just the database.

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

Any mature project, right? It's not just Django.

Yeah.

Everybody has to serve static files eventually.

That's the leap. That's the leap, yeah.

And that's the good thing is that these problems are not unique to Django.

Therefore, there are robust generic solutions that Django can leverage, which makes it really great that we're all sharing these common resources.

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.

It 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.

Okay, fine.

That's good.

And so the lessons that other places have learned about deployment

is something that Django Nauts can learn from.

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.

They're not trivial questions, right?

They're not.

They're not.

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 i'm blushing there are it's funny dear viewers because

i can see that carlton's blushing because we're on a video call

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

so as a slight digression i had a question for you around so you're as a developer advocate 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

it's really terrible but the canonical like react applications have their to-do list

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 it is it is basic stateless image manipulation

That makes sense. Yeah. Well, because of the same token, you know, with why should you use channels or, you know, what's the hubbub about async and Django? I often say, well, if you want, you know, like an Uber app, anything that's real, you know, I try to think of real time 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.

Yeah, this is getting into a more complex topic where there are certain terms in there that I wouldn't have used together.

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.

that's Carlton's role in this podcast I say things and he corrects me oh bless

or he just blushes at me and I get the message the ish there's a lot of issues here there's a

whole bunch of infrastructure gray 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 which is why i present here is what is

deployment here is what you know here is what we'll build on no i mean there's there's a massive

like yeah this idea of a rite of passage 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

of listen is what terraform is for beginners terraform is infrastructure as code so you could

do a deployment where you say gcloud sql instance create gcloud database instance create gcloud

gcloud you've got 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 yeah it also allows you to store

your infrastructure as code it's infrastructure as code terraform happens to be one of the

the infrastructure as code options out there.

There's Puppet, there's Ansible,

there's a few others out there,

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. Nice. And we'll link to that. What's the name of it?

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

I was watching the video for that by the other day because I was busy searching through the archives, but I don't remember the name of the application.

it was a little application that would show you different emoji as they evolved on different

phones and desktop um as they evolved on different phones and operating systems and the like

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 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 a 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

a cloud run button because infrastructure reasons but it is a terraform apply yeah right okay and

there's an eight-part shell script that is on the side but learning how these things connect

together why things are the way they are and then going in here is one i prepared earlier 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 yeah no i mean

good for you but but no yeah no i mean yeah it's so i mean i'm a big ansible user 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 exactly i could have done this in ansible i've used ansible

i could have done 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 playbook these terraform manifests into ansible playbooks in theory

it shouldn't be too hard yes in theory in theory so would you recommend like so somebody who's

facing deployment issues you recommend learning one of these technologies like you know whichever

one so this is where i have opinions 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 but you have now

I've already given the deployment talk at PyGotham links in the show notes but what I say in there

is when you have to choose things for deployment your number one choice should be what are your

co-workers or co-collaborators using 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 yeah 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 learned

so much yeah in a in a professional context this is the success criteria is making money basically

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 I think that's partly why and there's many reasons to do side

projects 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 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 if I was an engineer at Google, I would be using tried and tested technology that

every other engineer at Google knew and knew how to teach me. And there is infrastructure in place

to learn this technology outside of google people have barely heard of this stuff but google is big

enough that it's its own ecosystem right well i guess 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 exactly 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 at a django con

and you ask me about this feature in cloud run 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 null and void in the states of 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 is 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 well i like how you phrase that because i hadn't actually thought of it 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 is the opposite is to go to these conferences to talk to developers take that perspective and

then feed it into your company and try to change it that way instead of just the other way. I

hadn't really thought of it that way. That makes more sense to me. Several years ago now, I was

one of the headline keynotes at Ruby Conference Australia. And one of the other headline keynotes

was a wonderful human being called Aja Hamily. 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 and this is you've been

to google a year i forget did were you an advocate role before you were more pure engineering i was

pure engineering with a terribly expensive traveling hobby so you combine the two yeah

i i get well before everyone was shut-ins um i was able to convert my hobby into a full-time role

which is awesome 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.

Well, because I was going to ask if the role kind of met your expectations going in.

I guess that was the broader question.

Did you have a sense that 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.

The descriptions that I was given are definitely the descriptions I would give out.

It's always more complicated than that.

But in essence, 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.

What else?

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

You work at Google.

I heard the lunches are something else.

Is that true?

I've had lunches at Google.

Well, 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 on your site.

How about we get lunch and talk about it?

I've been working from home for a month now and there is definitely an overhead of having

to feed yourself.

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

right yes yes the food is absolutely exquisite oh the the cafe in the the new york office oh my god

i mean hello i'm back

okay so you're going to give us um some links on um how to get started right so if you've got

some for the show notes we're going to have um the get started with cloud run the here's your

django project example here's your one with full terraform script we're going to have all those

examples in the show here is the link to last year's talk django con talk um example flask

click button get application example project for the full django thing which is the same content

that will be my tutorial my tutorial has turned into let's let's embark on this big three hour

thing no we're just going to 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 arthur hammerley's tweet

definitely um tweets to the pie gotham talk tweets to your talk you were both in the footnotes for

my deployment talk by the way me yeah both of you oh how come yeah carlton's carlton's a django

fellow what did i do like i know which talk i referenced your hacking the hdp headers

hdp headers and littleware talk yeah yeah handlers that one yeah um last year yeah um

um i specifically referenced the deployment episode of django chat oh okay very nice

yeah it's in my references so i'll link to the references for my talk as well because all my

talk slides very circular yeah no it's like we all learn from each other and i've learned so much

from like i bought your book well and i learned stuff from it yes you tweeted some very very nice

things like in the initial days when i was extremely fragile about it um i think you said

something about learning something during it and i was like ah okay it's okay i'm not a django

developer i just i just mush things together and they sometimes work um i think that might

actually be the definition if you look it up i think that is the definition of a django developer

mushing things together there's a reason 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 jangoproject.com which i'm pretty proud of yeah no thank you for making those

because they do make all the difference i do need to go back and check whether they all got merged

but it's those things that i think makes developer advocates like this the skills that developer

advocates learn things like instead of just giving a talk on a thing committing a an upstream change

to change the base documentation to suggest this different thing it's like yeah go to where the

developers are fix the documentation like if you found that something's wrong then getting on your

soapbox isn't going to see it that it's wrong it's that it might just be kind of old in that it was

created it's no longer right and mod whiskey was the way and so much has changed since you know

those days i mean i know there's more whiskey express still going but like you know things

have moved on and those differences don't necessarily get reflected in the documentation

so when somebody comes along and takes the time to make that pr to the documentation all of a sudden

that's just gives it a refresh for everybody 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

it is it is still accurate but it could be improved upon yeah and that's always the case right yeah

yeah and if it means that one less person has to work that out for themselves then my job is done

Yeah. Well, I think it's great that you're doing this deployment education because part of what I've been thinking about recently is, you know, how do you explain deployment? 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 a huge chasm of who knows what, and then you're in professional land. Is there a way to break that up and give a sense of what that looks like?

That's something I'm 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 Kunicorn, 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 going to 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. Here's the really great thing.

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 and 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 of their own conference

yeah and yet it so it's it's how do you explain this to people without overwhelming them

It's sort of like, it's almost like, 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 going to hide things from you, but I'm not going to overwhelm you on purpose either.

One of the things that I've learned over years of crafting talks is that you can only say so

many words in half an hour. 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 i like that you also have a you're not

assuming a huge amount of knowledge because it's easier to just say this is a problem we had at

work and this is how we solved it it's 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 more work to take those extra

steps and pull yourself out of you know your own uh day-to-day stuff which is 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 this talk has like every time i give it i update my opinions about what i should be

teaching 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 going to be around after this talk is finished you're

the one that's going to 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 could 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 going to 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 learned through all these different

talks through the years they all blend into each other surely most of them come back to don't

get woken up at 3 a.m in the morning like that's the kind of the holy well i was up at 3 a.m this

morning before there's other reasons yeah but you've deployed a child that's slightly different

thing i was gonna say deployments a little bit like children they're related to you but they're

all different and you just go that's just how it is the ongoing maintenance though i hear is a

hassle but you know i find them a little more loving than my code is but you know is there

anything else, ways people to get in contact with you? I would put my doobly-doo in the

descriptions. I am contactable on Twitter. My email is really easy to find. 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

listen 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 both happen to be

about django well they hit our demographic exactly

well we'll have maybe more links we've had for any show for this one

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 i know like deployment is just such a big topic for all of our listeners

and for us and for you and so thanks for coming on it's really good i've been a system administrator

for nearly a decade now and i learned stuff even today 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 no thank you for coming on we'll see you in a year as ever everyone we're at chat

jango on twitter jango chat.com and we'll see you next week join us next time bye