Hey guys, we're currently building a prototype deployment with pulumi for microservice. We recognize 3 general parts in our cloud deployment:
1. General infrastructure (VPC, subnets, EKS cluster, etc)
2. Per service: required infrastructure/resources (S3 bucket, Database, ECR repos, etc)
3. Per service: deployment resources (pipelines, kubernetes deployments, services, ingress etc)
We are wondering what is the best practice with regard to separating these parts over different pulumi projects. We're pretty sure it is a good idea to have a separate project for 1 (general infra). However, we are wondering where 2 and 3 should be split up in two pulumi projects, where number 3 will update automatically in a deployment pipeline, and 2 won't, or whether we should make it 1 project, reducing the amount of pulumi projects to maintain. Any suggestions or best practices?
07/19/2022, 2:56 PM
this is a very nebulous concept, because it varies between orgs. In your situation, I would minimise the size of projects where possible.
Think about the rate of change that you have between different things. I’d use component resources to group things together where needed