2 ms·

> It's not the recommended devops tool for any cloud provider. The Deployment manager templates under CFT for GCP specifically state they recommend the Terrafo

> It's not the recommended devops tool for any cloud provider. The Deployment manager templates under CFT for GCP specifically state they recommend the Terraform modules. It is also the first provider listed under Oracle cloud. Pretty much every cloud list it as the preferred DevOps tool. > Random people writing code doesn't make that code valuable or of any sound quality. They have employees whose jobs it is to improve and add features to their software. It doesn't mean that it isn't. You act like only employees can write valuable code with sound quality, when in fact the opposite could be true and often is. > Clouds are and should be exactly as simple or complex as their customers request. Clouds should not be built around opinionated forum posts. The concept of a cloud provider is not anything unique. Hence why there are so many of them implementing their own API. Cloud providers budgets are heavily skewed to marketing, because if everyone could get the rates available through OVH, Hetzner, etc while still getting the same features through their own 3+node zero-config cluster then no one would pay the outrageous prices of AWS, Azure, etc.

void_mint 5y ago
> The Deployment manager templates under CFT for GCP specifically state they recommend the Terraform modules. So, "It's listed as the recommended tool for GCP" means "it's the recommended tool for any cloud provider" ??????????????? Both Azure and AWS maintain and promote their own resource provisioning systems. Also you just totally ignored the GCP Deployment manager templates listed on the same page. Meaning, Terraform is _an option_. > It doesn't mean that it isn't. You act like only employees can write valuable code with sound quality, when in fact the opposite could be true and often is. The average quality of an internal employee will be higher than the average quality of a random person submitting PRs, because you'd fire your employees if they weren't. This is common sense. > The concept of a cloud provider is not anything unique. Hence why there are so many of them implementing their own API. Cloud providers budgets are heavily skewed to marketing, because if everyone could get the rates available through OVH, Hetzner, etc while still getting the same features through their own 3+node zero-config cluster then no one would pay the outrageous prices of AWS, Azure, etc. The concept of a paid service isn't unique. Adding features to a paid service to increase users' engagement and/or acceptable price is normal and good. Again, common sense.

void_mint 5y ago

> The Deployment manager templates under CFT for GCP specifically state they recommend the Terraform modules. So, "It's listed as the recommended tool for GCP" means "it's the recommended tool for any cloud provider" ??????????????? Both Azure and AWS maintain and promote their own resource provisioning systems. Also you just totally ignored the GCP Deployment manager templates listed on the same page. Meaning, Terraform is _an option_. > It doesn't mean that it isn't. You act like only employees can write valuable code with sound quality, when in fact the opposite could be true and often is. The average quality of an internal employee will be higher than the average quality of a random person submitting PRs, because you'd fire your employees if they weren't. This is common sense. > The concept of a cloud provider is not anything unique. Hence why there are so many of them implementing their own API. Cloud providers budgets are heavily skewed to marketing, because if everyone could get the rates available through OVH, Hetzner, etc while still getting the same features through their own 3+node zero-config cluster then no one would pay the outrageous prices of AWS, Azure, etc. The concept of a paid service isn't unique. Adding features to a paid service to increase users' engagement and/or acceptable price is normal and good. Again, common sense.