Please don’t copy the terrible overlay setup in Kubernetes YAML for infrastructure. I don’t see what this offers above the standard Terraform command/functionality.
I don’t see a future in defining infrastructure in configuration languages with templating bolted on top of them. CDK for Terraform has had solutions for almost all of the problems described in the related talk (besides the existing code problem) for over a year now, and honestly, it is a huge improvement on managing infrastructure from my experience. Stacks have been in the tool for over two years now, code re-usability is amazing (writing a wrapper to get a nicer interface for a single resource is very viable, and usually great with CDKTF, while the terraform-native solution of modules is annoying enough to handle that you don’t use it for less than a dozen resources), and you don’t have to deal with any templating annoyances, since you have a proper programming language in your disposal.
Having a programming language to help you with abstraction is great, since there’s been literal decades of work put into improving the abstraction capabilities of languages. Configuration languages have received no such work, since usually configuration needs to be very explicit. But now configuring infrastructure is essentially programming, and I think the language for such work should be a programming language, not a configuration one.
But we figured all it does is just generate JSON and dump it into a cdk.tf.json file, so we chose to get rid of it to improve performance. CDK uses jsii to transpile your Python code to JS, then spins up Node to run it, synths your code, and then comes back. This took ~10s vs. the few ms Stacks takes, so we stopped using it.
You can see Stacks as an opinionated CDKTF, that, when used with the proper file structure, leads to an amazing dev experience (we only push resources to git, everything else is taken care of).
Quick correction - CDK uses jsii to call JS code from whatever other language, instead of trying to convert it to JS, which would be way harder. You don’t even need to use their CLI to generate the JSON - just running the file with a few special environment variables works.
While I do agree that it is slower, I think the benefits you gain from having a full-blown programming language are well worth it. You gain a fair bit of productivity because you need less “devops” people as more normal developers can understand and work on it, and the additional safeguards that you can gain by using proper type systems (e.g. passing a whole VPC object instead of it’s ID, AWS CDK has this built-in, but Terraform doesn’t because the underlying Terraform type system doesn’t have such information, but you can build it yourself). You gain a lot of extra capabilities as well, since you have a programming language under you - you can create new stacks programmatically, create truly re-usable templates, etc. One of the nicest things I’ve done with CDKTF was in essence a project infrastructure skeleton - for each project, a bunch of infrastructure managed with CDKTF would be spun up, managed out of decentralized repositories, but with all of the truly important code sitting in the same project generator repo - since it’s just a library that you can install, each project would just import it, and use the main skeleton construct, and other helper constructs to build out their own infrastructure. This was previously tried by templating plain Terraform files with jinja2, but was very brittle and hard to update in comparison.
But we do have a full-blown programming language, Stacks is written in Python.
If you mean we could’ve used CDK for all our infrastructure code, that’s definitely possible if starting from scratch, but we had >5100 files to migrate from HCL to CDK.
With Stacks we maintained the same “contract” with both our users and Terraform, so we didn’t have to change a thing.
Our devs don’t have to learn a thing and Terraform state doesn’t freak out.
We just made our code cleaner and more robust, DRY and free of drift.
Yeah, that’s why I said “almost all problems”. I do understand the difficulty of migrating from HCL to CDK, done it myself a couple times with relatively small projects, it’s definitely a fair bit of work every time. I’ve seen that the last update has worked quite a lot on that, so it might be quicker to do now, but it’s still not ideal. But I think if you’re working on a new project, or you don’t have that much infrastructure already (I’d say less than a ~100 resources), going with CDK is a lot better choice than Stacks.
Might be. Terragrunt is also a good choice if starting from scratch.
All these tools are very good if starting from zero, the problem with Terraform is when you want to migrate one to another. This is, mostly, because of Terraform’s state.
Migrating state is definitely possible, even if quite manual and somewhat annoying in CDKTF. IMO there are opportunities to mostly automate the state migration, and I hope tools for that will be soon built in CDKTF.
Mostly because of the code injection capabilities.
We inject >1200 AWS providers (accounts * regions) by default.
Stacks also declares variables for you, it injects state backend for all stacks’ layers…
It gives us a level of flexibility no other tool in the space does.
Also, we already had tons of Terraform deployments without Terragrunt so moving to it was a huge effort we didn’t want to make, so we wrote Stacks which is backwards compatible (from Terraform’s POV, nothing changed).
Please don’t copy the terrible overlay setup in Kubernetes YAML for infrastructure. I don’t see what this offers above the standard Terraform command/functionality.
Hi, author here, I suggest you check out my talk at SREcon where I explain the problems it solves.
Cool, I will check it out.
I don’t see a future in defining infrastructure in configuration languages with templating bolted on top of them. CDK for Terraform has had solutions for almost all of the problems described in the related talk (besides the existing code problem) for over a year now, and honestly, it is a huge improvement on managing infrastructure from my experience. Stacks have been in the tool for over two years now, code re-usability is amazing (writing a wrapper to get a nicer interface for a single resource is very viable, and usually great with CDKTF, while the terraform-native solution of modules is annoying enough to handle that you don’t use it for less than a dozen resources), and you don’t have to deal with any templating annoyances, since you have a proper programming language in your disposal.
Having a programming language to help you with abstraction is great, since there’s been literal decades of work put into improving the abstraction capabilities of languages. Configuration languages have received no such work, since usually configuration needs to be very explicit. But now configuring infrastructure is essentially programming, and I think the language for such work should be a programming language, not a configuration one.
Hi, author here, we used to use CDKTF actually!
But we figured all it does is just generate JSON and dump it into a
cdk.tf.jsonfile, so we chose to get rid of it to improve performance. CDK usesjsiito transpile your Python code to JS, then spins up Node to run it, synths your code, and then comes back. This took ~10s vs. the few ms Stacks takes, so we stopped using it.You can see Stacks as an opinionated CDKTF, that, when used with the proper file structure, leads to an amazing dev experience (we only push resources to git, everything else is taken care of).
Quick correction - CDK uses jsii to call JS code from whatever other language, instead of trying to convert it to JS, which would be way harder. You don’t even need to use their CLI to generate the JSON - just running the file with a few special environment variables works.
While I do agree that it is slower, I think the benefits you gain from having a full-blown programming language are well worth it. You gain a fair bit of productivity because you need less “devops” people as more normal developers can understand and work on it, and the additional safeguards that you can gain by using proper type systems (e.g. passing a whole VPC object instead of it’s ID, AWS CDK has this built-in, but Terraform doesn’t because the underlying Terraform type system doesn’t have such information, but you can build it yourself). You gain a lot of extra capabilities as well, since you have a programming language under you - you can create new stacks programmatically, create truly re-usable templates, etc. One of the nicest things I’ve done with CDKTF was in essence a project infrastructure skeleton - for each project, a bunch of infrastructure managed with CDKTF would be spun up, managed out of decentralized repositories, but with all of the truly important code sitting in the same project generator repo - since it’s just a library that you can install, each project would just import it, and use the main skeleton construct, and other helper constructs to build out their own infrastructure. This was previously tried by templating plain Terraform files with jinja2, but was very brittle and hard to update in comparison.
But we do have a full-blown programming language, Stacks is written in Python.
If you mean we could’ve used CDK for all our infrastructure code, that’s definitely possible if starting from scratch, but we had >5100 files to migrate from HCL to CDK.
With Stacks we maintained the same “contract” with both our users and Terraform, so we didn’t have to change a thing. Our devs don’t have to learn a thing and Terraform state doesn’t freak out. We just made our code cleaner and more robust, DRY and free of drift.
Yeah, that’s why I said “almost all problems”. I do understand the difficulty of migrating from HCL to CDK, done it myself a couple times with relatively small projects, it’s definitely a fair bit of work every time. I’ve seen that the last update has worked quite a lot on that, so it might be quicker to do now, but it’s still not ideal. But I think if you’re working on a new project, or you don’t have that much infrastructure already (I’d say less than a ~100 resources), going with CDK is a lot better choice than Stacks.
Might be. Terragrunt is also a good choice if starting from scratch.
All these tools are very good if starting from zero, the problem with Terraform is when you want to migrate one to another. This is, mostly, because of Terraform’s state.
Migrating state is definitely possible, even if quite manual and somewhat annoying in CDKTF. IMO there are opportunities to mostly automate the state migration, and I hope tools for that will be soon built in CDKTF.
Appears similar to Terraspace but at the moment I don’t see anything that couldn’t be done with Terraform modules.
I’m curious why Terragrunt wasn’t good enough. It also has templating capabilities and has been around for a long time now.
Mostly because of the code injection capabilities.
We inject >1200 AWS providers (
accounts * regions) by default. Stacks also declares variables for you, it injects state backend for all stacks’ layers… It gives us a level of flexibility no other tool in the space does.Also, we already had tons of Terraform deployments without Terragrunt so moving to it was a huge effort we didn’t want to make, so we wrote Stacks which is backwards compatible (from Terraform’s POV, nothing changed).
I mention Terragrunt at 8:00.