Over a million developers have joined DZone.

Push or Pull of Config Changes for a Production Stack

· DevOps Zone

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 reallyworthchecking 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

Published at DZone with permission of Paul Hammant , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}