3 ms·

If only CloudFormation followed this philosophy. Unfortunately, doing things "The Right Way (tm)" within AWS means torturously long feedback loops, tearing down

by davedx 7y ago

If only CloudFormation followed this philosophy. Unfortunately, doing things "The Right Way (tm)" within AWS means torturously long feedback loops, tearing down stacks and rebuilding them again over and over again (and when you're working with RDS databases, "tear down" is 10 mins and "rebuild" is 15 mins), then some stacks fail to delete because an IAM role that was just created is now somehow unable to be deleted... Our company has restricted it so CloudFormation is the only way to provision infrastructure because doing things the right way makes our lives significantly harder. And so the "native cloud" tax continues to accumulate and grow until you spend more and more time and money on just building and maintaining infrastructure...

carlsborg 7y ago
Why are you bringing down the RDS stack to make cloudformation udpates? Can you share an example of something that makes you need to do this over and over again?
- davedx 7y ago
  I'm creating a database with parameters, roles, backup buckets and so on. Usually each time I run the stack I either get a template error, or the stack partly runs then hits some other error. Then the stack rolls back, and re-running it will fail because it's in rolled_back state. So then I need to delete the whole thing and start again. When I can simply re-run and update the stack without deleting it I do (for example if I just change a property of one of the resources). But I spend a lot of time with stacks that are in broken states for various reasons.
  - acdha 7y ago
    I share this pain - it’s a major reason why we switched to Terraform, along with not having to wait 6-12 months for support for new AWS features - but I would recommend using CDK to generate your CF stacks. The cfn-python-lint tool was helpful for catching many things without a 20 minute delay but CDK goes even further on the boilerplate reduction and a real programming language beats YAML in every way.
  - carlsborg 7y ago
    Maybe changesets would be useful here. It’s like terraform plan but better because it’s aws native. $aws cloudformation deploy. .. —no-execute-changes etc https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html https://docs.aws.amazon.com/cli/latest/reference/cloudformat...

by davedx 7y ago

carlsborg 7y ago

Why are you bringing down the RDS stack to make cloudformation udpates? Can you share an example of something that makes you need to do this over and over again?

davedx 7y ago
I'm creating a database with parameters, roles, backup buckets and so on. Usually each time I run the stack I either get a template error, or the stack partly runs then hits some other error. Then the stack rolls back, and re-running it will fail because it's in rolled_back state. So then I need to delete the whole thing and start again. When I can simply re-run and update the stack without deleting it I do (for example if I just change a property of one of the resources). But I spend a lot of time with stacks that are in broken states for various reasons.
- acdha 7y ago
  I share this pain - it’s a major reason why we switched to Terraform, along with not having to wait 6-12 months for support for new AWS features - but I would recommend using CDK to generate your CF stacks. The cfn-python-lint tool was helpful for catching many things without a 20 minute delay but CDK goes even further on the boilerplate reduction and a real programming language beats YAML in every way.
- carlsborg 7y ago
  Maybe changesets would be useful here. It’s like terraform plan but better because it’s aws native. $aws cloudformation deploy. .. —no-execute-changes etc https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html https://docs.aws.amazon.com/cli/latest/reference/cloudformat...