5 ms·

If your only comparison is "I used to work with Heroku", Terraform might seem not great. I would argue this is a blub example, in that this person's lens does n

by _5yoy 6y ago

If your only comparison is "I used to work with Heroku", Terraform might seem not great. I would argue this is a blub example, in that this person's lens does not contain enough context or experience to be able to assess value. Terraform's value becomes clear when moving in scenarios like moving from CloudFormation to Terraform, or when trying to integrate a second cloud's resources into your infrastructure workflow. Without experience in anything other than Heroku, of course a tool designed to do many many things is going to seem complex and at times frustrating. > Iteration times are way longer than with even mobile apps. Like, “you’re liable to task-switch while waiting to see plan output” longer. I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life.

pm90 6y ago
> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Heh, same. Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provision complex infrastructure is just begging for a world of hurt. That being said. I think terraform could do better. I use terraform a lot, and yet I agree with the authors complaints that the syntax can be super confusing, is not documented very well, and the providers have their own idiosyncrasies. The last one isn't strictly an issue with terraform, its with the provider implementation. But... if terraform aims to be the Swiss army knife of infrastructure provisioning, I think criticism that its hard to standardize even within the same provider is fair.
- ciceryadam 6y ago
  > Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provision complex infrastructure is just begging for a world of hurt. It's also fun when you have to standardize something that was either created by hand in the Web UI (and has a bunch of hidden default values set), or was by some other orchestration tool, and then you have to import/recreate it in terraform. It's usually a PITA, but you'll learn a lot!
  - pm90 6y ago
    Yes! Its great to capture a bespoke configuration in code. You may already know this but there is a tool called terraformer that has limited support for doing just this: https://github.com/GoogleCloudPlatform/terraformer https://github.com/GoogleCloudPlatform/terraformer
- wgjordan 6y ago
  > Heh, same. Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provision complex infrastructure is just begging for a world of hurt. I disagree- I can't speak to OpenStack Heat (and I have no idea what you're referring to by 'cloud-provided orchestration tools' beyond these two specifically), but my own experience using CloudFormation to provision complex infrastructure is that it is in fact great for all but the most basic tasks (where any orchestration tool would just add unnecessary overhead).
  - pm90 6y ago
    > (and I have no idea what you're referring to by 'cloud-provided orchestration tools' beyond these two specifically), - AWS: cloudformation - GCP: deployment manager https://cloud.google.com/deployment-manager/docs/quickstart https://cloud.google.com/deployment-manager/docs/quickstart I imagine other clouds have similar tools (or perhaps they have converged towards more general ones like Ansible or Terraform). As for your disagreement: you're free to have your own opinion on this. But my personal experience has been that eventually converging infrastructure provisioning systems like CF have complex failure modes that make it hard to modularize and scale them up. With terraform: the cloud provider is reduced to a dumb API, and most of the issues you see can be resolved client side. Whereas when dealing with issues with cloudformation, its not something you can figure out yourself, you need to hope that the error is something that's clearly displayed to you and/or open a support tix with AWS.
    - ciceryadam 6y ago
      IMHO on AWS side: if you squint, you could also add AWS SAM among these orchestration tools
    - _5yoy 6y ago
      Azure: Azure Resource Manager templates
  - bassman9000 6y ago
    my own experience using CloudFormation to provision complex infrastructure If we're talking anecdotes, my experience is vastly different. Difficult to assess what's going to be a replacement (other than browsing the doc), replacements that cause a chain of other replacements, leaf replacement that fails due to some syntax in a SSM doc that wasn't checked at the very beginning, wasting 45 min, so everything gets rolled back, but you used Retain policies, so those ASG groups are now not managed, and still live, so you need to delete them manually. Building complex means breaking down stacks in multiple pieces, and you can only use URLs. Which can only point to S3. Which means you have to pre-upload your sources there. For which you have to build the tooling, because aws provides nothing. So not only you have to build your infrastructure: you need to build the infrastructure to build and develop your infrastructure. You want to know why a nested stack is going to replace that ASG you though it was safe? Well, you can always dive into the nested stack changeset... aaand nothing there. You can't. Maybe in the parent stack JSON. Complexity without loops? Good luck. Or lots of copy pastes, I guess. And the Conditions are just rudimentary and clunky. The Resources/Events UI is just meh with no sensible sizing for the otherwise huge columns (big names, big ARNs). Impossible to get the sorting of new events coming in right. Every refresh reshuffles the rows. And cfn L1 Support is hit-or-miss: 50% of the times it's simply not useful, because of the complexity of the infrastructure. We just get the problem echoed back to us. I'm lucky we have Enterprise, and can escalate. There would be issues we wouldn't have solved in weeks otherwise. I very much like the fact that we have a state management tool. But calling it great is an overstatement.
pqb 6y ago
> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Oh, I see I am not alone in having the same experience with the AWS CloudFormation (CF) update flow. I have started feeling "good enough" in CF after about 6-8 months to write templates from my memory (accompanied with a documentation page). The funny thing about the CF is fact, the all people I know had working flow based on searching GitHub/Gist over an example, edit, refine, deploy, push fixes, deploy, rinse & repeat. In the blogpost I have noticed mentioned Pulumi. To be honest, I have not used it yet, but I have tried AWS CDK [0]. I suppose it is AWS's go-to solution for everybody who wants to use the CloudFormation for saving deployment stages and also have programmed templates in languages of their choice (like a TypeScript or Python). It is interesting solution that I suggest investigating if you haven't done already. It supports "importing" CF templates as-is, so they can be incrementally translated to CDK. [0]: https://github.com/aws/aws-cdk https://github.com/aws/aws-cdk
- throwaway894345 6y ago
  I came to Terraform optimistically from CloudFormation, thinking it would fix many of the latter’s warts, and it sort of has, except it’s introduced as many of its own. I’m still undecided about which set of problems I prefer, but in general I’m disappointed with Terraform. Some particular things that bother me: I get the distinct impression that it’s trying to badly reinvent a programming language (with “locals” replacing variables, “variables” replacing parameters, and “modules” replacing functions, “for each” replacing loops or comprehensions, and so on). Additionally, I find myself wanting rollback support like CloudFormation has. It’s unsettling that TF makes it easy to get into a bad state. Further still, (and maybe this is just my organization’s use of Terraform), it seems the convention is to split the whole architecture up into lots of root modules, but the links between resources in these modules are basically string identifiers (e.g., ARNs in the AWS world) which will likely change if the resource gets deleted and recreated or if AWS changes their naming conventions or so on. Similarly, people seem to build these identifiers from strings instead of referencing them directly from resource attributes (I’ve seen this practice advertised in some of the AWS provider docs IIRC) which is bad for all of the same reasons that pointer arithmetic is bad. I do like that custom providers aren’t full-on lambdas that I have to deploy, unlike in the CloudFormation world, but mostly I’ve been disappointed. I wonder if Pulumi or AWS CDK is the solution I’ve been searching for, or if I should just stick to generating CloudFormation from YAML.
wgjordan 6y ago
> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Your experience must be over four years out of date, because CloudFormation has supported the ability to continue updating a rollback since February 2016 [1]. [1] https://aws.amazon.com/blogs/devops/continue-rolling-back-an-update-for-aws-cloudformation-stacks-in-the-update_rollback_failed-state/ https://aws.amazon.com/blogs/devops/continue-rolling-back-an...
- bird_monster 6y ago
  My experience is from 2019, friend.
  - wgjordan 6y ago
    Needing to contact support for this issue in 2019 only means that the user didn't know how to use the 'continue update rollback' feature properly, which was a feature added back in 2016 specifically to support the rollback-failed scenarios.
    - _5yoy 6y ago
      It's weird the frequency with which the AWS Support Reps agree the issues we find aren't those that would've been resolvable on our own, as each time we file a ticket we follow up with our reps for appropriate training and support. I understand that you like this tool, but you do not need to fight everyone suggesting it doesn't work as well as you want it to.
      - throwaway894345 6y ago
        I’ve also run into these from time to time, at an old gig where we didn’t have a support contract, and thus we just had borked stacks here and there and prayed that we would never similarly bork prod. On the other hand, we worked hard to get our CloudFormation templates to a state that we could rebuild prod from scratch fairly easily if it came down to it.

by _5yoy 6y ago

pm90 6y ago

> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Heh, same. Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provision complex infrastructure is just begging for a world of hurt. That being said. I think terraform could do better. I use terraform a lot, and yet I agree with the authors complaints that the syntax can be super confusing, is not documented very well, and the providers have their own idiosyncrasies. The last one isn't strictly an issue with terraform, its with the provider implementation. But... if terraform aims to be the Swiss army knife of infrastructure provisioning, I think criticism that its hard to standardize even within the same provider is fair.

ciceryadam 6y ago
> Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provision complex infrastructure is just begging for a world of hurt. It's also fun when you have to standardize something that was either created by hand in the Web UI (and has a bunch of hidden default values set), or was by some other orchestration tool, and then you have to import/recreate it in terraform. It's usually a PITA, but you'll learn a lot!
- pm90 6y ago
  Yes! Its great to capture a bespoke configuration in code. You may already know this but there is a tool called terraformer that has limited support for doing just this: https://github.com/GoogleCloudPlatform/terraformer https://github.com/GoogleCloudPlatform/terraformer
wgjordan 6y ago
> Heh, same. Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provision complex infrastructure is just begging for a world of hurt. I disagree- I can't speak to OpenStack Heat (and I have no idea what you're referring to by 'cloud-provided orchestration tools' beyond these two specifically), but my own experience using CloudFormation to provision complex infrastructure is that it is in fact great for all but the most basic tasks (where any orchestration tool would just add unnecessary overhead).
- pm90 6y ago
  > (and I have no idea what you're referring to by 'cloud-provided orchestration tools' beyond these two specifically), - AWS: cloudformation - GCP: deployment manager https://cloud.google.com/deployment-manager/docs/quickstart https://cloud.google.com/deployment-manager/docs/quickstart I imagine other clouds have similar tools (or perhaps they have converged towards more general ones like Ansible or Terraform). As for your disagreement: you're free to have your own opinion on this. But my personal experience has been that eventually converging infrastructure provisioning systems like CF have complex failure modes that make it hard to modularize and scale them up. With terraform: the cloud provider is reduced to a dumb API, and most of the issues you see can be resolved client side. Whereas when dealing with issues with cloudformation, its not something you can figure out yourself, you need to hope that the error is something that's clearly displayed to you and/or open a support tix with AWS.
  - ciceryadam 6y ago
    IMHO on AWS side: if you squint, you could also add AWS SAM among these orchestration tools
  - _5yoy 6y ago
    Azure: Azure Resource Manager templates
- bassman9000 6y ago
  my own experience using CloudFormation to provision complex infrastructure If we're talking anecdotes, my experience is vastly different. Difficult to assess what's going to be a replacement (other than browsing the doc), replacements that cause a chain of other replacements, leaf replacement that fails due to some syntax in a SSM doc that wasn't checked at the very beginning, wasting 45 min, so everything gets rolled back, but you used Retain policies, so those ASG groups are now not managed, and still live, so you need to delete them manually. Building complex means breaking down stacks in multiple pieces, and you can only use URLs. Which can only point to S3. Which means you have to pre-upload your sources there. For which you have to build the tooling, because aws provides nothing. So not only you have to build your infrastructure: you need to build the infrastructure to build and develop your infrastructure. You want to know why a nested stack is going to replace that ASG you though it was safe? Well, you can always dive into the nested stack changeset... aaand nothing there. You can't. Maybe in the parent stack JSON. Complexity without loops? Good luck. Or lots of copy pastes, I guess. And the Conditions are just rudimentary and clunky. The Resources/Events UI is just meh with no sensible sizing for the otherwise huge columns (big names, big ARNs). Impossible to get the sorting of new events coming in right. Every refresh reshuffles the rows. And cfn L1 Support is hit-or-miss: 50% of the times it's simply not useful, because of the complexity of the infrastructure. We just get the problem echoed back to us. I'm lucky we have Enterprise, and can escalate. There would be issues we wouldn't have solved in weeks otherwise. I very much like the fact that we have a state management tool. But calling it great is an overstatement.

pqb 6y ago

> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Oh, I see I am not alone in having the same experience with the AWS CloudFormation (CF) update flow. I have started feeling "good enough" in CF after about 6-8 months to write templates from my memory (accompanied with a documentation page). The funny thing about the CF is fact, the all people I know had working flow based on searching GitHub/Gist over an example, edit, refine, deploy, push fixes, deploy, rinse & repeat. In the blogpost I have noticed mentioned Pulumi. To be honest, I have not used it yet, but I have tried AWS CDK [0]. I suppose it is AWS's go-to solution for everybody who wants to use the CloudFormation for saving deployment stages and also have programmed templates in languages of their choice (like a TypeScript or Python). It is interesting solution that I suggest investigating if you haven't done already. It supports "importing" CF templates as-is, so they can be incrementally translated to CDK. [0]: https://github.com/aws/aws-cdk https://github.com/aws/aws-cdk

throwaway894345 6y ago
I came to Terraform optimistically from CloudFormation, thinking it would fix many of the latter’s warts, and it sort of has, except it’s introduced as many of its own. I’m still undecided about which set of problems I prefer, but in general I’m disappointed with Terraform. Some particular things that bother me: I get the distinct impression that it’s trying to badly reinvent a programming language (with “locals” replacing variables, “variables” replacing parameters, and “modules” replacing functions, “for each” replacing loops or comprehensions, and so on). Additionally, I find myself wanting rollback support like CloudFormation has. It’s unsettling that TF makes it easy to get into a bad state. Further still, (and maybe this is just my organization’s use of Terraform), it seems the convention is to split the whole architecture up into lots of root modules, but the links between resources in these modules are basically string identifiers (e.g., ARNs in the AWS world) which will likely change if the resource gets deleted and recreated or if AWS changes their naming conventions or so on. Similarly, people seem to build these identifiers from strings instead of referencing them directly from resource attributes (I’ve seen this practice advertised in some of the AWS provider docs IIRC) which is bad for all of the same reasons that pointer arithmetic is bad. I do like that custom providers aren’t full-on lambdas that I have to deploy, unlike in the CloudFormation world, but mostly I’ve been disappointed. I wonder if Pulumi or AWS CDK is the solution I’ve been searching for, or if I should just stick to generating CloudFormation from YAML.

wgjordan 6y ago

> I'm over here laughing in my "over an hour of CloudFormation only to have a run fail, and then a rollback fail, and have to contact AWS support" life. Your experience must be over four years out of date, because CloudFormation has supported the ability to continue updating a rollback since February 2016 [1]. [1] https://aws.amazon.com/blogs/devops/continue-rolling-back-an-update-for-aws-cloudformation-stacks-in-the-update_rollback_failed-state/ https://aws.amazon.com/blogs/devops/continue-rolling-back-an...

bird_monster 6y ago
My experience is from 2019, friend.
- wgjordan 6y ago
  Needing to contact support for this issue in 2019 only means that the user didn't know how to use the 'continue update rollback' feature properly, which was a feature added back in 2016 specifically to support the rollback-failed scenarios.
  - _5yoy 6y ago
    It's weird the frequency with which the AWS Support Reps agree the issues we find aren't those that would've been resolvable on our own, as each time we file a ticket we follow up with our reps for appropriate training and support. I understand that you like this tool, but you do not need to fight everyone suggesting it doesn't work as well as you want it to.
    - throwaway894345 6y ago
      I’ve also run into these from time to time, at an old gig where we didn’t have a support contract, and thus we just had borked stacks here and there and prayed that we would never similarly bork prod. On the other hand, we worked hard to get our CloudFormation templates to a state that we could rebuild prod from scratch fairly easily if it came down to it.