Ansible author here! Hi Mitchell and crew! Our users are great fans of Vagrant and Packer, so +1 for those.
From a cursory overview, it looks like Terraform is basically LIKE a CloudFormation type abstraction. Ansible contains declarative models for lots of cloud providers as well, but does not attempt to abstract out the different clouds. We generally view wanting to show things in their natural state (figuring you will know you want to use feature X or Y, and want the knobs/buttons exposed).
But yes, we have similar features for saying "X instances of this should be running now", make it so, all that don't require use of CloudFormation.
For people that like Terraforms flavor though, I can see users using these tools together. They could declare a cloud using either ansible or terraform, and then use ansible for the final configuration and application deployment, plus full lifecycle management.
I know things like Packer like to walk people down a more imagey road, but you can also use config tools to describe the recipes that build your images, and that would include Ansible, Puppet, Chef, or even (if you so wished) bash.
I'm not a fan of bash though :)
I'm happy to see more efforts to make cloud provisioning accessible though, and like the idea that this would allow more easy migration between some cloud providers. Ansible has a lot of the same declarative thingies, but will probably appeal more to people who aren't looking for the DSL.
It doesn't look like Terraform is attempting to be a provisioner itself, so it wouldn't do the things that Ansible or other config/app deploy tools do once you have a running instance, but does some of the things various config tools do to help you GET a running instance.
One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.
As for where the future of this tool is, I obviously can't speculate, nor should I. But I do welcome more attempts to simplify beasts like the AWS EC2 API space, because I think we both agree nobody wants to really keep all of that in their head at all times.
The best thing about this is even though Ansible and Terraform seem to do some similar things (Ansible, of course, has a few other tricks up its sleeve, but just comparing the tools in terms of infrastructure orchestration...), there's plenty of room in this space for multiple solutions.
Just like Chef and Puppet seem to have leapt off from a solid platform started by cfengine et all, and made 'configuration as code' a thing, Ansible, Salt cloud, and Terraform seem to be kicking off the 'infrastructure as code' movement (and are adapting to many different workflows—Docker, Chef, Puppet, etc. play nicely in this sandbox).
Too many places rely on band-aids, shell scripts, and manual process for infrastructure, mostly because tools like Ansible and Terraform haven't existed until recently (or today, in Terraform's case).
+1 for too many places rely on band aids. The frustrating thing is that there's no need now. These tools are adoptable by almost anyone and if you use them you shine a giant spotlight into the previously dimly lit area of your system configurations. You get documentation, testability and version control of your infra. It's extremely liberating.
One of the most valuable things has turned out to be the ability to refactor infra as a project evolves. Some task that would have required a few hands and a project manager now becomes a few edits.
I lead a CFEngine team and It never fails to amaze people when I demo end to end life cycle management "that used to take 3 guys 2 days" etc.
From a cursory overview, it looks like Terraform is basically LIKE a CloudFormation type abstraction. Ansible contains declarative models for lots of cloud providers as well, but does not attempt to abstract out the different clouds. We generally view wanting to show things in their natural state (figuring you will know you want to use feature X or Y, and want the knobs/buttons exposed).
But yes, we have similar features for saying "X instances of this should be running now", make it so, all that don't require use of CloudFormation.
For people that like Terraforms flavor though, I can see users using these tools together. They could declare a cloud using either ansible or terraform, and then use ansible for the final configuration and application deployment, plus full lifecycle management.
I know things like Packer like to walk people down a more imagey road, but you can also use config tools to describe the recipes that build your images, and that would include Ansible, Puppet, Chef, or even (if you so wished) bash.
I'm not a fan of bash though :)
I'm happy to see more efforts to make cloud provisioning accessible though, and like the idea that this would allow more easy migration between some cloud providers. Ansible has a lot of the same declarative thingies, but will probably appeal more to people who aren't looking for the DSL.
http://docs.ansible.com/list_of_cloud_modules.html
It doesn't look like Terraform is attempting to be a provisioner itself, so it wouldn't do the things that Ansible or other config/app deploy tools do once you have a running instance, but does some of the things various config tools do to help you GET a running instance.
One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.
As for where the future of this tool is, I obviously can't speculate, nor should I. But I do welcome more attempts to simplify beasts like the AWS EC2 API space, because I think we both agree nobody wants to really keep all of that in their head at all times.