To see how generally difficult configuration management can be, we only need to
look at the simplest of configurations: a flag to tell our web servers whether we’re
under maintenance. If so, we shouldn’t make requests against the database, and
should instead return a simple “Sorry, we’re under maintenance; try again later” message
to visitors. If the site isn’t under maintenance, all of the normal web-serving
behavior should happen.
In a typical situation, updating that single flag can force us to push updated configuration
files to all of our web servers, and may force us to reload configurations on all
of our servers, if not force us to restart our application servers themselves.
Instead of trying to write and maintain configuration files as our number of services
grows, let’s instead write our configuration to Redis. By putting our configuration
in Redis and by writing our application to fetch configuration information from
Redis, we no longer need to write tools to push out configuration information and
cause our servers and services to reload that configuration.
To implement this simple behavior, we’ll assume that we’ve built a middleware
layer or plugin like we used for caching in chapter 2 that will return our maintenance
page if a simple is_under_maintenance() function returns True, or will handle the
request like normal if it returns False. Our actual function will check for a key called
is-under-maintenance. If the key has any value stored there, we’ll return True; otherwise,
we’ll return False. To help minimize the load to Redis under heavy web server
load (because people love to hit Refresh when they get maintenance pages), we’ll only
update our information once per second. Our function can be seen in this listing.
With that one function plugged into the right place in our application, we could affect
the behavior of thousands of web servers within 1 second. We chose 1 second to help
reduce load against Redis for very heavily trafficked web sites, but we can reduce or
remove that part of the function if our needs require faster updates. This seems like a toy example, but it demonstrates the power of keeping configuration information in a
commonly accessible location. But what about more intricate configuration options?