Have you ever wondered about the software stack powering Talk Python, the training websites,
the mobile apps, the video and audio delivery, and more?
While at first glance, it might seem pretty simple.
There's quite a bit going on, actually.
We have our own custom search engines.
We deliver about 15 to 20 terabytes of traffic per month.
Our course video streams from eight locations throughout the world.
Our database server is sending about 12 megabits of traffic sustained all day, all night,
with no media in the mix.
And all of this stuff is powered by Python.
So this week, it's a bit of a role swap.
Dan Bader from RealPython is here to interview me about the Talk Python tech stack.
But we do get a chance to compare my tech stack with RealPython's,
a site which is becoming quite an important one for developers in the Python world.
This is Talk Python to me, episode 215, recorded on scene at PyCon 2019 in Cleveland on May 6th, 2019.
Welcome to Talk Python to me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is sponsored by Linode and Backlog.
Please check out what they're offering during their segments.
It really helps support the show.
All right.
Hey, folks.
We got a little bit of a different one this week.
So I'm excited to be here with Dan Bader from realpython.com.
Hey, how's it going, everybody?
It's good to see you, Dan.
Likewise.
This is so unreal because the last couple of times when I was on your show,
we were not sitting right next to each other at a hotel in Cleveland,
but we were doing this over Skype.
And so it's kind of cool, actually.
It's super cool.
Yeah.
And greetings, everyone, from the tail end of PyCon.
Not quite from the conference floor anymore since they cleaned that up.
So now we're at the hotel floor.
Yeah.
And it was a really sweet conference.
I mean, I don't know.
I'm sure you had a great, fantastic time, too.
I know you were always swarmed and surrounded by people and fans
that want to take photos and chat with you.
And yeah, it's really, really cool.
It's one of my favorite times of the year, honestly.
It's exhausting, but it's great.
Yeah.
I know it was an awesome conference.
I mean, thanks to everybody who organized it and put it on.
It was really, really amazing.
I feel like it's just getting better and better every year.
And there's more interest in Python.
And it's just so cool to hang out with the community.
Yeah, absolutely.
You meet all these people that you collaborate with on the internet or other things.
And you would never run into them because they live in Australia or Vancouver or wherever.
Yeah.
But here you run into all of them.
It's amazing.
Yeah.
It's really, really cool.
And one of the things I like the most is when you've been working with somebody or you know
them online, but you never actually met them or been on a video call.
And then you run into them.
You're like, oh my God, I had no idea.
Oh, this is you.
Like, this is so cool.
And it's, yeah, it's just been a ton of fun.
Yeah.
Another one of the takeaways, I guess, is everyone's just a person, right?
Like all these people working on these amazing projects.
They're really open to meet you and share ideas.
And like, if you just go and say hi, like chances are, you know, that you'll get to learn a lot
about, you know, whatever you're interested in.
Totally.
Yeah.
I think everybody is really, really welcoming.
And I mean, that's the whole point.
I mean, that's, I'm sure it's the same thing for you.
Like, that's why I go to these conferences, right?
To hang out and meet new people.
I'm not going there to hide behind my laptop or just be in like business mode, but it's
just fun to walk around and chat and grab a cup of coffee or beer with somebody.
Yeah, absolutely.
I consider this my geek holiday.
Yeah.
So I did say the opening that we have something a little bit different.
So we're going to sort of reverse the roles.
And Dan is going to interview me somewhat, but we're also, I'm also going to have a lot of
questions for you, Dan.
Sounds good.
Yeah.
I'm looking forward to this.
So a lot of folks have asked various questions at different angles, like how have you built
your Python stack?
Or why are you serving your audio this way?
Or how did you build your new mobile apps that you released?
Just all these different questions about the tech involved in the podcast and the training
and all the derivative stuff from that.
So I decided, Dan, you would be the best person to sort of represent the audience on that side
of the conversation.
Because one, you're super knowledgeable.
We're good friends.
But also, because you are also running a pretty high-end website.
Like, RealPython is one of the biggest Python sites out there these days, isn't it?
I mean, it's kind of hard to measure that in terms of, I don't know, like impact and everything.
But I can share some stats.
We just hit 1.3 million unique users per month.
So that's like several million page views a month just on RealPython.com alone, which
to me is just an insane number.
So yeah, I think, first of all, thanks.
And I think we're up there somewhere.
Yeah.
It's awesome.
Yeah.
It's definitely really, really growing since you've taken over stewardship of that resource
in the last year or two.
And it's awesome to see.
So we're going to talk about RealPython.com and what you're up to as well.
Cool.
All right.
I guess one of the things I did want to start to set the stage with before we get into
this conversation is we'll talk about some part and people might go, well, why didn't
you build that serverless?
Or why isn't that a microservice?
Or couldn't you have hosted this here in that way?
And probably the answer is yes, yes, and yes.
But I'm not doing any of those because there's just a lot of ways to make this work, right?
There's a lot of choices out there.
And I think maybe that's even why people are interested, right?
If like if it was you go to HP and you ask for a rack of servers and you set up this software
on it and you put it on the internet and that was the answer, like nobody would ask, how
many servers do you have?
I have three, one U servers.
Okay.
Interesting.
Right.
But because there are all these choices, I think it's interesting.
But I also want to just set the stage, like the choice that you might have made may
be different than the choice I'm making or the choice that Dan is making.
But, you know, just be aware, like they may all work, maybe better, maybe not.
I don't know.
But yeah, we're not judging.
And so please give us the same favor in return.
And I think there's also, you know, with all of this stuff, there's a huge like hindsight
effect here, you know, happening here where sure, we could have built this probably on a
number of different platforms and hosting services and tech stacks.
But a big reason, I mean, for me personally, why I'm doing all this stuff, you know, why
I love being involved with the Python community and being able to teach in the Python community
is that I get to play with these things and build software in the way that I like to and
that I enjoy.
So not everything is like a pure what is like the most effective or efficient way to do
this.
So that's so interesting.
You just made me realize I did the same thing, but unconsciously.
So like, I knew nothing about deploying on Linux.
So I feel like I originally tried going down the platform as a service route and like things
that would hold my hand as much as possible.
And then I'm like, no, I feel like I need to know this.
So I'm going to go force myself to use the infrastructure as a service thing and learn
Nginx and MicroWisgi and Linux and all these deployment things and how they work together.
So that if I guess so, I wasn't be a weak spot for me or something.
And I do feel like I took that on as like a learning challenge as much as a good way to
deploy.
I think it also works really well, but like also to learn, right?
Like if you get a chance, totally.
It's worth pointing out that you and I both run small businesses.
We are not at a huge enterprise with somebody that has made rules about what tech we can
use.
We can use anything long as like we're willing to live with the consequences, right?
And so at least personally, I use that as an opportunity to say, I want to use this tech
so I can learn it as well as I think it might be a good idea.
Yeah.
I think that's a big part of it.
And then, I mean, also, you know, wouldn't it be a shame if the biggest Python podcast was
hosted on a bash script somewhere?
Like it's got to be built on Python.
It's a Java app.
Yeah, I guess nobody's questioning that decision, right?
To build the app in Python versus some other tech stack.
Exactly.
I kind of think like set the stage, we're running on Python, both of us.
Let's start there, actually.
That's an interesting case because when I started the podcast, I didn't want to start a Python
website.
I wanted to start a podcast.
And yet, I needed a website to serve the RSS feed and the MP3s so that I could have a podcast,
right?
Like it was table stakes.
And right now, there are pretty decent options for hosting a podcast if you're willing to pay
a little bit.
Like fireside.fm is not bad.
Brian Okken uses that for testing code, for example.
When I started Talk Python, there was a few options and they were bad options.
Like they were not so good.
So, I looked at that and I said, well, am I serious about this?
Like do I want a site that looks good and people will respond to?
Or is going to look like the worst WordPress theme you've ever seen?
But technically, it will be an RSS feed.
And who cares?
You don't go to the website, right?
Yeah.
I totally get that.
And a lot of this stuff has changed also, I think.
Because when did you start Talk Python training?
I started...
Or the podcast?
The podcast started in April 2015.
The training site started in 2016 and February 15th.
I know because that was my day I was free from full-time employment.
Yeah.
And so, you know, with all of this stuff, I think, especially in the podcasting space, you
know, a lot has changed.
I mean, now it's sort of a legit thing like hosting a radio show.
You know, my parents listen to podcasts and not my grandparents, right?
But like people know about that this is a thing.
And when I think back, you know, even like three, four years ago, it wasn't at that level.
I mean, even just looking at the apps, you know, I really like the Overcast app, for example.
I don't think that was out back then.
And, you know, it was just all like basically Apple, iTunes or something.
And it's really changed and grown since then.
So now there's probably all kinds of different options.
But there's a lot of personal investment and all this like custom software that you've built.
I mean, that we've both built for our businesses.
And there's sort of also a barrier to move to something else.
I feel like we sound super defensive talking about this stuff.
Well, I think it's really interesting to consider like, should I have just said, no, I'm not going to build, say, for example, talk Python.fm and Python and build it myself and do the web design myself and all of that and figure out how RSS feeds and work.
And how am I going to get the video or the audio delivered without like breaking the bank and bandwidth and all of that kind of stuff.
Like I could have just put my credit card in at Podbean, got a crappy site for, you know, $5.
I don't know what the price is or whatever.
And just gone with that.
But, you know, I felt like there's going to be a point where I want to do something that it doesn't do.
And do I want to be walled off over there?
And also, it was a little bit of a learning experience, like you had said, like, oh, this will be to be a cool thing to run to understand how it all fits together.
So I just understand it better.
Yeah.
But, you know, I would say like three months in, I never started the podcast thinking I would get sponsors.
I thought that was a crazy idea.
It would just be something that I could, you know, have a community of people I interact with because I didn't have that.
But about three months in, one company approached me and said, hey, we would love to sponsor your show.
It looks so nice and polished and professional compared to all the other stuff out there.
And it's because all the other stuff was hosted in places that were like super cookie cutter and not so great.
And I'm like, it started to feel like it paid off at that point.
Like, oh, yeah.
And I can like feature them in this way that wouldn't be possible if it were there.
You know, like it slowed down the start, but it seems like it really paid off in a long term.
Yeah.
And that makes a lot of sense.
And I just wanted to add to that, you know, also looking at my experience kind of building a custom tech stack.
There's a huge element of survivorship bias in all of this where if you can pull it off and you can, you're successful with a custom solution, it's going to be awesome.
It's going to make you unique and you're going to be able to build out all these unique features.
But for every like 20 people who are trying to start a podcast of their own, there's going to be a lot of people who never make it to the actual recording because they're spending five months building their own infrastructure.
I've been there, you know, not with a podcast, but with other stuff.
That's a good thing to keep in mind for everything, right?
Like getting started is the most important thing in this journey for whatever you're doing, right?
I guess just to put a bow on that, like when I decided I'm going to try to build a site and see if I can make it work before I decided to host something else, host somewhere else.
I started out on a Friday.
I said, all right, done with work.
I really want to create this thing.
I'm going to just go all in on this weekend.
And by Monday morning, it was like live and beautiful and ready.
And so it was like, I'm willing to try a couple of days to see if doing it myself is crazy or not.
And then I would have maybe gone and, you know, paid a couple bucks to Podbean or whatever, right?
I wouldn't have waited three months before I even tried the podcasting side of the thing.
It was like, this is exciting.
Let me try it.
And if it works, I'll go with it.
Otherwise, I'll pull a ripcord and do something else.
Yeah.
Like do a little experiment and then see how far you can get.
Yeah.
Yeah, exactly.
So maybe, I don't know, maybe it's worth talking a little bit about the just quick fly over the tech stack.
What do you think?
Yeah, I think it'd be interesting.
I mean, how do you want to slice and dice this?
Like maybe we should talk about like, first of all, what are the main services that you run for your podcast?
And you've got the training site and all these other things.
Right.
Because they all have different goals and constraints and whatever, right?
For example, the training site demands low latency video delivery where the podcast site, it doesn't matter at all if that's delivered a little slower because it auto refreshes on your app and you just open it and it's there.
Yeah.
So let's see.
I have talkpython.fm, which is the website.
And let's just group the audio delivery in for that one.
I have pythonbytes.fm that I do with Brian and it's audio delivery.
And I've got the training site.
The Talk Python site and the Python Bytes site have custom search engines that I have as REST endpoints.
So search.talkpython.fm, for example.
You can consume that and search that if you want.
And internally, the site uses that so you can search for stuff and whatnot.
Same for Python Bytes.
So there's kind of that side of things and the audio delivery there.
And then there's the training site.
And the training site is actually a lot more complicated, I would say, on the infrastructure side because it's got to deliver the videos.
It's got to do e-commerce.
It has a bunch of accounts.
But also it has to have the video delivery, low latency, anywhere in the world.
It has the apps, right?
Now it has the apps, the iOS and Android apps around it and so on.
So, yeah, that's probably the landscape.
Also…
Your mobile apps.
Yeah, inbound, outbound, email.
We've got a bunch of services there, like the video stuff, right?
So when we record the videos, we don't release what we record.
We have to transform it into certain formats that work well in like iOS and are minimized in their like video size based relative to, say,
the resolution.
And there's like all that processing pipeline is pretty interesting as well.
Yeah, this is super cool.
I mean, it's kind of mind-blowing, you know, to go over this and sit down and really tease it apart.
Like what are even all the services that you run?
Because it's so much stuff, right?
People would…
Isn't it just a podcast?
I thought this myself.
Yeah, you know, it's a podcast.
So what do you need, you know, a laptop to record this?
Like we're sitting here.
It's kind of a nice and minimal setup.
But there's a lot of infrastructure that is powering all this stuff so that your listeners get to enjoy this on their commute and in their cars.
I mean, just to give people a sense, like a while ago, I sort of summed up all the data usage, bandwidth usage of my various servers and whatnot between the database and then the audio.
Not even counting the videos, which are their own special thing.
And I think it was running at like 17 terabytes of traffic a month.
Oh, wow.
It's a lot of Python.
So, yeah, it's pretty cool.
It's actually pretty awesome to see.
Amazing.
Okay, so this makes us even harder to kind of slice and dice this and dive into the most interesting bits.
I know one of the things that you and I have had some conversations about is the whole like, you know, monolith versus microservices and most recently also the serverless approach.
And I think it would be interesting to talk about that a little bit because I feel like now there's sort of a return to the monolith in the industry where people got burned by the server.
Yeah.
The pendulum has swung a little backwards, right?
So, I felt a little uncool, to be honest, a couple of years ago.
Same here.
Because people are like, dude, how are your microservices working?
I'm like, well, there's three services, right?
There's, say, talkpython.fm and then it also has like the search service and then it has an audio delivery bit that's like a little bit separate.
But that's not really microservices so much, right?
Microservices are way more small grained, certainly.
You know, and talkbython training is like definitely a monolith.
But I try to have a really pragmatic view of these things.
Like, I'm not Google.
I'm not Facebook.
I'm not LinkedIn, as Brian likes to say, right?
Like, why do I need to trade that off?
And I guess in this context, I'd love to hear your thoughts on this.
But when I think of like the, should it be a microservice or should it be more monolith, it feels to me like what I'm doing is taking the complexity and moving it from code complexity in a monolith to operational complexity in a bunch of services.
I'm better suited naturally with my experience to handle code complexity than DevOps complexity.
If I was maybe really good at DevOps complexity and not so good at code, maybe I would have chosen microservices, but that wasn't where my capabilities were.
So I'm like, I'm going to play to my strengths here and just stick with this.
Yeah.
Which I think that is the best solution if you're running a small business.
And I mean, in our case, we're both building all of the software ourselves.
Yeah.
And we're basically the CEO and CTO and main chief account of all this stuff in one person.
And so I think especially then to go down a route of adding a lot of complexity, like operational complexity early on is not a good place to be.
And like what I found really inspiring is Basecamp as a company.
I mean, there used to be 37 signals.
I love their stuff.
I used to read like Getting Started, their book religiously.
Yeah.
And it's, you know, it's really good, really good books.
And I think also really, just a really, really inspiring company and really good or like really interesting from a tech stack perspective too, because they're totally going down the monolith route.
I mean, their CTO is basically the inventor or creator of the Ruby on Rails framework, which is pretty much like Django in the Python world.
And they're purposefully building software using monolithic approach so that they can be effective with a small team, which is ultimately if you're running a one person or two person business, super important.
Like, I mean, you want that.
That 20% efficiency or whatever is massive when you're small.
When you're a huge company, huge companies are massively inefficient, like from my experience.
So that's pretty interesting.
I'm definitely a fan of just having things working simply and knowing that you can change it, right?
We could break it into microservices if we need to, but yeah, same.
And I feel like just serverless is just like that, but plus more.
Like it's more pieces I got to manage.
And so until I need it, I feel like I'm going to stick with what I'm doing.
Yeah.
And to me, it's interesting also that, you know, your search service is a separate thing.
So you're, it's almost a little bit of a hybrid model there for you.
Yeah, a little bit.
Where, and I think the Python bytes, that's a separate.
That's a separate app, right?
And it's similar for me where real pythons are a separate app, right?
And it's similar for me where realpython.com is like a monolithic web app, but then we
have this feedback form system that's separate or the PyCoders weekly newsletter that I run
is also a separate application.
And I think it makes sense to kind of slice things up this way because then you can treat
those systems in isolation.
And I guess the question is just, you know, when, I think it's a spectrum of like monolith
to microservice to let's say serverless, maybe it was like really, really tiny microservices
basically.
And so, I mean, we're both not running pure monoliths, right?
In that sense where if it was a pure monolith, like everything you have, like the podcast
and all the APIs, the search.
It would be one single thing.
Yeah.
I have eight different servers that are participating in like all the stuff we described at the beginning.
So maybe I don't know when it is a microservices architecture versus when is it a monolithic
architecture?
Because I mean, you basically have a search microservice in that sense, right?
So I've always been struggling with those terms a little bit.
Yeah.
I think there's two driving forces.
One would be technical and the other would be sort of team personal based.
Like, is there a technical reason to have those two things separate?
Do you want to consume them separately?
Should they be versioned separately?
Should they live on separate servers?
Things like that.
That's maybe a technical thing that'll push you into this mini microservice light?
Microservice light?
I don't know whatever you call it, right?
We're going to term.
And then the other one is, do you have people who are not experienced with the whole thing,
but maybe they could work on the search service, right?
Like if I had somebody who was like a junior developer who came on and I was going to have
them work on the search service for a month, like it's not really worth it and it's not
that big, but imagine it were, right?
Like it might make sense to have that separate.
They can deploy it and live with it.
And if they take down the search service, it's not the end of the world.
You know what I mean?
But if they take down the main site, like all of a sudden it's a problem potentially.
And so I feel like certainly microservices are easier for different teams to work on different
bits or different people to work on simpler bits.
But like you said, we're mostly doing the software development ourself.
And so that's absolutely not a pressure that is applied to our stuff.
Yeah.
I think that's a good point where you want the ability for one of those services to go down.
Like if it's an experimental new thing that you built, let's say like the search and you're
playing with the or working on the search feature, trying to make it better in some way, you want
to gracefully degrade the experience for everybody who's using the website.
Maybe search doesn't work, but everything else would still work.
I did that, for example, when I built like an ad serving, like an ethical ads platform for
realpython.com.
And it's now also used on PyCoders Weekly and some other sites.
And there was the same thing where it's like, you know, I don't really know if I'm going to
be running this thing in a couple of months.
It's more an experiment.
And instead of kind of polluting my monolithic code base with that new thing, I'd rather have
it separate.
And so I could also scale it independently.
So I'm wondering if that also factors into your decisions, like maybe search needs to be
scaled differently or one of these sites is going to grow faster than the other ones.
Yeah, absolutely.
Like if you need to scale one part a lot, it's easy to just scale that tier or put a load balancer
in front of that.
Also, it's running under different core domains and different SSL certificates and stuff.
So maybe that makes it a little easier to have it separate, like search.talkpython.fm, not
talkpython.fm/search.
Although that's kind of maybe minor.
I could change that around.
But yeah, it's certainly a consideration.
This portion of Talk Python to me is brought to you by Linode.
Are you looking for hosting that's fast, simple, and incredibly affordable?
Well, look past that bookstore and check out Linode at talkpython.fm.
Slash Linode.
That's L-I-N-O-D-E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe.
So no matter where you are or where your users are, there's a data center for you.
Whether you want to run a Python web app, host a private Git server, or just a file server,
you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly
support even on holidays, and a seven-day money-back guarantee.
Need a little help with your infrastructure?
They even offer professional services to help you with architecture, migrations, and more.
Do you want a dedicated server for free for the next four months?
Just visit talkpython.fm/Linode.
One of the differences between both of our setups there that I'm personally really interested in
is that for the hosting aspects of the infrastructure, we're using different approaches.
Absolutely.
The way I understand it, you will actually provision an individual virtual server and then run an
application on that.
Let's say Python Bytes has its own virtual machine somewhere in the cloud.
I'm more like the infrastructure as a service model, whereas most of my stuff runs on platform
as a service providers like Heroku.
I don't provision my own Linux server and keep it updated.
I just kind of offload that.
And so I'm really interested in how the infrastructure as a service model is working for you.
If you ever considered switching, for example, or if you see some benefits in it.
It's working pretty well.
I feel like I've definitely gained a lot of experience that I wouldn't have, right?
Like, give me 15 minutes, I could set up a new HTTPS service on Nginx backed by some, you know,
MicroWiz gear, GPU record or something.
And having like that experience, DevOps experience, I think is nice.
I think the way I kind of got there was a little bit of that learning and exploration stuff.
I kind of wanted to have that as a skill set.
So like, let me try it.
And, you know, when I started, it was like $10, two $5 servers, one for the database.
Maybe it might have just been one, right?
Like on the same server even or something.
But it was like really just a quick little easy way to get started.
And it worked really well for me.
I'm like, this thing is just perfect.
It works.
It's up all the time.
I love it.
As things have grown, it's gotten a little more complicated.
And I feel like I'm still really happy the way it is.
But it's sort of taken on its own life a little bit to have.
Because you're provisioning your own databases, right?
You're not going like, oh, Amazon, I need to.
So the way I have it set up is I have MongoDB as my server.
I didn't start with MongoDB, but I have it.
And I have the different services.
And they have all different databases, but they all are on the same database server, right?
So all the main sites, training.talkpython.fm, Talk Python itself, Python Bytes,
they all have their main server in like a load balance failover server.
So if I got a reboot or do maintenance, I can just like automatically through Python with an API.
Like as part of the deployment stack, what happened or flow, it'll switch it to this other super, super cheap cloud server,
handle the traffic well enough while it's off, and then switch it back.
Right?
But all of those share a central MongoDB virtual machine that's like, instead of having a bunch of small ones,
I bought like one high, high performance one and they just share it.
Yeah.
And it's fine.
I mean, like if you go log into the MongoDB server and you pull up in load and you say,
what is the traffic on this server?
Like the average bandwidth is about eight to nine megabits per second continuously.
So it's getting a lot of work.
But if you pull up the CPU usage, it's one to 2%.
Yeah.
I mean, it's like, it could take way, way more of what it's getting than it does.
So why did I choose that?
Why don't I go on Heroku or something like that?
I feel like what I got is already working.
I'm really happy with the way it works.
I can make it do just what I want.
Any change that I want to make, I feel like the sky's the limit, right?
I want to change how Nginx works.
Fine.
I want to make it serve HTTP2 for this part, but not for that.
I can totally do that.
Did you ever have like some incident with the database, let's say,
where you have to rebuild it from scratch or restore it?
I've never had any problem.
The database, it's been that configuration, let's say, for about two and a half years.
I've never had it go down or get corrupted.
What I have had is the network infrastructure inside the hosting, inside the host has had issues.
So the things couldn't find the server, but that wasn't the server process fault or the machine.
It was like the glue was broken for a little, but that's still, you know, like a couple minutes
if you sum it up over all those years.
The thing that makes this challenging that you avoid, which I want to hear your side of this here in a second,
is I can manage all this stuff, but I'm not running MongoDB in a replica cluster,
which would be the way for like true 100% availability because the changes that I need to make to it are like incredibly small.
But about once a month, there's a 10 second downtime because the underlying server has security patches.
Yeah.
And so I got to reboot the thing that is the center of that hub.
Yeah.
And so I've actually built stuff into say Talk Python, the training site, for example,
that I'll flip a switch to say the app is in off mode and every request will send you over to a page that says,
we're doing a major upgrade, please hold on.
And it has a meta tag that refreshes every five seconds and it notices when the database switchbacks on,
it takes them back to the page they tried to get to.
Come on, man.
That's not good enough.
We need eight nines.
Now, I realize like some people have to have 100% availability, but for my world, like 10 seconds downtime per month is acceptable, right?
I don't know.
That's the way I have it set up.
Tell us about what you're doing at RealPython because I get a lot of traffic.
I maybe do more pure bandwidth because I have audio in large quantities.
I think you do.
Pretty sure you do.
But you definitely do more requests.
I probably get under two or three million HTTP requests that are data-driven Python requests,
not static files and whatever, per month if I add them all up across all the things.
But I'm sure that you get quite a bit more.
So you're running a totally different setup.
Tell us how that goes.
The setup that I use for RealPython, like all the other stuff like the Ethical Ads platform, PyCoders,
pretty much all runs on Heroku these days.
And the downside is it's a lot more expensive than provisioning your own box.
But the upside is that, you know, recently I was going on my first vacation in like a really, really long time.
And my wife and I were going on this hike and we're coming back to civilization.
Very far away from a computer.
Of course, I brought the computer.
Yeah, so did I.
I'd never go about it just in case.
We're coming back from a site.
And I checked my phone and there's like 50 Slack messages.
Not 50, but, you know, it's like Slack is on fire.
Like the real Python Slack is on fire.
And I checked my email and there's like all these exception tracebacks.
And I'm like, oh my God, oh my God, oh my God.
And it looks like the database passed.
You know, some issue with the database.
That service has just disappeared.
And then I keep reading further down.
And I get this email from my hosting provider, from Heroku, from where we have the database set up.
And the way it works is you just say, okay, you know, I want the Postgres database, this version with this many rows of capacity.
And you get that box provisioned and they do all the backups and they provide an automatic failover and all of that.
And so I scroll down the emails further and I'm like, oh, okay, they detected that five minutes ago and already switched over to the failover automatically.
And then reprovisioned the master and kind of switched it back.
And I didn't have to do anything.
And it totally saved me probably like at least an afternoon of work while the website would have been down.
And not a regular afternoon of work.
A vacation.
Sorry, honey, we were going to be on the beach.
Because now I'm in the hotel frantically fighting this bad internet afternoon of work.
Exactly.
And so I was like, oh man, this is great.
I very much like that.
And so I was always a bit worried that something really bad would happen from a hosting perspective if I was going to start provisioning all my own boxes and then updating them.
This is a constant fear of mine of just like what happens if it just goes down.
It hasn't been a problem yet, but that doesn't prove anything.
It's just it hasn't happened yet.
Right.
Yeah, totally.
It's a real fear that I also have all the time.
Yeah.
It's pretty interesting.
But you're pretty happy with the platform as a service?
I'm really happy with it just from a usability friendliness perspective as a developer because I don't have to worry about installing.
When the whole Spectre thing happened and all of these interesting...
Oh, yeah.
We had that 10 second downtime for a lot of reasons.
Yeah.
You know, I didn't really have to do anything about it because I just basically tell the platform, like, here's the code for the app.
Here's the services that I need.
So I need like Redis as a cache.
I need Postgres as the database.
And just give me an endpoint that I can talk to or like credentials for the database.
And they will keep it patched and updated and make sure there's backups.
And there's like, it's always like a failover primary, secondary system.
And I very much like the sense of security it gives me.
But on the other hand, I mean, it's probably fairly unlikely that your server will just melt down.
And so what are you really getting?
You know, maybe it's worth the trade-off.
Yeah.
I mean, you're already protected of hardware failures on the IaaS systems because they'll move your VM across.
I've had several times the underlying machine has died and we moved your VM over somewhere else.
Yeah.
And it just kept rolling.
Have you ever considered like running your podcast on real, like bare metal in your living room, in your office room?
No.
I'll tell you a funny story really quickly.
Slight diversion, but I think it's worth it.
So this is from 19, I remember where I was.
This is like 95, 1994, 95.
I remember like the first Mozilla browser came out in 93.
So I had a friend who was a web designer friend.
And this predates all the like hosting.
Yeah.
I mean, this is like a couple of years in the internet.
And he somehow, I have been thinking back, I have no idea how he did this.
He had gotten the job to build the website of one of the major helicopter manufacturers in the world.
Wow.
Right?
And he was hosting, he was hosting all of his sites on his laptop in his house.
But, but we had a party at his house and somebody walked by and tripped on the power cord and unplugged it.
But it didn't turn off right away.
Right.
Cause it just went to battery.
Yeah.
But a few hours later that ran out of battery and it turned off and he went to sleep.
He woke up the next day and people were upset.
Like, why is the website?
Oh no.
We had a server failure is what he told him.
But it was, we had a party and someone pulled the cord on the laptop.
Is that insane?
Would that ever happen now?
Yeah.
It goes to show like how much this, this whole industry has changed.
I mean, maybe that's what they're doing at Heroku.
I don't know.
It's like in somebody's basement.
Yeah.
No, I would never, I would never consider on like bare metal.
Like there's just having the failover at the network level and just the bandwidth and the
flexibility, the geolocations, right?
Like I think a lot about where stuff located for different purposes.
That's going to be interesting too, to chat about that aspect because I know that for the
video delivery, for the courses, you're doing some really interesting stuff.
Like basically you built your own little, like not little, but like a content delivery network
to be like physically close to the person that's watching the video.
The first thing I hear when I talk to people about this is you're not just using a CDN and
I'm sure I'm going to hear some stuff about this again, because it's irresistible.
It seems to talk about it, but I'm not using CDN.
I'm using something else that lets me create, have more control over the visibility of the
URLs and the content, because I don't want to have just public content, even if it's sort
of protected on the app side.
It's like once you have URLs, they're just public, right?
So I have a way to like create signed short-term URLs.
But yeah, the video delivery is really important.
So that doesn't happen out of my servers.
That happens out of other places throughout the world.
So I have like eight locations.
Like there's a site in Mumbai, there's one in Sydney, there's one in Tokyo, there's one
in Ohio, right?
Where we are here and so on.
And so when you go to training.talkpython.fm and you play a video, not the little marketing
videos, but like all the other real content, the first question the site asks is, who are
you?
Are you logged in?
Are you allowed to do this?
The answer is yes.
Then the next one is, where are you?
Right?
So it'll figure out what of the servers that it has available to it, which one is closest
to you.
And then it'll, it'll stream it to you from that location, wherever you happen to be.
Nice.
Yeah.
And then to get it in those locations.
I've got one place I upload to.
And then this little system, a little like unit, a system unit from system D Python thing
that runs continuously on one of the servers.
And anytime it sees a change to like the main location, it'll synchronize it throughout the other seven places in the world.
So, you know, upload it to one place, walk away, you know, seven minutes, a few minutes
later, like it's in the different seven locations.
Yeah.
So the crazy thing to me here is that, that you're also doing your own video transcoding
and all of these things to be able to deliver to the app and to different browsers.
And yeah.
Well, I tried to just publish the Camtasia videos and they wouldn't play on iOS.
And then they were too big in other places and stuff.
And you've got to have certain underlying, like it's not good enough.
It's just an MP4.
Yeah.
It's got to have like this version or like these settings, or it can't be over like 1.5
megabit encodings for certain things.
And it's super painful.
And so actually shout out to Cecil Phillip.
He pointed me towards this.
So what I found and started using, I mean, obviously it's, you know, been around is Amazon
has something called elastic transcoder service.
All right.
So elastic transcoder service lets you come up with a very carefully structured set of transformations
to your video and you give it a video and it'll generate that, like give it a five minute
video and 20 seconds.
And you have like an output that is perfect for streaming on the other devices.
So I wrote a Python script that'll go to a set of like a course videos folder, run it.
It'll take all the videos.
It'll upload them to a temporary location in S3.
And then it'll use the API to talk to the transcoder service and have it drop into another
location in S3 when it's done.
And then when it's done, it'll grab it, download it, put it in a different spot on my stuff.
And just here's like the sort of streaming version of that course you just built.
It's awesome.
It still seems crazy to me, but I mean, I know that you're a really good engineer.
And the fact that you can pull this off, I think is really, really amazing.
When you told me about this the first time, I just thought it was mind blowing.
Because I was like, I'm just going to use Vimeo.
Well, here's the thing.
I started out with Vimeo.
I started out using Vimeo.
And it was really good until it wasn't good enough.
Right?
Like Vimeo was good, but it would periodically, like the embedded player stuff would stop working,
you know, and it'd be down for like 15 minutes.
It'd be like, you know, I'd start getting emails.
Michael's site's down.
I'm like, yeah, I know.
But it's 100% out of my control.
Then I would get questions like, hey, can I play this at 1.5 speed?
Like, no.
Player doesn't do 1.5.
It doesn't have speed.
So, no, I'm not.
I can't do that.
Just on and on.
Can I have an offline version or whatever?
Right?
Like there's all these things that you start to want and they eventually pile up.
And you're just like, okay, well, if not that, then what?
Right?
Because it was working mostly great.
But then it's like, all right, well, now it gets really complicated really quickly.
But, you know, it didn't start that way, right?
Like I was selling the courses.
Things were going great.
And then like I needed more than I could get from that sort of pro setup I had,
like the pro account or the business account I had set up with them.
I'm like, all right, that's, you know, thank you for your service.
But it's time for me to move on and do something else.
And by the way, this is way more expensive, right?
Like I'm paying for the bandwidth.
Oh, yeah.
Oh, I better do so.
And the transcoder is pretty cheap.
It's like $10 to transcode like hours of video or something.
And you do that once, but the bandwidth is more.
This portion of Talk Python to Me is sponsored by Backlog from NewLab.
Developers know the importance of organization and efficiency when it comes to collaborating on a team.
And Backlog is the perfect collaborative task management software for your team.
With Backlog, you can create tasks, track bugs, make changes, give feedback,
and have team conversations right next to your code.
You track progress with features like Gantt and burndown charts.
You document your processes right alongside your wikis.
You can integrate with the tools you use every day like Slack, Jira, and Google Sheets.
You can automatically register issues from email or web form submissions.
Take your work on the go using their top-rated mobile apps available on Android and iOS.
Try Backlog for your team for free for 30 days using our special URL at talkpython.fm/backlog.
That's talkpython.fm/backlog.
So would you say the fact that this also makes your offering unique, your website is unique,
sort of like a bespoke design, build it from scratch, like the search, all of that stuff is unique.
It makes you special.
And it makes, I think, as a visitor or reader, follower, consumer,
it feels different to go on one of your websites than like a run-of-the-mill WordPress site.
So is this something that sort of happened organically or is this something that that was your goal initially?
I would say it somewhat happened organically, but it was also somewhat of a goal,
like especially around the training stuff.
Like there were a lot of options.
Like I could have used Teachable or Thinkrific or Udemy,
or I could have partnered up with Pluralsight or one of those sets of people, right?
Those types of platforms.
And the consideration there was this is like my bet on my future.
And this is the most important thing I consider that I'm doing for the next couple of years.
I want it to be as nice as it can be.
I know I can build a better site than Thinkful or whatever, Teachable, these different places.
And I think it'll be more special if it's not just under some subscription place like Pluralsight or Safari Online or whatever, right?
And so I actually thought as hard as I could, like, is there a way I can avoid doing this, right?
Because I really don't want to.
It's getting in my way.
It's going to take me like weeks.
Like that actually took a long time.
It was like almost a month to write the site and all that stuff.
But in the end, I decided, you know, if I just do it like a band-aid, just pull it off, do it now, I'll be in a better place, you know?
And like keep in mind, this is like, this is the decision I had to make like the day I quit my job and I had no income and I could have no income until that was done, right?
It wasn't just like, oh, maybe I'll evolve it, whatever.
That gets you motivated, yeah.
Yeah, that'll get you going.
Like you'll get it written quick.
You know, when I think back, like we've been chatting about this stuff for a long time, right?
Yeah, absolutely.
Developing our stuff there in parallel.
And you've sort of drawn me into that direction more to do more custom stuff.
We had a real similar debate, right?
You're like, I could probably just set up some WordPress thing and make this happen like for real Python or whatever it was you were doing at the time.
My first Python education website, debater.org, which is still around, sort of my personal thing there.
That was a custom, sort of like a static site generator, but it was just all serving it from memory.
So it was like written in the BottlePy framework.
And, you know, way back when I wrote it in 2012, I didn't really know what I was doing, to be honest.
So it's kind of limping along.
And when I had the chance to do things properly with real Python, I was sort of torn between, oh, I would love to do something custom.
But I also know that there's downsides to it in the long run.
It's like a constant friction that is on you.
Like I would say I spend at least 10% of my time just keeping things running and smooth and adapted.
Like it doesn't, I don't know why, but it seems like there's always just a little bit of friction.
And you wouldn't have that necessarily with the other stuff, right?
Yeah.
Well, it's or so you would think, right?
I guess so you would think.
I was talking to a lot of people just in the web dev space.
And, you know, I used to work as a backend engineer for a company in Vancouver.
And shout out to Mobilify, a really cool company.
And my friends were pushing towards like, oh, just use WordPress.
You know, you can get all the plugins if you want to hire somebody.
There's a lot of people who know about WordPress and PHP versus Python.
You can buy a theme, you know, there's like this whole ecosystem for this stuff.
And, you know, back then I think we had a similar conversation about this.
And we're like, you know, you should really consider doing a custom implementation because
then you can tailor it exactly the way you want to.
And I'm so glad I changed my mind or partially you convinced me and that I rewrote realpython.com
as a Django app because now it is sort of a superpower being able to have a really tailored
and unique workflow for all the authors contributing to the site, you know, for our editing team
and just to be able to, you know, run something like a little linter on an article.
And I don't have to A, write that in PHP.
And then B, I think the other thing is as soon as you get, so for example, my wife's website,
she has a graphic design portfolio.
We built that on WordPress and that's cool and all.
You're so effective and fast in the beginning, but then you start running into all these issues
with these plugins playing together.
And maybe you don't even fully understand the underlying tech.
Like you can jump into Python and fix it.
Like, can you actually resolve that problem with PHP?
Yeah, no.
No, me either.
Some people, yes, but me, no.
Yeah.
And that's a big pain now where it's like, well, you know, this plugin is getting updated
and then there's like a new big new release or some security patch.
And these things are not all updating in sync and they're kind of all doing their own thing.
And it blows up a lot.
Whereas if you run your own application, you have a lot of control over the deployment process
also.
And so like in retrospect now, I'm really glad that it's a custom Python app.
Yeah.
That's awesome.
I guess the question is, how are we all going to feel about this in five years from now
where it's like, oh God, you've got to maintain this thing.
Actually, this brings me to another question that we haven't really touched on yet.
Like choice of Python web dev frameworks.
Yeah.
So you're using Pyramid, right?
Yeah.
I'm using Pyramid and you're using Django.
For the most part.
Yeah.
Django.
For the most part.
Yeah.
I'm also using a little bit of Flask for some APIs that people don't see, but they're there.
Yeah.
It's got some BottlePy in there still for debater.org, but everything else is Flask.
Yeah.
So that's an interesting one.
You know, there's two things that I really, really liked about Pyramid.
And keep in mind, this is 2015, not 2019.
When I decided these things, right?
Yeah.
So at least for one of them, one's unchanged, one's true.
For when I went, like my personal web style is like a minimalist, bring the little pieces
together.
I'm kind of a micro framework type person.
So I thought Django is nice, but it feels like kind of bigger.
I need to understand more of it at once.
And I felt like with the micro frameworks, I could like learn it piece by piece.
You know, like I'm going to understand this little part here.
And like, I don't know what that does.
I don't need to know.
I mean, that's actually on the Pyramid framework site.
Like one of their principles is you can be effective with a partial understanding of Pyramid.
Like I can call it.
So anyway, so I was considering Pyramid.
I was considering Flask and a few other things.
But when I, at the time, super underscore that, at the time I went to the Flask website and
said, this is for Python 2.
It may, may work on Python 3.
Your mileage may vary.
We have no guarantees for you there.
Right.
And I'm like, whoa.
I don't know if I want to get into that.
Right.
Like I don't want to start a brand new thing on Python 2.
If like that's its world.
I did a quick check of the performance stuff and Pyramid was faster than the other two on Python 3.
I think Flask was faster on Python 2, but that didn't make me happy.
Right.
I want to be on Python 3.
So, you know, having no legacy code, I'm like, all right, let me try this Pyramid thing.
The other reason I really like Pyramid is the Chameleon templates.
Like I very much dislike the style of the Jinja templates.
And it's not just Jinja, you know, C# has the Razor space that's very similar.
Django's templates are similar.
What I don't like is template languages that are very much not HTML.
Like you can't take a Jinja template and load it in a standard HTML editor and have it think it's okay.
Right.
Because you've got that angle bracket percent for something, something like their angle bracket percent and for all over the place.
Right.
Whereas Chameleon is more angular or view like, like Vue.js, like where it's attribute driven.
So you might have an attribute that is not understood, but that's valid HTML other than tal colon condition has a string.
Right.
It's like, I don't know what attribute means, but it's valid HTML.
Oh, does it actually like parse the template as XML or whatever?
And then like, it makes sure that it's valid.
Yes, it does.
Because if you have an unclosed tag, it freaks.
That is cool.
I had no idea.
Yeah.
It's like true HTML that's like extended by Python.
And also it's more, you can't write arbitrary Python code there.
You have to like have a little better architectural separation.
Those two things, when I got started, I'm like, okay, I like both of these about Pyramid.
And I didn't consider Django as much because it's a micro frameworks bent that I have, I guess.
And that's a personal thing, right?
Yeah.
No, for sure.
Yeah.
And I think it also, yeah, I guess like depends on the nature of the site and your workflow.
I think you do a lot of like terminal driven stuff, right?
When you just showed me your deploy process or when you, like, what does it look like for you?
I'm really interested in the workflows, right?
Because for a new podcast episode to go out, like what's going to happen once we're done recording this and you want to publish it on the website?
Oh, that's a good question.
So when we're done recording this right now, recording it, I'm going to convert it to multi-track WAV files.
I'm going to hit it with some audio filters, some quick editing, quick leveling.
So even if our mic settings are different or our distance we're holding our mics are different or like normally it's recorded at different locations, it all sounds like we're in the same room mostly.
I'm going to send that off to Marco.
Shout out to you.
I'm sure you're editing it now.
And Marco is an awesome guy that's been supporting me for a long time.
And he edits it into its final form.
I take that back.
I actually have a bunch of other little bits, like the ad bits and the intro bits and the music.
And I do all that in GarageBand because GarageBand is good for multi-track stuff.
I don't actually do the audio editing there, but I do like the composition of the tracks there.
Put that into an MP3.
I upload that to S3.
Like manually with the...
I'll use Transmit, but yeah, yeah, yeah, exactly.
So I upload that.
And then it goes into the Python world.
So then I log into a backend on Talk Python.
And I say, here's a new episode.
I type in the details and I say, here's the URL on S3.
And you could just serve it off S3.
But the amount of bandwidth that's going through there, like let me just do a quick test here.
So we have...
I want to have the right numbers and I want to make enough stuff here.
So if I served it off S3, it would be like $600 or $700 a month, which is not the end of the world,
but it's not ideal, I guess, right?
Especially when I was getting started.
And so I actually have another server, another virtual server that has tons of available paid bandwidth, right?
And with that, I just put it on there and just serve it out of IntuneX as a static file.
So when I add the S3 URL, it'll like grab it.
It's sort of a cache server.
Like it'll ask from the place it actually comes from.
And if it's not there, it'll get it from S3.
But if it is there, it'll serve it off disk.
And the reason is like that I'm even doing that is if for some reason I need to stop doing that or it goes down,
then I can just flip a switch and it'll fill back to S3.
So S3 is always there as like a reliable backend for the media content.
And as far as like updating the content on the website goes, like you...
There's like a little editor backend I built.
Okay.
Yeah.
Like a little web form or something where you could...
Yeah, exactly.
Like, you know, four or five pages that'll edit episodes, edit guests, things like that.
Yeah.
It's interesting.
Like I was just thinking like maybe a big part of the, you know, different approaches there is for your workflow
because it's so, it's heavily media based, right?
Like the deliverable is an MP3 file.
Yeah.
And so...
There's a lot of steps I can't avoid no matter what, right?
Yeah.
And it's like a different, you know, when I compare this, for example, to RealPython,
RealPython is more like a multi-user online magazine, really, right?
Yeah.
Like from the backend perspective.
And Django is great for that because it was built for that purpose, you know, at a news organization.
And so, at a newspaper journal.
And so, it was like a perfect natural fit for that because it gives you all this like amazing admin interface and all that stuff.
But when you're doing a podcast, like a lot of the technical aspects, you got to build a custom workflow for that anyway.
Like because a lot of it is like audio processing distribution and the content delivery.
Whereas with more like a magazine-based site, it's more you're doing a website.
You need multiple people interacting with the site side of things, right?
Yeah.
Where my main work is on the media locally and it just happens to be delivered there.
Yeah.
Interesting.
Here's the thing.
It's like, could I change things to do something better?
Maybe, maybe not.
But it's like...
It's all relative.
And it's just, it's working so well for me.
Like it's totally spot on.
So, and I'm happy.
So, you know, it's all good.
Yeah.
No, for sure.
I think, yeah, that's like the biggest thing to keep in mind there that it's all...
As long as it works, there's not necessarily like...
There's not a huge benefit to improving things much beyond that point.
I mean, I want to rewrite things all the time.
But realistically, you want extra...
It's a diminishing returns thing.
Right.
Absolutely.
For example, like you launched your mobile apps now.
Right.
That is a huge thing.
Instead, you could have spent the last year like rewriting all of your existing infrastructure.
Right.
Exactly.
So, it's in the hottest new framework.
It could be all Vue.js or whatever.
Right.
Like on Docker.
But whatever.
I got my mobile app and that adds true value.
Right.
When you're a small group of people working on something, you got to focus where it counts.
So, maybe that's worth talking about a little bit.
You know, people ask, you know, did I use Python for my mobile apps?
So, people who don't know, released two apps where you can take the courses in a much better
way on iOS or Android phones or tablets, whatever.
Right.
There's a lot of...
Especially on iOS, there's a lot of limitations to trying to do that through even a nice web
app.
It's just not the same.
So, having something truly native there was super important to me.
And I've wanted to do it for a long time.
And I knew it was going to set me back in terms of productivity and getting stuff done.
But I finally broke down and did it.
So, I guess the first question is what's it built in, huh?
Yeah.
Is it Python?
Man, I wish it was Python.
I tried to make it Python.
I even looked at Ionic for a while.
Ionic's pretty cool.
But I wanted something native for iOS, something native for Android.
I didn't want to do Kotlin and Swift.
I have a decent amount of experience with C#.
Right.
And the JavaScript.
So, the two choices were do something with Cordova phone gap type of thing, maybe on Ionic and some front-end framework there.
Or do something native with C# and Xamarin.
So, Xamarin takes your code and compiles it down to native instructions on iOS and on Android.
And it's like a true native app.
So, that's what I ended up doing.
And as far as the native apps go, like the mobile apps in this case, I think you've done some experimentation in the past, too, with like Electron and stuff like that.
Yeah.
That's more for the desktop side.
Yeah.
I had originally like prototyped it out with Electron.js.
And I was going to like move that to Ionic because they have the widgets that look native on the devices.
And they're just like, it was a constant whack-a-mole.
Like, I fixed this.
Boom, that broke.
I fixed this.
Boom, that broke.
And I'm just like, all right, this sucks.
I don't want to do this.
Like, let me try something else, you know.
Yeah.
You know, Xamarin is 100% free, right?
So, that's cool.
Plus, you were a C# developer in another life.
Yeah, exactly.
So, I had enough experience that that was not a horrible choice to me.
Like, would I prefer to write in Python?
Yes.
But can I go write?
In fact, what I did was I wrote the prototype in C# and WPF on Windows because I knew how to do that.
I didn't know how to do it on iOS or Android.
And then I hired a developer to help write that for the mobile stuff and just worked with them on that.
And that was a really good experience.
What was it like publishing these mobile apps?
Because, I mean, we're, in a way, I feel like we're really jaded creating content for the web or programming stuff for the web.
I guess what I could say is I didn't realize how good we had it.
I'm serious.
I mean, holy moly.
Like, the stuff would break all the time.
I would get builds from the guy I was working with and it would be like, oh, this doesn't work anymore.
Oh, did you do a build clean rebuild all on it?
No, I forgot.
Oh, now it works.
You know, you're like, what the heck is going on with this stuff?
You know, then you hit the app store and the gatekeepers.
And, oh, my God.
It's so super scary.
There was one person I was working with at Google and one person, presumably, I'm working with at Apple.
And if both places rejected the app over and over.
And it was like, well, if I can't make this person happy, the last four months of work go down the train.
And my hope of having a mobile app are gone.
And there's this person who is massively incompetent.
Like, let me just give you, I'm not going to go too long, but I just want to say I have a lot of sympathy for mobile developers now.
So, I submit the app on Android and the title is Talk Python Training Player, Talk Python Training Courses, something like that.
Yeah.
That's the title.
The subtitle is Take Talk Python Courses on, you know, on your device.
But in the description, it said Talk Python Training for Android is the best way to take our courses.
You can learn Python.
You can learn to be a web developer and so on.
Boom, rejected.
Why was it rejected?
It was rejected because there is an app called Learn Python and I'm trying to impersonate it.
Like, where do you get that?
And eventually I see where it says you can learn Python here.
I'm like, oh, they must think.
But it's like not the title, not the subtitles.
No graphics are about it.
Like, but way down there's the word you can learn Python.
It's no more verbs, man.
It's all trademarks.
So, I had to have an argument for four days because there's like a 12-hour turnaround period of it can say you can learn Python.
And that doesn't mean it is associated with an app whose title is Learn Python.
Eventually, the thing that broke that loose was, let's try a different word.
Let's say it was physics or music.
You want to, you can learn music with our app.
Does that mean we are the app called Learn Music?
No.
But like, I had to have this conversation for days with this person.
And if they just disagreed with me, they decided then I'm out of the app store.
Yeah.
You've made that investment to build the apps and somebody has worked on it for weeks and, you know, you have to coordinate everything.
Like, I pay for it, you know, like pay for the development.
Yeah.
And you can't find out until you're done.
Yeah.
Right?
You can't pre-submit it and see if they like it.
Right?
Yeah.
You can't.
That's what we're thinking.
Yeah.
That's cool.
Keep going.
You do it all and you try to launch it and they say no.
And it could be reasonable or it could be unreasonable.
Yeah.
Unreasonable.
But anyway, I'm super happy they're out.
I guess to round out that conversation, there's a bunch of APIs it works with.
And of course, those APIs are all in Python on the server.
But the thing you have on your phone is a Xamarin app, which is, I think, is a pretty cool thing that we have like 95% code reuse, visual designers, everything, and debuggers for it.
95% code reuse across the various platforms and so on.
I think that's going to help a lot in just keeping things manageable.
Right?
Because again, it's coming back to like, you're not 100 people working on infrastructure.
I can't have a Kotlin team.
Right?
Like, I don't know what this stuff like.
Yeah.
And you've got to be able, in the worst case scenario, you've got to be able to go in and jump in and maybe do a bug fix or something.
Yeah.
Something quick or whatever.
Right?
Like, if it were massive, I'd hire somebody.
But other than that, like, yeah, you want to be able to at least take it over if you have to somewhat.
Yeah.
So, that worked pretty well.
It's a really cool app.
I mean, you showed me later and I installed it on my phone.
And it's just really smooth and fast.
Thanks.
I think for a first release, like, it's really, really cool.
Yeah.
I'm really happy how it came out.
I'm glad we did it.
But boy, it was a shaky process to get there.
Yeah.
Not technically, but, like, approval and stuff.
Yeah.
I guess, you know, one more thing that I'd like to, like, sort of exchange.
Well, I'm doing what you're doing just so people can know.
Is, like, so, we have the stuff hosted.
Like, you talked about Heroku.
I got my servers and so on.
But I also use AWS for a bunch of stuff.
Even though I'm not on EC2.
I'm not a huge fan of EC2.
I think it's really expensive and really complicated.
I think it's built for, like, running Netflix and other massively awesome things.
But if I just want a server, you know, it's like, well, my security groups aren't, like,
I just want a little firewall and I just want to, anyway, let's not make that a rant.
But even though I'm not using AWS, I'm still using Elastic Transcoder.
I'm using Simple Email Service.
I'm using S3, Stripe.
I've got Stripe, MailChimp.
There's a bunch of other services that get involved here.
Like, how about you?
Like, what else are you using?
It's so fun, or not fun, but it's hard to think about this and, like, remember all the
services.
I know.
I'm sure I'm missing some.
But, like, for me, like, in terms of software that I use, Redis plays a big role.
Like, it's basically our caching system in between the database and, or not, you know, not in
between in any sort of, like, physical direct sense, but, like, the Django app will talk to
Redis and put some stuff there as a cache, like, the sessions live there.
I was wondering, like, are you using anything like Memcached or Redis or any apps?
I've considered using Redis for some of the search, like, build up a search index and
put it there.
But in the end, I'm just using MongoDB.
Yeah.
I mean, I'm using Postgres for a lot of things, like the full-text search.
I was like, let's just see how far we can get with Postgres full-text search.
And it's actually amazing how much modern databases can just do for you.
Yeah, that's awesome.
Where you, yeah, you don't have to invent this stuff from scratch or build your own index.
Yeah.
As far as infrastructure goes, yeah, I've got, actually, PythonistaCafe.com is hosted
on a DigitalOcean box.
Okay.
That's been really helpful.
Yeah, awesome.
And, yeah, I've been super happy with their service and, you know, just rock-solid hosting,
I felt like.
Let me throw one thing out there for people listening, by the way.
If you're thinking about hosting and you want to be on Amazon, check out Amazon LightSail.
Do you know about LightSail?
It's, like, really small.
So, it has the same pricing as DigitalOcean and Linode.
In bandwidth.
You get a free terabyte with a $5 server, which is $100 worth of bandwidth on S3 equivalent.
Nice.
And so, if you just want to be on Amazon, but you don't want all that stuff, like, and,
you know, LightSail as well.
Anyway, keep going.
Yeah.
Also use S3 and then CloudFlare as the CDN in front of everything.
You do a lot with CloudFlare, right?
Yeah.
It's been incredibly useful.
They have this great image transcoding service that is totally transparent to you, where they
will recompress your images and do, like, a browser detection.
So, if you're on Chrome or, like, modern Firefox, they will transcode your images to WebP
and then serve them out.
And that could, you know, reduce your image sizes to, like, basically half them.
And I don't have to go and, on the back end, write the logic for, like, oh, does this
specific version of Chrome support this format or Safari or whatever?
No, it can't be WebP.
It's got to be whatever.
But they make that decision for you and they can update those rules for everybody.
So, that's been incredibly helpful.
I guess we're basically out of time, Dan.
And there's, like, still so much more stuff we could talk about.
Email, I think, would be super interesting.
But maybe we'll do another one of these if there's interest.
Yeah, I guess we could come back.
I guess one other thing that people ask a lot that I just want to throw out there, it's,
like, why MongoDB and NoSQL versus relational?
Oh, yeah, yeah, yeah.
Yeah.
And to me, like, it's just the modeling stuff in the NoSQL database is really easy.
But the one thing I really love is, like, I've not done a database migration in two years.
Right?
But the data models have changed a lot.
Right?
Because the document databases or schema can just adapt most of the time to the new classes,
especially if it's additive and not subtractive.
You've never been burned by that?
Like, I kind of like having a schema I can trust.
Yes.
So here's the reason I don't think I've been burned by it is I have, to me, I know the schema
safety structure is in the app code.
So I have a special tier whose job it is to just talk to the database.
And it always enforces the schema.
And, like, I never, ever talk to it anyway other than through that part of code.
Okay.
And so...
The schema is in the business code.
There is still a schema because otherwise the code won't run.
Yeah.
But if you just ad hoc it or if you have five apps to talk to it and they don't share
that bit, then you very well could get burned.
So I'm just super careful because I've done it before.
And I think, like, if you're the sole developer working on it, I think that's a great model
too, right?
Where, yeah, you can take these shortcuts and they're basically fine.
But as soon as you have, like, I don't know, if you have a team of, like, 50 people working
on an application, then that stuff just starts breaking, like, every single day, right?
Where it's like, oh, who put a bunch of strings into this integer field?
Exactly.
Yeah, but for example, I use Mongo Engine, which is like SQLAlchemy or Django ORM, and
it will not let you put strings where integers go, for example, right?
So the safety is in the data access layer, but it's not that it's not there.
You know what I mean?
Right, right.
It's just shifted, like, it lives in the application versus the database.
It's kind of like the monolith versus microservice conversation as well, right?
Yeah.
Is there anything that we both really wanted to talk about, but we haven't yet?
I feel like we covered a lot of stuff.
We haven't really talked about Python bytes, I think, the infrastructure for that.
Well, Python bytes is pretty much like a fork of Talk Python.
Nice.
So it's real, real similar.
Yeah.
I mean, it's got its own instance of an app and database and stuff, but it's basically the
same.
We got the training stuff.
I think that's pretty much, I guess.
If you were to do this all over again, like right now, and you had a month to rebuild it,
like infinite time to rebuild it, how would you do anything different?
I don't know that I would do too much different.
Like, I'm really happy where things are.
Like, it doesn't go down.
It's easy to maintain.
It's cost effective.
The way I got here was like a circuitous path of like, oh, I'm going to try this platform
as a service thing.
Oh, it's kind of not really reliable.
Oh, I'm going to use SQLite so I don't have to deal with this other stuff.
But like, oh, now things are outgrowing that.
And just, I would have gone more towards either where I am or maybe towards Heroku or something
like that, where you are, if I felt like a platform as a service would have made me happier.
I don't think I would change too much, but I would have gotten to where I was a lot better.
But like, that's more quickly, like that's the curse of knowledge, right?
Like you kind of, how about you?
Yeah, I feel the same.
I mean, I'm pretty happy with how like all of the hosting aspects and the technical side
of that.
I think, I mean, it's much more about creating.
I have to continuously remind me of that, right?
where like the goal of this business is to provide really, really good training material
to people and to enable people to learn better and become better Python programmers.
Right.
Neither of us are selling tech.
We're selling content and education and experiences.
And this is just the facilitation layer.
Yeah.
And so from that perspective, I'm super happy with the tech.
And I think, you know, also considering that, what we just said, it's really important that
it's fun to work with the tech and that we get to work with all these interesting tools
and learn more about them so we can go out and teach others about them and share that.
So from that perspective, yeah, I'm super happy.
I mean, I would want to rewrite it in PHP or anything like that.
No, definitely not.
The themes, they're just not worth it.
Don't do it.
All right.
Well, Dan, thanks for doing this.
Don't like sort of interview me and sort of 50-50 hosting of the show today.
I really appreciate it.
It's been a ton of fun.
Yeah.
This is so cool to do this in person, like sitting next to each other.
Like initially it was like, oh, you know, when we're talking to each other, there's no delay.
Like usually there's like a 200 millisecond or I don't know how long delay is like over Skype.
We talk over each other all the time because of the latency and stuff.
Yeah, it's great.
The bandwidth is awesome right here.
Yeah.
It's 3D too.
It's all cool.
Thank you, Dan, for doing this.
And I can certainly recommend folks come out to PyCon next year.
Hopefully you could see some of this live as well.
Oh, yeah.
No, it was great.
It was, yeah, just a ton of fun.
We're going to be, PyCon is going to be in Pittsburgh.
So that's, I've never been to Pittsburgh.
Me either.
I'm looking forward to it.
I'm looking forward to that.
All right.
Well, cheers.
Thanks for being here.
All right.
Thanks so much for inviting me again.
Bye.
This has been another episode of Talk Python to Me.
Our guest, or should I say guest host, was Dan Bader.
And this episode's been brought to you by Linode and Backlog.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/linode.
That's L-I-N-O-D-E.
With Backlog, you can create tasks, track bugs, make changes, give feedback, and have team conversations
right next to your code.
Try Backlog for your team for free for 30 days using the special URL talkpython.fm/backlog.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
everything bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Thank you.