3 ms·
I'm a developer (mostly) and I'm brand new to serverless technology, cloud infrastructure, etc. I've never set anything up in AWS before, except for a few EC2 i
by meowface 8y ago
I'm a developer (mostly) and I'm brand new to serverless technology, cloud infrastructure, etc. I've never set anything up in AWS before, except for a few EC2 instances here and there. I've never used Cloudformation, Fargate, or anything like it.
I was recently asked to set up a recurring Fargate task with a container of an app I developed. Despite knowing nothing about the ecosystem, I was able to get it up and running with Terraform in a few days, with pretty much no headaches, friction, or confusing issues. I didn't touch the AWS console even once, other than to verify that it appeared to be set up correctly after running "terraform apply".
I considered using Cloudformation, but it just seemed kind of messy and confusing to me. It also felt very visually noisy. (And YAML wasn't the issue; I read and write YAML very often, and actually really like YAML and use it in all of my personal projects.)
Despite going into it totally blind, by contrast, I found Terraform very intuitive and sensible within the first few minutes of using it. It felt much more structured and organized, and just generally simpler to read and write. I also liked that it was provider-agnostic. And the "terraform plan" feature was super helpful.
I "cheated" a little bit by using these Terraform templates as a base: https://github.com/turnerlabs/terraform-ecs-fargate-scheduled-task https://github.com/turnerlabs/terraform-ecs-fargate-schedule.... I didn't have to change too much to get things working. I'm sure it would've taken longer if I wrote the whole thing from scratch.
I guess I'm asking: am I wasting my time investing in learning things like Terraform? Every reply in this thread is either recommending AWS-native alternatives to Terraform, criticizing Terraform, or both. For some reason I thought it was generally recommended over Cloudformation due to the lack of lock-in.
- jjeaff 8y agoIf terraform gets the job done and seems easier, then that is a good reason to use it. Especially as it seems that there are more boilerplate examples for terraform out there. But no lock-in is not a reason at all. There is effectively no amount of terraform config that will plug and play into a different cloud. It seems that it was pitched that way. But if you write anything in terraform for AWS you will have to fully rewrite it for GCP or DO. But at least you will be used to the syntax and conventions.
- meowface 8y agoThanks, that makes sense. I think a consistent syntax and data structures is definitely a still big benefit, even if it's not actually semantically vendor-agnostic. I think I'll probably keep using Terraform.
- scarface74 8y agoThat’s the problem. Of course AWS will have more boilerplate examples with CF. CodeStar is a whole library of CF based deployments. When you export a definition from a lambda you get CF. If you ever work for a company that uses AWS, they probably have a business support plan where you can get instant and excellent customer support on CF.
- Aeolun 8y agoOf course, if you use Terraform you likely wouldn’t need any support in the first place. Knowing Terraform is going to be a bit more helpful if you ever work with something other than AWS too.
- scarface74 8y agoRight because no one ever had issues with something as complicated as infrastructure set up. All the provisioners are different. If you have to learn new cloud infrastructure. Learning the IAC configuration is the least of your troubles.