Configuration Management
How do you share common configuration amongst applications in your enterprise? Trickier question, how do you share common configuration but allow local applications to override elements of that shared configuration? Oooo, oooo, or...how do you have applications get environment-specific configuration, in an environment agnostic way (i.e. not knowing what environment they are actually running in).
Configuration management in the enterprise is a pain, let's face it. This seems to come up a lot in conversations too. Spurred by today's Server Side article, here's a few ways it can be done (off the top of my head).
- properties file distributed with each node/instance of an application
- shared properties file via an NFS mount
- shared properties file via a web server/remote loading
- web service (maybe RESTful), with DNS resolution for the URL (IPs, bad)
- Terracotta shared configuration (as per the article)
Downside 1
The real downside that I can see for the Terracotta way (and this is always the case for doing things with TC) is that you must run with the TC boot jars. For the most part, this isn't an issue. But when you are dealing with legacy applications, it's not always an easy sell. "Hey boss, I'm gonna just run all our production app servers with the Terracotta boot jars so we can do some distributed JVM stuff. Don't worry about it."
Upside 1
On the upside, once you have your app server TC-enabled (so to speak), it's like opening a big barn door of possibilities. TC has a lot of very cool use cases that can change the way you think about distributed computing and architecture.
Downside 2
On the down side again, dealing with local apps overriding global configuration becomes more difficult. If any local app decides to (by accident or not) write back to the shared configuration bean, all of a sudden every node in the cluster has that new configuration. The possibility for error is certainly there.
Downside 3
Another down side is dealing with local configuration overriding the global configuration. In the TC case, it would basically mean having a two-tiered configuration lookup. First lookup the configuration element in the shared bean, next look it up again in the local bean (which has presumably been configured using a local properties file or the like) and if it exists, it will override what was found in the shared bean. Not bad I suppose, but should probably be added for the sake of completeness of a solution.
Upside 2
Okay, so the really cool part of this method though is that you never have to reload configuration elements from the source. Changes to the global configuration are picked up by each node on the next access to the configuration bean. That's sweet schnitz.
My numbers don't mean anything
Hmmmm, 3 downsides, 2 upsides. Not sure that means anything though. I certainly think that if you already have a TC-enabled application, this is a very viable solution for configuration management.
