3 ms·

Interesting - dynamic providers and configurations are exactly what we're doing with Terramate also. Seems like we're having a very similar approach while using

Interesting - dynamic providers and configurations are exactly what we're doing with Terramate also. Seems like we're having a very similar approach while using different tooling. Thanks for sharing the insights with me!

nikolay 4y ago
I know you can do it - but not as dynamically as I want, too. Maybe I'm not getting something, but I don't see the `for_each` or `count` equivalent in `generate_hcl` [0]. Also, stacks are predefined, not dynamic. With CDKTF, I can generate any number of stacks with one piece of code. In addition, I can define stack dependencies - let's say, my dev database stack depends on dev IAM stack - something that Terraform does not do and developers need to remember the order of `terraform apply` across stacks. [0]: https://github.com/mineiros-io/terramate/blob/main/docs/codegen/generate-hcl.md https://github.com/mineiros-io/terramate/blob/main/docs/code...
- katcipis 4y ago
  On the dynamic side of things we are working right now on adding support for dynamic block generation on generate_hcl, which should help. Regarding dependencies, did you took a look on the orchestration features on Terramate ? https://github.com/mineiros-io/terramate/blob/main/docs/orchestration.md https://github.com/mineiros-io/terramate/blob/main/docs/orch... They should be enough to let you easily define ordering and not depend on developers doing the ordering manually.
  - nikolay 4y ago
    Great news!
- mariux 4y ago
  We do not try to replace existing solutions or technologies. They all have their well known pros and cons. While working with customers we identified that even Terraforms HCL configuration requests too much knowledge from users. So we tried to come up with a tool where a team can take ownership of the Terraform part while the actually users can just write configurations (also in HCL). You can for sure achieve the same with CDKTF, there is no doubt. Terramate gives us the same orchestration features that you mentioned as you can define an order of execution between stacks. You can even enforce stacks to always run if another stack is triggered. Change Detection based on our Git Integration allows us to just run stacks that actually have changed and thus reducing wait times for very big set ups to a minimum, which makes our solution very scalable. We also currently work on easier stack management features to be able to create stacks with a single call (already available) or clone stacks for either promoting them through the environment e.g. from staging to production or to just duplicate resources easily. Those features will be used to create one-click solutions to request a new respository with a default config (as defined by the company) in less than 30 seconds + time to review (if desired) + very fast deployment. The goal here was to create a great user experience (UX) for teams that normally do not use Terraform or programming languages as GitHub is also used by other departments than engineering like marketing, hr or sales - but also allowing the team managing this solution to easily extend it to own needs. Our solution is currently based on Terraform but might even evolve to something else as we also see the bottleneck in the provider where both Terraform or CDKTF will face the same issues in the end.

nikolay 4y ago

I know you can do it - but not as dynamically as I want, too. Maybe I'm not getting something, but I don't see the `for_each` or `count` equivalent in `generate_hcl` [0]. Also, stacks are predefined, not dynamic. With CDKTF, I can generate any number of stacks with one piece of code. In addition, I can define stack dependencies - let's say, my dev database stack depends on dev IAM stack - something that Terraform does not do and developers need to remember the order of `terraform apply` across stacks. [0]: https://github.com/mineiros-io/terramate/blob/main/docs/codegen/generate-hcl.md https://github.com/mineiros-io/terramate/blob/main/docs/code...

katcipis 4y ago
On the dynamic side of things we are working right now on adding support for dynamic block generation on generate_hcl, which should help. Regarding dependencies, did you took a look on the orchestration features on Terramate ? https://github.com/mineiros-io/terramate/blob/main/docs/orchestration.md https://github.com/mineiros-io/terramate/blob/main/docs/orch... They should be enough to let you easily define ordering and not depend on developers doing the ordering manually.
- nikolay 4y ago
  Great news!
mariux 4y ago
We do not try to replace existing solutions or technologies. They all have their well known pros and cons. While working with customers we identified that even Terraforms HCL configuration requests too much knowledge from users. So we tried to come up with a tool where a team can take ownership of the Terraform part while the actually users can just write configurations (also in HCL). You can for sure achieve the same with CDKTF, there is no doubt. Terramate gives us the same orchestration features that you mentioned as you can define an order of execution between stacks. You can even enforce stacks to always run if another stack is triggered. Change Detection based on our Git Integration allows us to just run stacks that actually have changed and thus reducing wait times for very big set ups to a minimum, which makes our solution very scalable. We also currently work on easier stack management features to be able to create stacks with a single call (already available) or clone stacks for either promoting them through the environment e.g. from staging to production or to just duplicate resources easily. Those features will be used to create one-click solutions to request a new respository with a default config (as defined by the company) in less than 30 seconds + time to review (if desired) + very fast deployment. The goal here was to create a great user experience (UX) for teams that normally do not use Terraform or programming languages as GitHub is also used by other departments than engineering like marketing, hr or sales - but also allowing the team managing this solution to easily extend it to own needs. Our solution is currently based on Terraform but might even evolve to something else as we also see the bottleneck in the provider where both Terraform or CDKTF will face the same issues in the end.