How to deploy a website on Django as well as our thoughts on the multiple hosting options available.
Will Vincent 0:06
Hello, and welcome to another episode of Django chat. In this episode, we're going to talk about deployment, the things you need to do to change your Django application and options for putting your site online. as ever. I'm joined by Carlton Gibson. Hi, Carlton. Hello, Will How are you? I am good. So let's This is one of the top questions that I get as a Django educator. And it really is confusing the first time or several times you go through it. So there's a long list of things that are different on local Django versus deployment Django as a Django fellow, perhaps you could talk about why Django makes some of the choices they use, such as SQL lite and all the rest to make local development easier.
Carlton Gibson 0:42
Well SQL lite, when SQL lite like, you know, SQL was a separate programming language back to Days, Surely it's called SQL rather than SQL. So we'll call it SQL Lite. I you know, I don't know. Anyway, SQL Lite. Why? Because it's it becomes embedded in Python, and you can just get up and running. And you don't have to set up a different server and and so when you do start project and start app, and you can run server, you're up and running with SQL lite SQL. I just said, SQL. Who knows what it's called? The right one. Yeah, yeah, you're up with SQL Lite. Without any extra work. And, and, you know, when you first starting, the last thing you need is, oh, install Postgres. Um,
Will Vincent 1:23
yeah, it's, it's hard. It's quite hard to set up Postgres or another one on a server, especially if you're not using Docker and yeah, whereas SQL lite is file based. So it's just that little file right there. And boop, away you go. So let's go through, there's a list of things. And then we'll go through maybe and talk about the choices Django has made. But first, we should mention, there is a deployment checklist in the fantastic docs, which we'll link to, and you can run, run a command, manage that py check, dash dash deploy, which will in an automated way, say hey, you forgot some of these like must haves because it's a bunch of nice to haves depending on your project but there's a bunch of must haves of which switching over from sequel light is, in most cases one of them.
Carlton Gibson 2:05
Yeah, run that deployment check is well, Andy.
Will Vincent 2:08
Yeah, no, but I say that because I wasn't aware of that page in the docs for a long time. So
Carlton Gibson 2:15
yeah, so the two thing, the checklist, which is a page in the docs, and then the check command with the deploy flag, which is like, you know, automated So, you know, that normally when you when you migrate, the checks get run, but they do make sure you misconfigured an admin or misconfigured figure the Model Model, but these extra deployment only checks, you have to actually enable the flag and run the command.
Will Vincent 2:38
Yes, in the flag. So let's go through the list. So number one is probably debug. So in the settings.py file, by default, debug is turned to true which gives all sorts of nice debugging and other error collection. But you do not want to have that on for production. You want to change that to false because that means that anyone out there in the great Wide Web can See things you don't want them to see about your project and it will be insecure. So that is probably number one. If you had to pick only one thing is switched to bug to false.
Carlton Gibson 3:09
Yeah, and the the the error page that Django throws up shows your whole environment. Yeah,
Will Vincent 3:15
it's everything.
Carlton Gibson 3:17
You know, so you can't have that visit.
Will Vincent 3:20
And but I mean, how you configure that there's multiple ways to automatically toggle the bug. I mean, you can do it with different settings files, you can do it with environment variables. I'm curious, do you have a personal preference for how to do it because it's not it's actually a little bit tricky. configuring it. So it automatically knows Oh, I'm in local, you know, change the bug and whenever production change to something else? Oh, I'm almost
Carlton Gibson 3:44
scared to say what my personal preferences are. Yeah,
Will Vincent 3:46
you're better but what's the kind word?
Carlton Gibson 3:50
Stalinist? No, okay. So,
Will Vincent 3:56
so, well, I'll say so that so most many people have probably are aware of the two scoops of Django book which came out a couple years ago, which advocated multiple settings files. So you'd have a base settings file, and then a local settings file and deployment settings file which would override. And so you would sort of chain them together and run a different set of settings files, depending upon which environment you were in. That's the standard pattern people are aware of. And to be honest, that's what I use on quite a number of my projects. Yeah, and it works. There's nothing wrong with that. I have been using Docker a lot recently. And with Docker, you can use environment variables, which is 12, factor auth type of deal. And so there you can also override, but basically, you can have a single settings file and then you can override your environment variables. Yeah.
Carlton Gibson 4:42
And if I was starting fresh today, that's probably the way I would, I would do it. Yeah, I think it's simple. It's simpler. If you're, if you've never done it before, use environment variables don't do the settings pattern, but the settings pattern is fine too. But it is quite confusing. I mean, I've just finished the chapter on this in my Book Django for professionals and I've talked to quite a few experts about it, I could do a whole episode on just environment variables within Docker. So it's an it's not distinct Docker, it's in your local development environment. It's it's how do you set environment variables sensibly. And think crazy things like you know, because of the way the, the the heart of the Unix programming environment is settings, environment variables arrive in your processes strings, even though they might be integers. You might want them as integers. So you need some kind of help to cast them to the right type, or you need to be aware that they're going to come into strings. Environment Variables are kind of complicated. And they are I think, a first level multiple setting files can actually be easy. So you've got your base ones, which are the same in every environment. And then you've got your local ones where you've got you know, you have a know your local debate database set and then you've got your production settings which have your production database settings plus this debug equals
Will Vincent 5:58
false. Yeah, well in With with the Docker base environment variable setup, you have your your default, which is basically your local and then you. So you have a single settings file, you have a single environment variable file, like a dot m, and then you have a dot prod dot n, which just overwrites those. So it's actually, one, it's two files instead of three, though you would have with settings, but it's the same idea. You want to automate it. So one way people handle environment variables is to put them in an M file of some kind. So this is a file that has key pairs between the environment variable name and environment variable value, and somehow you get that into an environment.
Carlton Gibson 6:37
Yes, so and there are all sorts of tricks about that. But if you're going to have multiple environments, you're going to end up with one of these m files for each of those and we'll How is this any different from multiple settings files? It's that yes, no, yes, no free there's no free lunch here right
Will Vincent 6:53
now. And, and you can also just hard code your environment variables into your Docker compose file with Docker. Though I think generally speaking, a better practice is to create a dot m file, because then you can get ignore that file. So it's not in your source control. So your whole point about this, which is the whole point secret,
Carlton Gibson 7:12
right? The whole the whole thing is otherwise you put things like your secret key or your database, password and or whatever, into your source control. And you don't want to do that. And so
Will Vincent 7:23
yeah, what so this, so what we just discussed is a very shorter variation of the conversations I've been having with other experts. So you need some way to toggle between local and production. It is complicated. You can do the settings file approach. You can do the environment variable approach, pick one. Try not to spend too much time on it, as would be my advice, but it is tricky. And that leads us to the second Pro. The second thing you would want to change or at least make truly secret when you go into production, which is your secret key. So this is what 50 I think it's 50 character string. That's something that's automatically generated. When you do start project command, you've probably checked it into source control, you can actually do a link to it, you can use the internal Django to do on the command line to generate a new random secret key, which you might want to do. And then link to that through an environment variable. But that's something that you like it says in the settings files, but you really want your secret key to be secret, because if some it's used for all the hashing, of all this, all the other secret stuff within Django,
Carlton Gibson 8:27
no, but like, if you've got every sign in link, then it will be it will be used with the tango secrets and that will be used the secret key to generate the hash, the session identifiers, the you know everything like absolutely everything.
Will Vincent 8:41
So what do you so what do you how do you keep your secret?
Carlton Gibson 8:46
Okay, so yeah, exactly this so for production environment, you have one which is outside of source control. And normally I would keep that in a dot m file and then if I have super In a supervisor or in whatever Process Manager I'm using, load that into the environment when calling the the Jenga process. Yeah, that works with Ansible as well. And you know, ideally, you can store these things in some sort of vault.
Will Vincent 9:15
Yeah, like a password manager or somewhere somewhere. Yeah.
Carlton Gibson 9:17
Well, the password manager for small teams, but then when you deploying it, all the major cloud providers will provide a secret keeper place where you can put a secret in, and you can only fetch it back out with the right key, and it'll give you the it will give you that value. But it's not readable by anybody ever. So hashey Corp, I've got one called vault. And then Microsoft is yours got one and Google have got one and Amazon have got one as well. I can never remember the names of all the services, but they're a nice place where you can put those and they're online. They're shareable, but with a team, and then you can have your process access those on demand,
Will Vincent 9:54
right? Because this is another key aspects. If you're in a team setting, you might want everyone to have access to the code base. But you don't want everyone to have access to your stripe API key, for example, your production database password reproduction. Yeah, certainly the Yeah. Some horror stories I could tell about that. So if also one thing dimension there is a fantastic third party package Jango environment, which I haven't found a use case for it within Docker, but in standard non Docker environments, it packages up a bunch of other tools and it's a really great way to do 12 factor auth with environment variables, so we'll link to that number three I would say so debug secret key allowed hosts Do you want to
Carlton Gibson 10:34
Yes, so even a lot hosts are okay, so you don't want your Django app for my pretty website calm to respond to requests for someone else's evil website calm. So you allowed hosts is a list of exactly allowed hosts, you might respond to my pretty website calm, as well as my friends pretty website.com. You might respond to those two, but nothing else until you put those into allowed And then Django will reject any settings, any requests for hosts which don't match it. That's not, you know, that's not there are ways of spoofing the host header and other such things. But that's a nice base level check. It says no, I'm not going to respond to requests for the wrong website.
Will Vincent 11:18
Right. And that the default if you look in your settings.py file, it is just empty. Oh, it looks empty. But really, it's set to localhost and 12700 8000. If that was true,
Carlton Gibson 11:32
was that if debug is true, if debug is true,
Will Vincent 11:35
correct, right. Right. So you will have to set allowed hosts, whatever your deployment, whether it's a Roku, all the rest, you will have to put that in there. So
Carlton Gibson 11:46
yes. So but this is this is the error you get is from the checks. Remember, earlier on, we talked about the check framework where you have managed.pi check that's automatically run and that allowed host check is run every time and if the If debug is false, then it will check that you set allowed host correctly. Yeah. And that that's independent of the extra checks, which are deployed, deployed back. If
deployed.
Will Vincent 12:10
Django has these batteries, thoughtful people smarter than me have gone through this before.
Carlton Gibson 12:14
Yeah. And like, for instance, like, setting the right head of values and things on cookies and stuff that you you know, you and I, and everybody else we don't know, but somebody has thought about it. And they put the time in, and they've made sure that you've configured it right. And they tell you if you don't, and that's
Will Vincent 12:29
Yeah, it's quite nice. So let's see what would be number four, I would say static file stuff. So this would be images, CSS, JavaScript. There's actually Jacob Kaplan moss will link to this gave a fantastic talk at pi con on it's called assets in Django without losing your hair. And basically, you need to in Django, what are assets are called static for legacy reasons. And then there's often media which were To user uploaded content, so, you know, so a static asset would be an image. But you could also if it was coming from users, you would put it into a media. And his talk kind of goes into this. But the reason why there's a distinction is because you don't trust your users, you shouldn't. So you want to put that information, not on your server. And then when you reach a certain size, you probably want to take all those assets and not have them on your server, either even the ones you've created and put them in a CDN, like s3, or CloudFront, something like that. But one thing that I took away from that talk is, you can scale pretty far actually, with keeping assets on your local server. Actually, the numbers you gave were much higher than I expected, because I've always, I guess, prematurely optimized and gone right to s3 CloudFront. But he, maybe you're experiencing the same set, you know, you can go pretty far with not doing that.
Carlton Gibson 13:54
Yeah, I mean, if you let's say your standard setup system, you know, it's a single virtual machine running nginx with a Django application behind it, perhaps we can call in front of it. Green unicorn, we call it but gonna call if you've configured nginx to serve your static files directly from the file system and you, especially if you set the the right headers, the right response headers so that those requests are cached because they're static, they don't change. You can set Long live headers, actually read that instance, that that really basic one server instance, conserve a lot of traffic,
Will Vincent 14:31
don't do it unless you need to. And then there's the fourth level is web pack and parcel and all these things, you know, for packaging JavaScript, which if you can avoid avoid.
Carlton Gibson 14:42
Yeah, I mean, certainly, yeah, it depends. Again, it's like if you're, if you're, if you're shipping a small Django app yourself, then keep it simple. Don't get into all of that stuff. If you're part of a bigger team. You need all of that. You need that front end because that's what the front end team will give you. But you need to bundle it up, then you need to put Somewhere where your web server can find it be that on a CDN or be that on that your single web server, but you'd be amazed how much you can get a small instance to serve if you do the right things.
Will Vincent 15:09
Yes. Two more points. I haven't even done a quick list. So one is so the database so we mentioned you need to decide on your production database. And generally speaking, you don't want sequel lite right now. Built in support for Postgres, SQL, MySQL, and Oracle, though. Oracle may not be there for that long,
Carlton Gibson 15:24
so I think it's going now. Okay, I think we keep Maria DB is coming along.
Will Vincent 15:31
Okay, me, well, I'll edit out the Oracle slang then
Carlton Gibson 15:34
it's like, no, that's legal.
Will Vincent 15:39
Do you so for me, I've almost predominantly worked with Postgres. I feel like if you don't, if you need advice, that's probably the advice you will hear in the Django community. But if you're asking for advice, you also don't really know what you're doing. So it's they're kind of all the same at the beginner level.
Carlton Gibson 15:55
Yeah, I mean, so when I started, it was all my SQL. It was just that yes, that was The database and so for four or five years, I was running my SQL all the time. And then Postgres came along, and particularly with when Django bought in the contribute Postgres, the extra fields like the JSON field, the Raphael, the H, door stuff, you know, as range fields in there now is case insensitive text fields. There's all kinds of extra stuff which Postgres gave you as well as the geo Django stuff, which works kind of better on Postgres and Postgres pushed as ended up moving over to Postgres. And for a number of years now, that's been my sort of go to option. And the big
Will Vincent 16:37
tex search as well that Yeah, Django is integrated that Postgres has had for a while.
Carlton Gibson 16:42
Yeah, I'm increasingly coming back towards SQL Lite. For a lot of use cases. If that read heavy and things like this. I'm just a really closet fan and not a closet fan. You wear it proudly on the sleeve. I'm a big fan of it. But yeah, Postgres who is perhaps the beginning place to go in the Django community at this time, Adam Johnson I'm hoping really hoping to get on he maintains a package called Django my SQL which brings a lot of the features from that similar to con contract Postgres for my SQL and he'll come and tell us why you should use that or Maria dB, which is the open source equivalent or the Free Software equivalent of my SQL because some Microsoft sun or no sun owned my SQL and Oracle bought sun and so with it, my SQL is is owned by the Oracle brand. So Maria DB is the open is the free software.
Will Vincent 17:31
re offshoot of that, I think what Oracle owns Java now, right, or sun or whatever, you know,
Carlton Gibson 17:39
Java, so when sun bought, sorry, when Oracle bought sun, they got Java and my SQL
as the Yeah.
Will Vincent 17:46
For the package way to kill an open source community. Well, last last big one I would say is the admin. There's multiple ways to what's called the heart in it probably the biggest one is you should not run You should change the URL for your admin, you can go into your top level URLs file and do this. Just make it anything other than admin. Because if you were a malicious actor, you could write a script that says, hey, whatever site slash admin would be a Django site. And I will just try to brute force my way into the admin and cause all sorts of harm.
Carlton Gibson 18:22
Yeah. And if you run any web server ever, and you just look at the access logs for that you will see regularly like every hour, you will see request after request for known URLs, and most of those are WordPress URLs. But also Django URLs appear in those. And these are people running automated penetration kits, automated
scripts, which
attack find a server attacker server and find if it's got weaknesses. So if you by renaming your admin you can avoid most of those attacks for Django because they don't they it's not that your admin is any more secure. It's that the automated scripts don't Hit.
Will Vincent 19:00
Yeah, well, I remember the first time I set up. I think it was a digitalocean server. And I didn't know what I was doing and within, and whatever I forget the lockdown steps you're supposed to take within 90 minutes, basically, bots had taken over and I got a notice from digitalocean saying like your, you know, computing machine servers doing malicious things. So it has it's a scary place out there in the internet, especially if you're rolling your own server stuff.
Carlton Gibson 19:31
Yeah. And this is the key point is that these these attacks, aren't somebody picking you out?
Will Vincent 19:36
They have personal
Carlton Gibson 19:37
Yeah, firstly lamented. And so it's not.
If there is a vulnerability, which your site exposes, it's not a matter of if it's a matter of when,
Will Vincent 19:45
yeah, and so so definitely change the admin URL. There's actually Tracy Williams and Jeff triplet have written an article on hardening your admin which we will link to. So that's the basic stuff so it's Sounds like a lot. In practice, you will write scripts. So you'll get used to doing this for your Django sites. But the top ones are you got to switch debug, keep your secret key secret, allowed hosts, you'll need to put in wherever it is in production, static files, you'll need to think about that you need to choose a production database. And you should do some basic steps around the admin. And in addition to the check, there's also pony checkup, I believe is still the site that's run by Roman Sasha. Yeah, that will, you can put in the URL for your site, and we'll run a bunch of automated tests to see if it's secure. So that's a good like, the I always do that after I've gone through all these things, just as like a triple check. But there's also within Django, there's a couple commands that maybe do you want to cover, Carlton, so migrate, collect static
Carlton Gibson 20:51
route, okay, so for me, right, there's a 123 of deployment, which you got to do every single time. The first one is upload your code. You've got to get it onto the server somehow now, you know, back in the day, that's our sink and kind of beer is the job deploying PHP sites. But you can, what can you do, I don't know, you can clone your repository on the server and you can get put onto the server, which is not a bad way as long as you don't mess around and then get your your, your checkout messed up by, you know, getting
Will Vincent 21:26
companies I think do it this way. They put it up on GitHub or wherever and then pull from there. I think that's the standard function. And that's
Carlton Gibson 21:33
quite cool. You can extract some kind of zip archive you can you can even set up a PI clone and set up tools publish it to there, but that's, you know,
Will Vincent 21:45
yeah, I mean, with like Hiroko, you you push the code so you do like get push origin you do get push Heroku origin so that So literally, you have to step as you push it to GitHub or Bitbucket or wherever and then separately, you push it up to Heroku and then it will automatically Go through all the steps for each time you push new code to it.
Carlton Gibson 22:04
Yeah, and these, your app service has a similar thing where you can do a push from your local commit. And yeah, I think they can also pull on, you know, they can watch a GitHub branch as well. Some of these services do that. When you push to the GitHub branch, he automatically pulls on the on the server. That's kind of cool.
Will Vincent 22:19
Yeah. But this is only something you would put just sorry to interrupt. But so a big thing for beginners is they'll say, Well, I, you know, I wrote a local blog, jingle blog, and I put 10 entries in there. And then I put it up on my platform of service. And I don't see it, what up. And that's because it makes a ton of sense. It's because it, it just takes a while to understand that your local database is not your production database. It shouldn't be. You kind of get this drilled into you with practice, but that's why, you know, your local and your production environments are different, but it is it is confusing. And it takes a while for people to internalize that and I don't know if you have anything to add on that but I see people do that again and again. Again, I certainly
Carlton Gibson 23:00
went through that process myself saying, like, Oh, I just my site looks how I want it to look, why does that look like that in production? It's like, Well, okay, so the thing you can do here is you can set your, you can create a settings file, so you're not connecting to a local database, you're actually connecting to your remote database, assuming you that your local IP addresses allow you or you can SSH tunnel into wherever your production database is, you can set your local install to connect your to your production database, if you want to, when you're creating a small blog like this, this kind of works. So locally, you're developing on the code, but you're still when you write a blog post locally, it still goes into production database. And importantly, as well, your media files. So you know, you create a blog post and you upload an image. And that gets saved your local media file not to the one on your web server. Right, right. Where is it gone? And how do I see these things? is one thing you can do as well as if it's read heavy, you can use secret light, and you can just upload. You can
Will Vincent 23:57
Yeah, yeah, it's just a reality. To place. Yeah. And when
Carlton Gibson 24:02
you want to work locally, you can just download it and then you can work on that. And then you can upload it to replace it that way. That's kind of format sync to one. Yeah,
Will Vincent 24:09
yeah. No, I yeah. It does work. It does work. So Alright, so migrate the second command. Yeah.
Carlton Gibson 24:16
Okay. So the first one is upload code, right. And then the second one is you've got to migrate your database. And so know, if you've got a hosted, you know, you've on RDS and you've got a hosted Postgres instance, and you've created some changes, you've tested them locally, you've put your code up there. Now you've got to run migrate. And so you need to do that on your server that's connecting to your production database, or again, you can connect locally to build it.
Will Vincent 24:41
Yeah. And again, you'll say I ran it locally, like what's going on in production?
Carlton Gibson 24:44
Yeah, you've got to migrate your production database. And then the third one is collect static, where you put all the static files from your project somewhere where your web server knows how to find them.
Will Vincent 24:56
Yeah. And which we Jacob talks about this but yeah, the clicks command which is automatically run on Heroku. And I assume other platforms takes all the static files from all over your app puts them into one nice place for Django to refer to. That's another I mean, it takes take some time to internalize how static files work within Django.
Carlton Gibson 25:15
Yeah, it's a great guide, and you just got to take your time and like, all these things, yeah,
Will Vincent 25:18
the dogs, all your lights, you know, like, I always find, like, once I understand something, I go read the docs, I'm like, oh, like, they make so much sense. Like, I would have written them this way. But when you are learning it, and when you are frustrated, you know, it's like these half truths, and you're like, Ah, so it's not the dog's fault. But that is the reality of Django beginner we get it's like what we talked about in the how to learn Django episode. It's like, there's the docs, which are kind of like reference material versus the tutorial you need the walkthrough.
Carlton Gibson 25:47
Yeah, and that's time.
Will Vincent 25:48
This is my this is like my, my meta understanding at this point. My career is that tutorials and documentation are different things and should be and always will be But often you want the tutorial when you're learning not the docs.
Carlton Gibson 26:04
Yeah, no entirely,
Will Vincent 26:05
which is what I am working on so and others, so don't worry about it, we'll cover, we'll cover the bases. Actually, for image stuff, I wrote a recent tutorial on how to do image uploading, or file uploading within Django that covers some of the basics on static media files that will link to,
Carlton Gibson 26:22
it gives you an often, often the hardest thing here is if you're configuring on web server, is to configure the right directory permissions and make sure that you you know, your Django process can write to the folder and your web server can read from it. And yeah, that's, that's the last thing we should cover. So you know where to deploy. So so so one way you were just saying is a virtual machine where linode Digital Ocean, I'm sure there's others we're forgetting. But yeah, it's Yeah, they all they all all of the cloud servers offer pretty much all of these things. As far as I can tell. They all seem to offer what you net what I call a hosted runtime or a platform as a service where you just push your app code and runs it for you, and you don't have to worry about it. They all seem to offer a via a virtual machine solution where you can provision a virtual machine. It's like having a boon to server there. And yeah, you have to install that software or anything. But again, you can get images like base images, which we provision from that one, and it's already got the right Python installed, and it's all and then you, you just have to pip install, you know, Django or your project requirements, and create a virtual environment pip install the requirements and run it, and it works. Because it that base image has it has all the things you need to run a Django project on it. And then they all now seem to offer a container runtime where you could do a Docker container Docker container. Yeah. And so you know, it doesn't really matter which hosting provider I think,
Will Vincent 27:43
yeah, they're all but they're all challenging and confusing. I mean, I've I've only done it with a couple of them I understand and the abstract how it is done, I could figure out how to do it and all the others but reality, you know, Realistically speaking, you just sort of pick one. It's, it's Be beginner asked me, I would say do not go anywhere near a virtual machine, you should do as a learning exercise. But just use a platform as a service use Docker is or sent anywhere, just get it up there. The trap of virtual machines I found is that it feels like real engineering because it because it is, you know, DevOps is like a whole separate profession. And like it's like, getting gnarly, and you get in there and you fix things. But it's just endless. And your end users do not care where your site was hosted. They just want it to work and be up. And so unless you are at significant scale, in which case, you shouldn't be the only developer I would say, Don't go anywhere near this stuff, except for learning exercises worth doing. Or if you know what you're doing. You've automated scripts, which I suspect is kind of where you're at Carlton?
Carlton Gibson 28:46
Yeah. And this is what I was going to say. So you pick one and you learn it. Yeah. And then you make sure that your deployment to that scriptable. So tools here like fabric or Ansible. You know, Ansible is a big sort of name and that's what it's built in Python, you know? But you see, you've got a deployment script. So when you run, you know, my project, deploy Ansible playbook deploy it, it uploads your code, it does the get pull or whatever on the server in the right place. it migrates the database, it collects data, it runs, you know, the deployment checks that you want to do. It reboots your process manages that restarts, your Django application, the all these kind of things, you know, it refreshes your SSH certificate from Let's Encrypt it. Yeah, you know, script all of these bits. And then you can start to think, Oh, you know, I've got this running on App Engine, I can easily get this going on, you know, this app service over here, or this being Elastic Beanstalk over here by just changing a few bits of the script. And then all of a sudden, instead of being able to do it in one, you can do it in three, and then you think, Oh, I could do this with a virtual machine and y'all can provision a virtual machine and, and you slowly increase that Yeah, you
Will Vincent 29:54
slide you slide down into more and more people.
Carlton Gibson 29:57
Well, it depends how what values has to you.
Will Vincent 30:00
Yeah, that's
Carlton Gibson 30:02
Tom Dyson said on the wagtail episode that, you know, we were talking about the price, or did he say or was it in the chat? I don't know. But he was saying that, you know, that actually platforms at the surface, they're really quite affordable. Quite, you know, until you scale up quite high. Because the time you take
Will Vincent 30:17
Yeah, to take over a machine, whatever. It's like, oh, it'd be much cheaper if I did it on this micro instance, that only costs X dollars a month. Yeah. But you're not counting your hourly rate that it took to get that micro instance in a position where it could serve those requests. Exactly. I mean, I've I wasted weeks and weeks and weeks of my time on solo projects, or, you know, early stage startups fiddling around with virtual machines when, you know, you know, thinking yeah, exactly that thinking, Oh, well, I'm saving $50 a month versus the subject this platform is service. Meanwhile, two weeks of my life have gone away. So
Carlton Gibson 30:49
yeah, you could have been two weeks of your life writing copy or writing user interface code, which actually
Will Vincent 30:54
so so so you want so you should it is fun to learn how to do this stuff. is interesting, but value your time and I would say, be very specific about this as a learning exercise unless you're in a big company and then you know, you get paid.
Carlton Gibson 31:09
Unless your focus is down towards that DevOps stuff. Yeah, because they're different ways you can go, you might be more interested in that back end system admin DevOps stuff, in which case, learn it, because you ain't going to get the roles that you want without without that experience. But if it's not your specialty, if it's not your what they call the area of genius, then head somewhere our area of genius. I'd like that. Yeah, my wife told me about it. She read some books, I'll have to find out what the book was.
Will Vincent 31:34
Oh, okay. That's such a nice way to phrase it. Yeah, well, and I so I, I know that I am not a DevOps person. I am a very product focused engineer. That's a term I kind of veer more toward, even though I spend all this time on jenko IV are much more towards the front end. And I just want it to work and talk to users. get feedback,
Carlton Gibson 31:54
right? If you imagine a continuum, right. Yeah, they were like at the top end you've got I don't know doing the Graphic Design for the buttons in the UI, that kind of stuff at the bottom and you've got the configuring the network layer for your Kubernetes cluster. Like Django is sort of up the front end side of it, even though it's it is a back end framework. Yeah, it is. There's so much gnarly stuff below to be able to serve requests. The Django is actually from there.
Will Vincent 32:24
Yeah, that's the title for the podcast. Django is from Vegas, Brennan. And I think you know, in terms of just a side note on career advice, because I get emailed for career advice all the time, which is kind of hilarious to me. But I would say that it is probably much more marketable, to have a strong back end knowledge, though, it narrows down the number of companies you can work at, because not that many companies are at scale. However, you can spend 510 years you know, learning how to do all these things that are it's really hard to learn otherwise, whereas you know, CSS or JavaScript, you can do that on your own a little bit. Yeah, but you can also spend five or 10 years learning that stuff which You can and should I just saying maybe this is the bias that I see is that people respect 10 years of backend experience more than 10 years in front of experience, and maybe that's just carrying around clients. But
Carlton Gibson 33:11
no, there is that bias. I think it's totally misplaced, because someone who really know CSS is Yeah, absolutely invaluable. And it's, it's just as much a skill and it's just, you know, great experiences can't be crafted without it.
Will Vincent 33:22
Yeah, even the most hardcore, you know, lives in the command line engineer. When they see a site, they can say, that's an ugly site. And they will implicit, you know, implicitly judge it. And so anyways, yeah. All right. I think we covered it. It's a complicated topic. I've been spending months and months, trying to figure out how to simplify this for my new book, so I understand the pain of of all this, but the takeaway is you should check the deployment checklist. You should be aware of the check flag and pick a platform as a service. If you're just starting out, get it running, and then be aware that there are all these other levels and it's a it is really fun and interesting to learn all this stuff, but it's deep.
Carlton Gibson 34:03
Yeah. And be so you know, beep eight on the first hand, be prepared to take the time because it is deep and you need to get it right. But on the second hand be conscious of Hey, am I going down a rabbit hole that I don't really need to hear? Yeah, don't spend two weeks on. Like, you're not dependent. Think Seriously? Oh, you know, what's my career? What's my project? What's, you know, is this a benefit to me? Yes. Great. Anyway, that that's about well, that's about all we've got to say about deployment. I think so.
Will Vincent 34:29
Yeah. So we will see you next week. Carlton, I'll talk to you then. Right ticket Bye Bye bye.