#26: Deploying Python Web Applications (Updated) Transcript

00:00 So, you've built amazing Python web app- and now what? You want to put it online of course, but that's a whole different skills set. Well, today you're in luck, because Matthew Makai is here to tell us all about deploying Python web applications on episode #26, recorded Monday, August 17th, 2015.

00:00 [music]

00:00 Welcome to Talk Python to Me, 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.

00:00 Keep up with the show and listen to past episodes at talkpythontome.com and follow the show on twitter via @talkpython.

00:00 This episode is brought to you by Hired and Opbeat. Thank them for supporting the show on twitter via @hired_hq and @opbeat. That's right, Opbeat has joined the show as a periodic sponsor and they have a huge announcement for you, later in the episode.

00:00 I have a little news for you this week.

00:00 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 http://importpython.com/jobboard/

00:00 The past two episodes have been with book authors (as is this one), and for each episode I've given away a book to one lucky listener who has signed up as a "friend of the show".

00:00 I want to say congratulations to Kristian Wedmark from Sweden, who won Fluent Python and Keith Ord from Georgia who picked up Effective Python.

00:00 Want to win a book like Kristian and Keith? Well be sure to sign up at talkpython.fm as a friend of the show.

00:00 Let me introduce Matthew.

00:00 Matt Makai (@mattmakai) is a Twilio Developer Evangelist based in San Francisco, CA where he builds open source applications in Python and Swift. Matt spoke at EuroPython on "Full Stack Python" and PyCon about virtualenvs and web app deployments. He created the underwear library hosted on PyPI and writes Full Stack Python to help fellow developers learn how to build and deploy their WSGI-powered web applications.

02:21 Matt, welcome to the show.

02:24 Thanks for having me, Michael.

02:25 Yeah, I'm really glad you are here. We are going to talk about some awesome deployment stuff, based on your new book that you've wrote. So, before we get into deployments and that sort of thing, let's start from the beginning- what's your story, how did you get into programming in Python?

02:41 Yeah, sure, so I've actually been programming for long time, I took 4 years computer science in high school, I was very fortunate to have extensive computer science classes in high school and I strongly believe that needs to be extended throughout United States, and then through that I got into computer science in college, a James Madison University, and then I did my masters 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 Python scene.

03:21 Was your education in Java? Is that how you ended up down that path in the beginning?

03:27 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 underline 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 different languages that I could kind of switch back and forth when necessary.

04:04 Yeah, very cool. Ok, so you got a job in Java, and somehow you made your way over to Python-

04:09 Yes, 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 to sort of teaching myself Python I realized in a couple of hours of working on Sci projects I felt more productive then an entire day at the office. And, I just thought, well 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 Java projects and that was kind of my introduction to that world.

05:03 Yeah, that's really cool. It's both exciting and somewhat regretful like, why didn't you do it earlier? That's 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-

05:18 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, dictionary or a list, like you really appreciate that you don't have to resize that array, you can use the built in data structure and so much more productive.

05:34 Yeah, absolutely. All that stuff is way more appreciated at least from my perspective.

05:38 Yeah.

05:39 Awesome. So why don't you tell me a little bit about Full Stack Python?

05:43 Sure, so 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, and sending me emails and I would write these long detailed emails about how WSGI server operates or what the difference between Django and Flask was. And, one of my colleagues said, "You really should actually publish this, 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 Full Stack 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 I was sort of getting readers. So that was the very beginning of it.

06:45 So how many articles or topics did you have out of your email before you had to start writing for Full Stack Python?

06:53 Yes, so a lot of it was just around web frameworks, and especially around deployments, because I would deploy a lot of applications, to just basic server, because many of the consulting engagements I was on, didn't have existing Python projects. So they needed someone who was a quote unquote Full Stack developer. 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 that was the original quote unquote full stack was the web frameworks and the deployments and the servers and that sort of thing.

07:34 Yeah, that's really awesome. Your book that you wrote, what's the title?

07:38 So it's the "Full Stack Python Guide To Deployments"

07:42 Right, so this is basically taking all of your guidance and stuff around, the Python web frameworks, and just focusing on the deployments side of the story; so kind of assumes you are a competent developer, you've written this web app and now what, right?

07:56 Yeah, so I really recommend this to people, the way that this came about is that I kept getting emails from people who were reading Full Stack Python, and they were like, "Hey this is really great, Full Stack Python but it's super high level, and you've linked all these tutorials- but they are all sort of just, they are different tutorials they are mix 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 are super basic, like if you don't know how to do 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 is how you provision a server", and actually start it up.

08:48 Yeah, that makes total sense. You know, I do professional training for developers for Perma Job and I get questions like how can I even host my Pyramid web app or whatever type of web app you have created like some people who live and read the web world, well obviously you create this kind of server, that kind of server, but if you are maybe like a data scientist or you are transitioning, and you are 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.

09:28 Yeah, and I think you completely touched on it, if you are a data scientist, or you are a coding bootcamp graduate, or you are just out of undergrad, or maybe an intern- you've never been exposed to these concepts before, because they are not things that are typically taught in computer science program. And often deployments are not touched on coding bootcamp, and so 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. It was I don't assume you know any of these stuff, and we are going to walk through it step by step.

10:01 Yeah, that's really cool. I think that's a good place to start. You have this picture on deploypython.com, at the bottom of the home page, and it's kind of like a visual architectural base version of a table of contents.

10:17 Yeah.

10:20 It's really awesome, I really love that picture, so it's got like a server, and a virtual machine and all the various moving parts sort of sketched out in architectural but also showing the chapters- you kind of make your way to this architectural diagram, right?

10:34 Yeah, exactly. So I start each chapter with the same diagram and I highlight- there is specific color for each chapter. So for example, I think it's chapter 3 with operating systems is like a shade of yellow, and so I highlight "here is what we are 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 are working on, and maybe that's on your own server or that's a hosted service like GitHub or something like that, but these have an image in your mind of what we are 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 ok 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 is the virtual private server set", so that is what I try to clarify with the picture that is on deploypython.com, just "here is all the things we are going to walk through, and here is how they look".

11:31 Yeah, I think it's great to have a visual way to see what you are going to learn like that, architecturally.

11:37 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, "Ok, 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.

12:09 Yeah, that's excellent. And I'm sure that talk is actually on YouTube somewhere, right?

12:12 Yeah. Totally if you do EuroPython, Full Stack Python, my talk comes up actually if you do Google for Full Stack Python. Kate Heddleston gave a really talk as well, at PyCon I believe it was 2014, the kind of talk that walks through some of the same concepts.

12:30 Yeah, excellent, I'll put that in the show notes. So, let's talk about servers first. You are using Linode for your host here, yeah?

12:39 Yeah. Absolutely. And it's kind of I think maybe it's a little bit confusing in the book because I say "well, we are 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 already got an application, great, like let's figure out how to deploy it, you can pretty much follow the steps in each chapter, you start out with the server. And if you don't have an application, like here is a full tutorial, it's appendix C in the book"- it's 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 dependences and what not, it's a flask app. And so the idea is like 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.

13:34 Yeah, very cool. At minimum get clone it so you have something to deploy, right?

13:38 Yeah, totally and I mean a great part is I actually wrote that content on the Twilio blog which Twilio is my current employer and so that appendix has been a lot of people follow along with that and give me feedback on it, so it is a pretty good tutorial just to include as an appendix if you are trying to build a Flask application.

13:59 Yeah, excellent. Let's come back to talking about what you do at Twilio, because that sounds interesting. But- Linode.

14:06 Yeah, absolutely. So the idea behind really how we get started in this is like, ok we need to deploy our application somewhere. It can't just be living on your laptop, like people on the internet need to access that. And so we get a $10 amount server on the node and I walk through the steps of 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 unauthorised attempts to log in.

14:37 So we disallow the root user from being a login account and create a separate login account, we disable password of password authentication, we only have public key infrastructure authentication, and we set up firewalls and automatic upgrades and these things will not completely secure your server, but they are the good first steps that I would always recommend people to do to every single server that they are starting out.

15:01 You know, one thing that my current experience absolutely backs up but just sort of the way the cloud and sort of this type of hosting has been going- I was a little surprised you've weren't using like Ubuntu machines on EC2.

15:19 Yeah, sure. So, I think- I really like Amazon web services, but I also feel like it's almost over used for a lot of deployments, like you can actually take a virtual private server and scale that up to Hacker news traffic. If you can figure it properly. And I think that's one of those things where like you can wreck up a huge bill deploying to Amazon web services, if you are 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 are going to do that within the confines of a single virtual private server.

15:55 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 are right and there could be an entire separate book that's like, Ok cool, you've learned the gist of deploying web applications now it's actually go and deploy this on a cloud based infrastructure or I guess you call it like infrastructure as a service provider like Rackspace or Amazon or Azure.

16:22 Right, yeah, for sure. So, I think probably the majority of people out there would be better served by using something like Linode or Digital Ocean, the pricing is so straightforward and the setup is so easy and so quick, and EC2 is more, it's something that works for places like Netflix, which are doing amazing things, but it's like so large scale and when you are getting started, 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.

16:53 Yeah, I think it might be something to grow into, I 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 beside to it, but you are totally right and that is 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 a $1000 this month." And I'm like, "Oh no, I really don't want that to happen to people and have them be afraid of doing deployments", like if you get a bill for $10 a month that should be the maximum amount that you get out of this.

17:33 Right, it's much more predictable over in those places. Very cool. So when you are talking about locking down the servers, one thing that I thought was pretty cool that you recommend is using something called "fail 2 ban"

17:44 Yeah sure. Yeah so Fail 2 ban is package on Ubuntu that's on many other distributions as well which essentially sets certain parameters like time based failed logins. So if from a certain IP address there are fail login attempts, it will prevent any logins from that IP address for example for 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, they cannot do a password based login anyway after it's secured down, but it's just one other step of basically the just locking down the server that will prevent some of those unauthorised attempts.

18:32 Right. And why you are going through this process? You know, you are a machine, if it is on the internet it is basically under attack, right, and so having sort of password login safe for a while is still something you want to consider.

18:46 Yeah, and you know, I think part of it is just exposing readers to some of these tools and concepts they have at their disposal, I think that you could write and I'm sure the entire books are written about Fail 2 ban or about UFW which is the firewall tool that we use. But just knowing that they are there and that you've set them the basics parameters up, I think is enough to get people started but not dwell on this subject, so they can continue on and actually get the deployment done.

19:15 Right. The other thing that I made a note of 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.

19:26 I mean, I actually wrote the whole section on like setting up IP tables, and then when I started doing some research I realized that Ubuntu there is this uncomplicated firewall and I was like oh well, 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 meant.

19:49 Yeah, absolutely. I would say it's even uncomplicated. It's great.

19:52 Yeah.

19:53 So, then basically for the rest of the book, you said look, you could sit down and manually type these out of 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?

20:08 Yes. So, well there is fabric and there is ansible. And so the idea is I think that going through a manual doing deployment and reading through what steps you are taking, is really important for the learning process, but obviously you are not going to do this every time you have a deployment, so you are going to want to automate the entire process so you can deploy as many web applications in the future as you want, and you can modify the deployment scripts so they are custom built for your applications.

20:38 And so, every single chapter in the book- so starting with chapter 2 which is the server chapter, we do the manual steps and explain manual like what you are doing in those manual steps, and then I go into a sort of second section of the chapter which is here is how we automate the manual steps that we just did, with either fabric or ansible. And so starting in chapter 3, we have ansible playbooks that automate everything that we are building on top of and actually those, all those that playbook, that ansible playbook is actually all open source on GitHub under one of the GitHub reposts that I have.

21:18 Ok, yeah. Excellent, we'll put that out there on the show notes as well.

21:22 Yeah. Great.

21:23 Yeah, I think you are right, you know, this is one of the things where if you've got time and you haven't deployed your site live or whatever, it's fine to just sit there and fiddle with the server until you get it working. But if something goes wrong, especially you need to rebuild the machine or move it or scale it out or something, and you don't know how to do that, under some high stressed situations like the website is down, there is a lot of traffic, doing that by hand is just extremely stressful and if it is automated you push a button, few minutes later, life is good again. It's definitely recommended.

21:23 [music]

21:23 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.

21:23 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 5 or more offers in just the first week and there are no obligations, ever.

21:23 Sounds pretty awesome, doesn't it? Well did I mention the signing bonus? Everyone who accepts a job from Hired gets a $2,000 signing bonus. And, as Talk Python listeners, it get's way sweeter! Use the link hired.com/talkpythontome and Hired will double the signing bonus to $4,000!

21:23 Opportunity is knocking, visit hired.com/talkpythontome and answer the call.

21:23 [music]

23:11 I honestly, I've been using it for several years, I think it's a fairly stable default choice, but I think there is a ton of other great WSGI servers out there, and certainly if you are going the Apache modWSGI is a good to go, but just in this case I thought that the combination of Green Unicorn and Engine X just seem to be the one that I was most comfortable with and the most comfortable teaching other people about.

23:41 Right, sure, that makes a lot of sense. The one that I've been using is Micro WSGI, so that's also been pretty good.

23:49 Yeah, absolutely. And I've seen some of the, you know, you have to be careful about the benchmarks and stuff but I've read some benchmarks I've said that actually might be a faster WSGI server in many cases.

24:00 Right, so, you know, going with the theme that not everybody is a web developer and necessarily knows, maybe you want to talk really quickly about WSGI, the concept of WSGI itself.

24:10 Yeah, sure. So, that's web server gateway interface WSGI and the idea is like in the late 1990's there was, so Apache was the dominant web server back in the day, and someone grew a module for Apache called modPython and I used modPython 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 develop kind of languished, so the Python community came together and created a Python enhancement proposal- PEP, PEP 333 which created the WSGI standard and then there is the superseding one which is PEP 3333.

25:00 And that one just really was a simple update to say like we're expanding this to like Python 3 but the idea behind it is and I kind of have some background knowledge on this with application dependencies page on Full Stack Python, but the idea was like there needs to be a standard super simple way for a web application server like CherryPi or modWSGI or Green Unicorn, to execute a web application. And so, if you are using Django, Flask, Bottle, one of these frameworks, they implement the application side of the WSGI standard whereas your WSGI server implements the server side. And so there is the simple hook between the server and the application, we already got that up and running, so that you can deploy this in the standard way and you can mix and match different frameworks and servers. That provides the interoperability between the WSGI servers and WSGI applications.

26:03 Yeah. That's awesome. I mean, it basically means that we could switch between MicroWSGI and Green Unicorn and it wouldn't be that big of a deal, right?

26:11 Yeah. Exactly, so if you are more comfortable with the different WSGI server, you know, by all means you could use the exact same setup to switch out the WSGI server and use the one you are most comfortable with.

26:22 So, we've got an up running we've got our reverse proxy from Engine x over two Green Unicorn and everything seems to be good, but how do 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.

26:42 Yeah, sure. And the only other quick thing I wanted to add is you do add a task queue as well in there, task queues are for asynchronous data processing outside the http request respond cycle so the idea here is like, "That's such a common thing that people want to deploy I just added 26:58 as a part of our application deployment, 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.

27:09 Yeah, I think that is a good point and you know, some variation of an asynchronous queue can add so much scalability, in a really easy way, right?

27:17 Yeah, exactly, it's like, oh this database query is taking too long, when someone hits the server, well, just put it in an async task queue and process it every 15 minutes or something like that, if the data doesn't change that often. And that way you are getting pretty much scalability by the design of your application and the deployment rather than having to get a bigger server in order to somehow process that database query faster.

27:46 Yeah, yeah, definitely. Ok, continuous integration.

27:49 Yeah so the idea here is, again, many of the tutorials that I saw like continuous integration is completely separate setup from deployment, and so I thought, you know, this is really core to have applications deployed, so we take the ansible playbooks that we have created throughout the book, and we setup Jenkins as the implementation of the 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 2 separate servers.

28:19 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 standard most commonly called webhook. Webhook notifies Jenkins, "hey, there's been some changes" so Jenkins pulls down the code, makes sure that everything is working and this is the part where you can put in your hook for like unittest integration tests, and fail the build if those don't work.

28:49 And then, if everything is good, we deploy the code to the actual server, the production server and then you get handy little text message that says your application deployment is complete. So often times we have this really long running deployments, maybe they take 10 or 15 minutes to pull all of the code and do the whole deployment and everything, so maybe you want to step away from your computer, 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 all complete".

29:25 Very cool, and of course, Twilio is the backend for the text message, right?

29:30 Yeah, so I mean I really love using ansible and so I was just kind of playing around with some of the modules the stuff like that, so the Twilio module is a part of the standard ansible if you do like pip install ansible, so you can just use Twilio service with your credentials to send the text message. So I actually wrote that like a year, a year and a half ago.

29:54 Yeah, that's really cool.

29:57 Yeah, it's kind of under the notifications package. You can 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 is done, so there is all different types of notifications. You can do a notification to Slack, super easy to add that instead of the Twilio notification, but I kind of like to get a text message because I like to walk away from my computer when the deployment is on.

30:18 Yeah yeah no kidding. Let something else stick around and be tight to the desk. So one thing I do want to do is I want to give a shout out to one of my sponsors, Codeship, because you know, Jenkins is a cool Java and sort of configures itself, and codeship is kind of you know, CI as a service so check them out if you are not wanting to set up something.

30:39 Yeah, no doubt. I've had some- I have a bunch of friends who have good experiences with codeship, so...

30:43 Yeah, awesome. So, 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 have one section on deployment enhancements which we talk about and sort of touched on them, and others on performance. So the first one you said was sort of having a QA environment?

31:08 Yeah.

31:08 That might be a good idea.

31:10 So, yes, I glaze over this maybe a little bit, and maybe it deserves a lot more thought in maybe a future version, but the idea here is like in the majority of companies you have a test environment where someone can go in and make sure that the latest features that the developers have built are working or that it just runs for example like selenium test or something like that.

31:37 You could do that on a continuous integration server but the idea here is like instead of deploying your production environment, which if it's not you don't have a good code coverage, or wide enough code coverage could actually break the deployment, you deploy to its server, we take a look at everything and you say, "Ok, this is good, let's go ahead push the button and put this into production". Yeah, so that's yo know a possibility, certainly that's a very standard setup for having test servers.

32:06 Yeah. Definitely a good idea if it's a big problem you push out of bad build. Related to that, is having the ability to roll back a deployment-

32:17 Yeah. I mean, so most deployment now, I am sure that deployment is going to have some way where if it's turns out because a lot of times you have production data that is different from your test data especially if that is personally identified information so that will many times as I did some government consulting or maybe of hippa compliance in the healthcare industry, something like that, I certainly recommend that you don't just read this book, and do your hippa compliant deployment or something like that, I think this is really a learning book, but the idea here behind would be the deployment doesn't go bad, it's going 502 htp errors, maybe the WSGI servers having some issues, and so the idea is that you just roll back to the previous version without having to manually log into the application and all that stuff.

33:08 What are the moving parts you had in mind for that?

33:10 So, part of it is just going, you could go back to a different Git tags so what often happens, every time you are build on Jenkins you actually tag the code, so you could do that in that case and then you could go back to a previous tag which points to a previous commit. 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 or you can roll back the migration. So there is a bunch of different steps that are involved in there, and this kind of brings up the larger point which is like I added this chapter because I wanted to know from readers, what do they find most useful, like what are the problems that they encountered because I think these are all very valid things but maybe some of them are more important to readers than others.

34:00 Yeah, definitely. Another one in that area that I thought was interesting was deploying through a system package, instead of version 34:07 .

34:08 Yeah, so in this case, you could install your application by bundling like a debian package, or some people use red hat, and so red hat ahs rpms the idea here is you are not using source control in order to do your deployment and there are many advantages to doing that, but that's 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 the learning process that didn't lose people along the way.

34:48 Right, absolutely. It is a cool idea, in show 23 with Eli Ribble and Authentise, those guys were using pip for all their deployments, which along with Git tags, what's really interesting way of doing it basically they pip install their app and suck down all their internal libraries through a private PyPi server.

34:48 [music]

34:48 This episode is brought to you by Opbeat.

34:48 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 codebase and makes monitoring and debugging of your production apps much faster, and your code better.

34:48 Opbeat is free for an unlimited number of users, and until now has only been available for Django developers.

34:48 But, I can announce that they are launching Flask support today to Talk Python to Me listeners. Visit opbeat.com/flask to be amongst the first to join the Flask private beta.

34:48 [music]

36:07 Yeah, that's totally legitimate way to do it and in many environments like the security folks are going to say hey you actually cannot install from public PyPi or something like that, because they are worried about what could occur through those things, I think the main thing is just that every company has to decide what is going to work for them so they can get stuff done, and reevaluate that on ongoing basis, because what I often see with deployments as I used to go on to consulting clients was, they decided ten years ago how they were going to deploy their applications, and never reevaluated that. And that's where you really encounter some pains, because they are not up to date with the latest practices and what not.

36:46 Yeah, there is some pretty 36:48 stuff out there the people just stick with because- well, that's how we have been doing it.

36:52 Right, exactly.

36:54 That's kind of what your book is meant to be solving, isn't it? To some degree?

36:58 Yeah, I mean, I think that this is all going to continue to evolve, I wouldn't say that this is the definitive way that everyone should do their deployments. But I really do think that if you never touched the deployment before, this is- I feel pretty good that this is going to be a great resource for people that are in that situation.

37:18 Yeah, absolutely. So one thing that I suspect you thought of but is not necessarily in the book, and this is not a criticism I agree with it- is containers, or are containers. And Docker.

37:29 Yeah, totally. Well, my hope is that I can actually get one of my good friends, Andrew Baker who is one of the reviewers of the book to write a chapter on Docker. He actually did the O'Reilly video for Docker, sort of the introduction of Docker, I'm not as familiar with containers as so far it has not been something that I've spent a lot of time with, so I didn't want to lead the reader in the wrong direction but I certainly think that that is a possibility for doing deployments, and may simplify the process a lot.

38:00 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 Engine X, it just happens to be you might do that in the container, right?

38:13 Sure.

38:14 But still, the knowledge is built on what you did, so that makes a lot of sense. And the last thing you talked about were sort of performance improvements, right? So you talked about putting this all on one machine, no load balancing, like on a $10 server and then that's good for like six months until the traffic spikes and then- what?

38:35 Yeah, I mean it totally depends on your application, I mean if you are doing everything 38:40 on the backend, then you could actually scale this to like a very large number of requests, per second, but there are very clear ways in which you can off load processing, and for example serving static assets from a content delivery network, that is a super easy when if you have a bunch of images in your application and instead of serving it from your Engine x server, you are going to be serving them up from Acmy 39:09 or Amazon cloudfront, something like that.

39:10 You could also have multiple web servers that are connected to a single database backend and have good balancers between them- again, all of these things add some complexity, some more than others to the deployment process and are totally valid ways to improve performance, but it's going to depend on the application I think that's where more the new ones like going from after reading this book you're kind of a beginner knowledge level of deployment, to go to the intermediate level you really have to look at your specific application and say ok where are the bottlenecks and that's where you change your deployment process to match.

39:47 Right, it doesn't make sense to just go I'm going to scale the heck out of this thing, and you are adding complexity that you might not need to be adding, right?

39:54 Yeah. Exactly.

39:56 The other thing we can swap in here instead of improving performance is maybe improving durability. Because a lot of 40:04 on our scale will also get you that, right, machine fails you could take it at load balancer or you've got to reboot one, something like that, right?

40:12 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 40:20 the read only server and you have a write only database server, there is sorts of ways to prove the durability here, if that's top of mind for your application.

40:31 So, you want to talk a little bit about what you got going on at the Twilio, before we wrap things up?

40:37 Yeah, absolutely.

40:39 First- what is Twilio?

40:41 Sure, so Twilio is a cloud communications platform, which might sound a little bit buzzworthy if you are a developer, but really the idea is we provide a web api that I like to think of as an abstraction layer upon the telecommunications industry. But more broadly than that, as we expand out, so we started out with voice calling. We later added few years later, SMS, we've added multimedia message, it's like text messaging but also sound clips, movie clips, pictures via text message, through standard MMS protocol, over domestic carriers in the United States, and Canada.

41:25 And then now, we've expanded, we have a beta product for video which is just pretty much the coolest thing that I have ever played with, building a video application that's abstracted over webrtc, we expose all the underline things but you can build a video application like 5 minutes and is like my favorite thing to play with lately. We also have a beta product for IP messaging, we've introduced a lot of these things lately and the idea is if you are a developer and you are adding some type of communications to your application, or that's a mobile web application, then you should think about using and take a look at Twilio, and that kind of gets us into what I do for Twilio, which is my title is developer evangelist, some companies call that developer advocate, or developer relations.

42:17 All of my work for the most part is Open Source. So I am helping the community be able to implement not only implement, Twilio and their applications, but also just being active and involved in the communities that I most enjoy being part of, and obviously first and foremost, that's a Python community, it's been my community for years now, I've so many great friends in that community. I'm really really proud of just the direction that the community is going, I think we've got some incredible leaders, putting us int he right direction for things like PyCon...

42:58 Yeah, I think that growth and positive energy is accelerating if anything. So it's very great time to be a part of it.

43:06 Yeah, so that's kind of my primary community. I've also been doing a bunch of Swift and like IOS I just bought the Apple watch which is pretty cool so I'm certain of devil in that area but really, like those are my core communities and so like time I was at a Swift meet up tonight I'll be at San Francisco Python, but the idea is like as a developer 43:27 now in the community I am really just helping my fellow developers. Like I would be doing that anyway, the great part is if they are building an application and they want to know how to send the text message but 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 have already met me or they've met one of my colleagues, and therefore it is super easy to call me up on the phone and I can help them out and they can start using Twilio.

43:55 Yeah, that's awesome. It's great to have you as a resource for that. So obviously Twilio is all about having Python developers pip install your guys' APIs and work with them. Are you using it internally or using Python internally?

44:10 Yeah, absolutely. So there is a project called Flask RESTful, which is pretty common for creating restful APIs with Flask so that actually is what runs our web API itself. We actually open source that project now it's in its own separate organization on GitHub, but that was created by some folks at Twilio and so we open source that for the community. So we do use quite a bit of Python internally, we also use JVM languages like Scala and Java, have some PHP on the back end, PHP is still a totally valid language, and then we have some IOS and Android developers who work on some of our mobile stuff. So we've got a lot of languages in the mix, at Twilio.

45:02 What does the deployment look like for your API relative to your book?

45:08 Sure, yes. So really the big difference kind of goes back to what we talked about earlier. We actually are completely deployed on Amazon web services. And so, we have for the most part, a mutable 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. So we don't have people going in and modifying servers that are already operational.

45:38 That helps with complexity, it also helps that when you have thousands or however many servers we have out there on the Amazon web services that you cannot go and manually configure those servers. So, certainly many of the principles that are taught in this book, like especially around web server configuration are completely valid for how we run our operations, but they are at the very large scale, considering the number of API calls that we have in every single hour of every single day.

46:12 Yeah, that's really awesome. I think that's the right use case for EC2 right, when you get to that scale and you need that much programmability to the API to actually create and provision machines and all that kind of stuff, right?

46:25 Yeah, exactly. It means that also 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- the deployments that we do at Twilio are they've been honed and enhanced and in some ways, increased in complexity over the past seven years the life cycle of the company, so these things don't suddenly get created over night.

46:54 You grow into those sorts of things absolutely. I don't know if you listened to the Netflix episode, where they talked about what they are doing in EC2 there and the y have so many different configurations and so on, that they actually set up SciKit learn and machine learning to understand if there is a deployment problem.

47:12 I mean, that's amazing, I have really great friend at Netflix, and he actually spoke at Twilio signal conference past year, and 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. And they use just a huge number of Amazon machine images, in order to snapshot what they want to deploy. So they are probably one of the first really to take advantage of the free AMI snapshots and now they are using out of scale and obviously using machine learning, and they are on the forefront develop this stuff, it's amazing what they are working on.

47:56 Yeah, if your book introduces people to the beginning steps, that's the opposite end of the spectrum, isn't it?

48:03 Yeah, sure, and I mean I think- my hope is that if you read this book and you are really excited about these deployment concepts, because the deployments used to be like a system administrator going in and punching a bunch of keys, and manually installing things, like yes you should understand some of that stuff so you can get like a foundational layer for doing deployments and setting up servers, but really deploying at scale is programming. Like when you're automating a deployment, you are programming in the same way as you are building an application. And so, what Netflix and what we are doing at Twilio, huge part of the deployment process is just programming the deployment process and automating everything that's out there.

48:46 Very interesting, thanks for sharing that look inside Twilio, it's cool. Two questions before I let you out of here.

48:53 Sure.

48:53 What's your favorite editor, if you are going to write some Python code, what do you open up?

48:57 I use Vim for pretty much everything. I use X code for writing Swift, just because that's like the default that you've got to do. I've been using Vim for a long time. You probably can tell if you ever go to the Vim page on Full Stack Python it's a lot more meaningful information than Emacs page, which was community contributed because I don't know if I've actually opened up Emacs before. Nothing against it, I'm just stuck with Vim for a long time.

49:27 yeah, that's funny, and I can imagine you wouldn't want to do storyboards in IOS

49:33 No, I don't want to figure out how to write IOS applications in Vim.

49:39 Yeah, that definitely requires an ID. All right, other one is your favorite PyPi package that maybe people do not know about, and you want to raise awareness of.

49:47 Ok, so I'll go with two of them. 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, there were like 5 or 6 weeks and it's like I thought why don't we have when you are working in Django, like a Python manage.py 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.

50:17 So if you use like pip install Underwear and you add it to your install packages you suddenly get new mange.py commands, and one of them is deploy. And you just point it at the server and boom. Your application is up and running. I haven't worked on it all that much lately, but it's kind of magical when you get the configuration right and you are just like, "wow, I just deployed through pythonmanage.py" So, Underwear is that one, it's all open source.

50:44 That's really cool, the fact that you got that name for it is awesome.

50:49 Yeah, well I mean the meaning behind the name was basically like this is how you could start doing your deployments, if you want to and then you can change your deployment process later, and no one will know, it's like changing your underwear and like no one sees your underwear.

51:10 So, no one really cares how that goes. I don't know, and it's really funny when people are like, oh, like I was at Django conference one time, and someone was like, "oh, you are the Underwear guy", and my colleague was like "I'm sorry?", like 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 underwear model or something like that. So, but other than that, I mean, I actually really like the especially when I was doing consulting I mean saving time through like the Excel like read and write packages.

51:44 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, 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, these packages on PyPi are like so much time savers, like I just, I don't know, every time I use them I've been like thank goodness, like if I had to create all this from scratch myself I never would have gotten this project done.

52:25 I think you are right about how much of corporate America Enterprise space runs on Excel. It's crazy.

52:34 Yeah, I mean, companies have entire names for- like, one company I worked for called them EUCs, and they kept throwing around EUCs acronym, and I'm like, what is a EUC? And they are like End User Computing basically means the end user created the computing system on which they are doing all the processing, which is Excel.

52:56 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?

53:13 Yeah, sure. So one way would be to just go to deploypython.com and then that has a link to buy the book on Gumroad, if you want to go to Gumroad directly, it's a gumroad.com/l/python-deployments, and I actually created a promo code for anyone who is listening, it's t-a-l-k-p-y-t-o-n-t-o-m-e we'll make sure that's included as part of the refernces, but anyone can use that for 15% off the book and also I am happy to answer questions about it and if people pick it up and they realize that it 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 for you, I am happy to give you a refund for it. I just really enjoyed creating the book and hearing from readers and continuing to improve it along the way.

54:03 Yeah, that's awesome. Thanks for writing it, it's a really good book. I recommend readers go to deploypython. com, go to the bottom of the page, look at architectural picture and if you don't know how all those pieces get created, wired together and set up, check out the book. It's all about that.

54:22 Cool, thank you very much Michael, this has been great.

54:24 Yeah, thanks for being on the show Matt, talk to you later.

54:24 This has been another episode of Talk Python To Me.

54:24 Today's guest was Matthew Makai and this episode has been sponsored by Hired and Opbeat. Thank you both for supporting the show!

54:24 Hired wants to help you find your next big thing. Visit hired.com/talkpythontome to get 5 or more offers with salary and equity right up front and a special listener signing bonus of $4,000 USD.

54:24 Opbeat is the mission control center for your Python web application. Keep an eye on errors, performance, profiling, and more in your Django and, start today, Flask web apps.

54:24 You can find the links from the show at talkpython.fm/episodes/show/26

54:24 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 on the website.

54:24 Our theme music is Developers Developers Developers by Cory Smith, who goes by Smixx. You can hear the entire song on our website.

54:24 This is your host, Michael Kennedy. Thanks for listening!

54:24 Smixx, take us out of here.