Dedicated Orchestration Utilities

A question that comes up quite a bit from people without a strong ops background is, why do we have dedicated orchestration tools instead of just using the venerable Puppet, Salt, Chef, Ansible solutions? It’s a fair question for individuals who have been informed that traditional configuration management tools are an industry panacea. It’s also true that there’s a significant amount of overlap between these YAML infrastructure descriptions, and it most certainly causes confusion about why there is a distinction between these categories in the first place. I think Yevgeniy Brikman summarized the main concerns brilliantly. Sure, you could use the Ansible modules for AWS and describe the datacenter within the confines of configuration management, but then you will experience problems maintaining the stateful design of the datacenter. Good configuration management is statefully aware at the individual node level, while orchestration is the same at handling the big picture. You can’t describe the number of nodes in Ansible and have it consistently maintain that value across execution runs. Instead, it’ll just launch new ones without attempting to match state with what already exists. I don’t want to imagine how this type of behavior would affect non-instance services. I’m a firm believer in using the right tool for the job. My preferred method of describing infrastructure is to invoke Ansible as a provisioner within Terraform to handle node level idempotence. I’m a little dismayed this is considered 3rd party and hasn’t been official Hashicorp canon, but their philosophy tends towards disposable pre-baked nodes instead of updating node state. There’s definitely an argument for this direction, but providing a full accurate description of the system from individual machine state all the way up to the datacenter is not an obsolete concept. Ansible slots into Terraform and handles that last mile perfectly AFAIC.