This really might depend on the context. On long term it's worth to take a deeper look for a moment if you are not after quick shots and go beyond experiments for a sustainable (and large) infrastructure.
So we have got many clouds out there. Deployment automation means, they have some API.
So what does make a deployment automation tool delivering infrastructure as code capability?
Now there are some challenges to address human readability and sustainability varying by programming language ecosystems and communities:
- Cloud products being themselves computer infrastructure and network engineering (these are different disciplines!) abstractions are not following some official "cloud domain" ISO/IEEE naming standards as far as I know. That is, all the names are pushed by vendors and might be marketing biased. So either you invent your own terminology or decide which terms are most generic, or a mix of that. There is therefore a good reason that you find also cloud vendor specific deployment languages and tools for example like Cloud Formation by AWS.
- Somebody needs to maintain related components to support new API versions for every cloud platform!
Some deployment tools delegate the cloud driver (that's another term for cloud platform specific code bases) to separate projects, which in their term delegate responsibility for API compatibility to one or another boilerplate (=often boring and tedious) API implementations.
Therefore my conclusion is that depending on your purposes the most straight-forward way to write infrastructure as a code is the programming language of your choice using a well-supported SDK which is though vendor-specific!
Still this is the point where you have got greatest flexibility because for a small standard use case you could write your own abstraction layer and your custom logic whatever you want.
Recent Terraform example: its Apache CloudStack driver has backward compatibility problems because it's based on some less-visible CloudStack API SDK written in Golang. I am sure you can run into problems of this sort with any deployment tool; so if you commit to one, bring enough courage and patience to connect with and contribute to the corresponding community (same is for SDKs but they at least typically have less abstraction).
That is, before deciding for a certain cloud deployment automation tool, consider besides the things you see on the surface like syntactic sugar and community support also the following aspects:
- If it's open source, is it written in a programming language where you/your team could create an emergency patch if things go really worse?
- How well supported are those cloud drivers critical to your business: these typically can't be all of them, if so, you might run into issues like GitLab with Docker Machine (also a specific deployment tool after all), where a significant technical base for a competitive product feature suddenly breaks away because all the responsibility in this context had been factually outsourced to the open source community.