Interview with Andrew Godwin about deployment

This is an interview I took from Django core developer Andrew Godwin about deployment. Recorded in DjangoCon EU 2017, Florence, Italy.

ANT: Hello everyone! This is Antonis from djangodeployment.com. It’s 5 April 2017 and I am at the European Django Conference in Florence. I am sitting with Andrew Godwin, who is a Django core developer mostly known as the creator of migrations and now Django Channels, and we are going to have a little chat about deployment. Hello Andrew!

AND: Hello! It’s lovely to talk to you!

ANT: Thanks! Some years ago you tried to create a deployment service which was called ep.io. So, could you tell me a little bit more about that?

AND: Of course! As a bit of background history, we’re talking quite a few years now when Heroku was just for Ruby at the time, and so I was sitting in DjangoCon US and me and a friend had the idea to, why not do Heroku for Python?, which of course was an idea common to several startups at that time. We took on the challenge of making a platform-as-a-service, which is what Heroku of course is. I think it was two or three years from start to end of that project. It was quite difficult, and eventually we sort of shut down gradually, the company itself moved to a project then called Orchard, which then later got sold on to Docker, Inc, so it still had a history through that time, but I left it around four years ago.

ANT: One question that I’ve been having about deployment, because I started a blog and a book about deployment and I see that people are really interested: So I asked my readers, why do you care when you can just press a button in Heroku and have your application deployed? I got a number of answers but I’d like to have your viewpoint.

AND: So that’s a very interesting and common question of course, and I have a number of different viewpoints. The first one for me is cost, ultimately. Heroku is very expensive for what they give you in terms of resources. Obviously the value out there is in terms of management and time saving and wages, but in general I would say that, as someone who’s experienced in deployment, I can do that. If that is in my range, I don’t need to spend too much for it. And the other part is customization. Heroku, I would say, is very good for a small or medium sized web site where you fit into the common pattern, but as you grow you inevitably become more specialized. You require different kinds of routing or network or storage and that’s the point where I think that something like Heroku restrains to make everything work, you can’t have one pattern that works for every big site. Now, would I recommend it? For a small site, absolutely. Would I run it? No. But that’s two very different things.

ANT: I think that services like Heroku, or, maybe, the Divio cloud, they treat deployment as a black box. That is essentially their purpose, to make deployment simpler for you, so you are not supposed to know anything about it. But do things eventually go wrong? And when things go wrong, is it useful to have knowledge of the mechanics of deployment in order to fix things? Or is it maturing now? Is it a matter of maturity?

AND: So it’s not just maturity, it’s also about how well you are equipped to deal with these problems. Having full knowledge of the system is not useful if you don’t have the resources to fix that system. You just know about your failure rather than not knowing about your failure. So I think it is in some cases better to know of a failure and be able to fix it, but doing that requires a lot of expertise that is hard to find, like good operations people are very very thin on the ground in almost every part of the world. So it really depends, is it worth for you to know how to fix the black box or can you take the failure? One good example that isn’t about deployment is a database. If MySQL or PostgreSQL fails, it’s technically open source, you can, in theory, go and fix it, but in all likelihood you don’t have the knowledge or the ability to fix the problem in PostgreSQL, and so, it’s not about if it’s technically close, it’s also if it’s by the nature of its complexity close to you. If I made you a system that is fully open, and gave you that system with the ssh keys and everything, but you didn’t know how it worked, it would still be effectively a black box, but now it’s a black box with no support contract. In a lot of cases it’s best to have a black box with a support contract than something you half-know yourself.

ANT: People compare Django deployment to PHP deployment, because PHP has a fame for easy deployment — you just throw your files in a directory and it just works. Is there any fundamental reason why Django has to be harder? And a related question is, is PHP deployment really simpler, or is it deceptive to think that you can just throw your files in a directory and that’s it?

AND: There’s two parts to that question. The first one that I will address is, is it really simpler? The answer is, for a small project yes. PHP has the unenviable ability to just take a directory, put a file in there, and you’re off. And for that reason I came into web development from PHP. I had my problems with it as a language but I still respect the ease of use of it. The problem is that simplicity quickly becomes irrelevant as you get bigger and bigger, and one of the downsides of PHP can often be, yes it is a directory, and so you have to have an htaccess file in the old days, there’s a few more security issues. In Python and Django it’s just having standards. Before the advent of WSGI — when I started doing Django WSGI was there but very new — it was much harder, you had to sort of find a custom web server, wrangle with it, and it wasn’t particularly right. So we have come a long way in having a standard where you can pick anyone of uWSGI, mod_wsgi, Gunicorn, a number of other servers, plug any Python application into them, and there you go. It is more difficult, but it’s only very marginally more difficult. And ultimately I think, what I see the difference is with PHP you can drag-and-drop files in an interface, with Django you need to have some command line access. I think for some people just the presence of a command line makes it seem more difficult — it may not be more difficult but it makes it seem more difficult. That’s ultimately the sticking point some people have.

ANT: One example I have been thinking about that, a very simple one, is that when you deploy you also need to setup the email settings so that it can email you in case of an error, and for people who have no experience in deployment this is also something that they have to learn. You have to do this also in PHP I guess.

AND: Of course, you do, the difference there being that PHP is not setup to email you errors by default. If you configure it you can make it show a 500 page; if you do it incorrectly, as if you leave DEBUG on Django, it will show you a full traceback and all these wonderful variables and things exposed in there. So it’s more the case that out of the box Django is looking for an email address to send errors to. In a way that might be outdated by itself, for example I use something like Sentry more often than emails, my mailbox is already full enough. It’s just the defaults, the way it arrives, like, you install Django, you open that settings file, and there’s like 40 different things that you’re like “Oh! Do I need this? Do I fill it in?” and one of those is the email address.

ANT: OK. This is everything, so thank you Andrew and thanks everyone for listening.

This is a republication of an old article first published in my Django Deployment site.

Interview
© 2017 Antonis Christofides and Andrew Godwin.
The interview is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

Photo by Bartek Pawlik
© 2017 DjangoCon Europe 2017
Original photo