I am going to disagree with your take on configuration management tools and “inevitable” configuration drift. My own experience here is with Chef but I am sure that other competing tools have acheived feature parity by now.
Configuring a node (server/vm in Chef parlance) under management by Chef is accomplished by the installation of the chef agent, a daemon which brings the node into compliance with some desired state. The author is under the mistaken impression that this is a one time affair and that is incorrect. The chef agent wakes up and runs on a regular schedule with a configurable frequency and skew. At each run, the chef agent can check in with a Chef Server and pull any updates to the definition of its desired state and apply any necessary changes. These definitions of the desired state can be versioned and the Chef Server can track which version of the desired state should be applied to each node. Updating a node to the new desired state is simply a matter of incrementing the version assigned to the node. Even without Chef Server, a node can be updated by pushing a new desired state definition to a node.
The Chef ecosystem provides a rather comprehensive toolset for efficiently and dynamically managing large numbers of nodes as well as the workflow and processes found in mature devops organziations.
