2014-12-31
I love Apache (well, like it at least)
There is somewhat of a meme around the sysadmin and web world that Apache is a bad web server that no one should use, or at least not use for very long. And if you're using Apache or thinking about configuring something with Apache, maybe you should think about how to migrate away or pick a setup that will make that easy. I once sort of felt this way and experimented with (and still use) alternatives like lighttpd, but I no longer do so; these days I think that Apache is your best default choice for a web server.
I will put it like this: choosing Apache is a lot like choosing to write code with a high-level 'scripting' language like Python or Ruby instead of C++, Java, or Go. The result is not always as fast as it could be but often it will be pretty good (sometimes excellent), much of what most people are doing doesn't need the flat out speed, and the whole thing is easy to set up, quite convenient, and does a lot for you, including things you may not initially realize that you want or need.
Apache is not likely to be the highest performing or least resource using web server you can configure (although you might be surprised). However in real life most of the web sites most people set up do not need to support massive loads (and when they do you may find that the bottlenecks are not in the web server). And what Apache gives you is almost unmatched support for easily set up and deployed web app systems. CGI scripts are very simple; PHP files can simply be dropped into place; Python applications need only mod_wsgi; even Ruby on Rails apparently has an Apache module. If you want to use FastCGI and app daemons and other higher-capacity things, well, Apache supports that too. Not infrequently it will give your simple applications practical performance boosts, for example by compressing their HTTP responses when possible.
(In my personal interest of TLS security I've also wound up feeling that Apache is in practice at the forefront of allowing you to set up good TLS configurations. Other web servers can have spotty support for various things, but Apache is almost always there. These days I recommend that people who care about TLS look very carefully at anything other than Apache.)
Apache can have what I've called the Apache configuration tax, where for simple setups (like static file service) other web servers can have simpler setups with less configuration work to do. On the other hand I've found that sensible Apache configurations create very simple Apache setups. And any complex server design is probably going to be complex to express in a configuration, regardless of what web server you're using.
All of this leaves me feeling three things about Apache. First, Apache is a perfectly sensible choice as your web server, one that shouldn't need defending any more than a choice of a more sexy and talked about web server like nginx (or lighttpd, which no longer seems to be the latest hotness). Second, Apache probably should be your default choice of web server. Unless you already have special expertise and tooling for other web servers or unless you can clearly see why Apache is a bad fit for your target environment, just going with Apache will probably make your life easier and work just as well. And finally, that Apache deserves more love in general. It's really time for Apache to (re)take its place as a perfectly respectable web server, not the embarrassing relative we don't talk about.
(I'll admit that this is kind of a rant because I've decided that I don't want to feel defensive any time I talk about using Apache. But my views have really shifted on this over time, as I used to share the common attitude that Apache was outdated or at least a catastrophic performer (not really, actually, to my surprise in that situation). My personal site still runs lighttpd, but I'm not convinced that that's the right decision; it persists partly out of inertia and partly because Fedora's Apache configuration setup is terrible.)
A retrospective on my one Django web application
Looking back, it's been almost four years since I started writing our first and so far only Django web application, a system for automating much of our new Unix account requests. Since retrospectives are relatively uncommon, today I want to do one for what has been a really faithful web app.
I suppose that's a good summary of the whole situation: after I wrote it, the application has been trouble-free. Over the years I've done a few tuneups to make it a bit more convenient to use for some tasks and to reduce the possibility of accidents while people use it (and there was one interesting bug), but that's it as far as code revisions have gone. This does means that I haven't had to face things like schema migrations; the schema we started with is the schema we still have, and it'll probably last all the way to end of life with this application (which is not going to be any time soon, since we'll probably always need something to do this job).
(Okay, I'll admit it; we have little enough data stored in the system that I might not even try a schema migration but instead just do a database dump, edit the dump a bit, and load it into a new database.)
I'm still pretty happy with our choice of Django, SQLite as the underlying database, and mod_wsgi for deployment. All of them work and I don't see any obviously better alternative, either then or now. Django does a bunch of magic with database models, but I'm a pragmatist; the magic works.
My one real regret about the structure of the web application is that it has (gasp, shock) no tests at all. The core reason for this is that learning Django testing at the same time that I was learning Django was just too much work, and of course there has never been either the time, the energy, or the clear need to go back afterwards to figure out how to do it and add tests. This doesn't make much of a difference for development since there isn't much development, but it does make a difference for upgrading Django itself. And frankly that's one area I've been weak on; we're behind in both our Django versions and jQuery and part of that is because testing new versions is not drop in and go but instead manual.
We're behind on Django versions primarily because we rolled our own; when we built the application initially, the version of Django packaged on the Ubuntu version we were using wasn't advanced enough. These days I would use the Ubuntu 14.04 Django version and be done with it for four years or so (ie I'd be counting on the Ubuntu people to feed me non-breaking security updates that we could install without any particular testing). I don't think we're actively at risk, but it's something I do worry about.
What I don't like about Django boils down to two things, both relatively minor. First, with SQLite we've found that Django's internal 'id' primary key field can reuse ID numbers if and when old records are deleted. We use and expose these ID numbers in a few places (for example, in audit records) and it would be slightly nicer if they didn't get reused. The most annoying (and potentially dangerous) place is that they appear in the URLs exposed to administrative users, which means that an old URL can go to a completely different account request in six months instead of just being invalid.
(These unguarded URLs are not exposed to non-administrative users and operations on them do have specific security checks, so you can only touch entries you have authorization for.)
Second, I have historically found it hard to find release announcements and changes for new Django versions, which I have to do because I need to read over them as we update from version to version. If I closely followed Django and updated on every version change I think I'd be fine, but as it is now I wind up ignoring Django version shifts for months at a time and then have to grubbing through the site to find all of the release announcements for every version between where we are and where the state of the art is.
(In fact I just went through the Django website and couldn't immediately locate even a 'what is new in the latest version' page, much less ones for previous releases. And I know the information is somewhere, because I've found it before.)
PS: that we have only one Django web app is not because we've grown disenchanted with it, it's just that we haven't had a combination of time and need to write any more (and we do have a second one somewhere quite far down the priority list). Well, for me to write any more; my co-workers don't do Django so far.
Update: It turns out that Django release notes are all available in one spot here. They're even conveniently all linked to each other so you can go back and forth (although this is not necessarily the chronological order, since point updates may be made to older versions even after a new version has been released).