Paul Hammant's Blog: Push or pull of config changes for a production stack
So Logan has a viable “Application Configuration Application” (ACA). I’m reminded that I should never be allowed to name things. Hot Toggles (TM) might have been a better name for the thing. It’s really worth checking out.
An outstanding issue is how to get changed config data (JSON) to the nodes in a production stack that need it. We’ve implemented one simple mechanism for a sample Java app. In time we’d need to have code snippets (or reusable libraries) for many regular enterprise language choices.
Here’s a brain-dump of the choices, without mentioning specific languages:
Where configurable nodes access ACA (pull)
- Polling for changes on a separate thread
- might suffer from thread death, and have restart issues
- threads might be idiomatically incorrect for ‘container’
- not all languages allow thread spawning
- Polling for changes associated with a end-user request
- blocking issues?
- Could happen ahead of serving of request
- Could happen after the response is served
For this design to work, the configurable nodes would need authentication details for the ACA
Where ACA directly modifies configurable nodes (push)
- ACA directly pushes changed config to the nodes
- ACA needs to authenticate with nodes, which feels backwards
- multi-threading may help shorten the delay in updating many nodes
- ACA has to maintain a list of the nodes that need updates
- ACA pushes changed config on to a message bus, to which the nodes subscribe
- encryption of data on the bus could be important
Hmm, I wonder if there is a Memcache/Ehcache way of securely percolating changed config…
Where ACA merely notifies configurable nodes of ‘change’ (push)
- ACA pushes ‘some change has happened’ onto a message bus, nodes callback to ACA to pick-up changes.
- nodes need authentication details for ACA
- ACA directly notifies nodes that ‘some change has happened’, and the nodes callback to ACA to pick-up changes.
- nodes need auth details for ACA, but not vice versa
- multi-threading may help shorten the delay in updating many nodes
Syndicated
Dec 7, 2012: This article was syndicated by DZone