5 ms·
CloudFormation is awful. I used it extensively for about a year and will never go back.
by meddlepal 11y ago
CloudFormation is awful. I used it extensively for about a year and will never go back.
- pmoriarty 11y agoCould you please elaborate on your experience? Very interested. Also, would you mind talking about what you use instead?
- meddlepal 11y agoI use Terraform right now but I'm looking at some other tech as well currently because Terraform is a bit too low-level for my current employers needs (but a fantastic product overall). CF problems: * JSON format is awful (practically speaking this can be solved with Troposphere...) * So slow. * UPDATE_ROLLBACK_FAILED ... It apparently was fixed very very recently, but what a garbage design decision. * Debugging CF errors is a nightmare. * Nested templates have to be stashed in S3.
- lox 11y agoCfoo (https://github.com/drrb/cfoo https://github.com/drrb/cfoo) is great, it's simply a yaml-to-json converter with some syntactic sugar for cloudformation. Troposphere seemed like too heavy an approach.
- eropple 11y agoYMMV, but I'd much rather Cfer (https://github.com/seanedwards/cfer https://github.com/seanedwards/cfer), which I found useful enough to contribute back to. A real DSL instead of relying on comparatively inexpressive YAML is very appealing to me.
- xorgar831 11y agoLikewise, CF is the leading cause of outages in our infrastructure. We've completely abandon it in favor of Terraform. * CF gets deadlocked if resources are changed outside of it, and there's no way to prevent people from doing that either * No concept of a rolling update to a fleet or any warning it's going to cause an outage with out having to dig through fine print in the docs on every single change, just terminates all the EC2 instances in an ASG/ELB in some cases * If you have a template, remember any change you make to that template has to be applied to every single stack you have, otherwise you'll either damage something or deadlock the stack when updating it later, it can't figure out what's deployed on it's own and maintains its own state that can be different from the real state. We had to stop using templates at all and just store a copy of each template in our local git repo. * If you have more than 100 stacks searching the list of stacks requires clicking a handful of times on the "show more stacks" button before it'll show the one you typed in * Stupid slow, esp. compared to Terraform * Doesn't delete Route53 DNS records even after saying it does in the log outout * Can break ELB configurations, such as sticky sessions and cause outages * Doesn't actually support deploying all AWS resources, SNS/SQS perms/rules aren't complete for example.
- jzelinskie 11y agoBecause we don't want to abstract the cloud provider (and potentially lock us out of any Amazon-specific behavior), we use a small Python script that takes Jinja2-templated YAML and compiles it to JSON. It also handles the uploading to S3 and a whole bunch of convenience macros for generating the more verbose parts of defining infrastructure in CloudFormation. It took a lot of hair-pulling to write it, but now that it's done, CF isn't so terrible to use.
- smithclay 11y agoI've found the Python wrapper troposphere useful for dealing with the JSON. https://github.com/cloudtools/troposphere https://github.com/cloudtools/troposphere
- lox 11y agoAs a counter point, we use Cloudformation extensively at 99designs and whilst it has some quirks, it's also been stable, reliable and incredibly beneficial for automating lots of our infrastructure.
- SteveNuts 11y agoWere you using cloudformation only or did you use something like troposphere
- meddlepal 11y agoCloudFormation only.
- buremba 11y ago+1 1. We can't test the templates in local environment, the only way to test a template is to create a real cluster which usually takes ~15 minutes. 2. The error messages are not helpful enough. It usually fails with "SETUP_FAILED" error with no proper error cause. 3. The rollback may not work if you change the configuration. You need to delete the resources manually or even need to get help from Amazon since the resources stuck at some failed status. 4. The JSON template is hard to write and read. We have a fat single file template that has 2k lines and scared to change it since we might broke something. 5. Not all AWS actions are supported. For example we need to add custom resources (ELB and RDS instances) to a Opsworks stack but it's not possible with Cloudformation.
- zwily 11y agoI'm not a CloudFormation superfan, but... 1. Yup. 2. In my experience, the error message is usually fine, but there are many times where it's completely obtuse. 3. They just added a new feature to help with this. When you get ROLLBACK_FAILED, you can now tweak things and retry the rollback. It has helped me a few times not have to contact support recently. 4. 100% agree. I write all my templates in yaml, which helps a lot. I really hope they just add native yaml support. Example[1] 5. You can now create custom resources using Lambda from within your templates, which is pretty cool. Example[1] edit: I should add that at my company, we mostly use Terraform now. I still like to use CF for projects that will be open-sourced though, as I don't want step 1 of my instructions to be "install terraform". [1] https://github.com/zwily/sqs-to-lambda-via-lambda https://github.com/zwily/sqs-to-lambda-via-lambda
- leg100 11y agoCan't counter these points other than that what else is there to automate AWS infrastructure? Terraform suffers all these problems, too.
- buremba 11y agoI don't have experience with Terraform but it should be possible to find a way to fix these issues except the first one.
- 11y ago
- the_arun 11y agoWhat do you use instead?