A common question from people setting up devops in the cloud is where to track configurations. You certainly have a vast array of technologies to help you track configurations, including configuration management (CM) tools such as Puppet, Chef, Ansible, and Cfengine.
However, a more fundamental question is: Where should configurations exist?
I’ve seen a great deal of enterprises recently that have not been able to get configuration tracking right. The core problem is that they lost track of configurations for the applications, and they ultimately had to be re-created. That meant the initial configurations that worked best got lost in time.
Configurations provide basic information on platform configuration, including version of core platform components, versions of the code itself, the database, and a bunch of other stuff that if out of whack will make your application production out of whack as well. Indeed, configuration is the central tracker of devops, and you need to get this one right out of the gate.
I believe configurations should exist with the applications. Either as configurations-as-code (CAC) or as configurations that use some structure, whether proprietary or open. Either way, they are bound to a code tree, and not somewhere in configuration tools where they then need to be located and invoked during development, test, and deployment.
An emerging best practice is to write your configurations with new code, change configurations with existing code, and couple those configurations directly to the code tree when sending it up the devops chain.
That way, the other tools and/or people can see the configuration bound to that particular code tree and database configuration without having to look for it in a configuration repository.
This goes well beyond application configurations: Security configurations, governance configurations, compliance configurations, database configurations, and testing scripts also need to be coupled to the application code tree. You should do this as a best practice, so your workloads are logically and physically bounded so they are very easy to keep track of.
You should do this no matter how few workloads you need to track or how simple your devops tool chain is. Trust me: Your workloads will grow and your tool chain will get more complex quickly. And if you don’t manage configurations the right way upfront, you’ll pay a very heavy price later in either inefficiencies and erros or in retrfittng your applications’ configurations to what they should have been all along.