Thoughts on Configuration

So my previous pieces on CDI qualifiers has somehow led me into thinking very deeply about configuration, so here’s some stream-of-consciousness on the subject.

I’m aware that the de facto standard in this space is DeltaSpike’s configuration extension, and it works just fine as far as it goes.

I’ve also worked with Netflix’s Archaius, and way back in the day some of the Apache configuration libraries.

I’ve always been faintly bothered that at the heart of all these systems is (sometimes explicitly, sometimes just kind of present in “flavor”) a configuration hierarchy: you stack configurations and then different layers of the hierarchy supply different values.

But—and I might be wrong here—one thing that I’ve become more and more convinced of is that real world configuration is not a hierarchy.

We’ve already seen that there are some implicit qualifiers in a CDI application that end up being part of the configuration coordinates of the application.  That is, made up qualifiers like @Production (for environment or project stage), @Experimental (for phase or canary testing) and @UsWest (for something like region or datacenter) together with possibly other implicit qualifiers identify your application in configuration space.

Those things aren’t hierarchical. They’re cooperating aspects of the configuration space of the system.  Your configuration space may be one-dimensional (no test environment, no funky project stage, no data center things to worry about), or five- or sixteen-dimensional (your application can be deployed into all sorts of places within a huge configuration space).

Here’s how it seems to me that an interaction goes with such a configuration system:

My application: Hello, I would like a value for db.url please.
Configuration system: Certainly. I actually have several—some specific, some not.  Where are you?  Who are you?
My application: OK, well, I know that my configuration coordinates are phase=experimental, environment=production and region=uswest. Maybe that will help you.
Configuration system: Yes. Please hold. {Heads over to a remote corner of the office.} Hi, configuration source one?
Configuration source one: Yes?
Configuration system: Can you get me a value for db.url in the uswest region suitable for the production environment and the experimental phase?
Configuration source one: Let me see…no, but I could give you a value suitable for environment=production and phase=experimental…but I don’t have anything more specific than that (i.e. explicitly for region=uswest).  So the value I gave you might not be maximally specific, but that might be OK for you?
Configuration system: OK, that might work. Hang on. Configuration source two?
Configuration source two: Yeah, I heard you guys. I can give you a value for all three aspects!
Configuration system: Great! Thanks. Configuration source one, you’re off the hook.

The point here is not the witty dialogue, but the fact that the most specific value wins, not the value that has a particular place in a hierarchy.

You could conceive of a situation with that same dialogue above, but one configuration source can give you a value suitable for the region and phase, and another can give you a value suitable for the phase and environment, but none can give you a maximally specific value.  Which one of those (region, phase) is more primordial in a hierarchy?  Answer: neither!  They’re two axes of configuration.  This thought experiment means only that your configuration is basically underspecified, not that some arbitrary source in a hierarchy should win.  You might want to do different things in the case of an underspecified configuration.  Probably you actually want to notify someone that values aren’t set right.

Or, consider the same dialogue, but this time all you get is two out of three (region and environment, let’s say).  In that case, it might be perfectly reasonable to take the value offered (i.e. since there aren’t any conflicts (which is more primordial? region or environment?), you can just take the value knowing that it’s as specific as you’re going to get).  Maybe the db.url configuration value varies only along the environment and region axes and not along the phase axis.  That might be fine.

Anyway, where am I going with this?  I am not sure, but, again, it sounds like the germs of a configuration system that would plug nicely into CDI.  Stay tuned.


One thought on “Thoughts on Configuration

  1. Pingback: More Thoughts on Configuration | Blame Laird

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s