7 ms·

As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform module

As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engineers are more familiar with Terraform already, but learning Cloudformation is really not that hard...And if you can't work out how to use a basic tool, you should not be running infrastructure anyway, because IT is a constant cycle of change. I'm not saying Terraform is not good, but I just think a native solution of the platform is preferable over a 3rd party tool.

brightball 5y ago
Terraform also had the advantage of being able to pull together multiple services outside of a single provider. Want to use Cloudflare with AWS and another 3rd party provider that offers services in an AWS region? Simple with Terraform.
404mm 5y ago
Also a DevOps guy, I like Terraform from the “user” experience. It’s much more comfortable eco system to be in than AWS CF. Managing your resources is also better experience. That is until you hit an issue with resource or situation not being correctly supported by TF. CF has the vast advantage of being native and fully supporting AWS resources. Unfortunately it gets complicated (not complex) so quickly and has a strong feel of rushed MVP.
c7DJTLrn 5y ago
I seem to recall that years ago, Terraform was touted as an abstraction layer for cloud providers meaning that you could write some HCL and move between them seamlessly. A solution for vendor lock-in. Maybe that was nonsense but that's certainly not the case today.
kosolam 5y ago
If you are saying that it’s better to run native than Terraform then to me it means that Terraform is not good enough - which is also my experience from poking it. It covers all use cases on all clouds, buy only ~80% of each use case. The rest you have to figure out by yourself. Which often means diving into CloudFormation and such - so basically losing the advantage of Terraform.
- Thev00d00 5y ago
  I think it varies on the quality of the providers, at least in AWS I've yet to come across something missing
  - shell0x 5y ago
    But why not just Cloudformation then? What advantage does Terraform provide over Cloudformation in your opinion?
    - hnlmorg 5y ago
      For one, it's closer to a proper programming language as opposed to straight up data interchange format. Sure if you write it in YAML than you can take advantage of variables but YAML's syntax for variables is pretty gross. Comparing CloudFormation to Terraform is a little like comparing HTML and CSS to Javascript (though Terraform isn't nearly as nice to code in as Javascript -- and I'm not exactly a big fan of Javascript). You can cover most use cases with plain HTML and CSS but the moment you need to get a little more intelligent with your code you get stuck.
      - alpha_squared 5y ago
        > For one, it's closer to a proper programming language as opposed to straight up data interchange format. Sure if you write it in YAML than you can take advantage of variables but YAML's syntax for variables is pretty gross. I think that's what AWS CDK[0] and Terraform's CDKTF[1] are trying to solve. Given the context of your example, I'd liken Terraform to CSS and CloudFormation to HTML; CDK/TF to Javascript. It's not a great analogy, but Terraform as is right now is just close enough to a programming language to deceive you into treating it like one. But it really isn't and those issues become glaringly clear the more you use it. [0] https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/ [1] https://learn.hashicorp.com/tutorials/terraform/cdktf https://learn.hashicorp.com/tutorials/terraform/cdktf
hnlmorg 5y ago
I'm not the biggest fan of Terraform either but it would be naive to deny that Terraform doesn't still offer a lot of advantages over CloudFormation even if you're not writing cloud agnostic code (even though I do actually agree with your point that Terraform doesn't make your infra cloud agnostic). Terraform offers far more constructs than CloudFormation and there is still a lot to be said for using the same language from describing your AWS infra as GCP, Github, any on prem infra, etc (even if the resources differ between providers requiring bespoke code for each). It's a bit like those who advocate node.js because it means the same developers can right frontend and backend code and in the same language. If you like the tooling around CloudFormation in AWS then you're better off with serverless (`sls`) or even Amazon's own CDK (https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/) over YAML-based CloudFormation stacks in my opinion. That's not to say I don't think Terraform doesn't have its warts: properties are non-guessable, IDE integration is pretty mediocre, and it's overly verbose in calling modules (so bad that sometimes the calling code has just as many lines as the module itself!) but I do still think it is the least worst tool available at the moment. And one can always use a 3rd party tools like Terragrunt if you want to fix some of the shortcomings of Terraform while still taking advantage of it's benefits (though personally I'm on the fence about whether the industry really needs yet another transpiler that compiles to code that needs to be transpiled....it's starting to feel like it's just abstractions all the way down....)
- throwaway894345 5y ago
  I agree with this. Terraform is definitely the least-bad tool, especially in that it integrates with so many more services than CloudFormation and has far fewer bizarre limitations than CloudFormation (e.g., you cannot pass objects in CF, and arrays can only be simulated as comma separated strings). Terraform isn’t great, but CF is awful, and even the AWS folks will point you at the CDK instead.
  - devoptimist 5y ago
    Agree CF is crap. Each clouds SDK in the language the team is most familiar with is by far the best option. State can be stored in git. Any version of my infrastructure is a git checkout away. I use Go, and the documentation for the AWS SDK includes copy-paste examples Try and checkout Terraform from 6 months ago and run it? Frequently I cannot even get someone’s tutorial example written a week prior to work without edits. I checked out a year old commit in my infra repo; rebuilt an entire ECS stack deprecated 18 months ago. Just be programmers. The cloud ops scene is just reselling the same delusions as Unix grey beards and Windows server admins. It’s about making hardware do the right thing, not hand wavy semantics. Most of the people I work with just regurgitate memes. Very few actually test them for truth.
threatofrain 5y ago
What do people here think about Pulumi?
- CGamesPlay 5y ago
  I really like Pulumi, and have done some really interesting stateful infrastructure work using it in the past. Because you get a full programming language, you can definitely code yourself into a knot that is difficult to debug, but the saving grace for Pulumi I think is that the output of the program is a simple declarative object describing the target state. So you can almost think of Pulumi as a generator for Terraform files.
- jokethrowaway 5y ago
  I like the concept of using different languages instead of terraform because I consider the latter to provide pretty terrible developer experience. I don't like the idea of having a Turing complete language to do that. I would prefer things to be declarative. Honestly I would just be happy with a better terraform without yaml and better tooling for terraform. I tried to use pulumi and they didn't support something I needed, or maybe I was too dumb to understand how to do it, so I insta quit. They're also pretty pushy in selling whatever they're selling.
  - deleted 5y ago
    [deleted]
d4mi3n 5y ago
I'd point out that one of the biggest advantages of Terraform isn't managing cloud infrastructure (though I certainly like it for this), but for providing a common language for integrating vendors and other 3rd parties into my own cloud infrastructure. I've worked in a couple organizations that had a lot of success managing things like cloud access security brokers, web application firewall appliances, ticketing systems, identity providers (with and without multi-IdP federation) and more. Doing this without Terraform is incredibly manual and requires even more manual process to keep these systems in sync with your cloud. Having a common automation framework that can manage this is indispensable--and useful even if you're not using Terraform to manage your core infrastructure.
CGamesPlay 5y ago
One of the things I like about Terraform and Pulumi and the non-vendor-specific ones is the cross-cloud features. My very basic Terraform use from the article has a machine set up on Hetzner cloud and an S3 bucket on AWS, for example.
whazor 5y ago
From my enterprise perspective Terraform is cloud agnostic, as you "only" have to once configure the CI/CD pipeline, secret management, and state management. Afterwards you are free to use any cloud you want and have all the benefits that come with Terraform (including infracost). Especially if you create templates, you can use Terraform in multiple projects quickly. However, my biggest issue with Terraform is that the promise of dependency graphs is in practice broken. Providers will break once the underlying resources are not yet there. The hack to solve this is having several Terraform directories which you run after each other. Still, I think multiple clouds is the way forward. You can negotiate prices down and use services are best suited for the projects. Especially with other players such as CloudFlare and Backblaze, which already have Terraform providers available.
encryptluks2 5y ago
I used to be in the same camp, but instead would use the aws CLI for automation. I wasn't happy with how far behind many features in Terraform was at the time. However, since then I gave Terraform another shot and dang am I glad that I did. It is fast, easy for me to get started with. I would much rather waste effort and time on Terraform which is cloud agnostic than spend a bunch of time learning something specific to AWS
weitzj 5y ago
> I'm not saying Terraform is not good, but I just think a native solution of the platform is preferable over a 3rd party tool. I would agree if you have your green-field approach and can commit to a single platform. From my current experience I use AWS, Azure some other SaaS hosted products like ElasticSearch, Instana, Opsgenie, Kubernetes, databases, Grafana, Prometheus. And with all these products you have a bunch of people in the companry which specialize in their domain and can't know all the tools in all details but have to talk to each other. So what makes terraform so special in my case is that you can streamline the interaction between multiple teams by focusing on defining well-known interfaces between those teams. The interfaces in the case of terraform would be: variables (inputs) outputs Or you can have specialized teams, which will offer terraform modules for other teams to use. So for me terraform does not have to be agnostic as this is not the point of it. The benefit of terraform is to streamline interactions (inputs,outputs) for your needs. Teams could automate their things with a python script for example, and use terraform just as a "hull" to offer a way to pass inputs,args to you python script and report back some outputs. What a Dockerfile did, was to establish a well-known interface on how to define what a container is, by giving a standard-way on how to declare a "CMD,ENTRYPOINT,PORT,etc." And terraform in that sense gives you a standard on how to define your inputs,outputs when you build,configure infrastructure,Saas, etc.
dtech 5y ago
As a software engineer, Terraform/HCL being a real declarative programming language is a big advantage of the big ball of JSON/YAML from cloudformation.
pm90 5y ago
You’re entitled to your opinion, but I want to point out that learning N different custom infra as code systems for N clouds is not really sustainable. If you’re mostly using just one cloud, it makes more sense. Terraform is cloud agnostic in that once you build a process around it… CI/CD of Infra as Code, runbooks around how to work with failures, break glass etc, you can basically use the same thing for any cloud, since all of them have terraform “providers”. Also all the major clouds (even the minor ones) have pretty strong first class support for terraform.
nickthemagicman 5y ago
>> but I just think a native solution of the platform is preferable over a 3rd party tool I had a job interview where someone asked me what I would prefer Terraform or Cloudformation for AWS. I said Cloudformation because it's managed by AWS who writes the actual software as well. And they kind of smugly said Terraform is better because it's cloud agnostic. I was thinking...have you ever USED Terraform.
- Glyptodon 5y ago
  I wouldn't consider myself super in love with terraform, but Cloudformation has been nearly 100% unpleasant experiences for me, though I will admit to not being an expert. Mostly it seems like it's harder to know your changes don't have any mistakes and will do exactly what you expect. Is there a CF equivalent to TF plan? We've also found TF seems to apply changes faster in many cases.
  - nickthemagicman 5y ago
    I agree CF kinda blows compared to real programming lang, and is probably legitimately better as an intermediate generated template than hand crafted code. Even AWS has come up with a CDK to avoid building CF and use real prog langs. I've never used it though. I just personally think that if youre going to be a part of an ecosystem, things go much more smoothly when you stay in that ecosystem as much as possible. Also Amazon is a massive company compared to hashicorp so I feel more comfortable about my infrastructures longevity with AWS tools. Not saying hashicorp is going anywhere anytime soon and if it did the open-source community would probably take over, but it eliminates that tiny tiny risk. I would probably use the AWS-CDK now instead of CF.
  - nickthemagicman 5y ago
    Im not super familiar with terraform but think change sets may compare to terraform plan? https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
desktopninja 5y ago
This is preciously my sentiment but its drowned out by my peers with cargo cult buzzword fo "terraform is cloud agnostic" :(
mitchellh 5y ago
(Creator of Terraform, Co-Founder of HashiCorp) I'm quite late to respond here, but just wanted to clarify one thing: Terraform is WORKFLOW agnostic, not TECHNOLOGY agnostic. This is a key part of our product philosophy that we make the 1st element of our Tao: https://www.hashicorp.com/tao-of-hashicorp https://www.hashicorp.com/tao-of-hashicorp I've talked about this more with more references in this tweet: https://twitter.com/mitchellh/status/1078682765963350016 https://twitter.com/mitchellh/status/1078682765963350016 I don't think we've ever claimed cloud portability through "write once run anywhere;" that isn't our marketing or sales pitch and if we ever did make that claim please let me know and I'll poke some teams to correct it. Our pitch is always to just learn one workflow/tool and use it everywhere, but you explicitly WILL rewrite cloud-specific modules/code/etc. With Terraform, the big win for folks is learning how to write and use Terraform, then knowing a fully supported official tool (to some extent) for hundreds of API-driveable systems. Instead of educating an engineer on CloudFormation, Azure ARM, etc. they learn ONE tool and ONE syntax and then adapt that to their cloud-specific knowledge. More details are in the tweet I mentioned above, but I hope that helps. Fully respect you not being a fan of Terraform, I don't mind that, I just wanted to make sure for yourself and others reading that it is clear that we also don't believe Terraform is cloud agnostic in the sense you described.
- ArtWomb 5y ago
  I'm curious to see what you think of the "hash stack" for self-hosted projects: consul, nomad, vault. Honestly, seems pretty ideal to me ;) Why not provide a cloud host tier for startups akin to CLoudflare Pages?
- bengale 5y ago
  I actually much prefer this. When things try to be technology agnostic, or too generic you end up with the lowest common denominator for features.
- Omekutio 5y ago
  I highly appreciate what Terraform does for me and the whole industry. I also think sometimes why i don't like it very much and how i would make it different. How the state is handled, including potential secrets in it, is just frustrating. Having root secrets for your whole setup exposed/unsecure is bad. The state is relativly fragile and cumbersome to clean up or fix. I also can't grasp that tf even needs a state and the cloud providers can't return the current state just fast enough. Only a lightweight cache would then be needed. And probably due to implementation details, plans show sometimes changes when there would be no changes necessary. For me its a good tradeoff to use terraform for setting up a k8s environment and then handling everything with ArgoCD. Google Connector is a very great thought: you create a k8s resource and the cloud provider executes it for you on their cloud. No terraform needed anymore at all.
bradknowles 5y ago
I’ve used CloudFormation at a previous employer. I hate, loathe, and despise the thing. YAML is not a programming language, and any attempt to turn it into a programming language is fraught with pain, woe, and suffering — at least on the part of the poor suckers who are tricked into using it. Give me a real programming language, with interfaces to the appropriate constructs necessary to do the job, via an SDK. In AWS, that means using CDK, not CloudFormation. Feel free to argue over whatever aspects of TerraForm that you don’t like, but please, for the love of ${DEITY}, please do not recommend CloudFormation as your suggested alternative.
- dragonwriter 5y ago
  > YAML is not a programming language To bw fair, while CF can be written in YAML for less visual noise, its fundamentally JSON. Also, its not a programming language, its a target-state description language. > Give me a real programming language, with interfaces to the appropriate constructs necessary to do the job, via an SDK. In AWS, that means using CDK, not CloudFormation. Technically,“CloudFormation via CDK”. You can't do “CDK, not CloudFormation” because CDK is just a tool for generating CloudFormation.

brightball 5y ago

Terraform also had the advantage of being able to pull together multiple services outside of a single provider. Want to use Cloudflare with AWS and another 3rd party provider that offers services in an AWS region? Simple with Terraform.

404mm 5y ago

Also a DevOps guy, I like Terraform from the “user” experience. It’s much more comfortable eco system to be in than AWS CF. Managing your resources is also better experience. That is until you hit an issue with resource or situation not being correctly supported by TF. CF has the vast advantage of being native and fully supporting AWS resources. Unfortunately it gets complicated (not complex) so quickly and has a strong feel of rushed MVP.

c7DJTLrn 5y ago

I seem to recall that years ago, Terraform was touted as an abstraction layer for cloud providers meaning that you could write some HCL and move between them seamlessly. A solution for vendor lock-in. Maybe that was nonsense but that's certainly not the case today.

kosolam 5y ago

If you are saying that it’s better to run native than Terraform then to me it means that Terraform is not good enough - which is also my experience from poking it. It covers all use cases on all clouds, buy only ~80% of each use case. The rest you have to figure out by yourself. Which often means diving into CloudFormation and such - so basically losing the advantage of Terraform.

Thev00d00 5y ago
I think it varies on the quality of the providers, at least in AWS I've yet to come across something missing
- shell0x 5y ago
  But why not just Cloudformation then? What advantage does Terraform provide over Cloudformation in your opinion?
  - hnlmorg 5y ago
    For one, it's closer to a proper programming language as opposed to straight up data interchange format. Sure if you write it in YAML than you can take advantage of variables but YAML's syntax for variables is pretty gross. Comparing CloudFormation to Terraform is a little like comparing HTML and CSS to Javascript (though Terraform isn't nearly as nice to code in as Javascript -- and I'm not exactly a big fan of Javascript). You can cover most use cases with plain HTML and CSS but the moment you need to get a little more intelligent with your code you get stuck.
    - alpha_squared 5y ago
      > For one, it's closer to a proper programming language as opposed to straight up data interchange format. Sure if you write it in YAML than you can take advantage of variables but YAML's syntax for variables is pretty gross. I think that's what AWS CDK[0] and Terraform's CDKTF[1] are trying to solve. Given the context of your example, I'd liken Terraform to CSS and CloudFormation to HTML; CDK/TF to Javascript. It's not a great analogy, but Terraform as is right now is just close enough to a programming language to deceive you into treating it like one. But it really isn't and those issues become glaringly clear the more you use it. [0] https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/ [1] https://learn.hashicorp.com/tutorials/terraform/cdktf https://learn.hashicorp.com/tutorials/terraform/cdktf

hnlmorg 5y ago

I'm not the biggest fan of Terraform either but it would be naive to deny that Terraform doesn't still offer a lot of advantages over CloudFormation even if you're not writing cloud agnostic code (even though I do actually agree with your point that Terraform doesn't make your infra cloud agnostic). Terraform offers far more constructs than CloudFormation and there is still a lot to be said for using the same language from describing your AWS infra as GCP, Github, any on prem infra, etc (even if the resources differ between providers requiring bespoke code for each). It's a bit like those who advocate node.js because it means the same developers can right frontend and backend code and in the same language. If you like the tooling around CloudFormation in AWS then you're better off with serverless (`sls`) or even Amazon's own CDK (https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/) over YAML-based CloudFormation stacks in my opinion. That's not to say I don't think Terraform doesn't have its warts: properties are non-guessable, IDE integration is pretty mediocre, and it's overly verbose in calling modules (so bad that sometimes the calling code has just as many lines as the module itself!) but I do still think it is the least worst tool available at the moment. And one can always use a 3rd party tools like Terragrunt if you want to fix some of the shortcomings of Terraform while still taking advantage of it's benefits (though personally I'm on the fence about whether the industry really needs yet another transpiler that compiles to code that needs to be transpiled....it's starting to feel like it's just abstractions all the way down....)

throwaway894345 5y ago
I agree with this. Terraform is definitely the least-bad tool, especially in that it integrates with so many more services than CloudFormation and has far fewer bizarre limitations than CloudFormation (e.g., you cannot pass objects in CF, and arrays can only be simulated as comma separated strings). Terraform isn’t great, but CF is awful, and even the AWS folks will point you at the CDK instead.
- devoptimist 5y ago
  Agree CF is crap. Each clouds SDK in the language the team is most familiar with is by far the best option. State can be stored in git. Any version of my infrastructure is a git checkout away. I use Go, and the documentation for the AWS SDK includes copy-paste examples Try and checkout Terraform from 6 months ago and run it? Frequently I cannot even get someone’s tutorial example written a week prior to work without edits. I checked out a year old commit in my infra repo; rebuilt an entire ECS stack deprecated 18 months ago. Just be programmers. The cloud ops scene is just reselling the same delusions as Unix grey beards and Windows server admins. It’s about making hardware do the right thing, not hand wavy semantics. Most of the people I work with just regurgitate memes. Very few actually test them for truth.

threatofrain 5y ago

What do people here think about Pulumi?

CGamesPlay 5y ago
I really like Pulumi, and have done some really interesting stateful infrastructure work using it in the past. Because you get a full programming language, you can definitely code yourself into a knot that is difficult to debug, but the saving grace for Pulumi I think is that the output of the program is a simple declarative object describing the target state. So you can almost think of Pulumi as a generator for Terraform files.
jokethrowaway 5y ago
I like the concept of using different languages instead of terraform because I consider the latter to provide pretty terrible developer experience. I don't like the idea of having a Turing complete language to do that. I would prefer things to be declarative. Honestly I would just be happy with a better terraform without yaml and better tooling for terraform. I tried to use pulumi and they didn't support something I needed, or maybe I was too dumb to understand how to do it, so I insta quit. They're also pretty pushy in selling whatever they're selling.
- deleted 5y ago
  [deleted]

d4mi3n 5y ago

I'd point out that one of the biggest advantages of Terraform isn't managing cloud infrastructure (though I certainly like it for this), but for providing a common language for integrating vendors and other 3rd parties into my own cloud infrastructure. I've worked in a couple organizations that had a lot of success managing things like cloud access security brokers, web application firewall appliances, ticketing systems, identity providers (with and without multi-IdP federation) and more. Doing this without Terraform is incredibly manual and requires even more manual process to keep these systems in sync with your cloud. Having a common automation framework that can manage this is indispensable--and useful even if you're not using Terraform to manage your core infrastructure.

CGamesPlay 5y ago

One of the things I like about Terraform and Pulumi and the non-vendor-specific ones is the cross-cloud features. My very basic Terraform use from the article has a machine set up on Hetzner cloud and an S3 bucket on AWS, for example.

whazor 5y ago

From my enterprise perspective Terraform is cloud agnostic, as you "only" have to once configure the CI/CD pipeline, secret management, and state management. Afterwards you are free to use any cloud you want and have all the benefits that come with Terraform (including infracost). Especially if you create templates, you can use Terraform in multiple projects quickly. However, my biggest issue with Terraform is that the promise of dependency graphs is in practice broken. Providers will break once the underlying resources are not yet there. The hack to solve this is having several Terraform directories which you run after each other. Still, I think multiple clouds is the way forward. You can negotiate prices down and use services are best suited for the projects. Especially with other players such as CloudFlare and Backblaze, which already have Terraform providers available.

encryptluks2 5y ago

I used to be in the same camp, but instead would use the aws CLI for automation. I wasn't happy with how far behind many features in Terraform was at the time. However, since then I gave Terraform another shot and dang am I glad that I did. It is fast, easy for me to get started with. I would much rather waste effort and time on Terraform which is cloud agnostic than spend a bunch of time learning something specific to AWS

weitzj 5y ago

> I'm not saying Terraform is not good, but I just think a native solution of the platform is preferable over a 3rd party tool. I would agree if you have your green-field approach and can commit to a single platform. From my current experience I use AWS, Azure some other SaaS hosted products like ElasticSearch, Instana, Opsgenie, Kubernetes, databases, Grafana, Prometheus. And with all these products you have a bunch of people in the companry which specialize in their domain and can't know all the tools in all details but have to talk to each other. So what makes terraform so special in my case is that you can streamline the interaction between multiple teams by focusing on defining well-known interfaces between those teams. The interfaces in the case of terraform would be: variables (inputs) outputs Or you can have specialized teams, which will offer terraform modules for other teams to use. So for me terraform does not have to be agnostic as this is not the point of it. The benefit of terraform is to streamline interactions (inputs,outputs) for your needs. Teams could automate their things with a python script for example, and use terraform just as a "hull" to offer a way to pass inputs,args to you python script and report back some outputs. What a Dockerfile did, was to establish a well-known interface on how to define what a container is, by giving a standard-way on how to declare a "CMD,ENTRYPOINT,PORT,etc." And terraform in that sense gives you a standard on how to define your inputs,outputs when you build,configure infrastructure,Saas, etc.

dtech 5y ago

As a software engineer, Terraform/HCL being a real declarative programming language is a big advantage of the big ball of JSON/YAML from cloudformation.

pm90 5y ago

You’re entitled to your opinion, but I want to point out that learning N different custom infra as code systems for N clouds is not really sustainable. If you’re mostly using just one cloud, it makes more sense. Terraform is cloud agnostic in that once you build a process around it… CI/CD of Infra as Code, runbooks around how to work with failures, break glass etc, you can basically use the same thing for any cloud, since all of them have terraform “providers”. Also all the major clouds (even the minor ones) have pretty strong first class support for terraform.

nickthemagicman 5y ago

>> but I just think a native solution of the platform is preferable over a 3rd party tool I had a job interview where someone asked me what I would prefer Terraform or Cloudformation for AWS. I said Cloudformation because it's managed by AWS who writes the actual software as well. And they kind of smugly said Terraform is better because it's cloud agnostic. I was thinking...have you ever USED Terraform.

Glyptodon 5y ago
I wouldn't consider myself super in love with terraform, but Cloudformation has been nearly 100% unpleasant experiences for me, though I will admit to not being an expert. Mostly it seems like it's harder to know your changes don't have any mistakes and will do exactly what you expect. Is there a CF equivalent to TF plan? We've also found TF seems to apply changes faster in many cases.
- nickthemagicman 5y ago
  I agree CF kinda blows compared to real programming lang, and is probably legitimately better as an intermediate generated template than hand crafted code. Even AWS has come up with a CDK to avoid building CF and use real prog langs. I've never used it though. I just personally think that if youre going to be a part of an ecosystem, things go much more smoothly when you stay in that ecosystem as much as possible. Also Amazon is a massive company compared to hashicorp so I feel more comfortable about my infrastructures longevity with AWS tools. Not saying hashicorp is going anywhere anytime soon and if it did the open-source community would probably take over, but it eliminates that tiny tiny risk. I would probably use the AWS-CDK now instead of CF.
- nickthemagicman 5y ago
  Im not super familiar with terraform but think change sets may compare to terraform plan? https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

desktopninja 5y ago

This is preciously my sentiment but its drowned out by my peers with cargo cult buzzword fo "terraform is cloud agnostic" :(

mitchellh 5y ago

(Creator of Terraform, Co-Founder of HashiCorp) I'm quite late to respond here, but just wanted to clarify one thing: Terraform is WORKFLOW agnostic, not TECHNOLOGY agnostic. This is a key part of our product philosophy that we make the 1st element of our Tao: https://www.hashicorp.com/tao-of-hashicorp https://www.hashicorp.com/tao-of-hashicorp I've talked about this more with more references in this tweet: https://twitter.com/mitchellh/status/1078682765963350016 https://twitter.com/mitchellh/status/1078682765963350016 I don't think we've ever claimed cloud portability through "write once run anywhere;" that isn't our marketing or sales pitch and if we ever did make that claim please let me know and I'll poke some teams to correct it. Our pitch is always to just learn one workflow/tool and use it everywhere, but you explicitly WILL rewrite cloud-specific modules/code/etc. With Terraform, the big win for folks is learning how to write and use Terraform, then knowing a fully supported official tool (to some extent) for hundreds of API-driveable systems. Instead of educating an engineer on CloudFormation, Azure ARM, etc. they learn ONE tool and ONE syntax and then adapt that to their cloud-specific knowledge. More details are in the tweet I mentioned above, but I hope that helps. Fully respect you not being a fan of Terraform, I don't mind that, I just wanted to make sure for yourself and others reading that it is clear that we also don't believe Terraform is cloud agnostic in the sense you described.

ArtWomb 5y ago
I'm curious to see what you think of the "hash stack" for self-hosted projects: consul, nomad, vault. Honestly, seems pretty ideal to me ;) Why not provide a cloud host tier for startups akin to CLoudflare Pages?
bengale 5y ago
I actually much prefer this. When things try to be technology agnostic, or too generic you end up with the lowest common denominator for features.
Omekutio 5y ago
I highly appreciate what Terraform does for me and the whole industry. I also think sometimes why i don't like it very much and how i would make it different. How the state is handled, including potential secrets in it, is just frustrating. Having root secrets for your whole setup exposed/unsecure is bad. The state is relativly fragile and cumbersome to clean up or fix. I also can't grasp that tf even needs a state and the cloud providers can't return the current state just fast enough. Only a lightweight cache would then be needed. And probably due to implementation details, plans show sometimes changes when there would be no changes necessary. For me its a good tradeoff to use terraform for setting up a k8s environment and then handling everything with ArgoCD. Google Connector is a very great thought: you create a k8s resource and the cloud provider executes it for you on their cloud. No terraform needed anymore at all.

bradknowles 5y ago

I’ve used CloudFormation at a previous employer. I hate, loathe, and despise the thing. YAML is not a programming language, and any attempt to turn it into a programming language is fraught with pain, woe, and suffering — at least on the part of the poor suckers who are tricked into using it. Give me a real programming language, with interfaces to the appropriate constructs necessary to do the job, via an SDK. In AWS, that means using CDK, not CloudFormation. Feel free to argue over whatever aspects of TerraForm that you don’t like, but please, for the love of ${DEITY}, please do not recommend CloudFormation as your suggested alternative.

dragonwriter 5y ago
> YAML is not a programming language To bw fair, while CF can be written in YAML for less visual noise, its fundamentally JSON. Also, its not a programming language, its a target-state description language. > Give me a real programming language, with interfaces to the appropriate constructs necessary to do the job, via an SDK. In AWS, that means using CDK, not CloudFormation. Technically,“CloudFormation via CDK”. You can't do “CDK, not CloudFormation” because CDK is just a tool for generating CloudFormation.