
CloudFormation updates, what's happened since you started using Terraform - dblooman
http://www.dblooman.com/aws/2016/10/09/Cloudformation-updates,-what%27s-happened-since-you-started-using-Terraform/
======
otterley
> It lacks some CloudFormation features, like rolling updates. One of the
> great things about CloudFormation is the ability to update an AMI in a stack
> and have it roll out that AMI in a controlled way. In order to do this
> exactly the same way in Terraform, you need to learn how to do...
> CloudFormation.

Have you tried using `create_before_destroy` in a resource lifecycle block? Or
are there issues with it that are difficult to work around?

~~~
toomuchtodo
This works, but its critical you define "wait_for_elb_capacity" if this is in
reference to an autoscaling group associated with an ELB serving any sort of
inbound requests. Otherwise terraform will create the new resources, _and then
immediately terminate the old resources before the new resources are fully
available_ ("f--- it, we'll do it live" mode).

This won't do a rolling deploy per se, it'll just bring up all new resources,
wait for them to be healthy, and then terminate the old resources; if you want
to do rolling changes, you'll need Cloudformation (or if its deploy-specific,
tooling like Spinnaker).

~~~
otterley
What is the practical difference between the two methods? It seems like a "six
of one, half a dozen of the other" kind of situation. Besides, building an
entire replacement stack component before cutting over seems like a wise
course of action to me (cache warming concerns aside) to avoid issues caused
by inconsistency among peers.

~~~
toomuchtodo
The practical difference is that with Terrfaorm, once you've started your
apply, you are committed. Rolling modifications allow you to stop and rollback
if necessary.

I admit Terraform's DSL is superior to Cloudformation JSON/YAML, but
Cloudformation wins on more powerful primitives for infra modifications.

