The opinionation is the biggest advantage of an approach like this over a more generic tool like terraform
Though you can create Terraform modules to get your own opinionation so it’s not like you’re missing out just because you use terraform
oh wow, the app team must have liked that
I’m working on the same now in Terraform for another client
The goal is for an application to just need to include a module or two that cover all the cloud patterns we’re following
And pass environment into them, with other inputs available to cover all the use cases the module supports
super opinionated, like a module for apigw+lambda that just needs an application name, FQDN and env, and it handles everything else including networking components, policies, etc
that sound interesting. I was trying to learn how to do things like that with CDK. During that time I never came across j2 in materials I was reading.
Cdk is like a whole 'nother approach to iac
More like pulumi, you get a “real” programming language and API calls the library converts into … Other API calls 
Personally I would rather be closer to the native API that creates the resources
But that’s how terraform works too. Under the hood it’s largely using cloud formation for aws
You can tell if you look at CloudFormation documentation and compare to the Terraform provider for the same resource
The parameters in the Terraform provider will usually match one to one including the structure of maps/lists/objects
Some terraform providers are ridiculous and actually need the exact same JSON object that the underlying API uses :man-facepalming:
Dynatrace is one like that, basically worthless abstraction to use TF for it
Funny you say that I was looking at the TF documentation for Dynatrace the other day.
Like not useless as and it won’t do the thing but it doesn’t actually do anything for you
Other than I guess you can have your dashboards in your Terraform state
I don’t recommend bothering to build dashboards via terraform or the dt API
