Not the parent, but for one, doing a CF update is all-or-nothing. Either you roll the whole thing out, or you roll the whole thing back. If you have a lot of servers, and things are going down, you want to just STOP. But you can't. Also, if you click too quickly, sometimes you can get into a weird state and not be able to rollback OR update anymore.

I think this behavior is sensible. Additionally, you can disable rollback. However, cloud formation has needed and lacked a "dry run" option for a long time. It would be really nice to have that. However, the documentation does indicate what effect an update on any given resource will have.

I recommend against making sweeping changes to your infrastructure without thoroughness. Without saying this is what you're doing, I see a lot of developers who get involved with cloud treating changes whimsically. I'm not saying you should write perfect code. But thoroughness and a solid procedure (and backup plan) is a good place to start.

dry run for cfn == create change set :-)

(also, it helps to use nested stacks)

Same thing happens with other tools like Terraform though: once you've kicked off an apply, you are committed.

yeah, but having the option to run 'terraform plan' really helps you know what you're getting yourself into.

We've had Terraform take action that wasn't in the plan, in production.

I call it "pray and apply".

https://news.ycombinator.com/item?id=12214879

BOSH is able to cancel operations. You press Ctrl+C and it asks if that's what you intend.

CloudFormation change sets make CF updates a little less painful/mysterious:

https://aws.amazon.com/blogs/aws/new-change-sets-for-aws-clo...

changeset is very limited. when you have sub stack, change set cannot detect thing change in sub stack :(

Because massive json files with pseudo-invocation syntax and a ton of gaping issues that aren't readily solved by pre-existing template solutions pauses for breath and just bizarre decisions about holding and fielding and really poor integration with new services (you can tie ECS clusters in a knot with CF trivially) and API call limit hits KOing CF provisioning jobs and...

I mean, what it's doing is hard and I use it over, say, Chef... but it's not a "good" product. Heck, you cannot even truly validate CF templates without running them. The CLI and builder just do a crude structural check pass. Got a case error in a nested structure? Too bad, the entire job is rolling back.

While we're on the subject, I want to mention terraform (https://www.terraform.io/).

I'm not going to straight up recommend using it, but I will recommend checking it out. It's certainly a lot better than CF, but it still has really glaring issues and very much feels like alpha software (see discussion here: https://news.ycombinator.com/item?id=12213935 and some of my complaints here: https://news.ycombinator.com/item?id=12214358).

I am on the opposite fence. I also comment on the recent Terraform discussion. Basically the abstraction layer is too complex; why not template JSON and build the cloudformation stack? In the end, nested CF stack is still, a hard problem.

Why do you think the abstraction layer is too complex? I found terraform was essentially designed with AWS as a first-class citizen (if not for AWS in the first place), which means everything maps really well.

I strongly dislike HCL, but that's essentially what it is - templated JSON.

There are a few issues: stacks sometimes partially complete and you are left with a bit of a mess; stack creation has insanely long timeouts and a lot of retries, so it often sits there for 15 minutes before eventually failing; and deletions can fail part way through because there is some dependency that isn't obvious (and which they don't make it easy to find). I still like it (infrastructure as code is cool), but it needs more work.