Unlike CloudFormation, Terraform has a one-to-one mapping between what you define in the template and what gets deployed. This means creating multiple resources from the same definition oftenrequires duplicating code. Terraform does not have a concept similar to a stack in CloudFormation, which can provision multiple resources from a common definition. Stacks act as an intermediary between the definition and the actual deployment. Terraform workspaces come close to this, but having a native construct in the service is altogether a better experience.

Support for programming constructs

Terraform has support for programming constructs, such as for-loops, string manipulation, if-else branch workflows, and so on. It is easier for software developers to have this flexibility, but overusing them can make the templates difficult to understand. CloudFormation keeps this somewhat basic with conditions and rules but does not offer a lot of flexibility in a way that it maintains the declarative aspect of the templates and does not hide a lot of details around these constructs. It’s easier to mess up with this logic in Terraform and end up with an unintentional change of state.

State management for deployed resources

CloudFormation is rock solid in this area since all states are abstracted from the end user. Change sets are reliable and give a good overview of the modifications that the stack will go through if you proceed with the deployment. This can be easily incorporated into automation workflows. When it comes to sharing state data, you have the option to use outputs and exports, which we’ll cover soon in the hands-on deployment.

Terraform, on the other hand, has different options to work with state. By default, it stores everything on a local disk, which leads to all sorts of trouble when you’re working within a team. Remote storage is also offered but requires other services such as S3 and DynamoDB to be provisioned first. For state dependencies, entire state files have to be exposed, which is not a secure mechanism. So, CloudFormation’s opinionated approach stands out in terms of stability and security.

Better integrations offered by cloud-native services

Working with Terraform in a highly secure cloud environment with no internet connectivity can sometimes be difficult to set up. AWS offers VPC endpoints to work around such limitations, but imagine having to set up a separate VPC endpoint for every single service you work with. On the other hand, working with CloudFormation would require the creation of a single VPC endpoint for the service itself. The provisioning requests for all other resources are then entirely taken care of by the service itself as it directly consumes the service APIs using AWS’ network backbone. As you can imagine, dealing with these problems in a large-scale deployment can be a pain, and services such as CloudFormation offer a more seamless user experience.

Leave a Reply

Your email address will not be published. Required fields are marked *