This project is archived, but the idea of Terrastack lives on in the Terraform CDK.

Terrastack enables you to keep using Terraform as engine, while defining your resources in actual programming languages such as Typescript, Python, Java or C# - with more to come (perhaps Ruby?).

This is made possible by the Cloud Development Kit (CDK) and jsii for generating the polyglot libraries. While the major use-case for the CDK is generating Cloudformation configuration as YAML, it's capable of generating pretty much any configuration.

Applying it Terraform was inspired by the release of cdk8s, which also paved the way for rapid progress towards a working Terraform version.

Terrastack makes use of the following things:

• Terraform provider schemas - See an example
• Besides from HCL, Terraform understands JSON as well
• Code generator to transform the provider schema in proper Typescript classes
• A custom Stack and ResourceObject class to interface with the CDK

With that, we're able to generate packages for any given Terraform provider in the following languages:

• Typescript (tested)
• Python (tested)
• C# (yet to test)
• Java (yet to test)

In the current state, this is mostly a prototype. It demonstrates that it's possible and quite useful to leverage the CDK. Interfaces and Apis will certainly change and there are still some problems to solve.

However, it's possible to generate full bindings for a given Terraform provider (tested with AWS and Google Cloud so far).

• Generate Terraform constructs (Level 1 in CDK speak) from the Terraform JSON schema
• Build Terraform stacks out of those resources in Typescript, Python, Java or C#
• Reference resources within a stack
• Synthesize valid Terraform JSON which is plannable and applyable
• Leverage existing CDK packages which are not bound to cloudformation directly, such as global tagging or an IAM Policy builder
• Improve developer experience
• Multiple Stacks with individual state
• Input Variables
• Outputs
• Remote State
• Pregenerate schemas for Terraform Providers
• Built-in functions
• Generic resource features such as lifecycles and dependencies
• Modules
• Dynamic blocks
• count / for each
• Assets
• Converting HCL to Terrastack resources
• Publish easy consumable packages for providers and open source modules
• Better Terraform integration
• Unit / Integration test examples
• More examples

• Sebastian Korfmann - Cloud Solutions Architect based in Hamburg. Available for hire starting from Q2/2020