So you've built this amazing Python web app, and now what?
You want to put it online, of course, but that's a whole different skill set.
Well, today you're in luck because Matthew McKay is here to tell us all about deploying Python web applications on episode number 26, recorded Monday, August 17, 2015.
I'm a developer in many senses of the word because I make these applications, but I also use these verbs to make this music.
I construct it line by line, just like when I'm coding another software design.
In both cases, it's about design patterns.
Anyone can get the job done.
It's the execution that matters.
I have many interests.
Sometimes it can flake.
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 brought to you by Hired and OptBeat.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at OptBeat.
That's right, OptBeat has joined the show as a periodic sponsor, and they have a huge announcement for you later in the episode.
I have a little news for you this week.
First, Import Python, the newsletter, guys, have created a free job board.
So whether you're hiring or looking for work in Python, check out importpython.com slash job board.
The past two episodes have been with book authors, as is this one as well.
And for each episode, I've given away a book to one lucky listener who's already signed up as a friend of the show.
I want to say congratulations to Kristen Wedmark from Sweden, who won Fluent Python,
and Keith Ord from Georgia, who picked up Effective Python.
Do you want to win a book just like Kristen and Keith?
Well, be sure to sign up at talkpython.fm as a friend of the show, and you'll be in the running.
Now let me introduce Matthew.
Matthew McKay is a Twilio developer evangelist based in San Francisco, California,
where he builds open source applications in Python and Swift.
Matt spoke at EuroPython on FullStackPython and PyCon about virtual ENTs and web app deployments.
He created the Underwear Library hosted on PyPI and writes FullStackPython to help fellow developers learn how to build
and deploy their WSGI-powered web applications.
Matt, welcome to the show.
Thanks for having me, Michael.
Yeah, I'm really glad you're here.
We're going to talk about some awesome deployment stuff based on your new book that you wrote.
So before we get into deployments and that sort of thing, let's start from the beginning.
What's your story?
How do you get into programming in Python?
Yeah, sure.
So I've actually been programming for a long time.
I took four years of computer science in high school.
I was very fortunate to have extensive computer science classes in high school.
And I'm a strong believer that that needs to be expanded throughout the United States.
And then through that, I got into computer science in college at James Madison University.
And then I did my master's in computer science at Virginia Tech.
So I've studied computer science for a long time, got a great foundation, and then became a professional programmer as soon as I graduated from college.
So that pretty much led me into the Java world, which was a bit away from where I am now with the Python scene.
Was your education in Java?
Is that how you ended up down that path in the beginning?
Yeah.
Well, it was a combination of C, C++, and Java.
I think most people go into C++ and they learn a lot about the underlying data structures and pointers and all that stuff.
And I just found at the time when I discovered Java that it was great to not have to think about a lot of the lower level details.
And so for me, I just kind of naturally gravitated towards Java also because that's where all the jobs were going.
And so I sort of grabbed onto that and had enough experience in the different languages that I could kind of switch back and forth when necessary.
Yeah, very cool.
Okay, so you got a job in Java and somehow you made your way over to Python.
Yeah, so the gist is I was doing Java development on actually a military project for the Department of Defense.
And I just realized that we had so many Java developers on our team.
And I would go home at night and I was like, I was still trying to learn more and more about programming.
And when I came across Python and I started teaching myself Python, I realized in a couple hours of working on side projects, I felt more productive than an entire day at the office.
And I just thought, wow, this is something that I think is really powerful as a language, as an ecosystem.
And I wanted to hang my hat on that.
So I started getting on projects that were more based in Python, or I would, for example, write scripts that were in Python for a Java project.
And that was kind of my introduction to that world.
Yeah, that's really cool.
That's both exciting and somewhat regretful.
Like, why didn't you do it earlier is one of the feelings I personally had coming from C++, which I spent a lot of time working on and perfecting to just leave in the dust.
Yeah, but it makes you appreciate it, right?
I mean, every time you don't have to handle pointers or you have a built-in data structure, a dictionary, or a list, you really appreciate that you don't have to resize that array.
You can use the built-in data structure, and it's so much more productive.
Yeah, absolutely.
All that stuff is way more appreciated, at least from my perspective.
Yeah.
Awesome.
So why don't you tell me a little bit about Fullstack Python?
Sure.
So a few years ago, 2012, I was working on a bunch of different Python projects, consulting projects, and I was working with many junior developers, and they kept asking me questions.
They would send me an email, and I would write these long, detailed emails about how a WSGI server operates or what the difference between Django and Flask was.
And one of my colleagues said, you really should actually publish this.
It's like, you should put it out there, at least just on a website where other people can read it.
And that was pretty much the start of Fullstack Python.
I took a Christmas break where I had a week off, and I just started writing.
And I pretty much pulled in a lot of what I had from emails to just create this original site that I just kind of added to day by day, and it just kept growing.
So that was the very origin of the site was, hey, people might be interested in this information.
And lo and behold, I started getting readers.
So that was the very beginning of it.
So how many articles or topics did you have out of your email before you had to start writing for Fullstack Python?
Yeah, so a lot of it was just around web frameworks, and especially around deployments, because I would deploy a lot of applications to just a basic server, because many of the consulting engagements I was on, they didn't have existing Python projects.
So they needed someone who was a quote unquote, full stack developer.
I know that's like a much maligned term.
A lot of developers don't like the term full stack.
But I felt like it actually really did apply.
And I'm kind of stuck with the name now.
And I don't know, I kind of like it.
So yeah, so I basically that was the original quote unquote, full stack was the web frameworks and the deployments and the servers and that sort of thing itself.
Yeah, that's really awesome.
Your book that you wrote, what's the title?
So it's the full stack Python guide to deployments.
Right.
So this is basically taking all of your guidance and stuff around the Python web frameworks and just focusing on the deployment side of the story.
So it kind of assumes that you're a competent developer, you've written this web app.
And now what, right?
Yeah.
So I really recommend this to people.
The way that this came about was I kept getting emails from people who were reading full stack Python.
And they're like, hey, this is really great.
Love full stack Python.
But it's super high level.
And you link to all these tutorials.
But they're all sort of just they're different tutorials.
They're mixed and match.
And it was really hard for someone to just without any knowledge of deployment, just get started and figure out without reading 50 different articles, like how to actually do a deployment from start to finish.
And some of these things are super well, I wouldn't say they're super basic.
Like if you don't know how to do them, I wouldn't feel bad about it.
But it's just something like walking through provisioning a virtual private server that can be super confusing the first time you do it.
So in the book, I actually walk through like, here's how you provision a server on Linode and actually start it up.
Yeah, that makes total sense.
It's, you know, I do professional training for developers for part of my job.
And I get questions like, how can I even host my pyramid web app or, you know, whatever type of web app you've created.
Like some people who live and breathe the web world, it's like, well, obviously you create this kind of server or that kind of server.
But if you're maybe like a data scientist or you're transitioning or you've been in Q&A and you're starting to become a developer, like those are hard choices.
And I think part of the guidance of just, hey, look, choose this type of hosting over that type of hosting alone is actually really valuable.
Yeah.
And I think you completely touched on it.
If you're a data scientist or you're a coding bootcamp graduate or you're just out of undergrad or maybe an intern, you've never been exposed to these concepts before because they're not things.
That are typically taught in computer science program.
And often deployments are not touched on in a coding bootcamp.
And so just the fundamentals, just the foundational level of how do you get a server?
How do you create public private keys?
That's completely unknown.
And that's pretty much how I wrote the book was I don't assume that you know any of this stuff.
And we're going to walk through it step by step.
Yeah, that's really cool.
I think that's a good place to start.
You have this picture on deploypython.com.
I read at the bottom of the homepage.
And it's kind of like a visual architectural based version of a table of contents.
Yeah.
It's really awesome.
I really love that picture.
I saw it.
So it's got like a server and a virtual machine and all the various moving parts sort of sketched out in architecture, but also showing the chapters.
And you kind of make your way through this architectural diagram, right?
Yeah, exactly.
So I start each chapter with the same diagram.
And I highlight there's a specific color for each chapter.
So like, for example, I think it's chapter three with the operating systems is like a shade of yellow.
And so I highlight here's what we're working on in this chapter.
And the idea is you start out with this like kind of high level conceptual idea of roughly what we're working on.
And maybe that's on your own server or that's a hosted service like GitHub or something like that.
But you at least have an image in your mind of what we're going to be working on.
And I think for people that are just starting in this space, it actually can be super confusing.
Like, well, okay, I have a Git repository.
But is that like local on my computer?
Or is that on GitHub?
And how do they relate?
And where does the virtual private server sit?
So that's what I tried to clarify a bit with the picture that's on deploypython.com.
It's just here's all the things we're going to walk through.
And here's how they look.
Yeah, I think it's great to have a visual way to see what you're going to learn like that architecturally.
Yeah, I mean, actually, that came from a lot of this came from a talk I gave at Europython in Berlin in 2014 called Full Stack Python, where I pretty much had a picture like this.
And I walked through conceptually what the full stack of a Python deployment is.
And the feedback from people was like, that talk would have been really hard to follow if not for the visuals.
So I thought, okay, obviously, these visuals are powerful.
And I should continue on with that.
And I've been trying to add even more to them to fullstackpython.com as I go along.
Yeah, that's excellent.
And I'm sure that talk is actually on YouTube somewhere, right?
Yeah, yeah, it totally is.
If you do Europython, Full Stack Python, my talk comes up.
Actually, if you do Google for Full Stack Python, Kate Hedleston gave a really great talk as well at PyCon.
And I believe it was 2014 that kind of walks through some of the same concepts.
Yeah, excellent.
I'll put that in the show notes.
Yeah, so let's talk about servers first.
You're using Linode for your hosts here, yeah?
Yeah, absolutely.
And it's kind of, I think maybe it's a little bit confusing in the book because I say, well, we're going to deploy this application.
And actually, before we kind of dive into the servers, I actually have an appendix where we create an application.
I say, like, if you've already got an application, great.
Like, let's figure out how to deploy it.
You can pretty much follow the steps in each chapter and you start out with the server.
And if you don't have an application, like, here is a full tutorial.
It's the appendix C in the book where I walk through an entire open source application, Flask application, that has all of the pieces that we need.
Like, it has a task queue.
It has all these application dependencies and whatnot.
It's a Flask app.
And so the idea is, like, if you, before we even get started with the server, if you've got an application, great.
If you don't, hey, you might want to go and read appendix C if you want to know about this application before we deploy it.
Yeah, very cool.
At minimum, get cloned so you have something to go deploy, right?
Yeah, yeah, totally.
And, I mean, the great part is, like, I actually wrote that content on the Twilio blog, which Twilio is my current employer.
And so that appendix has been, you know, a lot of people have followed along with that and given me feedback on it.
So it's a pretty good tutorial just to include as an appendix if you are trying to build a Flask application.
Yeah, excellent.
Yeah, let's come back to talking about what you do at Twilio because that sounds interesting.
But Linode.
Yeah, absolutely.
So the idea behind really how we get started in this is, like, okay, we need to deploy our application somewhere.
That can't just be living on your laptop.
Like, people on the internet need to access that.
And so we get a $10 a month server on Linode.
And I walk through the steps of, like, how to actually provision that.
And then once we provision it, we boot it up and we create a public-private key and we lock down the server against unauthorized attempts to log in.
So we disallow the root user from being a login account.
We create a separate login account.
We disable password authentication.
We only have public-key infrastructure authentication.
And then we set up firewalls and automatic upgrades.
And these things will not completely secure a server, but they're the good first steps that I would always recommend people do to every single server that they're starting up.
You know, one thing that my current experience absolutely backs this up, but just sort of the way the cloud and sort of this type of hosting has been going, you know, I was a little surprised you weren't using, like, Ubuntu machines on EC2.
Yeah, sure.
So I think, you know, I really like Amazon Web Services, but I also feel like it's almost overused for a lot of deployments.
Like, you can actually take a virtual private server and scale that up to hacker news traffic if you configure it properly.
And I think that's one of those things where, like, you can rack up a huge bill deploying to Amazon Web Services if you're not careful.
Whereas, like, the idea behind this was, like, let's learn all the pieces that you need in order to actually deploy a Python application.
And we're going to do that within the confines of a single virtual private server.
It's a much more controlled environment for the audience of the book, which is really people who are unfamiliar with deployments.
But I totally think you're right, and there could be an entire separate book that's like, okay, cool, you've learned the gist of deploying web applications.
Now let's actually go and deploy this on a cloud-based infrastructure.
Or I guess you'd call it, like, an infrastructure-as-a-service provider like Rackspace or Amazon or Azure.
Right.
Yeah, for sure.
So I think probably the majority of people out there would be better served by using something like Linode or DigitalOcean.
The pricing is so straightforward, and the setup is so easy and so quick.
And EC2 is more, you know, it's something that works for places like Netflix, which are doing amazing things, but it's, like, so large-scale.
And when you're getting started, you know, it seems like it used to be the place to start, but maybe it's not the good starting point.
Maybe it's a place to grow into.
Yeah, I think it might be something to grow into.
I just really wanted to try to cut down the complexity so that everyone felt like they could follow along in the book.
And I think that if you understand the concepts in this book, you can probably also move on and pick up the Amazon Web Services side to it.
But you're totally right in that it's confusing on some of the pricing.
And I also have heard a lot of horror stories from new developers that said, like, oh, I accidentally spun up, like, 20 servers, and I got a bill for $1,000 this month.
And I'm like, oh, no.
Like, I really, really don't want that to happen to people and have them be afraid of doing deployments.
It's like, if you get a bill for $10 a month, that should be the maximum amount that you get out of this.
Right.
It's much more predictable over in those places.
Very cool.
Exactly.
So when you're talking about locking down the servers, one thing that I thought was pretty cool that you recommend is using something called fail-to-ban.
Yeah, sure.
Yeah, so fail-to-ban is essentially just a package on Ubuntu.
I believe it's on many of the other distributions as well, which essentially sets certain parameters like time-based failed logins.
So if from a certain IP address there are failed login attempts, it will prevent any logins from that IP address for, for example, like the next 30 minutes.
So the idea would be it provides just enough, like just enough of a prevention that someone who is trying to log into that server.
Now, granted, they can't do a password-based login anyway after it's secured down, but it's just one other step of basically just locking down the server that will prevent some of those unauthorized attempts.
Right.
And while you're going through this process, you know, your machine, if it is on the internet, it is basically under attack.
Right.
And so having it sort of password login safe for a while is still something you want to consider.
Yeah.
And, you know, I think part of it, too, is just exposing readers to some of these tools and concepts that they have at their disposals.
I think that you could write, and I'm sure there are entire books written about fail-to-ban or about UFW, which is the firewall tool that we use.
But just knowing that they're there and that you've set the basic parameters up, I think is enough to get people started, but not dwell on those subjects so they can continue on and actually get the deployment done.
Right.
Yeah.
The other thing that I made a note of in this chapter when I was reading your book is UFW or uncomplicated firewall.
That thing is so easy to set up, and it's great.
Oh, I mean, I was...
I actually wrote a whole section on, like, setting up IP tables.
And then when I started doing some research, I realized in Ubuntu there is this uncomplicated firewall, and I was like, oh, wow, this does everything that I was trying to show off in IP tables.
It's so much easier.
I think it'll just simplify the deployment process.
So that's pretty much what I went with.
Yeah, absolutely.
I would say it's even uncomplicated.
It's great.
Yeah.
So then basically for the rest of the book, you said, look, you could sit down and manually type these out at the command line, but that doesn't make a lot of sense.
Like, let's make this reproducible.
And so the next thing you bring up is actually Ansible and playbooks, right?
Yeah.
So, well, there's Fabric and there's Ansible.
And so the idea is I think that going through and manually doing deployment and reading through what steps you're taking is really important for the learning process.
But obviously you're not going to do this every time you have a deployment.
So you're going to want to automate the entire process so that you can deploy as many web applications in the future as you want.
And you can modify the deployment scripts so that they're custom built for your applications.
And so every single chapter in the book, so starting with chapter two, which is the service chapter, we do the manual steps and I explain manual, like what you're doing in those manual steps.
And then I go into a sort of second section of the chapter, which is here's how we automate the manual steps that we just did with either Fabric or Ansible.
And so starting in chapter three, we have Ansible playbooks that automate everything that we're building on top of.
And actually those, all of those, that, that playbook, that Ansible playbook is actually all open source on GitHub under one of the GitHub repos that I have.
Okay. Yeah. Excellent.
We'll put that out there on the show notes as well.
Yeah. Great.
Yeah. I think you're right.
You know, it's, this is one of the things where if you've got time and you haven't deployed your, you haven't made your, your site live or whatever, it's fine to just sit there and fiddle with a server until you get it working.
But if something goes wrong, especially, you know, you'd need to rebuild the machine or move it or, or scale it out or something.
And you have got to do that under some high stress situation.
Like the website is down and there's lots of traffic doing that by hand, you know, it's just extremely stressful.
And if it's automated, you push a button a few minutes later, the life, you know, life is good again.
It's definitely recommended.
This episode is brought to you by Hired.
Hired is a two-sided curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front, and you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers in just the first week, and there are no obligations ever.
Sounds pretty awesome, doesn't it?
Well, did I mention there's a signing bonus?
Everyone who accepts a job from Hired gets a $2,000 signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me, and Hired will double the signing bonus to $4,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the call.
Yeah, absolutely.
I mean, no large scale, or even I would say for the most part, small scale website or web application really is going to do a manual deployment.
It's just so time consuming.
And the last thing you want is to make all these code changes and then all of a sudden be like, oh, it's going to take me 20 minutes to deploy all this stuff.
Man, I'll just do it tomorrow because I don't feel like doing it right now.
Right.
You get what you can get with some of those large enterprises where it's like they deploy every six months and they're down for the weekend.
Right.
Exactly.
Something insane like that, right?
Yeah.
No, you should be able to just deploy immediately as soon as you make changes.
And so that's part of what the automating each step is.
And almost, I don't really call it out like this, but it's almost like if you're playing a video game and you hit a checkpoint.
And if you mess up or die or whatever, you go back to that checkpoint.
And that's kind of how I see the automated steps at each chapter.
When you're finished with automating that chapter, you know you can always fall back to that checkpoint if you mess something up in the next chapter.
Yeah.
I think of it the same way.
So now we're getting in your sort of steps along the way.
We've got the server.
Well, the server is really set up by Linode.
But we've got the VM running in their machine.
We've got the Ansible Playbook.
Now it's time to start serving some stuff, right?
So you start with Nginx.
Yeah.
So one of the key ideas I try to drive home in the book is like if you look at the picture on deploypython.com, it's all concepts.
So a web server is just a conceptual idea of serving, of receiving and responding to HTTP requests.
But the actual implementation of these things is something that is different.
Like Nginx or the Apache web server or Microsoft has IIS.
Like these are implementations of a conceptual idea called the web server.
So each chapter actually has two pictures.
It has the conceptual idea that we are implementing and then the actual implementation of that, which is in starting in chapter four, Nginx.
So yeah, so we set up and install Nginx.
There's actually a way to do it.
I walked through.
This was one thing I went back and forth on was do I do HTTPS only, which I kind of favored.
I wrote an initial draft with just HTTPS.
We set up an SSL cert.
And the feedback from one of my reviewers was like, you know, I think that's awesome, but I really just want to get this started.
Like I just want to make sure this thing works and is serving up HTTP requests.
And so I actually have a bit of a fork in the road, which is you can do this either with just HTTP or with HTTPS.
And I do caveat that like if you're doing a web application, you really should do it over HTTPS.
Yeah, it is a little more work, but it's definitely recommended.
I was reading somewhere that Google is going to start downgrading the rank of sites that are not SSL.
So there's one more reason to run it over SSL, right?
Yeah, and I mean, in today's world, SSL connections, they used to be way slower than non-encrypted connections, but they're just a little bit slower now.
So I think that's what Google is trying to do.
It's basically saying, hey, we know your site's a little bit slower, but we're going to give you the benefit of the doubt because it is encrypted that will improve your page rank score, something like that.
That's my guess about what Google is doing there.
Yeah, I agree.
So I think Nginx is a pretty safe bet.
It seems like it's kind of been taking at least the Python world by storm the last few years.
Yeah, I mean, I've used Apache so many times in the past.
Certainly, if you're comfortable with Apache, there's no reason why you couldn't use it in this case.
It's a very solid, stable, mature platform or implementation.
I just, you know, Nginx seems to be what the Python community has.
I would say a good percentage of the Python community has said, yeah, this is something that works really well.
And we're setting it up in two different ways.
One is it's actually serving up the static content.
So things like the JavaScript files, the images, the CSS, but it's also serving as a reverse proxy to the WSGI server, the web server gateway interface, which is the Python web server that's serving up your application.
And so we actually have two configurations within our larger configuration, one to handle the regular web server requests, the static files, if you will, and then the other part, which is serving as a reverse proxy.
And I just felt like Nginx configuration for that was pretty simple and straightforward.
And I thought maybe a little bit easier than the, what can be fairly lengthy, large configuration files that come with Apache.
Yeah.
And like you said, it's, it's pretty mainstream in the Python world these days.
Very cool.
So then the next thing you, you talk about, I've got this server.
It has a web server.
It can serve things.
Let's get some things on there, right?
Yeah, absolutely.
So that, that kind of goes into the, the source code.
So we create a deploy key.
So the idea behind a deploy key is it's like a, a read only key so that you can pull down your changes to your production server, but you can't make changes in production and push them back.
It's good from a bit from a security standpoint, but that's really not the main thing.
The main thing is the, the good practice of not making changes in production that are sort of different from your development environment.
So it's a one way, pull down the source code, pull down your static files, and then you start serving that with the web server.
Right.
So production is something that you push to, not you frantically log in over SSH, nano some files and save them back and then try to get that balanced across your, your cluster or something.
Right.
Yeah.
Cause otherwise your development environment is not going to match your production environment.
And, and it's just, that's, that's, that's more headaches than most people want to deal with.
It's better just to get, pull down your changes to the production server and not go the other way.
Right.
And so you had to pick up concrete source control system.
So you used what visual source safe?
Uh, I used, oh, I see.
Oh, wow.
I was like, you must have glazed over that chapter.
Maybe, maybe Git is too common now.
I don't know.
No, I mean, Git is just totally taken over.
Right.
And you used GitHub.
It is totally taken over.
GitHub in your example, right?
Yeah.
So I used GitHub, obviously, you know, they have the free accounts.
Um, certainly could have used Bitbucket there.
Um, but I've used GitHub, for a long time now.
Um, and you know, I've used many different version control systems.
I unfortunately, I, unfortunately, at one point used IBM's clear case, in my very first job, which was exceedingly painful, then went a little bit better with SVN and then came upon Git, a while back.
And I've just never, never looked back to, those other systems.
So, so that's what we use in this book.
I, I think that, Git can be conceptually a bit confusing for people that are, are new to software development, which once you kind of get the hang of it.
Uh, and also there's a ton of great resources that are out there for, for new people.
Um, I think that's just the way to go right now.
Yeah.
I love Git too.
And I have not looked back, but it is slightly more complicated than some of the other systems to get started, I think.
But you know, it's, it's so pervasive.
Like it would make, it's definitely the right choice.
So then you wanted to set up some of the different tiers for your system, right?
So you actually set up Redis and Postgre, right?
How's that fit into the story here?
Yeah, sure.
So, the idea is, well, most web applications, including the example one I have in the appendix is, backed by a relational database.
It's just stable, you know, stable, mature technology, that kind of houses the majority of your data, or at least your transactional data.
Um, but also, you know, I, I hesitate a little bit to call Redis like a no SQL data store.
I guess it kind of fits.
It's a key value pair store, and it's all in memory.
Um, but I use that for some of the, like in the example application, like counting votes.
So really fast data that's coming in.
Um, I temporarily store in memory just because you could have hundreds of thousands of votes coming in, at the same time.
So, we go ahead and set up both of those things in the sixth chapter.
And the idea is like most web applications now are using some sort of relational backend.
Um, you know, whether that's, my SQL or Postgres or whatever, whatever have you.
Uh, those are probably the two main ones I've used both of them.
I've used Oracle.
Um, I tend to go with Postgres now.
Uh, and then there's some sort of no SQL data store, maybe an in-memory data store like Redis.
I just find that like Redis, I set it up with every single project because it just comes in handy for session data or for just counting things.
Or if I have a query that is just really hammering the database, I'll just cache that in Redis and it just comes in handy.
As long as you remember that, like, if you reboot the server, that everything is going to get cleared out of Redis, then it's pretty safe bet that it'll come in handy on almost every project.
Yeah, I agree.
At least in that use case, I'd kind of hesitate to throw Redis into the NoSQL bucket because if you're not really saving, it's more like a cache server, distributed cache server.
But yeah, super good use, super easy to use from Python, right?
Yeah, I think conceptually the idea I was trying to get across was like, these are, this is not an either or proposition.
Like the idea that like, if you use MongoDB, you're not going to be using any other type of data store.
Like that doesn't really make sense.
Like you use the best tools that are available and sometimes you need multiple tools in order to accomplish that.
And I wanted something that was, more than just a standard relational database, to make this chapter a little bit beefier to show that like, there's, there's multiple ways that you can sort data on this, in this application.
Yeah.
Excellent.
And your example, you just set this up all on the same server, but in practice it would be other, other machines most likely.
Yeah.
And so that actually kind of brings up like a larger point, which is, I, I do make updates to the book.
I've already put out my first update based on reader feedback.
Um, just cleaning up some typos, cleaning up some confusing sentences, those sorts of things.
But if people are like, Hey, I've done the whole deployment and I really want to separate this out into two separate virtual private servers.
Um, that, that is a very good first step if you're trying to sort of scale up your application.
Uh, and so I may actually create a separate chapter just that walks through the process of like, okay, you have your deployment on a single server.
How would you separate out, you know, your relational database, and whatever else have you, and then connect those in a secure way to your, web server.
I think, that might make a lot of sense.
That would make a lot of sense.
I mean, putting them on separate servers and having them talk to each other, super easy.
The words in a secure way that that's where the deployment story starts.
You got to have a little more experience with the infrastructure you're working with.
Right.
Yeah.
And in an early version of the book, like I had actually two separate servers.
And what I realized was I spent so much time explaining why in this, in this chapter deploying, these databases that like, okay, well, we need to make sure that, that these connections, the connection is encrypted.
And we need to make sure that the database server can only talk to, you know, your web server.
And, you know, here's how, like, I just, I just felt like there was a bit more complexity there that I didn't want to glaze over.
Cause I didn't want to leave people thinking like, okay, I've set my server up, like my two servers up and they're, you know, they're, they're all safe and secure when in reality they weren't.
So I really felt like that was going to have to be a separate chapter in order for people to learn the, I'd say like kind of the right way to, to handle that when you're separating out to two separate servers.
This episode is brought to you by OpBeat.
OpBeat is application monitoring for developers.
It's performance monitoring, error logging, release tracking, and workflow in one simple product.
OpBeat is integrated with your code base and makes monitoring and debugging of your applications much faster and your code better.
OpBeat is free for an unlimited number of users.
And until now has only been available for Django developers, but I can announce that they are launching Flask support today to all you Talk Python listeners.
Visit OpBeat.com slash Flask to be among the first to join the Flask private beta.
Yeah.
I mean, there's been headline, various database servers that have been, you know, just left wide open.
People open the ports and had no authentication.
And guess what?
There's 600,000 instances of this particular database out there that people could just read because people made a mistake.
Oh, oops.
Did you forget to lock this down?
Exactly.
And that kind of goes to, you know, back to our point about Amazon Web Services is that, you know, a lot of people think that those, those, the ports on Amazon Web Services are secure.
And they're really not like, unless you manually secure different EC2 instances, you're actually going to open up a lot of security vulnerabilities.
Right.
Maybe you, you've got to go to your security group and set up some sort of, virtual, right.
Only these machines in the security group can talk to these others in this other security group.
But when you're new and you're just trying to get a website up, like that's not something you even know exists, but let alone, you know, let alone that you could change it and configure it.
Right.
Yeah, exactly.
I mean, there's a fine line between, I wanted to teach as many concepts as possible, but I also didn't want people to leave thinking, leave the book thinking, yeah, I know what I need to know about all these topics, but have some gaping hole in their knowledge that is actually going to come back to bite them later.
And I felt like just deploying on a single server that if you really need to scale it, you can actually, you can actually take the server and get a $20 server instead of a $10 server.
And that will perform better, just by a vertical scaling.
And that I think is probably going to be better for a lot of the readers, than, than adding additional complexity, that they don't know about.
Yeah, absolutely.
I think, you know, for the folks who this book is aimed for vertical scaling versus horizontal scaling is probably the right way to go in the beginning.
Right.
Yeah, exactly.
And the idea is like, hopefully, I, as I do in, as I try to do in my, in my job, like I inspire and equip developers to want to learn more about these subjects.
Like they feel like they have a grasp on the basics and they can take that and, and learn more themselves based on all of the resources that are out there, either in other books or on the web, whatever have you.
And they'll, but they won't get bitten in the meantime by some, you know, gaping hole in their knowledge that really kind of screws them on their initial deployment.
Okay.
So I think it's, you know, following your architectural path here, I think it's time to actually get some Python stuff running, right?
Yeah.
Yeah, finally.
And that I have to say, if I have like one major, major criticism of the book is like kind of how long it takes to get this WSGI server, up and running.
Uh, but you know, this is just kind of how these things work.
And, and, again, it's about, you know, learning as much as possible throughout the process.
So, yeah, so, you know, after we set up the databases, we, set up our dependencies in a, in a virtual end.
Uh, we install the dependencies from, PyPI and we actually get our WSGI server up and running.
Now we run the WSGI server through supervisor so that we can, you know, start and stop it and make sure that it starts up in case we move the server and that sort of thing.
But, yeah, and then we, I talked a bit about the interaction between, you know, virtual end and, supervisor and the WSGI server and the WSGI server we set up in this case is, is green unicorn.
Um, so those, those different pieces to it, basically establish the Python component, the major Python component of the application.
Yeah.
And I think, you know, the fact that you're using virtual environments here is kind of helping people down the right path, right?
So you probably have one server and one website and you don't necessarily need a virtual environment yet, but as things grow, you maybe want to adopt it.
Right.
So just starting from the beginning, it's pretty easy to set up a virtual environment, especially with the Ansible script and so on.
Yeah, exactly.
You might as well bring it into the conversation.
And, and I didn't want to have, I mean, if you've done the other things, right, it's probably not as big of an issue, but I didn't want to have,
or have to have, Python running as a route so that you can install the dependencies into the base installation of the operating systems, Python interpreter.
So that was really what I was trying to avoid there was saying like, Hey, this is running, as a process under your deployer user or your supervisor user, whatever have you.
Right.
And in this particular setup, the, the users created the server there.
Technically they can run stuff as a route and they can do sudo and they'll be fine, but I've certainly worked with people in environments where some of the developers don't get route access to the deployment machines and the production machines.
And they'd still like to be able to, you know, configure their app or something.
And this, you know, like you said, gets around the security limitations.
So it's, it's nice in that regard.
Yeah.
I mean, it certainly gets around some of them.
I mean, if you don't have any type of route access, then you can't run a web server on port 80.
Um, so that'd be like one thing where, it should be that the, well, my guess is, and there's obviously many different ways you could set this up, but my guess is the system admins just locked down the route, but maybe gave sudo privileges to some sort of, sub account or something.
Right.
I think that, you know, the situation I'm thinking of, it was mostly, they didn't want people modifying the machine wide Python configuration more than anything.
Right.
Yeah.
Yeah, exactly.
And you get around with that, with this, in this case.
Yeah, absolutely.
So green unicorn, why'd you pick that?
I, you know, I honestly, I've been using it for, for several years.
Um, I think it's a fairly stable, default choice.
Um, but I think there's a ton of other great whiskey servers out there.
Um, and certainly if you're going the Apache route, mod, mod whiskey is, is a good route to go.
Um, but it just, in this case, I thought the, the combination of green unicorn.
And, and, and engine X just seemed to be the one that I was most comfortable with and the most comfortable teaching other people about.
Right.
Sure.
That makes a lot of sense.
The one that I've been using is micro whiskey.
So that's, that's also been pretty good.
Yeah, absolutely.
And I've, I've read some, I've seen some of the, you know, you have to be careful about the benchmarks and stuff, but I've read some benchmarks that have said that that actually might be a faster whiskey server.
Um, in, in many cases.
Right.
So, you know, going with the theme that not everybody is a web developer necessarily knows, maybe you want to just talk really quickly about what whiskey, the concept of whiskey itself.
Yeah, sure.
So, so that's web server gateway interface, WSGI.
And the idea is like in the late nineties, there was a something.
So Apache was the dominant web server back in the day.
And someone wrote a, module for Apache called mod Python.
And I use mod Python for a while.
It was pretty much just a execute arbitrary Python code.
And, that worked really well for a while.
There were some security vulnerabilities, discovered in it and development on a kind of languished.
So the Python community came together and created, a Python enhancement proposal of pep, PEP three, three, three, three, which created the whiskey standard.
And, then there was a superseding one, which is PEP three, three, three, three.
That's four threes.
And that one just really was a simple update to say, like, we're, we're expanding this to include Python three.
But the idea behind it is, and, and, and I have a kind of have a, some more background knowledge on this with the application dependencies page on, on full stack Python.
But, the idea was like, there needs to be a standard, super simple way for a web, web application server, like, you know, cherry pie or mod whiskey or, green unicorn to execute, a web application.
Uh, and so if you're using Django flask or bottle, one of these frameworks, they implement the application side of the whiskey standard, whereas your whiskey server implements the server side.
And so there's a simple hook between, the server and the application in order to get that, up and running, so that you can deploy this in a standard way and you can mix and match different frameworks and servers that provides the interoperability, between, the whiskey servers and the whiskey applications.
Yeah.
That's, that's awesome.
I mean, it basically means that we could switch between micro whiskey and green unicorn and it wouldn't be that big of a deal, right?
Yeah, exactly.
So if you're more comfortable with a different whiskey server, you know, by all means, you could use the exact same setup, but switch out the whiskey server and, and use the one you're most comfortable with.
So we've got our app running.
We've got our reverse proxy from Nginx over to green unicorn.
Everything seems to be good, but now you want to start pushing changes to your production servers and you want to make sure that stuff is not broken before you do that.
So that brings us to continuous integration.
Yeah, sure.
Um, and the, the only other quick thing I wanted to add was we do add a task queue as well in there.
Um, task queues are for asynchronous data processing outside the HTTP request response cycle.
So the idea here is like, that's such a common thing that people want to deploy.
I just added celery as a part of our application deployment.
Um, just so that people would be comfortable with adding that.
I feel like that's something that is often left out of deployment tutorials that I thought really needs to be included in the book.
Yeah, I think that's a good point.
And, you know, some, some variation of an asynchronous queue can add so much scalability to your app in a really easy way, right?
Yeah, exactly.
It's like, oh, this, this, you know, this database query is taking too long, when someone hits the server.
Well, just put it in an async task task queue and process it, you know, every 15 minutes or something like that.
If the data doesn't change that often.
Um, and that way you're getting, pretty much scalability by the design of your application and the deployment rather than, you know, having to get a bigger beefier server in order to somehow process that up, that database query even faster.
Yeah, yeah, definitely.
Okay.
Continuous integration.
Yeah.
So the idea here is, again, many of the tutorials that I saw, like continuous integration was like this completely separate setup from doing a deployment.
And so I thought, well, you know, this is really core to how applications are deployed.
Um, so we take the Ansible configurations, I'm sorry, the Ansible playbooks that we've created throughout the book.
And we set up Jenkins as the implementation of a continuous integration server.
We do it on a separate virtual private server.
So technically, if you do the whole setup, it's $20 a month because you have two separate servers.
Um, but then we set up the whole configuration where when you push changes from your local development environment to GitHub, it has a service hook, or what's really, standardly called.
Uh, most commonly called a web hook, web hook notifies Jenkins that, Hey, there's been some changes.
So Jenkins pulls down the code, make sure that everything is working.
And this is the part where you could put in your hook for like unit tests and integration tests, and fail the build if those don't work.
Uh, and then if everything is good, we deploy the code to the, the, the actual server, the production server.
And, then you get a handy little text message that says your application deployment is complete.
So oftentimes we have these really long running deployments.
Maybe they take 10 or 15 minutes to pull all the code and do the whole deployment and everything.
Um, so maybe you want to step away from your, from your, server, I'm sorry, your, your computer go, you know, go, go grab a coffee or a beer or something like that.
But then when it's all done, then you get a text message to your phone and it says, Hey, this is, this is all complete.
Very cool.
And of course, Twilio is the backend for the text message, right?
Yeah.
So, I mean, I, I really love, using Ansible.
And, so I just, just kind of playing around with, some of the modules and stuff like that.
So, so the Twilio modules like in, it's, it's a part of the standard, Ansible, if you do like a pip install Ansible, so you can just do, use the, use Twilio service with your credentials to send a text message.
Um, so I actually wrote that, like a year, year and a half ago.
Yeah.
That's really cool.
Yeah.
It's kind of under the notifications package.
Um, you could also do like, for example, I don't do this in the book, but you could do like an email or something like that, when the deployment's done.
So there's all different types of notifications.
Um, you can do a notification to Slack, super easy to add that in instead of the Twilio notification.
But, I'm kind of partial to getting a text message because I like to walk away from my computer and the deployment is working for me.
Yeah.
No kidding.
Let something else stick around and be tied to the desk.
So one thing I did want to do is I want to give a shout out to one of my sponsors, CodeChip, because, you know, Jenkins is, is a cool Java app install and you sort of configure yourself and CodeChip is kind of, you know, CI as a service.
So check them out if, if you're not wanting to set up something.
Yeah, no doubt.
I've had some bunch of friends who've had good, good experiences with CodeChip.
So, yeah, awesome.
So that, that was kind of the end of the book in its current form and you had some, Hey, you might want to consider these other things sort of right at the end there.
And so you had one section on deployment enhancements, which we've talked about a few, we've sort of touched on them and others on performance.
So one of the first one you said was sort of having a QA environment.
Yeah.
That might be a good idea.
So, yeah.
So, you know, I, I glaze over this maybe a little bit, and, and maybe it deserves, you know, a lot more, a lot more thought and maybe a future version.
But the idea here is like in, in the majority of companies, you have a test environment where, someone can go in and make sure that the latest, features that you've, that you, the developers have built, are working or that it just, runs, for example, like Selenium tests or something like that.
Now you could do that on the continuous integration server, but the idea here is like, instead of deploying to your production environment, which if it's not, you know, you don't have a good code coverage or, wide enough code coverage could actually break the deployment.
You deploy to a server where you take a look at everything and you say, okay, this is good.
Let's go ahead, push the button and hit this, put this into production.
Um, yeah.
So that's, you know, a possibility.
Uh, certainly that's a very standard, setup for, you know, having test servers.
Yeah, definitely.
Definitely a good idea.
If it's a big problem when you push out a bad build related to that is, having the ability to roll back a deployment.
Yeah.
I mean, so most deployments now, a mature deployment is going to have some way where if it's, if it turns out, cause a lot of times you have production data that is different from your test data, especially if that's, you know, personally identifiable information.
So that was many times as I did some government consulting, or maybe you have HIPAA compliance in the healthcare industry, something like that.
Um, I certainly don't, I certainly recommend that if you, you don't just read this book and do your HIPAA compliant deployment or something like that.
I think this is really a learning book.
Um, but the idea here, behind, behind code rollbacks would be, the deployment doesn't, goes wrong, goes bad.
Um, it's going 502 HTTP errors, maybe the whiskey servers having some issues.
Uh, and so the idea is like, you just roll back to the previous version without having, to manually log into the application and all that stuff.
What, what are the moving parts you had in mind for that?
Um, so, so part of it is just going, you could go back to a different, get tag.
So what often happens every time you do a build on Jenkins, you, you actually tag the code.
Uh, so you could, you could do that, in that case.
And then you would go back to a previous tag, which points to a previous commit.
Um, the, the complication there really comes in with the database, schema.
So if you've migrated the database schema, you also need to add in a hook where you can, roll back the migration.
So there's a bunch of different steps that are involved in there.
Um, and this kind of brings up the larger point, which is like, I added this chapter because I wanted to know from readers, what would they find most useful?
Like, what are the problems that they're encountering?
Because I think these are all very valid things, but, maybe some of them are more important to readers than others.
Yeah, definitely.
One other one in that area that I thought was interesting was deploying through a system package instead of version control.
Yeah.
So in this case, you could install, you could install your application by, bundling it in like a, you know, Debian package or some, some people use a red hat.
Um, and so red hat has RPMs.
Um, the idea here is like, you're not using source control in order to do your deployment.
And there are many advantages to doing that, but that's, I would, I would argue that's a little bit more of an advanced deployment topic.
And something that, has more complexity than I wanted to introduce the reader to at this point, in the book.
I was really trying to make sure that this was a learning process that didn't lose people along the way.
Right.
Absolutely.
It is a cool idea.
You know, in show 23 with, Eli Ribble and Authentize, those guys were using pip for all their deployments, which along with get tags was really an interesting way of doing it.
Basically they'd pip install their app and it would suck down all of their internal libraries to a private PI PI server.
Yeah, that's totally, totally a legitimate way to do it.
And in many environments, like the security folks are going to say, Hey, you actually cannot install from, from public PI PI or something like that.
Cause they're worried about, breaches that could, could occur through those things.
I think the main thing is just that every company has to decide what's going to work for them so they can get stuff done and reevaluate that on an ongoing basis.
Because what I often see with deployments as I go, as I used to go into consulting clients was they decided 10 years ago how they were going to deploy their applications and never reevaluated that.
And that's where you really encounter some, some pains, because they're not up to date with the latest practices and whatnot.
Yeah.
There's some pretty egregious stuff out there that people just stick with because, well, that's how we've been doing it.
Right.
Exactly.
That's kind of what your book is meant to be solving, isn't it?
To some degree.
Yeah.
I, I mean, I think that this is all going to continue to evolve.
I wouldn't say that, you know, this is, you know, the definitive way that everyone should do their deployments.
But I really do think that if you've never touched a deployment before, like this is, I, I, I feel pretty good that this is going to be a great resource for, for people that are in that situation.
I'll learn a ton from it.
Yeah, absolutely.
So one thing that I suspect you thought of, but it's not necessarily in the book, and this is not a criticism, I agree with it, is containers or are containers.
And Docker.
Yeah, totally.
Well, my hope is, is that I can actually get, one of my, one of my good friends, Andrew Baker, who was one of the reviewers of the book to write a chapter on Docker.
He, he actually did the O'Reilly video for Docker, sort of introduction to Docker and knows a ton in that area.
So I am not as familiar with containers as, so far has not been something that, I've spent a lot of time with.
Um, so I didn't want to leave the reader in the wrong direction, but I certainly think that that is, a possibility for, for doing deployments and may simplify the process a lot.
Yeah, I think it would.
I mean, it doesn't negate all the knowledge in your book.
You still need to know how to set up green unicorn.
You still need to know how to set up NGINX.
It just happens to be, you might do that in a container, right?
Sure.
But still the knowledge is, is it's totally builds on what you did.
So that makes a lot of sense.
And the last thing that you talked about were sort of performance improvements, right?
So you talked about putting this all on one machine, no load balancing, like at a $10 server.
And then, you know, that's good for like six months until the traffic spikes.
And then, then what?
Right.
Yeah.
I mean, it totally depends on your application.
I mean, if you, you know, if you're doing everything with Redis on the backend, then you could actually scale this to like a very large number of requests per second.
Um, but there are, very clear ways in which you can offload processing, and for example, serving statics assets from a content delivery network.
That is a super easy win.
If you have a bunch of images in your application and instead of serving it from your Nginx server, you're going to be serving them up from Akamai or, you know, Amazon CloudFront, something like that.
Um, you can also have multiple web servers that are connected to a single database backend and have load balancers, between them.
Um, that again, all of these things add some complexity, some more than others to the deployment process and are totally valid ways to improve performance.
Um, but it's going to depend on your application.
And I think that's where more of the nuance, like going from after reading this book, you're kind of a beginner deploy, beginner knowledge level and deployment.
Um, to go to the intermediate level, you really have to look at your specific application and say, okay, where are the bottlenecks?
And that's where you change your deployment process to match.
Right.
It doesn't make sense to just go, I'm going to scale the heck out of this thing.
And you're adding complexity that you might not need to be adding.
Right.
Yeah, exactly.
Yeah.
The other, thing we could swap in here instead of improving performance is maybe improving durability because a lot of the horizontal scale will also get you that right.
If a machine fails, you could take it out of the load balancer or you've got to reboot one, something like that.
Right.
Yeah.
I mean, that's, yeah, you could absolutely have like a database replication server where, that's a read only server.
So maybe you read from the read only server and you have a write only database server.
Um, there's all sorts of ways you can improve the durability here.
Um, you know, if you, if that's top of mind for your application.
So you want to talk a little bit about what you got going on at, Twilio before we wrap things up?
Yeah, absolutely.
So,
first, what, what is Twilio?
Sure.
So, so Twilio, Twilio is a, it's a cloud communications platform, which might sound a little bit buzzwordy if you're a developer.
Um, but really the idea is we provide a web API, that I like to think of as an abstraction layer upon the telecommunications industry.
Um, but more broadly than that, as we expand out.
So we started out with voice calling.
Um, we later added a few years later, SMS, we've added a multimedia message.
So it's like text messaging, but also, you know, sound clips, movie, clips, pictures via text message, through a standard MMS, protocol.
Um, over domestic carriers in the United States and Canada.
Um, and then now we've expanded it.
We have a beta product for video, which is just pretty much the coolest thing that I have ever played with.
Uh, building a video application, over, it's, it's abstracted over, WebRTC, but we expose all the, all the underlying things, but you can build a video application in like five minutes.
And it's like my favorite thing to play with lately.
Uh, but we also do, we also have a beta product for IP messaging.
Um, we've introduced a lot of these things lately.
And the idea is if you're, you are a developer and you are adding some type of communications to your, to your application, whether that's a mobile or web application, then, you should think about using.
And, and take a look at Twilio.
Um, and that kind of gets into what I do for Twilio, which is, my title is developer evangelist.
Um, some companies call that like a developer advocate or developer relations.
Um, the idea is like all of my work for the most part is open source.
So I'm helping the community be able to implement, not, not only implement Twilio, in their applications, but also just, being active and involved in.
The communities that I, I, most enjoy being a part of.
And obviously first and foremost, that's the Python community.
It's been my community for, for years now.
I have so many great friends in the Python community.
Um, I'm really, really proud of just the direction that the community is going in.
I think we've got some incredible leaders, putting us in the right direction for things like PyCon and, just the general community.
Yeah.
And I think that growth and positive energy is accelerating if anything.
So very, it's a very, it's very great time to be part of it.
Yeah.
So, you know, that's kind of my primary community.
I've also been doing a bunch of Swift development.
Um, I like iOS.
I just bought the Apple watch, which is pretty cool.
So I'm starting to dabble in that area.
Uh, but really like those are my, my core communities.
And, so like I got last night, I was at a Swift meetup tonight.
I'll be at San Francisco Python.
Um, but the idea is like as a developer vandalism out in the community, and I'm really just helping my fellow developers.
Like I would be doing that anyway.
Um, the great part is if they are building an application and they want to know how to send a text message or they want to add two-factor authentication, or they want to add voice calling or video in the future.
Like I can help them do that and I can help them really quickly.
And hopefully, they've already met me or they've met one of my colleagues.
And therefore, it's super easy to shoot me an email or call me up on the phone and I can help them out and they can start, using Twilio.
Yeah, that's awesome.
It's great to have you as a resource for that.
So obviously Twilio is all about having Python developers, you know, pip install your guys' APIs and work with them.
Are you using it internally or using Python internally?
Yeah, absolutely.
So, there's a project called Flask RESTful, which is pretty common for creating, RESTful APIs with Flask.
Um, so that actually is what runs our, web API itself, like the endpoints themselves.
We actually open source that project.
Um, it's now in its own separate, organization on GitHub.
Um, but that was created by some folks at, at Twilio.
And so we, we open source that for the community.
Um, so we do use quite a bit of Python internally.
Um, we also use, JVM languages like Scala and Java.
Um, we still some, have some PHP on the backend, which, some people are a little bit, you know, skittish to admit, but, PHP is still a totally valid language.
Um, and then, you know, we have some iOS and Android developers who work on, on some of our mobile stuff.
So we've got, we have a, a, a lot of languages in the mix at Twilio.
What does the deployment look like for your API finance relative to your book?
Sure.
Yeah.
So, really the big difference and kind of goes back to what we were talking about earlier is we actually are completely deployed on Amazon web services.
And so we have, for the most part, an immutable architecture, which means that once you spin up a server on Amazon web services, you don't modify that server in flight.
We spin up new servers with new configurations and backfill and spin down the servers that are old.
Um, so we don't have people going in and modifying, servers that are already operational.
Um, that helps with complexity.
Uh, it also helps that, you know, when you have thousands or however many servers we have out there on Amazon web services now, you cannot go and manually configure those services.
So, certainly many of the, principles that are taught on this book, like, especially around web server configuration are completely valid, for how we run our operations.
Um, but they're at a very, very large scale, considering the number of, of API calls that we, we have, in every single hour of every single day.
Yeah.
That's really awesome.
I think, you know, that's the right use case for EC2, right?
When you get to that scale and you need that much fine grain programmability to the API to actually create and provision machines and all that kind of stuff.
Right.
Yeah, exactly.
But it means that also that like the knowledge you learn from doing deployments here is completely valid for doing deployments in a much larger environment.
It's just that, those tend to be, those deployments that we do at Twilio are, you know, they've been honed and enhanced and, and in some ways, you know, increased in complexity over the past seven years, the, the life cycle of the company.
So, you know, there's, these things don't suddenly get created overnight.
Um, you grow into those sorts of things.
Absolutely.
Yeah.
I don't know if you listened to the Netflix episode, but they talked about what they're doing in EC2 there and they have so many different configurations and so on that they've actually set up scikit learn and machine learning to understand if there's a deployment problem.
That, I mean, it's amazing.
I have a really great friend at Netflix, and he, actually spoke at, Twilio signal conference, this past year.
And, he, he talked a lot about all the tools at their disposal.
I think what they do where they open source, a lot of their tools is absolutely incredible.
Um, and, they use a, just a huge number of, AMIs, which are like the Amazon machine images, in order to pretty much a snapshot, what they want to deploy.
Um, so they're like sort of, they were one of, I think probably one of the first to really take advantage of the free AMI snapshots.
And now they're, you know, using that at scale and obviously using machine learning and, they're on the forefront of all this stuff.
It's, it's amazing what they're, what they're working on.
Yeah.
If, if your book introduces people to the beginning steps, that's the opposite end of the spectrum, isn't it?
Yeah, sure.
And I mean, I think my hope is, is that, if you read this book and you're really excited about this deployment, these deployment concepts, because deployments used to be like a system administrator going in and punching a bunch of keys and, you know, manually installing things.
Like, yes, you should understand some of that stuff.
So you can get like a foundational layer for doing deployments and, and setting up servers.
But really, deploying at scale is programming.
Like when you are automating a deployment, you are programming in the same way as building an application.
And so, what Netflix and, and what we're doing at Twilio, a huge part of the deployment process is just programming the deployment process and automating everything that's out there.
Very interesting.
Thanks for sharing that look inside Twilio.
That's cool.
Two questions before I let you out of here.
Sure.
Uh, what's your favorite editor?
If you're going to write some Python code, what do you open up?
I use Vim for pretty much everything.
Um, I use Xcode for writing Swift, just because that's like the default, that you go to, but I've been using them for a long time.
And, that is my, my go-to my, Vim as you probably can tell, but if you ever go to the Vim page on full stack Python, it's a, a lot more, meaningful information than the Emacs page, which was a community contributed.
Cause I, I don't know if I've ever actually opened up Emacs before.
Nothing, nothing against it.
I just, I stuck with Vim for a long time.
Yeah.
That's funny.
And I can imagine you wouldn't want to do storyboards in iOS.
No, I don't, I don't want to figure out how to, how to write, you know, iOS applications.
I don't know.
Yeah.
That definitely requires an ID.
All right.
Other one is your favorite PI PI package that maybe people don't know about it.
You want to raise the awareness of.
Okay.
So I'll, I'll go with two of them.
Um, one is like a little bit more self-promoting.
My favorite one that I wrote is called underwear.
And the idea behind underwear was I wrote this project over like five or six weeks.
And it's like, I thought, why don't we have, when you're working in Django, like a Python
managed out by deploy, like, and that just deploys your entire application to a, like a
virtual private server.
And what it does is it uses Ansible programmatically under the covers, to handle the entire
deployment for you.
Uh, so if you use like pip install underwear and you add it to your installed packages, you
suddenly get new managed out by commands.
Uh, and one of them is deploy and you just pointed at a server and boom, your application
is like up and running.
I haven't worked on it all that much lately.
Uh, but it's kind of magical when you get the configuration, right?
And you're just like, wow, I just deployed through the Python managed out by, commands.
So underwear is that one that's all open source under MIT license.
That's really cool.
And the fact that you've got that name for it is, is awesome.
Uh, yeah.
Well, I mean, the meaning behind the name was basically like, this is how you could start
doing your deployments.
Um, if you want to, and then you can change your deployment process later.
Um, and no one will know it's like changing their underwear and like no one sees your underwear.
So like, they don't really care how that goes.
So I don't know.
That was the gist behind it.
That's funny.
I thought, and it was, and it was actually, it's really funny when people are like, Oh,
uh, like I, I was at Django con one time and someone was like, Oh, you're the underwear
guy.
And my colleague was like, I'm sorry.
Like what, what did that person just say?
And I was like, Oh, I wrote the underwear package.
Like that's what they mean.
I'm not an underwear model or something like that.
Um, so that, but other than that, I mean, you know, it's, I actually really like
the, especially when I was doing consulting, I mean, saving time through, like the,
Excel, the Excel, like read and write packages.
Um, and so it's been a little while since I've used them in the past, but like, if you need
to read from or write to Excel spreadsheets, which, is shockingly the system of choice
for the vast majority of corporate America.
Um, like if you were trying to create a web application that automates what is happening
in Excel spreadsheet, like these packages, so it's like Excel, RD, and Excel.
W I believe something like that.
Um, these packages on PyPI are like so much time savers.
Like I just, I don't know.
Every time I've used them, I've been like, thank goodness.
Like if I had to create this all from scratch myself, I never would have gotten this project
done.
I think you're right about how much of corporate America enterprise space runs on, on Excel.
It's crazy.
Yeah.
I mean, companies have entire names for like one company I work for called them,
EUCs.
And they kept throwing around the EUCs acronym.
And I'm like, finally, I'm like, what is an EUC?
And they're like end user computing basically means the end user created the computing system
on which they are doing all their processing on, which is, Excel.
Yeah.
That's pretty much what it means.
Those are, those are some good ones to know about.
Thanks.
Matt, this has been super interesting.
And I think for those listeners out there who are not day to day doing deployments, this is a really
helpful book.
Do you want to just tell people how they can get your book and things like that?
Yeah, sure.
Um, so one way would be to just go to deploy python.com.
Uh, and then that has a link to buy the book on gumroad.
Uh, if you want to go to gumroad directly, it's a gumroad.com forward slash L forward slash Python dash
deployments.
And I actually created a promo code for anyone who is listening.
It's, talk Python to me, with all dashes.
We'll make sure that's included as part of the, the references.
Um, but anyone can use that for 15% off the book.
Um, and, and also I'm, you know, I'm happy to answer questions about it.
And, you know, if people pick it up and they realize like, this isn't the book for them,
I try to be as clear as possible on the audience, but if you pick up the book and it's not great
for you, happy to give you a refund on it.
But, I just really enjoyed creating the book and hearing from readers and continuing
to approve it along the way.
Yeah, that's awesome.
Thanks for writing it.
It's a really good book.
I, I recommend readers go to deploy python.com, go to the bottom of the page, look at that architecture
picture.
And if, you know, knowing how all those pieces get created, wired together and set up in a
repeatable way is helpful, you know, check out the book.
It's all about that.
Cool.
Thank you very much, Michael.
This has been great.
Yeah.
Thanks for being on the show, Matt.
Talk to you later.
This has been another episode of talk Python to me.
Today's guest was Matthew McKay.
And this episode has been sponsored by hired and opt beat.
Thank you both for supporting the show.
Hired wants to help you find your next big thing.
Visit hire.com slash talk Python to me to get five or more offers with salary and equity presented
right up front and a special listener signing bonus of $4,000.
Opt beat is the mission control center for your Python web application.
Keep an eye on errors, performance, profiling, and more in your Django.
And now starting today, Flask web applications.
You can find the links from today's show at talkpython.fm/episodes slash show slash 26.
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 and direct RSS feeds in the footer of the website.
Our theme music is developers, developers, developers by Corey Smith, who goes by Smix.
You can hear the entire song at talkpython.fm.
This is your host, Michael Kennedy.
Thanks for listening.
Smix, take us out of here.