3 ms·
> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Oh, I
by pqb 6y ago
> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life.
Oh, I see I am not alone in having the same experience with the AWS CloudFormation (CF) update flow. I have started feeling "good enough" in CF after about 6-8 months to write templates from my memory (accompanied with a documentation page). The funny thing about the CF is fact, the all people I know had working flow based on searching GitHub/Gist over an example, edit, refine, deploy, push fixes, deploy, rinse & repeat.
In the blogpost I have noticed mentioned Pulumi. To be honest, I have not used it yet, but I have tried AWS CDK [0]. I suppose it is AWS's go-to solution for everybody who wants to use the CloudFormation for saving deployment stages and also have programmed templates in languages of their choice (like a TypeScript or Python). It is interesting solution that I suggest investigating if you haven't done already. It supports "importing" CF templates as-is, so they can be incrementally translated to CDK.
[0]: https://github.com/aws/aws-cdk https://github.com/aws/aws-cdk
- throwaway894345 6y agoI came to Terraform optimistically from CloudFormation, thinking it would fix many of the latter’s warts, and it sort of has, except it’s introduced as many of its own. I’m still undecided about which set of problems I prefer, but in general I’m disappointed with Terraform. Some particular things that bother me: I get the distinct impression that it’s trying to badly reinvent a programming language (with “locals” replacing variables, “variables” replacing parameters, and “modules” replacing functions, “for each” replacing loops or comprehensions, and so on). Additionally, I find myself wanting rollback support like CloudFormation has. It’s unsettling that TF makes it easy to get into a bad state. Further still, (and maybe this is just my organization’s use of Terraform), it seems the convention is to split the whole architecture up into lots of root modules, but the links between resources in these modules are basically string identifiers (e.g., ARNs in the AWS world) which will likely change if the resource gets deleted and recreated or if AWS changes their naming conventions or so on. Similarly, people seem to build these identifiers from strings instead of referencing them directly from resource attributes (I’ve seen this practice advertised in some of the AWS provider docs IIRC) which is bad for all of the same reasons that pointer arithmetic is bad. I do like that custom providers aren’t full-on lambdas that I have to deploy, unlike in the CloudFormation world, but mostly I’ve been disappointed. I wonder if Pulumi or AWS CDK is the solution I’ve been searching for, or if I should just stick to generating CloudFormation from YAML.