This message was deleted.

Hey Kevin! At Nullstone we follow this same pattern. We use TF to provision infrastructure and containers as our unit of deployment. Once we had the initial automation in place for launching a full environment, adding ephemeral or preview environments followed the same pattern. If you want to chat about this, I don’t mind sharing our experiences and learnings. I sent you a DM to connect as well.

hey kevin! im not sure if you guys have fully decided on terraform but ive worked with both and i think pulumi is a better choice for IAC 🙂 why? terraform forces you to use their domain-specific language = hashicorp config language (HCL) whereas you can write IAC for pulumi via any familiar general purpose languages (eg Python, Typescript, Jayascript, Java, etc). for our infrastructure and platform teams we found it much easier for them to write IAC in the same language they use for other development pulumi also offers better test support eg unit, property and integration tests + secrets management out of the box 🙂 this is my opinion having worked with platform teams using both

So we have bunch of private terraform module where we baked in some of our business logic and we use terragrunt on top of it to reuse these. Does pulumi have something like this? Would you recommend moving from tf to pulumi? @sabina

I have not looked at pulumi for IAC, but I can see how this would simplify the code side, however infrastructure changes and application delivery is still separated in some way. Also terraform has created terraform-cdk to compete against pulumi and aws CDK while being able to re-use modules and providers.

One thing to keep in mind w/respect to Pulumi vs Terraform is that TF is much more widely used so finding engineers who know how to use it is much easier

Just my two cents in this thread - if you are looking to have the IaC on the same language as your apps, you might want to consider using CDK for Terraform. Is quite powerful and easier for developers to adopt. https://developer.hashicorp.com/terraform/cdktf

We have found that creating a seperation of concerns (deploy is different than Infra provisioning) builds a substantially more robust platform experience.

@Andrew Fong I would agree with that, we separated the two as well

How do you handle passing infrastructure configuration into application deployment. The best example I have of this GCP service account information needed at application deployment time.

Since we provision the infra using TF, the infra configuration needed is returned as TF module outputs We then store those outputs for the “workspace” When code deployments are triggered, we can then take those outputs and pass them into the deployment

make sense, I current do the same, just not in a very standard/opinionated way yet.

we are building a deployment product that handles exactly this problem

make sense. I came across the "platform" work group under the CNCF Application Delivery TAG that has a very similar charter: https://github.com/cncf/tag-app-delivery/tree/main/platforms-wg/charter

happy to talk more about what we’re building www.prodvana.io

yup just looking at your solution now 🙂

Thing of us as declarative configuration that has a workflow that sits on a convergence engine