Build ulcer-free webapps, please
Recently, I’ve been heavily involved in moving the database / web application infrastructure of the company I work for; we have been migrating our production systems over to a new IP space and new physical space in a colocation center. In an ideal world, this would be a simple matter of changing IP addresses, updating DNS records, and then at least physically moving the servers (but probably bringing up second instances of them in the new location, then switching DNS and keeping the old ones in place for overlap for any public-facing applications). Well, in the real world, a small company like mine ends up having tons of old, poorly designed and poorly written web application code that has things like public IP addresses of database servers hardcoded — which means that, in addition to doing the ideal-world things, I get to sift through thousands of lines of hellish ASP code to make sure I get all the database configuration changed.
Let’s talk about avoiding this situation.
First of all: DNS is there for a reason — use it. Whatever you do, don’t depend on a public IP address (or any IP, really) to remain the same forever. Especially with web applications — there is quite likely a nice layer of caching between your application and the actual DNS lookup to minimise any possibility of DNS lookups slowing down your application, so just don’t worry about it. If there isn’t, you can add it. Later on, when someone’s moving the database server, they’re going to be pissed at you if they have to go into your application to change things instead of just making a single change in DNS (and maybe pointing the old record to the new server). Another reason for this problem is DNS admins who suck — create CNAMEs for services that point to A records for hosts (e.g., database.example.com is an alias for myhotdbserver.example.com). Implement things using the CNAMEs. Then, when you have to replace your decade-old database server because it keeps falling over under load, you only have to change where the CNAME points.
Second: Don’t repeat yourself. How do programmers not get this? In my company’s case, we have a whole lot of little duplicates of the same application, each of which has some small difference (organisation identifier, branding, perhaps some very small difference in behaviour), but whose working information is stored in the database in the same format as all the others. Putting aside for the moment the fact that one application with many variables should have been used here … each little duplicate also has its own include file, which contains that information mentioned above that differentiates it from the other duplicates. What else does the file contain? Database connection information. That’s right, we’ve got tens of duplicates of the same web application, all completely intended to work off the same database, and each has its own database connection configuration. Why didn’t the programmer(s) of this thing take a few minutes of their time to simply create a global include file? I don’t know. I really can’t fathom it.
So, I got to make changes in many, many files. Now, at least, they’re pointing to a DNS name that can be changed. Just, please, don’t inflict these evils on your sysadmins, gentle reader. Use DNS wisely, and put your configuration in one place.