> You need to write idempotent ansible from the start. No excuses. Absolutely. And code reviews, etc. just like code. > Then you would implement a retry logic

> You need to write idempotent ansible from the start. No excuses. Absolutely. And code reviews, etc. just like code. > Then you would implement a retry logic in ansible since your cloud APIs will fail for weird reasons or you really must wait that a resource in AWS is truly ready before you run another task. ( for example vpn gateway in AWS must be ready and then you can attach a vpn connection, or a route53 zone record has to propagate before you do something with it. But in the meantime your other tasks can continue in parallel. Only the vpn tasks needs to wait) Yes, Ansible modules have a retry built in or a wait_for statement. You can also control the serialization serialize: (or was it parallel), or run_once or when. You have a couple of tools at your disposal. > At this point we did not do any code reviews yet and we did not answer the question: “how should the infrastructure look like?” Why not? We usually start with some diagram in README.md or Confluence or a Design Proposal before the code. Code never gets released without a merge request. > This especially means: how do you actually delete resources with Ansible? So you Start to introduce a kind of “state” for your resource. state: absent, you can use in about every module. > So, if you squint hard enough, idempotent, resilient, parallelizable, thread-safe, fast ansible with a state is what terraform solves. If you look at tools like terratest you even get to do unit/integration testing for your infrastructure code. I believe terraform hides way too much and is too magic. Troubleshooting when terraform goes wrong is really really hard. You have two states to look on -- the cloud state and the TF state. And now you need to know two tools too, since you will likely need Ansible anyways to configure and operator the hosts later. > So as soon as you are more than 1 person handling infrastructure following best practices like code review and testing, without getting insane, use terraform. Beg to differ, 100s of engineers sharing ansible galaxy roles with semantic versioning and whatnot in a very good way at my org. > Once you do not work in isolation any more, either in a team or as a consultant who needs to hand over their work (and Teach people how idempotent ansible works), I would favor terraform any time. Maybe you're right. If I'm doing freelance I will likely use Terraform to interact with Cloud. IMO Ansible, just like coding, requires a bit of a community around it with best practices, reviews and etc.