4 ms·

> Heh, same. Any of the cloud-provided orchestration tools (Cloudformation, Openstack Heat etc.) are great only for the most basic tasks; using them to provisio

> 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.
- pugz 6y ago
  I mostly agree with you, but on this one: > Difficult to assess what's going to be a replacement (other than browsing the doc) Do you know of any better solution than docs? Or better implementations of docs? I struggle to imagine how they could handle this better - but I've been using CF for so long that my imagination is limited.
  - bassman9000 6y ago
    I'd be happy if they just showed: - the nested stack elements that are going to change, not only the parent ones - the logical members/fields that prompt the change from the changeset window. All this info they have, and should be trivial to show, which tells me they either don't use their own tooling (no dogfooding), or they have internal, better diagnostic tools not exposed to customers.

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.

pugz 6y ago
I mostly agree with you, but on this one: > Difficult to assess what's going to be a replacement (other than browsing the doc) Do you know of any better solution than docs? Or better implementations of docs? I struggle to imagine how they could handle this better - but I've been using CF for so long that my imagination is limited.
- bassman9000 6y ago
  I'd be happy if they just showed: - the nested stack elements that are going to change, not only the parent ones - the logical members/fields that prompt the change from the changeset window. All this info they have, and should be trivial to show, which tells me they either don't use their own tooling (no dogfooding), or they have internal, better diagnostic tools not exposed to customers.