Katie is a Developer Advocate for Google and regular conference speaker. We discuss advanced deployment techniques and tools such as Google Cloud Run, relational vs non-relational databases, Terraform, and more.
Carlton Gibson 0:06
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 Halliwell. Hi, Carlton. Hello. And with us this week, we've got Katie McLaughlin, who's a developer advocate at Google Cloud. And we've really got to run since we can grill her about cloud run Google's new, exciting, easy deployment. Thank you, Bob.
Katie McLaughlin 0:26
How are you, Katie? I'm great, Carlton. It's great to come back. I mean, yeah, I got invited back. This is strange.
Will Vincent 0:34
Your first repeat guest.
Carlton Gibson 0:37
Yeah, well, I missed you last time. I'm afraid. I do apologize. My mom was ill. 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, say all cloud run this, you know, it's kind of nice and easy. So Could you tell us a bit about it? And we'll Yeah, we'll discuss that and see how it goes.
Katie McLaughlin 1:04
Right? Well, collaboration 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 Django, it needs to be a little bit more complicated, but I have 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. Yay, Happy anniversary. I have been working on making Django and legacy databases on serverless deployments easier to use.
Carlton Gibson 1:59
Hang on, you just said That was a big sentence legacy databases on the
Katie McLaughlin 2:03
legacy databases on serverless. Compute.
Carlton Gibson 2:06
Right? Okay. So you're talking about Postgres, right? I need I need Postgres to run my Django. Yeah,
Katie McLaughlin 2:11
yeah. You can use graph QL. You can use these no SQL things. But Postgres is pretty cool. Still.
Carlton Gibson 2:22
Just got the Django ORM. Right, which is, yeah,
Katie McLaughlin 2:25
yeah. So you kind of need a relational database to get that to work. 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 storage. 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.
Carlton Gibson 2:46
Is there a button I can click with?
Will Vincent 2:50
That was my question. If I'm, if I want to play around with it, what's the simplest way I can get it to work?
Katie McLaughlin 2:55
There is if you jump on my GitHub, I have a couple of sentences up Including a service that I wrote last year for my Python us talk in Cleveland, which is he as a service, so it's github.com slash plugins slash i h hyphen as 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 play on Google Cloud for you.
Carlton Gibson 3:21
Fantastic. Okay, so that's cool. Right? So but there's moving parts that because you've talked about a database of 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 Roku, or I can stick it on a zoo, or I could stick it on App Engine, which is Google's all the hosted runtime, right? But I need a database. I need my Postgres instance. So I can spin one of those up quite easily.
Katie McLaughlin 3:49
Yes, you can click button, get Postgres database. And then by adding a add Cloud SQL instances parameter on To your run deploy script, you can connect the two things together.
Carlton Gibson 4:05
Right? And that's quite easy. Yeah. Okay. And what would you say for playing around like I can scale, I can spin up a Postgres nine, really small one, and I can send it all the way up because I'm a big fan of managed database services.
Katie McLaughlin 4:17
Manage databases are so good, as someone who used to have to spend a insubordinate amount of time trying to maintain them, having someone do that for me. And paying them for that is like short done, take take my money, because it's
Carlton Gibson 4:35
backups and updates, everything
Katie McLaughlin 4:37
and maintenance. And yeah, and funny, you should mention all this stuff because I have just recorded my PI con talk, which is what his deployment anyway where I talk about the virtues of managed databases and all other sorts of wonderful deployment stuff, where I mentioned that manage databases are probably the only thing You'll end up having to pay for in a server 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
Will Vincent 5:12
by, say backups. Yeah,
Katie McLaughlin 5:13
yeah. Like your code is going to live on your laptop. It's going to live on GitHub. It's going to live on get lab, it's gonna live in multiple places, your production database lives in one place, make sure to secure and make sure that it's saved.
Will Vincent 5:29
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.
Katie McLaughlin 5:45
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 to 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 see that same developed code in production without any major changes.
Will Vincent 6:31
So a couple of things you mentioned, they're thinking of Carlton, so you have to use Docker though, to use this, right?
Katie McLaughlin 6:36
You don't have to.
So this is where it gets a little bit complicated and I apologize,
I'm getting nothing the benefits of Docker was he still
Carlton Gibson 6:47
got this reputation.
Will Vincent 6:49
Like it's out there. It's our
Katie McLaughlin 6:52
previous episode that I should have listened to to hear about this
Carlton Gibson 6:56
Katie McLaughlin 7:00
Not computing at the moment. So I apologize that I haven't been listening religiously as I want. Okay,
Will Vincent 7:05
Katie McLaughlin 7:06
But containers are a really good idea containers are basically a packaging mechanism. Do you remember Java?
Carlton Gibson 7:15
I tried not to get heard of it.
Katie McLaughlin 7:18
When you package up and release a Java application, you're sending around JAR files. They're just zips, a Docker container or any container is just a terrible 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 will clean x 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 off 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.
Carlton Gibson 8:43
Okay. And you like talking about packaging up and Docker being just a sort of a Docker image being just a kind of tarball like, we talked about App Engine before used to used to literally zip your files up and upload a zip file to Google nowadays. unzip it and put it in the right place now, right? How would you is App Engine still around or it is
Katie McLaughlin 9:05
definitely around it is what, which is, 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 Gk cluster, you can run it in other clusters.
Will Vincent 9:51
And that's what's so nice. I think the portability of of doing the container approach.
Katie McLaughlin 9:55
Yeah, and not just that, but how I feel Cloud running all of this is I still don't know Kubernetes. And I don't have to know Kubernetes.
Carlton Gibson 10:08
Right. That's the trick.
Katie McLaughlin 10:11
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
Carlton Gibson 10:22
because that's the nice thing, right? Because the trouble with this kind of modern containerization movement is it gets evermore complex. That's the kind of things you need to know to 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 then terraform. And you know, Kubernetes is that was too much, too much, too much. I can't learn all of that.
Katie McLaughlin 10:48
And you shouldn't have to know which is why, like, you could spend the time to create a resilient robust multi node high available Ability Postgres cluster, like knife one. Yeah. Same with Kubernetes.
Will Vincent 11:05
So I have two nerdy questions for you. So one is on your H. A s repo. Yeah, I was, um, some reason I was I looked at the Docker file inside of using Alpine and I was like, how do you use that with Django and then I realized it's a flask app. curious your thoughts on Alpine versus slim vs 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 the psycho PG binary driver thing that works with Postgres sequel, and I believe you can't use it. Alpine 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.
Katie McLaughlin 12:00
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 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 complexity dependencies if you're using just a Python stuff or stuff that already has compiled source packages.
Will Vincent 12:58
Interesting. Yeah, I didn't Know that it will and I mean, because the quick and dirty I took away was that the standard, you know, Python Docker images like 700 megabytes or something like that. Slim is 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, just a completely. So slim is just know the standard library in Alpine is a whole separate beast.
Katie McLaughlin 13:20
So it's not not the standard library. I just I'm sorry, I'm trying to find the Docker file. It's sitting somewhere on the Docker Hub somewhere. I'm sorry, this is this is terribly nerdy, that's fine.
Carlton Gibson 13:35
But if you want to limit you, you know if that was your concern, you'd start from Alpine and you you'd layer on the dependencies that you needed.
Will Vincent 13:43
I start with slim,
Katie McLaughlin 13:45
I would start with slim,
Will Vincent 13:46
right. And yet you're using Alpine here.
Katie McLaughlin 13:49
So, yeah, that particular one is that is floss as a service is a stateless application. It has no state, no database. It uses pillar 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 of 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.
Will Vincent 14:34
Right? Okay, cool. I feel a bit better because I recommend slim in my Django for pros book and since it says pros in the title, I'm always like, want to make sure it's still accurate all this pros use and what's about
Katie McLaughlin 14:49
so you can it's just a case of this is all open source stuff and Alpine is newer and has less coverage. Basically
Will Vincent 14:58
its first heard about it. I knew about slim and and i think was Jeff Triplett was like, why aren't you using? Like, what is Alpine Jesus, like half the size like? So okay, good that that that'll be helpful for people that understand the differences because it again to Carlton's point. It's another layer,
Carlton Gibson 15:15
I wanted to come back slightly to this idea about database because i think i think deployment quite often looks kind of simple. You get a tutorial, 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 keep coming back to this database thing. And you've said something about 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 at low levels, but it strikes me that the same thing happens if you whichever platform you're on, you need this manage 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 that I mean in a 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 will just work nicely. What do you think
Katie McLaughlin 16:24
there's a reason why graph qL and no SQL databases exist? Because they do not require the infrastructure that something like Postgres does, they can. You can have a data store and jagged knees. I think it was pronounced. There was a talk in Hungary pi con, Gen Con Budapest. There was a talk in Budapest about getting Django working on App Engine with data store, which is not a relational database. 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. Yeah, but that database, that data storage mechanism does not have an ongoing cost, right. So you can spend on whenever you can spend 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.
Carlton Gibson 17:38
Yep, neither does your Postgres, neither does RDS, which is Amazon's, like they're all a cost.
Katie McLaughlin 17:46
Yeah. But with sufficient database manipulations, you could have a development project, like a Google Cloud project and as your project with one Postgres instance, and then multiple data bases where the developers have access to only one database, multiple databases and 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 ci CD and all the rest of the things that go into any mature Django project,
Carlton Gibson 18:29
or a mature project, right. It's not just Django. Yeah, everybody
Will Vincent 18:32
has to serve static files eventually. That's the, that's the leap. Yeah.
Katie McLaughlin 18:36
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 we'll still use the base components.
Carlton Gibson 19:22
Okay, fine, that's good.
Katie McLaughlin 19:25
And so the lessons that other places have learned about deployment is something that Django notes can learn from. I mean, we've got out migrate and 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 are the things
Carlton Gibson 19:55
which are not trivial questions, right?
Katie McLaughlin 19:57
They're not they're not check it out. Most gave a really good talk about the complexities of just static migration at pi con. Yeah, I referenced his talk. I reference your talk, Carlton. In my what is deployment anyway talk links in the show notes
Carlton Gibson 20:18
on blushing Roz.
Katie McLaughlin 20:19
It's funny debuts because I can see that Cotton's blushing because we're on a video call it the things that you can see if you're lucky enough to get asked on this podcast.
Will Vincent 20:33
So it's a slight digression. I had a question for you around. So you're 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?
Katie McLaughlin 20:48
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 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's an image, give me back the thumbnail. Here is an image turn into a cross stitch chart, which is what is this? It is basic stateless image manipulation. That makes sense.
Will Vincent 21:23
Yeah. Well, because of the same token, we know with Why should you use channels or you know, what's the hubbub about async? In Django, I often say, Well, if, if you want, you know, like an Uber app, or 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 feels like I don't know if it's the best example but I think I say like, well, that 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
Katie McLaughlin 21:53
Yeah, this 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, 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. This is
Will Vincent 22:16
that's Carlton's role in this podcast, I say things and he corrects me.
Katie McLaughlin 22:20
Will Vincent 22:23
Or he just blushes at me and I get the message.
Katie McLaughlin 22:26
The issue, there's a lot of issues here. There's a whole bunch of infrastructure graybeard issues where this stuff has been previously regale 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, that communities need to ensure that they are more accepting of newcomers and beginners and such. So a whole bunch of the things 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,
Carlton Gibson 23:15
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. For beginners, you've mentioned a thing called terraform. A couple of times, just tell our listeners what terraform is,
Will Vincent 23:36
Katie McLaughlin 23:37
terraform is infrastructure as code. So you could do a deployment where you say, G Cloud SQL instance, create g cloud database instance, create G, cloud G Cloud, you got all these COI 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 infrastructures, code. terraform happens to be one of the infrastructures, 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 providers 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's the terraform I created earlier.
Will Vincent 24:53
Good. Nice, and well, we'll link to that. What's the name of it?
Katie McLaughlin 24:58
That was Carleton to your friend of my wonderful application that I built for ORM. The sequel, this talk that I gave at Django con in 2018.
Carlton Gibson 25:10
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.
Katie McLaughlin 25:18
It was a little application that would show you different emoji as they evolved on different phones and desktop. As they evolved on different phones and operating systems in the like, when I wrote that, that was around trying to describe SQL and migrating that into o RM 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 brought that talk. So I've taken that sample application and done all the work to deploy it manually using infrastructures, code using management 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, uni Codex. 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. The tutorial that was accepted for pike on 2020 is let's build ourselves a several as Django deployment. And that is the source code, which is, here's 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 I 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 known as a cloud Run button because infrastructure reasons, but it is a terraform apply.
Carlton Gibson 27:10
Yeah, right. Okay.
Katie McLaughlin 27:11
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 go? 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's one we prepared earlier is different to working through it. And it's completely different to the prerequisite for this tutorial is 50 years of data center maintenance. Yeah, no, yeah, no,
Carlton Gibson 27:39
no, yeah. No, I mean, yeah, it's. So I mean, I'm a big Ansible user. I'm used to terraform a bit and I play with it, and I can see but you know, I've already got these Ansible playbooks. So I keep crafting notes, 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. And then it's just a quick command to do that again,
Katie McLaughlin 28:03
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.
Carlton Gibson 28:27
Yes, in theory,
Katie McLaughlin 28:29
Carlton Gibson 28:31
So would you recommend like so somebody who's facing deployment issues, you recommend learning one of these technologies, like, you know, whichever one
Katie McLaughlin 28:41
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 except for Python. And then Python 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
Carlton Gibson 28:58
you have now
Katie McLaughlin 29:00
Haha, I've already given the deployment talk at pi Gotham 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. 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 my SQL, you could use my SQL. If you happen to work at a place that has an exceptional crew of my SQL administrators then use my SQL. It does not make sense to use Postgres in that instance. The same arguments could be made for using any particular cloud provider or 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. 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.
Will Vincent 30:37
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 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 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
Katie McLaughlin 31:17
if I was an engineer at Google, I would be using tried and tested technology that every, every other engineer at Google knew, I 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 its own ecosystem.
Will Vincent 31:38
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.
Katie McLaughlin 31:47
Exactly. And this is why things like sufficient documentation sample applications. This is how I kickstart myself in smaller projects. My work in the developer advocacy and Developer Relations team is work more in the open source tooling that users use the 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 asked 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, no employed in the states have. 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.
Will Vincent 32:52
I like how you phrase that because I hadn't actually thought of it. I thought, and maybe others feel this way. But that Developer Advocate 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 the developers take that perspective and then feed it into your, 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.
Katie McLaughlin 33:26
Several years ago now, I was one of the headline keynotes at Ruby conference in Australia. And one of the other headline keynotes was a wonderful human being called Asha hemily. We now get to work together. And Asha 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.
Will Vincent 34:27
And this is even the Google a year I forget to review an advocate role before you were a more pure engineering.
Katie McLaughlin 34:33
I was pure engineering with a terribly expensive traveling hobby.
Will Vincent 34:40
So you combine the two Yeah,
Katie McLaughlin 34:42
I get Well, before everyone was chatons 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. Anytime 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.
Will Vincent 35:08
I guess that was the broader question. 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.
Katie McLaughlin 35:19
The descriptions that I was given a definitely the descriptions I would give out. 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. What else?
Carlton Gibson 35:48
Well, I wanted to ask about the lunches right. You work at Google. I heard I heard the lunches.
is that true?
Will Vincent 35:59
I've had lunches at Google. At least have a sales rep and we would go there just for the lunch. There's nothing to talk about there just like put bigger ads in your site. How about we get lunch and talk about it.
Katie McLaughlin 36:08
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.
Carlton Gibson 36:35
Katie McLaughlin 36:36
yes. Essentially exquisite. Ah, the cafe in the New York office. Oh my god.
Unknown Speaker 36:46
I mean, Hello, I'm back.
Carlton Gibson 36:50
Okay, so you're gonna give us some links on how to get started, right. So if you've got a Jetsam for the show notes, we're going to have the Get Started with cloud run that Here's your Django project example. Here's year one with full terraform script, we're going to have all those examples in the show.
Katie McLaughlin 37:07
Here's the link to last year's talk Django con talk 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. Now we're just going to run through the GitHub because like, it's like, I'm just going to do a here's the GitHub tutorial but have it like running it, running it through with you as my tutorial, and links all in the doobly doo. What other links with that? RJ Emily's tweet, definitely. tweets to the PI Gotham talk, tweets to your talk, both in the footnotes for my deployment talk by the way, me? Yeah. Both of you.
Carlton Gibson 37:58
Oh, come on.
Will Vincent 38:00
Yeah, Carlton's a Django fellow
Carlton Gibson 38:02
did I do I know which talk
Katie McLaughlin 38:05
I referenced? You're hacking the HTTP headers, HTTP Pettit. headers and talk you handlers. That one. Yes. And I specifically referenced the deployment episode of Django chat.
Will Vincent 38:21
Oh, okay. Very nice.
Katie McLaughlin 38:25
Yeah, it's in my references. So I'll link to the references in my talk as well, because all my talks like very circular. Yeah. No, it's like, we all learn from each other. And I learned so much from like, I bought your book well, and I learned stuff from it.
Will Vincent 38:46
Yes. You said you tweeted some very, very nice things like in the initial days when I was extremely fragile about it. I think he said something about learning something during it and I was like, Okay.
Katie McLaughlin 38:58
I'm not a chango developer. I just I just mush things together and they sometimes work.
Carlton Gibson 39:06
I think I definitely look it up. But I think that is the definition of a Django developer
Katie McLaughlin 39:12
pushing things together.
Will Vincent 39:13
That sounds awesome.
Katie McLaughlin 39:16
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 Comm. Which I'm pretty proud of,
Carlton Gibson 39:33
ya know, thank you for making those because they do make all the difference.
Katie McLaughlin 39:38
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 skill set, developer advocates learn things like instead of just giving a talk on a thing, committing a an upstream change to change the Based documentation to suggest this different thing. It's like, 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.
Carlton Gibson 40:15
That is wrong is that it might just be kind of old in that it was created in mod whiskey was the way and so much has changed since you know, those days. I mean, I know this mod 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 time to make that point PR to the documentation, all of a sudden that's just gives it a refresh for everybody.
Katie McLaughlin 40:41
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 case, right? Yeah. Yeah. And if it means that one less person has to work that out for themselves, then my job is done.
Will Vincent 41:11
And 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 a prototype or something in the middle, and then there's just huge chasm of who knows what, and then you're in professional land. Is there a way to break that up and, and give a sense of what that looks like? 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 jumped 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 Guna corn 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 it 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 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 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.
Katie McLaughlin 42:33
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 have 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 in varied, but every single production setup has been a little bit different, which is why we need these options of choice. But as Caitlyn 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 aspects about this. The second last slide of my talk lists topics that I did not cover that each have their own conference.
Will Vincent 43:51
Yeah, and yet so it's it's how do you explain this to people without overwhelming them? It's sort of like you it's almost like a like, I had a family antastic Professor with 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. Not gonna hide things from you, but I'm not going to overwhelm you on purpose either.
Katie McLaughlin 44:18
One of the things that I've learned over years of crafting talks is that you can only say so many words and half an hour. But this Django tutorial has so many aside 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 other sites. Okay, but how can I teach things without storytime with Katie? There are so many different ways to tell these stories. My unique Codex tutorial is one way to tell this story and to teach infrastructure. Hopefully, by the end of it, you get the sample application deploy, but if you've learnt just one thing new, then my job is done.
Will Vincent 44:59
I like 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 a 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 spaces, 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 rare, because those are a lot. It's a lot harder, more work to take those extra steps and pull yourself out of, you know, your own day to day stuff, which is which is super interesting, too. But to try to generalize it and perhaps come to ideas around why do we do it this way,
Katie McLaughlin 45:42
this talk is 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 am 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 3am, 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 Yeah, surely
Carlton Gibson 47:00
most of them come back to don't work. We get woken up at 3am in the morning.
Will Vincent 47:05
Like, that's the kind of the 3am this morning. But another reason Yeah, you've deployed a child but 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.
Katie McLaughlin 47:19
The ongoing maintenance though, I hear it's a hassle. But you know,
Will Vincent 47:24
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?
Katie McLaughlin 47:30
I would put my Doobly Do you want on the descriptions? Yeah, like 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 listened to or fresh off the press. I have a talk up there called what is deployment anyway, any tutorial deploying Django on serverless. infrastructure. Okay, so both happened to be about Gengar.
Carlton Gibson 48:06
Well, that they hit our demographic. Exactly.
Will Vincent 48:13
Well, we'll have maybe more things 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, and learning about Yeah, and learning about Alpine and slim to that sort of blowing my mind a bit.
Carlton Gibson 48:29
I don't know, like deployments 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.
Katie McLaughlin 48:36
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.
Carlton Gibson 48:52
No, thanks for coming on. We'll see any
Will Vincent 48:57
as ever, everyone, we're at Tango. On Twitter Jango chat.com and we'll see you next week. Join us next time bye bye