The term configuration management has a long history beyond software development. When applied to software, people usually refer to the implementations of:
- CFEngine
- Puppet
- Chef
- Ansible
- Salt
- Docker
- Kubernetes
- Terraform
- Fleet
- And lots more...
In a nutshell, configuration management in software refers the process of configuring the servers, and then writing the intructions that allow your software to deploy and run. The instructions also encode more configuration options like environment variables, keys and passwords that will be used by the software. In some cases, configuration management involves installing static packages/libraries, in other cases it's installing a app and then launching it with context.
This is a vast topic, because there are enormous amounts of things to configure. Some of it is essential complexity, others are incidental and may have arisen from leaky abstractions that have been built on top of computers over time.
Implementing configuration management is often the first step that software companies take in order to get into the devops automation boat. (They usually start off with hand-rolled bash scripts.)
There is however flaws in our current configuration management landscape. Take a look:
- http://stani.sh/walter/pfcts/original/
- https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/
- http://www.slideshare.net/profyclub_ru/8-mitchell-hashimoto-hashicorp
It just seems that all the existing configuration management tools doesn't solve everything, and there's always some complexity that it doesn't map well onto. Can there be a solution-model that is sufficiently applicable so that it can fit the 90th percentile of the developer's intent?
We think there can be. We call it the Forge Architect. A functional constraint logical domain specific language that considers infrastructural instances as first class type primitives. It's job is the express a functionally reactive infrastructure.