The best way to deploy cloud resources is almost always to use an infrastructure-as-code (IaC) tool. What isn’t clear is which IaC tool to use in your scenario. So, I present to you an opinionated flow chart of which tool to use depending on your scenario. Here it is:
Everyone has their favorite tool, so I have no doubt that this will make some people upset. In this post, I’ll discuss some of my reasoning.
Software Engineers prefer programming languages
My main opinion around IaC is that that software engineers should prefer a full programming language and framework for doing infrastructure as code. IaC Frameworks that allow for this include:
AWS CDK
Pulumi
Terraform CDK
Of these tools, I recommend AWS CDK if you’re on AWS as it is covered by AWS Support Plans and is actively developed and used internally by Amazon. For other clouds, I prefer Pulumi over Terraform CDK because Pulumi is more mature. In a couple of years, if HashiCorp keeps up its commitment to Terraform CDK, I expect it to become more compelling.
Less skilled programmers should NOT use a full programming language
If your team doesn’t include at least a couple of skilled programmers, then I would not advise picking an IaC that uses a full programming language. You’re better off using an IaC that uses a DSL/JSON/YAML like
CloudFormation
Terraform
Bicep
GCP Config Connector
If your team has a mix of strong programmers and less skilled programmers, then it’s probably fine to use a programming language IaC.
Take advantage of Support Plans
If you are using IaC at a large corporation, then you very likely have an enterprise level support plan with one or more cloud providers. You should strongly consider selecting IaC tools that are covered by these plans. Should you run into issues with the covered IaC, then your cloud provider is “on the hook” to provide support.
These tools include
AWS CloudFormation
Azure Bicep
AWS CDK
GCP Config Connector?
Pulumi and Terraform both have Enterprise Plans that you can pay for. Of course, you would generally pay for these separately from your cloud provider support plan.
Single-Cloud
Each big Cloud Provider has robust IaC using a domain specific language (DSL) offering for single-cloud if you choose their Cloud. AWS has CloudFormation. GCP has Config Connector. Azure has Bicep. Terraform works well for all of these as well.
The tricky part is that teams with programmers should prefer an IaC tool that uses a programming language. This is easy in AWS because you can just use CDK. However, as far as I know, Config Connector for GCP is not supported by any programming languages. This leads me to prefer Pulumi for GCP (Terraform CDK would also work).
Multi-Cloud
Most of the cloud specific tools provide little or no support for third party resources. Bicep is just for Azure. Config Connector pretty much just supports GCP.
CloudFormation has public and private registries now. I highly recommend using them for companies that are already deeply embedded in AWS CloudFormation.
However, no tool has better multi-cloud and third-party functionality than Terraform and by extension Pulumi since it can make a Terraform provider into a Pulumi provider. Both tools are open source so custom providers can be written.
Hybrid Cloud
For Hybrid Cloud cases, I believe that Ansible is likely the best tool though I wouldn’t say Ansible is strictly an IaC tool (it really isn’t one at all). However, it can be combined with IaC tools like Terraform.
Reality is that if you’re doing Hybrid cloud, the most difficult thing you’ll be doing is data center automation. Various hardware components have very specific tools for configuring them. These tools can almost always be configured by Ansible. None of the other tools mentioned in this post would support this.
DSL > JSON/YAML
I prefer IaC tools that use a DSL for the configuration language over tools that use JSON or YAML. JSON is difficult to write because of quote escaping and multi-line hell. In YAML, it is easy to make indentation errors. Furthermore, a truncated YAML file is often still valid YAML which can lead to issues should the file be corrupted.
DSLs like HashiCorp Configuration Language for Terraform or Azure Bicep are better suited for IaC. They are much more readable than YAML/JSON and much more writeable YAML/JSON. They still can be prone to truncation issues, but not to the extent YAML is.
Of course, as a programmer using AWS CDK, Terraform CDK, or Pulumi you don’t have to care too much about this. A CDK that produces JSON is a good model.
Serverless IaC
If you are deploying Serverless apps, then much of this discussion isn’t highly applicable because there are IaC options specific to Serverless that do a great job. I may do a separate post on those.
Kubernetes
Like Serverless, I would have to do another post on IaC for Kubernetes. Overall, I am underwhelmed by some of the popular tools for Kubernetes IaC like Helm which I view as total garbage. That said, most of the tools described in this post actually do a pretty good job deploying to Kubernetes so much of this post could still apply.
Conclusion
Choosing the right IaC is an important decision and often not one that is easy to change. I’ve only touched on some of the dimensions used in making a decision. Other dimensions include cost, developer community, and leveraging your existing experience.