News for hackers. Stuff that matters.

A comment on Why We Moved from Amazon Web Services to Google Cloud Platform. Parent comment

Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by dack on Friday August 05, 2016 @04:09PM (#12235407)
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.
[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by jonaf on Friday August 05, 2016 @08:50PM (#12236557)
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.

[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by jdub on Saturday August 06, 2016 @04:40AM (#12237531)
dry run for cfn == create change set :-)

(also, it helps to use nested stacks)

[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by toomuchtodo on Friday August 05, 2016 @04:11PM (#12235421)
Same thing happens with other tools like Terraform though: once you've kicked off an apply, you are committed.
[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by adamveld12 on Friday August 05, 2016 @06:25PM (#12236115)
yeah, but having the option to run 'terraform plan' really helps you know what you're getting yourself into.
[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by toomuchtodo on Friday August 05, 2016 @06:31PM (#12236142)
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

[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by jacques_chester on Saturday August 06, 2016 @09:39AM (#12238079)
BOSH is able to cancel operations. You press Ctrl+C and it asks if that's what you intend.
[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by cheeseprocedure on Friday August 05, 2016 @04:20PM (#12235475)
CloudFormation change sets make CF updates a little less painful/mysterious:

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

[ Parent | on HN ]
Re:Why We Moved from Amazon Web Services to Google Cloud Pla... by kureikain on Friday August 05, 2016 @04:57PM (#12235708)
changeset is very limited. when you have sub stack, change set cannot detect thing change in sub stack :(
[ Parent | on HN ]