3 ms·

I use CloudFormation to manage similar AWS web-app infrastructure. I've been continuously evaluating Terraform over the years (it is indeed maturing quickly), b

I use CloudFormation to manage similar AWS web-app infrastructure. I've been continuously evaluating Terraform over the years (it is indeed maturing quickly), but have still decided to stick with CloudFormation for now, and would still continue to recommend the same for anyone managing an AWS-exclusive (or mostly-AWS) deployment. To respond to some specific items mentioned in this post: - "Terraform has a more straightforward and powerful language (HCL) that makes it easier to write and review code." It's easy to pipe configuration through your favorite 'straightforward and powerful' templating language of choice to generate the stack template used by CloudFormation. I definitely wouldn't use CloudFormation at all without an extra preprocessing step of some sort. - "Terraform has another gem of a feature that we rely on: terraform plan. It allows us to visualize the changes that will happen to the environment without performing them." CloudFormation has a similar feature called "Change Sets" (released in March 2016). Finally, two more things to note: - CloudFormation supports "Custom Resources", which allow you to write Lambda-function scripts to perform any custom operation you want (e.g., interact with third-party APIs, or support new AWS resources that don't yet have an official CloudFormation resource implementation). There's not as extensive a library of providers Terraform supports, but you can often find open-source providers to fill the gaps on AWS resource until an official implementation is released. And if not, you can just write a quick and dirty implementation yourself. Terraform supports a similar feature in "Custom Providers", but they are Go-only as opposed to the various supports Lambda-language runtimes. - CloudFormation and all official AWS-resource implementations not only have excellent public documentation but are officially supported by AWS Support, which is a big deal if you're deploying something with any degree of complexity or cost/risk. As for Terraform's strengths: its extensive set of resource providers beyond AWS ecosystem can't be beat. Also, it has great support for mapping existing infrastructure resources, which is a feature still sorely lacking in CloudFormation. (I'm surprised the author of this post didn't take advantage of this for their migration to avoid downtime!)

ben0x539 9y ago
> It's easy to pipe configuration through your favorite 'straightforward and powerful' templating language of choice to generate the stack template used by CloudFormation. I definitely wouldn't use CloudFormation at all without an extra preprocessing step of some sort. The tricky bit is what kind of logic you can apply to values that are the result of provisioning/looking up resources in the first place, isn't it? Like, what dynamically determined resource IDs are exposed to the language and in what places you can reference them. Basically the capability of terraform's interpolation language vs. CloudFormation Fn::* constructs, I suppose.
0x62c1b43e 9y ago
Could you share what preprocessors/templating languages you've used with CloudFormation?
- Corrado 9y ago
  cfn-builder[0] is my take on simplifying CloudFormation templates and allowing project teams to manage their own stack. I built it specifically to use in a CD/CI environment so it doesn't use things like input parameters that might change from one run to another. Most variables are stored either in a global namespace (AccountId, IP Addresses, AMIs, etc.) or in separate environment namespaces (Subnet IDs, CidrBlocks, etc.) It even includes several built-in commands to help you maintain your environment, including one to update the global namespace with current AMI information. The CFN coverage is not as complete as I would like but I've built and managed production workloads with it and it does the job. Since it's built on NodeJS so if you know JSON and a little bit of Mustache it's not hard to understand. Anyone want to help? [0] https://github.com/KangarooBox/cfn-builder https://github.com/KangarooBox/cfn-builder
- wgjordan 9y ago
  I've used Embedded Ruby (ERB), I was also converting YAML to JSON before CloudFormation added native support for YAML templates (Sep 2016). My company's web application was a Ruby/Rails stack so `.yml.erb` syntax was already quite familiar to our team. Pre-processing the template is a simple shell one-liner that you can easily add to your test/deploy scripts: cat template.yml.erb | ruby -rerb -e "puts ERB.new(ARGF.read, nil, '-').result" > template.yml A lightweight template-preprocessor step adds just enough scripting automation (in a familiar language/environment of your choice) to cut through boilerplate, and avoids imposing yet another domain-specific intermediate abstraction layer on top of the whole stack (e.g., troposphere's Python API, arguably also Terraform's HCL).
- malcolmjuxt 9y ago
  At JUXT we use Clojure's EDN, bolstered with some tag literals courtesy of our Aero library (described here: https://juxt.pro/blog/posts/aero.html https://juxt.pro/blog/posts/aero.html). We use ClojureScript to compile to TF's JSON. EDN allows comments, ignores commas and otherwise is a nicer JSON. Aero allows us to encode multiple environments in a single document, and include ciphertext for secrets. We're pretty happy with the overall result.
stimur 9y ago
Disclaimer: I work for AgileBits. CloudFormation is a great tool, don't get us wrong. It is one of the first cloud IaaC tools. And it has it's downsides: - inability to address specific object in the state, similar to `-target ` option in terraform - forcible re-deployment (`taint`ing) of the resouce is not possible too, well, not as easy as in TF - when creating ChangeSet in CF, it is absolutely useless on nested stacks, all you see in it is "Stack will be updated", even if there is nothing to update - targeted `destroy`s do not exist, as well as destroy `plan`s: similar to what `terraform plan -out plan.out -destroy -target aws_resource.name; terraform apply plan.out` does - The work with state, renaming, reassigning, deleting and importing resources is missing in CF as a class - TF refreshes state of the resources each run, checking their actual state and trying to revert any changes applied to them outside of the flow, CF assumes that nothing is changed and gets very surprised when it is drifted or simply doesn't match its expectations. ( I know there is drift detection, but does it actually restores the desired state? I've never had a chance to check that..) When we deployed new TF stack, we imported part of the resources created by old CF template. And now I am a bit worried to clean it up, because it might try to delete old resources, even with '"DeletionPolicy": retain'. I have no visibility or control over its action. Basically: apply the template and pray. ChageSets also failed me once, trying to do not what it was telling me in the plan. Terraform plan once captured into the file will do exactly what it promised me, when applied. To sum up: both tools got their 'pro-'s and 'con-'s, and personally I feel more comfortable with the Terraform.

ben0x539 9y ago

> It's easy to pipe configuration through your favorite 'straightforward and powerful' templating language of choice to generate the stack template used by CloudFormation. I definitely wouldn't use CloudFormation at all without an extra preprocessing step of some sort. The tricky bit is what kind of logic you can apply to values that are the result of provisioning/looking up resources in the first place, isn't it? Like, what dynamically determined resource IDs are exposed to the language and in what places you can reference them. Basically the capability of terraform's interpolation language vs. CloudFormation Fn::* constructs, I suppose.

0x62c1b43e 9y ago

Could you share what preprocessors/templating languages you've used with CloudFormation?

Corrado 9y ago
cfn-builder[0] is my take on simplifying CloudFormation templates and allowing project teams to manage their own stack. I built it specifically to use in a CD/CI environment so it doesn't use things like input parameters that might change from one run to another. Most variables are stored either in a global namespace (AccountId, IP Addresses, AMIs, etc.) or in separate environment namespaces (Subnet IDs, CidrBlocks, etc.) It even includes several built-in commands to help you maintain your environment, including one to update the global namespace with current AMI information. The CFN coverage is not as complete as I would like but I've built and managed production workloads with it and it does the job. Since it's built on NodeJS so if you know JSON and a little bit of Mustache it's not hard to understand. Anyone want to help? [0] https://github.com/KangarooBox/cfn-builder https://github.com/KangarooBox/cfn-builder
wgjordan 9y ago
I've used Embedded Ruby (ERB), I was also converting YAML to JSON before CloudFormation added native support for YAML templates (Sep 2016). My company's web application was a Ruby/Rails stack so `.yml.erb` syntax was already quite familiar to our team. Pre-processing the template is a simple shell one-liner that you can easily add to your test/deploy scripts: cat template.yml.erb | ruby -rerb -e "puts ERB.new(ARGF.read, nil, '-').result" > template.yml A lightweight template-preprocessor step adds just enough scripting automation (in a familiar language/environment of your choice) to cut through boilerplate, and avoids imposing yet another domain-specific intermediate abstraction layer on top of the whole stack (e.g., troposphere's Python API, arguably also Terraform's HCL).
malcolmjuxt 9y ago
At JUXT we use Clojure's EDN, bolstered with some tag literals courtesy of our Aero library (described here: https://juxt.pro/blog/posts/aero.html https://juxt.pro/blog/posts/aero.html). We use ClojureScript to compile to TF's JSON. EDN allows comments, ignores commas and otherwise is a nicer JSON. Aero allows us to encode multiple environments in a single document, and include ciphertext for secrets. We're pretty happy with the overall result.

stimur 9y ago

Disclaimer: I work for AgileBits. CloudFormation is a great tool, don't get us wrong. It is one of the first cloud IaaC tools. And it has it's downsides: - inability to address specific object in the state, similar to `-target ` option in terraform - forcible re-deployment (`taint`ing) of the resouce is not possible too, well, not as easy as in TF - when creating ChangeSet in CF, it is absolutely useless on nested stacks, all you see in it is "Stack will be updated", even if there is nothing to update - targeted `destroy`s do not exist, as well as destroy `plan`s: similar to what `terraform plan -out plan.out -destroy -target aws_resource.name; terraform apply plan.out` does - The work with state, renaming, reassigning, deleting and importing resources is missing in CF as a class - TF refreshes state of the resources each run, checking their actual state and trying to revert any changes applied to them outside of the flow, CF assumes that nothing is changed and gets very surprised when it is drifted or simply doesn't match its expectations. ( I know there is drift detection, but does it actually restores the desired state? I've never had a chance to check that..) When we deployed new TF stack, we imported part of the resources created by old CF template. And now I am a bit worried to clean it up, because it might try to delete old resources, even with '"DeletionPolicy": retain'. I have no visibility or control over its action. Basically: apply the template and pray. ChageSets also failed me once, trying to do not what it was telling me in the plan. Terraform plan once captured into the file will do exactly what it promised me, when applied. To sum up: both tools got their 'pro-'s and 'con-'s, and personally I feel more comfortable with the Terraform.