Transcript: High Performance Django - Peter Baumgartner

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

Hello, Will.

And this week we've got Pete Bamgarner with us from uh Lincoln Loop.

Hello, Pete.

Thank you for coming on the show.

Thanks for coming on.

We talk about Link and Loop, we talk about things like high performance Django, deployment, um, topics like that.

But we always ask, how did you get started and how did you find Django?

Like what's your backstory?

Like, you know.

I my uh I'll I'll try to keep it short, but um graduated college with a computer science degree, uh right at the beginning of the dot-com bust, the original dot-com bust in the 2000s.

Uh good timing.

And uh from that um folks, there was a really uh there was somebody doing kind of website and emails, uh email hosting in our town that would go on vacation and I think they ran a server out of a closet or something, and the server would die, and people wouldn't have an email for two weeks while he was on vacation.

And so, you know, people started asking us, hey, can you help us out with your email?

And kind of figured out email, and then with that came websites, and uh so picked up um PHP and WordPress and and got into that and um kind of painted myself into a corner a couple of times trying to build WordPress plugins for things that should have been much more than that, and um had tried uh you know, picked up Ruby on Rails and all that, and and uh eventually came to Django, and that was like that was

running off of the subversion trunk days pre-Point nine six um something like that.

And you you've sort of always been on the landscape, you know.

Lincoln Loop was one of the first agencies that I knew about that were blogging about Django and using it, and

So um, you know, got some traction on that and did uh kind of a lightning talk at uh I think it was the first DjangoCon.

It was at Google um and their Mountain View campus on some like customizations to the admin I had done, which really were not that like was kind of like some you know injecting some CSS in and stuff, and people were like you know, mind blown.

Like it was not, it was just early days, you know, people hadn't kind of thought of it yet.

So uh yeah, just I kind of really feel like uh in the right place at the right time type situation, you know.

Um, I think that was harder for me to kind of wrap my head around.

So uh yeah, but but the documentation definitely was huge as well.

Well, because it's easy to think about now versus back then, whereas now Python is much more broadly used than Ruby.

Ruby is pretty much predominantly used with Rails, but back then it was you know not so much the case.

I mean it was probably a number of years later, I think it was 2012 when I was deciding which of the two to play around with, and um Rails had better beginner materials and there were more I was in San Francisco at the time, more startups using it, but I just picked Django for some reason.

I think 'cause I just knew I had to pick one and go deep on it rather than bouncing around.

Whereas now I think it's hopefully with my stuff and others, there's more content for Django beginners, but it definitely felt eight years ago like your average Django person was coming in with you know, if not a CS degree, knowledge of Python, whereas if you were you know, all the boot camps were Rails.

Like I think all the boot camps now are pure JavaScript pretty much, but they still basically don't do Django at all.

They if they do have batteries included, it's Rails to this day.

And I saw, you know, Django seemed like it was a couple years behind Rails and figured, you know, hey, maybe you can get in now and and uh beat the crowd.

So building out that agency and you know the type of client work you've you've done over the years and how that's developed?

Um and eventually we we just kind of didn't see eye to eye anymore.

Uh they saw it as kind of a value add-on for their services, and I was more interested in building kind of a standalone agency.

So we parted ways.

Um, but at the time all my clients were local, I was just freelancing.

Um most, you know, a lot of website hosting stuff and supporting, you know, people setting up Microsoft Outlook for their emails and and all that.

Uh and got involved with a couple of uh real estate companies here and was kind of frustrated with the state of the world of of real estate search.

So that's that was kind of my first big project I built in Django and um built a bunch of tooling around that.

Actually, had a little product that I was kind of operating for a while, and and that was where I started blogging about it and and kind of shifted gears of of my company from being uh, you know, we build kind of brochure WordPress sites for local businesses to, you know, we're focused on Django and and all that.

Um and honestly, like the phone just started ringing.

It was kind of shocking to me.

Um, I remember like one day I got a, you know, I mean, I I don't think people were calling me directly, but you know, getting an email uh and and you know, got an email from National Geographic, and they're like, you know, hey, we're looking at moving to Django, and you know, I'm like working out of a spare bedroom at the time, you know, all by myself.

And uh yeah, I was like, yeah, you know, and and so uh pretty quickly had more business than I could handle on my own.

And uh at the time it was really easy to find Django developers that wanted to work professionally, like people were working with Django and their you know, personal projects and on the side, but there wasn't a whole lot of professional opportunity around it.

So uh I was able to kind of just go through the open source community and start picking people out.

Like, hey, I've seen you, you know, I've used some of your software.

Do you want to work on Django stuff?

And they're like, Yeah, great, I'd love to.

I'm you know, doing PHP stuff or working in Plone or whatever.

Um, so people kind of jumped at the opportunity.

for me it was um native app development, but you know, as well as Django.

I was you know, I I did build apps and then used Django for the back ends, but finding into the way into a niche where it's like actually there's loads of air here, there's loads of air around, and then there's lots of clients who are desperate, and it's like all of a sudden, oh this is a really sustainable.

I mean, there have definitely been kind of you know kind of peaks and valleys, and um it it was a long time before

It was always contract work and per project, and then I kind of looked around and you know, we all realized like I've basically been paying you full time for three years, you know, um, because there hasn't been a gap.

Uh so um, you know, then making that transition, but

So you've got regular clients that you know are gonna pay

sales every month.

Like we I think we have more of it now.

Uh it was more kind of back to back-to-back projects, and that was stressful.

Um, because you don't know when it's gonna the next one's gonna come.

I remember there was an agency in um Barcelona that won all sorts of awards.

They were doing like Facebook's app and they'd won, you know, they were up on stages and all the big things, and you know, they were like, wow, every everyone was watching them, and all of a sudden they just disappeared because I don't know, the work dried up for three months and they had 50 developers on

That that kept me up at night for uh you know a few years in the beginning.

Yeah, and I remember, you know, as we were growing, like I had a line of credit um with the bank that was I can't remember if it was attached to our house or a car or something, and like completely draining it every month to cover paying people while I waiting for you know checks to come in from you know, we we were profitable, but just the kind of cash flow wasn't there yet.

We didn't have a uh you know buffer.

And um yeah, that was uh I'm I'm glad we're not there anymore.

It's stressful.

But I mean, interesting to hear, you know, you from a business point of view, like your story, and it's you

Um your high performance Django book, deployments, and then app pack.

And maybe I'll put it to you.

Which how how do you how do you string those together?

Um because we've sort of been circling around it, but deployments and maintaining a site anywhere, but especially with Django is non-trivial.

Yeah.

And you've done a lot of work on this.

Yeah.

Uh so um we definitely did some learning by trial and error, and there was some good information out there.

I remember at the time, um uh shoot, the the guy that does Sentry, uh he was working at like chess.com or something, or I can't remember where it was.

He he gave a talk uh about like scaling Django, and this was really early on.

David Kramer.

Uh and yeah um uh

I can't remember what it was uh where he was working.

This was yeah, uh long time ago.

But yeah, you know, so there were some people doing it, but it just wasn't kind of common knowledge at the time.

And uh I think it was sort of piecing stuff together from what other people had learned doing Rails and and and all that.

So um we did one large site that was like a gaming publication and it was like a CMS and like they had a little social network built in and stuff, and they would do these like drawings, like first comment gets you know, like a free so such and such.

So they would like post something on their site and like immediately like it would just go bananas, and it was not just people like reading the site, it was like people trying to type in comments and stuff.

So uh we learned a lot um through you know kind of trial by fire there.

And uh I think the book came about.

We had a client that we worked with who was you know large, uh another large CMS company, and um they had a bunch of really smart devs on their staff, and you know, they came to us and said, Hey, you know, we've got this scaling problem, and our our sites you know periodically go down, and we're really lost here.

We're just we're just stuck, like we just could use another set of eyeballs, and and they kind of explain their system and how it's working and all that, and then like, gosh, like this isn't the way you should be doing it, you know.

Like, and it was like a

Can you help us fix this system when really the solution is like you should probably burn that thing to the ground and and do it a different way?

Um for sure.

So I I I kind of was doing a write-up for the client on on sort of you know our recommendations on on how to proceed.

And um I I think like, and not to like I hate it when people are like, oh, these people are idiots or whatever, like they were really smart people.

And I I think um, you know, they they made some early-on architecture choices that probably made sense at one point that you know they carried on for a long time.

So um I I think you know it's easy to come in in hindsight and say, like, oh, that's all wrong.

But uh at the time I I think you know things made sense.

But I I as I was kind of doing the write-up for them, you know, the the words were just like flowing, like it was really easy.

I was like, I should, you know, I could probably write more on this.

And and so I I'm pretty sure I was coming back from a conference or something and sat down on the airplane and wrote like 5,000 words on you know, like how to how to set up scaling and and how this should be done or whatever.

And it's like, all right, I could probably do a book out of this.

And so I

You were doing you there was a link and loop update or a Friday, like it was an email.

But yeah, yeah, we will

have years behind you.

Like I I I was doing that, the the newsletter thing uh mostly on my own, and I just got sick of it.

Um but

Like actually Jeff came on to that because I was basically ready to just be like, I can't.

Like um, so and I you know having that having a couple weeks where you can just be like, I'm just not especially when you're not really you know you're not really getting paid for it, so it's the right easy to drop.

And um I mean it I think barely we have ads which covers the cost of the Rails app that we use to host it.

So it's not a you know, it's for the community.

Because that's Discord.

So the whole the whole Django ecosystem built on the side.

Jeff and I got some emails from people saying, hey, how come you're using a Rails site for this?

And it's like, well, if you saw that it was a Rails site, you would have seen that it's also a company, and you know, yeah, we could have built it, I guess, but uh I don't need I don't need to build everything myself.

I was like, and I was like, but hang on, I heard about that on your email, and you would oh yeah, yeah, yeah.

Totally.

So you were on the you were on the plane, you knocked out 5,000 words, you thought, yeah, I'm gonna do that.

Yep.

So so I kind of was like, all right, it I should make sure people are gonna want this before I you know kill myself writing the rest of it.

So put it up on Kickstarter, and the Kickstarter did well, and I think the only reason it it got finished was because of the Kickstarter, because uh I I write like the the first 5,000 words were really easy, and you know, it was relatively easy some of the other stuff, but there was a lot of stuff that was you know where it's like I'm pretty sure this is the right way to do it, but now I really need to like, you know, if I'm gonna write it in a book, like I really need to fig

ure it out.

And so, you know, going through and testing stuff, and then parts where you know I was a little fuzzy and I needed to lean on some of the other people we work with, uh, and um it it just got grueling towards the end.

And I I hear a lot of people that have you know published a book say this.

So I I really think the only reason it got completed was I had taken people's money and and committed to a date that it was going to be done.

And so it was like, all right, I you know, I have to do this.

Um and and this part of the reason I haven't ever finished a second version.

I've I've tried to pick it up a couple of times, and uh I you know, I I get through some of it and I'm like, I think I have PTSD or something from the from the first time.

I can't force myself to sit through it.

Um, but you know, like you were saying, you know, talking about deployment, I I think one of the realizations as we were writing that was um that book is not terribly Django specific.

Uh a lot of the things in it are kind of common deployment scenarios.

You know, you've got a a caching layer in front of some app servers and a database, and you know, you cache some database queries, and uh that's the general architecture.

And I think that's the thing that when we you know did this consulting job that it was was missing, it was like they they it cobbled these other pieces together, and um uh so I think that's where I started getting more into being interested in deployment and and kind of configuration and all that.

And these days I I don't really do much Django development at all.

I'm kind of more focused on um running servers and uh you know doing deployments and Docker and containers and and all this fun stuff, um, which is a little weird because it's kind of full circle from where I yeah,

So uh yeah, that that's um so the one thing I wanted to mention with the book is uh so we originally put it out in can't remember if it's 2015 or 2017, but it's a few years old now.

Uh I think I still stand by a lot of the information in it, but there is some stuff in there that's outdated, either you know, packages we were using that that aren't um around anymore.

Uh and and like I said, I've been hoping to to do a new revision of it, and it just hasn't come to fruition yet.

So we're actually working with somebody now to get a free version of it published online.

Um you'll just be able to read um read it on the website.

Uh so I'm hoping that'll happen in the next month or two.

Uh and then I I've I've I I have not wanted to sell it anymore because I don't feel great that it's you know outdated, but I also don't want to just throw it in the garbage because I feel like there's still a lot of valuable information in there.

So this seemed like a it's run its course, you know, uh uh and uh seemed like a good way to kind of uh partially sunset it, I guess.

I mean it go on.

It was really more like, as you said, this is how you construct it and these are the tools.

So even when I so that has longevity as opposed to like like for me, like I have to every nine months update my code snippets, um, which is like you know, uh you know, if they didn't sell, I would definitely wouldn't do it.

So um I appreciate when I wrote when I read it that you wrote it at that level.

Cause I think that is, especially with deployment, it is something where the the big topics are kind of the same.

And as I recall, like I think the two big things you said is basically database hits hurt you and you know, cash all the things, and then you broke down the steps in the second half.

I think is when you got more into like Nginx and and like the server itself.

Um, because this is pre-platforms, or I appreciate you didn't mention Heroku or any sort of hosted service in the book.

Um, but I you know, I I've always felt like that stuff's great for people that you know need to uh do all sorts of weird custom stuff, um, but but Heroku and and the like are are really the place to be for your kind of average person to even you know running a business or whatever.

Most people are not uh Google scale companies and don't need to operate as if they were, you know.

You had a something you're gonna add there.

There was a another one, the O Raleigh one that you know I have on the shelf somewhere, but I I can't remember the name of it right now, but it was the same.

They the examples were using MySQL and PHP or something like that, but it was the same patterns, you know.

It's it's the you know, the the write-through cache, the you know, the database optimize that, scale it out, have a read replica if you can, or you know, these kind of things which are exactly as you said, kind of um implementation agnostic.

It doesn't matter whether you did it in Django or Rails or you know, Elixir or whatever, you're gonna have the same problems.

Yeah, and yeah, I I totally agree.

Yeah, you're basically your your application is this, you know, your application and your database are the slowest parts of of whatever you're doing, and the more you can avoid touching those things, the the better off you are.

Yeah.

So I want to reference um, you gave a 2015 talk on Django deployments done right, which I watched before this, and we'll put a link to that.

That covered a lot of way, you know, best practices.

I because I was thinking about that company because uh I'm wearing a Quizlet shirt.

I worked at this company Quizlet that's now grown.

And you know, so why do companies get themselves in this holes of technical debt?

You know, it's partly because they didn't know any better, it's part, but it's also partly because like they've got their own fires to deal with.

So it's like even though it takes extra time, it's like no one has time to spend a couple of weeks, if even if they have the expertise to like build, you know, burn it down, which is sort of why consultants are great, because you know, you don't usually just sit there with nothing to do in a company, um unless you're going out of business, and then you got all the time in the world to refactor until you lose all your customers.

Yeah, and I I think people, you know, I think in the the talk I I kind of hit on it a little bit, but I I think people forget about the like the human cost of all of this.

Yeah, if you put you, you know, yeah, you're running a million of miles an hour and you don't have time to optimize your deployment process, but if your site's going down half the time you're deploying and your team is like, you know, totally stressed about it and uh you know constantly like waiting for the next fire to happen, like you're gonna get burnout.

People are gonna leave.

Like people can't do that for a sustained amount of time.

And and kind of looking at how do you give people a calmer, safer environment, and and there's benefits to both sides on that, you know, like there's surely if you're if your site goes down, that's a uh an expense on the business side.

Um, but it's also you know taking a toll on your team.

Um and and I think making that stuff so it's it's not stressful, it's not, you know, like a oh god, like my hands are sweating moment.

Um when you when you push that button to deploy is is huge.

Uh and I've I I know I've been there, like I've been in those situations where it's like this is terrifying.

I I just waiting for something to topple over when I push this button, you know.

And it's like, no, no, no, no.

No, you can't be you can't be in that position.

You've got to, yeah, if you've got a fix, you've got to be able to get it out.

Yeah.

There's there's like day one, there's very little value in branding tests, right?

Yeah.

Like, you know, the the the value comes two years down the road when somebody has to refactor or upgrade, and like they can do it with some peace of mind versus uh you know, being having to go through and click everything or whatever.

Uh yeah, I think that's a that's like a savings account, you know.

Yeah.

And you know, in a crunch, they basically learn that if you know developers will say it takes four weeks, and they'll crack the whip and say, Well, get it done in two weeks.

And so developers will ship something that looks like it works in two weeks.

And the takeaway is the the PM is like, Oh, I just gotta crack the whip on these lazy developers.

And developers are like, that was terrible.

There's no test coverage, I'm only doing that a couple times, and then I'll leave.

So they both feel like they won, but the company's lost.

So I always try to like tell the non-technical people, like, you gotta build in overflow for testing, deployments, you know, because I know you can't see it, and it makes you sound good to your boss, but you're killing your team here.

So if you want them to stay around for more than a year, you need to, you know, do something different.

Even just like like a even like psychologically, like with especially with testing or or bugs in particular, like having like a bug squash day, like Equislet, we would have it once a month, we'd have a day dedicated to bugs.

So that let the PM offload the um hierarchy to the developers.

It wasn't just like I'm saying no all the time.

It was like, okay, I'm gonna clear the overhead space, and then you need to prioritize, and then you know, you then you have fun with it instead of just like this endless queue of you know, uh, these bugs, these tests, these deployments.

So there's also like a psychological part to it all.

And yeah, that's that's hard it's hard to make the business case on that sometimes.

Um, we we deal with with uh with our clients, you know, they uh they may not see it um immediately, but but you have to explain, you know, yeah, it's it's important that you upgrade this library, and you know, you've been we're gonna spend 10 hours on it and your site's gonna work just like it did before.

You you change the oil you change the brakes you change the tires you you know you you put new what wash in the wipers the car drives the same but you wouldn't not do that right yeah you know

it's gonna run 10 years later you know like the Bitrod is a really weird thing that like yeah you build something and then it just it you set it aside and five years later you know a year later it doesn't work anymore.

ome like you know woodworkers or something totally analog where things don't need changing but the antidote is I try to tell myself well what about like a chef a something a chef makes something it's literally gone in 20 minutes you know so you know on the spectrum of things like it does last a while you know um but yeah you need to have like offline things that you do uh so deployments let's talk about app pack um because this is something new that you've just I think just publicly announced right can you say what this is ye

hing in Bodo or Boto3 and assuming you could still get you know that version of Python to run like it'll probably work in a few years uh maybe five years um and I I don't think you get that same kind of guarantee with other stuff uh you know if I we used uh salt stack um as a configuration management tool in the past and you know upgrades were always kind of scary as like the service area is so big what's gonna break it's kind of hard

thing to test you know um uh so I I've kind of over the years transitioned from writing you know building site building and deploying sites as if they're on a Linux server and that Linux server could be anywhere to taking more advantage of the you know I think the the term these days is like cloud native you know um like AWS specific tools or if you're on GCP or Azure or whate

ver um they've got some pretty nice stuff there like we've been using RDS uh Amazon's database service for a long time and that's amazing like I I would gladly pay extra money for them for me to never have to think about a database again like uh yeah I don't have to worry about backups or you know upgrades or whatever like it's just taken care of and that's that's huge.

Like I'm happy to run stateless services that you know like it's okay if the app crashes or goes away like we can get it going again but yeah losing data is a different story.

So so yeah when uh we we've kind of been slowly transitioning uh from from this like configuration management on Linux servers type scenario to uh to more uh kind of cloud native stuff and and using a fair amount of uh Amazon ECS which is their container service um it's sort of like Kubernetes uh I'm not a huge fan of Kubernetes myself

uh just because we don't operate at a scale where I think Kubernetes is really valuable.

You know even our clients that get you know millions of page views a a a day they're running like one or two apps you know we've got multiple environments for them but they're not running a hundred a thousand apps or you know different projects um so so for us I don't think Kubernetes makes a ton of sense uh and I I sort of like Docker was a tough one for me um you know it's it's another kind of layer of abstraction but

but there's value there in being able to bundle your application and and getting it out onto servers and Amazon ECS kind of lets you do that same thing as as Kubernetes and just say hey I've got this image just run it I don't care where it runs or how it runs or whatever just you know make sure it has this much CPU and RAM and and run it somewhere um which I I think matches the mindset of kind of how most developers want to work on projects like I

need I need this much RAM for this thing and just run it.

I don't care where it runs I don't want to have to secure it I don't want to have to deal with any of that but like Amazon's stuff is I think their their backwards compatibility is sometimes like a blessing and a curse.

Like some of it's just feels really archaic and like the amount of hoops you have to jump through to kind of glue these services together or even figure out which services to glue together is is non-trivial.

I've got my head wrapped around it but trying to pass this off to somebody else who's focused on python or JavaScript development like good luck you know like not that it's like you know you need to be really smart to do it but it's just like a lot of stuff you need to know um and it makes sense once you know it but it it's it's too much so so anyhow uh that's where kind of at pack came from and I think I started it when uh covet hit

and I was like kind of stuck in the house and it's like you know I I think there's uh I can I can glue some of these things together and and make this work a little easier and always kind of having in mind like Heroku does this really well and I I would tell anybody like if you fit the Heroku model like you use Heroku they're great like that that's that's the general put you push your code they figure out like yeah it's Python and they put it on a server and you don't have to worry about they

an Amazon server.

So if you want Elasticsearch you got to go someplace else and get it and and you have to run that traffic over the public internet and you know you have to trust some third party with your data or you have to go to AWS and set it up yourself.

built on Amazon right so the Amazon uses Amazon Web Services internally and you kind of start to see like okay like if I was going to build like a microservices version of a platform as a service, all the microservices you need are there.

You know, it's got a way to to store secrets, it's got a database, it's got a way to run containers, it's got load balancers.

Um, so at pack was just kind of a way to glue those things together and sort of spackle over all the extra knowledge you need.

You know, 90% of the time, everybody's gonna set it up the same way.

Um, if you want to like follow best practice or whatever.

Uh so yeah, um, that's what I've been working on.

I started, I guess, last May.

Uh, and so our our site runs on it, but that's not really that exciting.

It's pretty uh trivial.

Um we're rolling it out to a larger client um this month and uh kind of just trying to work out any kinks or you know figure out what doesn't click for people.

Um and uh we've been rolling it out to kind of some uh individuals as well.

Uh so the the way it works is is you bring your own Amazon account, um, but we kind of give you all these tools that set it up in the right way for you, and your data, your app all run in your account, and you can have your controls on that.

Um and we kind of just run uh so we built a bunch of cloud formation templates, um, which is like Terraform, it lets you set up a bunch of resources there.

Uh, we have a CLI and a web dashboard um and uh an auth service that uh let's see, auth service, and then uh we have um something that plugs into Amazon Event Bridge, which uh lets us get notifications on what's happening in your environment and then kind of figure out what needs to be done and send the right AWS API calls to keep things moving along.

So uh an example would be like, you know, you set up a project, you push your code, a build triggers when the build finishes, then that sends a signal that says, hey, this build is successful, and our code can say, okay, now we need to figure out if there's a release task like Django migrations that need to run.

And if you've defined that, then we kick off a task in ECS that runs your migrations.

And then if those run successfully, then we kick off a deployment that that updates your site.

And like that kind of stuff that seems like it should be really easy and trivial is like actually kind of challenging in in AWS and in kind of eventually consistent container land and all that.

So um yeah, we we kind of take that off of people's hands.

Do you have is it currently, or do you have plans for it to be, you know, Rails or whatever language framework?

There's a a project out there called uh build packs, um, cloud native build packs.

Uh and that's uh I think originally it spun out of Heroku, um, but uh a bunch of other systems are using it now.

I think Google Cloud Run uses it.

Um I I can't remember uh a bunch of other people use it.

And so um you can use all of Heroku's build system.

Well, not all of it, but like the a lot of it's been open source.

So um you just define, well, it can go in and detect what your app is if it's a simple app.

So if it goes in and sees a requirements.txt file, it'll say, oh, this is Python.

If it sees package.json, it'll say, oh, this is node, and it'll build kind of following best practice and in a generally sane way.

Um, so so we're using that.

So yeah, it's it's totally it.

I think there's eight different languages that Heroku's build packs support, and there's other um uh other kind of like Google has their own build packs.

Um, I think the Cloud Foundry Cloud Foundry has some build packs out of their own, but I Heroku's some of them don't support Python, Heroku's does, so that's so it's

Than say a Docker file.

Um and I think that's like just another example of like this balloon of knowledge that you need to have.

Like the fact that people need to understand Docker and how to write a Docker file uh to be able to deploy an app is crazy to me.

Um so yeah, this this kind of manages that for you without you needing to have Docker on your machine and and no Docker.

You you can use it if you want, but uh you don't have to.

Yeah.

I mean, so my third book, The Professionals One, uses Docker and writing it was a challenge to make it accurate but simple.

And I get so many Docker questions.

Um, you know, and it is it's hard to because I wanted it to be, I th I I do think Docker is very common, and also because Mac, Windows, whatever system, um it's helpful that for me I can just write the same thing, though.

Of course, there's been some Docker Windows stuff, anyways.

Um I

Yeah, anyways, I was like, of all the you know, I'm using Docker for it to be the one true thing and it you know it breaks for a while.

Um, but it is a total I I don't like as a content creator, I don't like just being like, yeah, you need this.

Here's like a couple paragraphs, just run this Docker file and don't peek under the hood.

You know, it's like a million lines of go and it works until it doesn't.

And when it doesn't, I don't know what to tell you.

Exactly.

And and we deal with that, we you know, a lot of our client projects, um, there there's I don't know, maybe 50-50 of folks uh at Lincoln Loop that develop locally with Docker.

Um and if you're hopping from project to project, it's a kind of a godsend uh that that you know you can just jump on another project and do Docker Compose up and things just work.

Um, but if you're yeah, if you're working in the same project day in and day out, and you know, you know how to set up your own machine, it's it can be a real hassle.

Like it gets in the way.

It's it's slow, it's um, you know, especially on Mac where you're like under the hood, there's a Linux virtual machine that's running everything.

And how are you, you know, the way it shares files across that is kind of weird, and yeah, uh, you know, the networking stuff's kind of weird, and just throwing it at somebody and say, like, oh yeah, just use Docker, you're fine, you'll be fine.

Like that's a that's a big leap right there.

That's what I do.

It works out okay, but yeah, I I agree.

I mean, we do, we have things packaged together like App Pack, but it also seems like the bigger ecosystem of what you need to know grows, right?

Because people ask me, like, how do I learn how to program?

It's like, okay, well, HTML, CSS, databases, SQL, Python, JavaScript, you know, you know, I was like, and that's just to get started, and then you can try my beginner's book.

Um I w I wish I, you know, I wish there was a the what is that balance, right?

And then then and then Docker and all these things come on, and it just seems like it's sort of people just learn it as they need it, but they just kind of like band-aids, right?

No one really has the time or the resources to like fully understand Docker, fully understand, you know, whatever the tooling, because there's so much tooling.

But anyway, so that's why, you know, especially with deployment, something like App Pack, Heroku, um, button, which Carlton's working on, these tools make all the sense in the world.

I mean, personally, like, I have no interest in ever spinning up a Linux box.

Like, I I'm I never want to do that ever.

Yeah.

It's like it's got nothing on it, so you then you've got to install everything.

You you don't want to do that.

And then you're yeah, I feel like you end up in the same place there as like with the testing thing.

Like, yeah, sure, you can spin it up and you can like manually install all your packages, like assuming you know how to do all this stuff and like get it running.

What happens when you now need to, you know, you want to get a new version of Python and it's it's not easily installable on your system.

And you know, how do you move all that stuff?

How do you manage upgrading the system?

How do you make sure like somebody hasn't you know hacked into your system or what?

Like, there's a whole lot of extra stuff beyond just like getting it running, um, which which we know as developers, you know, like once you've gotten it running, like that's you know, maybe half the battle.

I don't know, like doing tests and refactoring it and making it understandable and copying it and documenting it.

And if you can't redeploy it on fresh architecture with the same ease, or you know, it's gonna take a bit longer because you've got to you know spin up the new whatever, but that's the test.

Can you can you redeploy it?

And if you can, then you're in a good place.

For sure.

I don't, you know, it it targeting a um a smaller scale thing.

I'm look like because I'm looking at you know helping individual developers who you know they they want to get their app online.

It's more about it.

So I'm building a native Mac app and you know a native app where you can enter your um variables and enter your secrets so they'll be encoded in the app and then it'll launch it and get it into the right place for you with those environment variables populated so that you don't, you know, that difficulty that people have where they're committing secrets to the repo when they don't know how to you know they don't know how quite how to manage that.

And so it's more targeting that layer layer rather than spinning up a you know a an east ECS cluster, which I think is a bit um is a bit too much for the the the kind of user I've got in mind.

Is that to put stick something on AWS, that's the right place to put it for me.

But you don't want to have to deal with all of that nonsense just to configure basically a a correct um AWS environment.

And the the thing you said that's 100% correct is that 90% of people are gonna do it exactly the same way every single time.

And it's that 90%, yeah, fine.

And and for me with button, I'm you know, I'll I'll out straight up saying, look, if you're already into containers and you know Kubernetes or you know, you you know all this stuff, then buttons not for you.

It's buttons for uh, you know, I've I've I've I've written my first Django app.

How on earth do I get it online?

If you can for whoever you know like solves this problem to you know take the polls app and you know put that up the easiest, you know, because that's for someone new, that's what they want.

Um, but you know, the docs isn't gonna do that because Django itself doesn't do that.

And um you know, and in some ways it's like the early framework Scrum, right, where Django was one of many uh Python-based frameworks.

So hopefully there'll be multiple ones that sit between learning AWS and um Heroku.

It certainly seems like there's plenty of room.

Like there's the the you can't possibly serve, you know.

I could, you know, if I if I worked on button for the next decade, I could cover like half of the the territory with features and it would be bloated and unusable.

It would be exactly the thing I'm trying to provide a solution for.

Um and and so I can I can target one niche and P P can target another one, and then and Amazon's up there going, look, we're basically talking to infrastructure engineers.

And if you're not one of them, we don't want to talk to you.

And so, well, most people who want to deploy an app, they're not infrastructure engineers.

it's not worth it.

Uh I I posted an example on Twitter the other day.

So I was um, you know, part of what we do is like set up a load balancer for people and add a certificate so it's got you know TLS and all that, and um, I was updating that so you get uh logs from your load balancer because that's something people want, you know.

And it was uh when I finished building it all out, it was 10,000 characters of JSON for cloud formation to, you know, you set you have to set up it, it gets logged to an S3 bucket, you have to set up your S3 bucket.

You have to set all these like arcane IAM policies to allow the load balancer to talk to the S3 bucket.

If you want to be able to like tear it down quickly, then you need to write custom code to empty all the files out of your S3 bucket before you delete it.

Uh, you need to write like special stuff so uh by default it'll just keep filling up your S3 bucket.

Like S3 is cheap, but you don't want to keep logs for you know five years.

So you need like a custom rule to delete old logs, and like there's just it's so much there, it's mind-boggling to what you something you would expect.

Like, this seems like it should be like a line or two, you know, like yeah, I want logging, you know, like that that should be easy, but uh it's it's not.

And at the end of the year, I was looking at my diary and I was thinking, do you know what?

I actually didn't make any progress from the whole time COVID hit till the end of the year.

And I said, talking to my wife, I said, Well, you know, I've got to find some time.

So I've got this button Saturday, which Saturday morning where I can sit and work on it, and it my button Saturday is just like creating these, you know, these rules putting them all together so other people don't have to.

It's smiling at that.

Smiling at that.

Well, I

Like you can put it together however you want, you've got tons of flexibility, like there's certainly value in that, but uh it it it gears it to a very specific user, you know.

Like its docs are pretty out of date.

I know the the sort of Django overlord they've had has changed a couple times over the years.

So, you know, even Heroku doesn't have a simple story for Django.

Um so so just as a you know, just like Stripe started off as payments for developers and now it's for everyone, you know, it seems like that's a nice logical progression for a hosting platform too.

Like if you can nail the Django piece, because it is, I mean Heroku, Python Anywhere, I guess there's Replit.

You know, there's just such a chasm to spending the time that you the two of you are doing, which most people don't want, don't know how to do or don't want to do.

Like, oh, you need Django storages to do that, and you know, how do I like use DJ database URL to like there's all this this kind of knowledge that we have, having done this before, that coming in as a new person is even that's like just that part's overwhelming.

Just getting a uh I I I gave a Django Khan talk on this that was like prepping your project for production, like it's uh it's a big deal, it's a big difference between getting something running on on localhost versus uh getting it running elsewhere, just even without all the how do you how do you do deployment stuff, just getting your your code ready?

So, oh god, I've got to set on my domain for email and I've got to verify the domain and do those funny DK, whatever the Jobba thing records.

And ah

It's like through our auth.

They used to be able like use four or five years ago, you'd be you could do that.

Well, and then even if you say I'm gonna build like a really, really basic Django site and show you how to do it, well, I need to show you email.

And you know, Sendgrid last year changed something major, so you know, so it's like I when I first built the first editions of my books, because like on version five for them, I had you know all these other services I would use, and now I'm just like really trying to strip everything away because they change so much and you know beyond the control.

Um and yet, you know, as a jobbing developer, that's what you have to do is keep up to date with these things.

So anything that can be hosted and out of sight, out of mind, it's like take the money.

I don't want to deal with it.

For sure.

When so people should sign, is that the action item for people listening?

Go to uh pack.io.

Uh I'm I'm trying to keep it really small, uh, just to kind of get feedback and and polish the experience.

I'm I'm taking the uh I I can't, is it Reed Hoffman or you know, if you're not embarrassed of your first version, you waited too long to launch.

Yeah.

Um it works.

There's you know, there's rough edges, but uh I'm guessing a lot of people probably wouldn't, you know.

I know because I can peek behind the curtains, but a lot of people hopefully wouldn't even notice it.

Uh um, so yeah, just we're we're kind of trickling people in right now and um hoping that uh we get enough kind of feedback from that to do a larger public launch.

Super.

What any is there anything we've missed that we haven't covered that you want to mention to folks?

Um no, I I think you hit it all.

Uh you know, like I said, um so yeah, Lincoln Loop, we're still doing, you know, Django consulting and and helping folks with either build Django sites, maintain them, uh support them, all that.

Um and and at pack's kind of been my my personal project over the last few months.

And um yeah, look for the high performance Django stuff online soon.

And yeah, that's that's what we've got going on.

Super great.

I know we've long wanted to have you on, so thank you for accepting.

Thanks so much for reaching out.

I enjoyed it.

Bye bye.