If you develop multiple web sites and host them on the same boxes, you might be familiar with this pattern:
So you start off with a site for a client, or maybe yourself, and you grab yourself a server or set of servers on a rack somewhere. And then another client comes along or another idea hits you, and now your company is looking at running two applications. Neither has particularly huge traffic, so you just add another virtual host to your current server environment and move on.
And another site comes along, and another, and another. Those $5.95/month web hosts put hundreds of sites on the same box, so why should you be any different?
Eventually, you’ve got, say, a dozen sites on the same rig that used to host one. Maybe it’s all on a single box, maybe you’ve got balanced front ends and replicated databases, but either way, eventually you’re going to run into a problem with space.
Maybe one app gets popular and starts taking up so much resources that the other apps are starving. Maybe all 12 of your sites get equally busy.
(12 is just a number I made up, by the way)
Eventually you’re going to need more room. You can either spread the apps over more servers, or if it’s one app that’s busy, you can shard it into a new environment, but either way, you need more servers.
If you’re in an environment that doesn’t happen to have empty rack space above or below your boxes, you’ll have to deal with downtime for all 12 sites while you move to a different spot in the data centre. That’s assuming that the data centre has room, of course, otherwise you might have to move to a new data centre altogether.
And then you wait for the pattern to happen again.
Cloud computing is supposed to fix a lot of this. We’ll see, of course, but for now, let’s assume the model works for what you’re doing.
Now, compare the physical resource issue with the intellectual resource problem. This is a lot more common, and I don’t see a lot of good solutions:
So you start off with a developer or two for that first app. Maybe a contractor. Then you get two. Working on new sites is fun, but the old one needs some love now and then, and sometimes gets cranky.
Extend that scenario to 12 sites. That’s 12 sites that you need to have someone on board for who can remember how the thing worked, what the business constraints are, and how to push out a patch if necessary.
That server move I mentioned above? You need to have people on your team who know how to migrate and test each of those applications.
Oh, and when all 12 sites have independent bugs pop up on the same week that 8 clients have requests for changes to thir sites? Yeah…
Typically, most companies seem to follow one of three strategies for dealing with domain knowledge (this applies to desktop apps as well, by the way):
1) Have a body or two assigned to each site. Even if it doesn’t need any attention that week. It’s inefficient as hell, you won’t find star developers that way because there’s no room for innovation, and every time someone quits you have to decide whether to rehire/retrain or move that app to model 2:
2) Have each person responsible for multiple sites. It’s more efficient, but I rarely see a lot of redundancy here, and it gets crazy when the feature requests come rolling in. The old adage of “if you want something done, give it to the busiest person” tends to apply, and your former stars get bogged down with more and more baggage to the point where they don’t want to take on any new projects because it’ll be more to maintain, and new stuff was the whole reason they started developing code in the first place…
3) Outsource the work to contractors, and hope they’re available to make changes when required.
As a developer who’s been involved in all 3 situations in the past, the best answer I can give is 4) don’t do more than 1 project, but that’s rarely an option for anyone running a consultancy-based model. I’ve got a few ways to mitigate the pain, which I’ll cover in upcoming posts.
Leave a Reply