We all have our own personal Kryptonite, that little something you encounter as part of your job that just never seems to go right no matter what you do. For me, that Krytonite is server configuration. It doesn’t matter how clear you make the how-to directions, I will find a way to fail at it no matter how hard I try to get it right on the very first time. It’s like magic, or karma, or some other-worldly force that’s determined I fail when trying to set up any new environment.
The problem is that isn’t just the fault of any 1 thing. It’s the fact that for real-world server setups, there’s a ton of different stuff running, all of which needs to be set up and configured, and all of which needs to work with each other. Applications have multiple configurations for the multiple services that get run, and they all have to be just right for everything to run properly. Doing a good job at this sort of thing goes beyond being “detail-oriented” and skips right into “anal retentivity and ability to divine all the related configuration files required.”
This isn’t some problem that exists as a result of nonsense or laziness. The only way to guarantee another service is present is to bundle it with your service so they’re installed together. That sort of thing is typically frowned upon as violating important principles like Separation of Concerns and KISS. After all, there’s a wide variety of technology out there that people can mix and match to fit their specific needs and styles, so it’s better for the end users of your product to just play nice with everything.
This isn’t just a “me” thing either. At my last job, we had a policy any time we had to do something that required changing anything other than 1 specific, developer-specific line in the configuration files. The first person to get everything working zipped up their server setup and put it on a shared drive so that we could all download it, change our 1 developer-specific line, and get things to work. If that doesn’t sound like a red flag for “Our architecture is too complicated and hard to work with”, I don’t know what is.
Only that’s a lot easier said than done. There’s all the different 3rd-party stuff you have that your software uses or runs on, then there’s all the stuff you (or your company) write (which is probably several services and processes in and of themselves, each with their own configuration files I’m sure). Put simply, the bigger your technological stack, the harder it is for a normal human to set it up and get the application running the way it was supposed to be. This seems pretty obvious, so let me rephrase it. The point at which your application becomes hard to set up and configure, is frighteningly sooner than you think.
The problem with this state of affairs is that there may not be a better state of affairs. All of this stuff is (or at least they should be) designed to be deployed independently, so they need to come with their own independent configuration options. I suppose you could make 1 supermassive configuration file that has sections for each service you run, but that just replaces the problem of having too much stuff to keep track of with the problem of having a configuration file too big to for a human to grok.
Trying to improve things requires re-doing your application’s architecture, so good luck pitching that to the ol’ boss. After all, this isn’t causing the users problems, it’s just making the developer’s lives harder. Re-designing how your system is set up is a huge undertaking, and a high-risk one at that. Given that there’s not a good alternative to the huge collection of configuration files present in many development environments, it’s also a low-reward undertaking at best. That being said, I’m still keeping my eyes open for a better personal Kryptonite-free alternative all the same, if only for my own sanity.