8 ms·
Can someone explain to me if people still do new projects using CloudFormation? If so why? I'm in an enterprise and they do everything with CloudFormation, but
by rjzzleep 5y ago
Can someone explain to me if people still do new projects using CloudFormation? If so why?
I'm in an enterprise and they do everything with CloudFormation, but it doesn't really make sense to me. None of the code is reusable, it's yaml or json, which isn't easy to write to begin with.
I remember in the early days there were 2 frameworks that would compile to CF. I googled recently and found Lono, and it looks nice, but there's a fraction of the modules available that are available for terraform and getting help is also limited by the number of users. And then there is the big question for me why are building things that make CF look like Terraform[0].
I'm not a fanboy of Terraform either, there's plenty of stuff that I didn't like about it. But even AWS themselves almost seem to have more reusable templates in Terraform than they do CF.
[0] https://lono.cloud/ https://lono.cloud/
- blowski 5y agoIf you've spent the last 7 years writing CloudFormation scripts, why would you bother switching? If you're starting from scratch today, though, i agree that Terraform is better for most use cases.
- zoover2020 5y agoCDK is backwards compatible with CFN templates and could act as a drop in replacement. IaC improves DX and saves so much more time, compared to debugging JSON/YML.
- blowski 5y agoI haven't used CDK - you recommend it over Terraform then?
- nuker 5y ago> writing CloudFormation scripts templates, not scripts, Declarative. And CFN is much more lean and reliable than TF, I recommend it for new to AWS people.
- jdub 5y agoI enjoy writing near-pristine CloudFormation. My only tweak is that I write "literate" templates in Markdown using ```yaml blocks, then strip everything else out before executing them. I (re)use a lot of templates as "products", e.g. I have an RDS PostgreSQL template that I've been maintaining and using for years. CloudFormation modules are great for encapsulation and reuse if you actually have anything you want to reuse at sub-template granularity. I rarely do. For example, we have a bunch of API services that all work the same way. In that case, the granularity of reuse is the template. I don't have a bunch of different services/products that all need to reuse a given resource in the same way. For the same reason, I'm not very excited by CDK and other CloudFormation-producing tools. I started mucking around with Terraform, but immediately discovered I needed to create a provider (custom resource). That's an incredibly manual process to begin with, but almost all of it is translating between Terraform representation (structures based on HCL2) and the JSON representation of whatever API you're using. So much translation when 99.999% of the APIs you'll use will be JSON. Aaaaaarrrrghhhh. Sorry.
- mixedCase 5y ago> but immediately discovered I needed to create a provider That doesn't make any sense to me, if you're coming from CloudFormation. What for?
- jdub 5y agoTerraform often doesn't cover complex, less commonly used AWS services or features. For example, practically zero coverage of the entire Media Services suite of products.
- mixedCase 5y agoAnd for those edge cases, you can use this: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudformation_stack https://registry.terraform.io/providers/hashicorp/aws/latest... Which still gives all the power of HCL to generate the CF stacks. No need to create a new provider.
- anothernewdude 5y agoLots of early infra as "code" used yaml. But I certainly don't touch any IaC stuff that wouldn't allow me to easily move between vendors. AWS have terraform because it can drive adoption. It is in Amazon's interest to drive lock-in and it certainly seems their biggest goal. If you don't like Terraform, perhaps you would consider Pulumi? It's similar, but doesn't pretend that yaml is sufficient. Infrastructure as Actual Code. https://www.pulumi.com/ https://www.pulumi.com/ Keen to hear of similar tools myself.
- chrisandchris 5y ago> But I certainly don‘t touch any IaC stuff that wouldn‘t allow me easily move between vendors. How does Terraform achieve that better than CF besides that it has the ability to provision other providers? If you want to switch from say AWS to Azure, you are still required to reconfigure each and every resource as they are named differently, behave probably differently and have different parameters. In that time you probably have learned the equivalent of CF in Azure (if there is some). It‘s not unachievable, but saying it‘s „easy“ is far away from the truth.
- Dobbs 5y agoBecause this can be done piecemeal and in place. Additionally if you use modules and the like it can be done in swaths without issue. Additionally you can tie things across domains. Use Route53 with Azure servers, etc.
- anothernewdude 5y agoHow does terraform make it easy to move between vendors when CF doesn't allow it at all? Is that actually a question you are seriously asking? The providers for AWS/Azure/Openstack/VSphere look very similar, to the extent that terragrunt templates can smooth over the differences. Calling renaming provider resources 'reconfiguring' is a stretch. If that's the worst thing you ever have to do, then I would suggest you're not doing much that is complicated in this space at all.
- chrisweekly 5y agoEveryone I talk to hates CF and is moving to or already exclusively using Terraform.
- rbanffy 5y agoTerraform is not exactly something people I know love. We accept its existence and that’s it.
- schoolornot 5y agoYep, everyone loves it in the beginning and then the warts start to show. It's a really bad feeling when you get stuck not being able to do something in HCL. Then you Google it and find 50 other people had the same issue and were told _you're not supposed to do that_
- rbanffy 5y ago> and then the warts start to show. It's warts, all the way down.
- chrisweekly 5y agoI didn't say I liked it, just made an observation.
- watermelon0 5y agoThe major benefit of CF (if you don't need to manage non-AWS resources) are rollbacks. Basically, in almost all situations, if something cannot be provisioned, or a service doesn't become healthy, CF would roll back to the previous state. With Terraform you are mostly on your own, and you can easily end up in broken state, which needs to be manually fixed.
- Dobbs 5y ago> Basically, in almost all situations, if something cannot be provisioned, or a service doesn't become healthy, CF would roll back to the previous state. Until it doesn't and then you are in a completely unfixable state, must file support tickets and get AWS support to debug it and figure out how to unbork it. Meanwhile terraform gives you tools to investigate and fix it.
- mixedCase 5y agoUnless I was doing something really stupid with null_resources, a rollback for me has always been achievable either over a terraform destroy, or a new terraform apply after reverting a commit.
- fishnchips 5y agoMain reasons to use CF over TF in the AWS world include: rollbacks (giving you some form of transactionality), better understanding of success criteria (though arguably Terraform now can understand what it means for an ECS deployment to succeed), and more complete support for newer features.
- deberon 5y agoI would argue against your final point. They may support some features that Terraform does not, but on the whole I would expect Terraform to have a more complete feature-set than CloudFormation.
- fishnchips 5y agoAll I’m saying is that many new features are supported by CF first, for obvious reasons. Overall though yes, TF has a broader feature set and better documentation. I generally prefer to read TF AWS docs to reading AWS’ own, even outside of TF context.
- whoknew1122 5y agoSpeaking as someone who works in AWS Support, AWS Support can only support Terraform on a best-effort basis. There have been many times where someone provides me a small snippet of an error message from Terraform, and the error is so vague as to be useless. I then have to ask the customer for more detailed logging to even figure out what APIs Terraform is even calling. After that I can maybe cobble things together with CloudTrail to figure out the issue. But that's only because I have personal experience with Terraform. If you get a support agent who isn't familiar with DevOps generally and only knows CloudFormation? You're not going to get the same level of support. Meanwhile, we have a full team and competent internal tooling to troubleshoot CloudFormation. Using Terraform instead of CloudFormation limits the speed and competency of the support you can get from AWS. Speaking as someone who plays with both at work and personally, here's what I think: If you're in an AWS monolith with a large team that uses AWS Support as your primary support channel (i.e. you don't have in-house AWS experts), go with CloudFormation. Terraform doesn't do anything on AWS that CloudFormation can't, and AWS can better support you. If you're in a multi-cloud scenario, it's better to use Terraform (if only because you don't have to learn two different syntaxes). If you're a one-person shop or don't rely on AWS Support for support? Do whatever you want. (And while I do work at AWS, please know I could care less whether you use CloudFormation. I'd rather you use the tool best for the job, even if it isn't an AWS product. While some people may conspiratorially say that AWS tries to lock you into AWS services to the exclusion of anything else, most people at AWS just want you to use the right tool for the right job. I have no problem telling someone not to use AWS if it doesn't work for their usecase -- nor do most of my co-workers)