https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# dotnet
s
This message was deleted.
đź’ˇ 1
w
p
@millions-journalist-34868 We started out with a single file just to get started, but we have since gradually decomposed our Pulumi code in various ways
For example, we have extracted a bunch of reusable resources into class libraries to avoid duplication and repetition
But more importantly, we have made each microservice in our whole environment “own” its own infrastructure code
So we have a top level Pulumi C# project that defines a custom stack (strongly typed)
đź‘Ť 1
And each microservice has its own class library project (which also references the Pulumi libraries) that defines a custom resource for that microservice
Each microservice custom resource encapsulates all the Azure resources required by that microservice, and provides outputs for the things that might be used as inputs to other resources
So it’s all very neatly and hierarchically structured and encapsulated
Each microservice custom resource is used and configured much like any other standard resource, with the same constructor signature pattern of a name and an 
Args
object with a bunch of 
Input<T>
properties
Let me know if there’s anything more specific you’d like to know..
m
And where do you put shared resources (key vaults or app configuration for instance).m ? They are taken as input for the different microservices that need them ?
I am wondering when ( for what number of resources) do you know that it's time to separate things into multiple files, projects.
p
Funny you should mention Key Vault and App Config
Those are exactly what we call our two “global” resources
We manage those outside of Pulumi (basically manually in a separate resource group)
And we query for them by known names, from the Pulumi program, to get a reference to them
So we can use their outputs (like resource ID, vault name, etc.) as inputs to other things
As to your second question, the number of resources has never been a factor for us in the decomposition
For us it’s more about logical ownership
The logical components of our solution should own their own infrastructure, basically
đź‘Ť 1
Whether that’s a single resource or a hundred, doesn’t matter
l
@millions-journalist-34868 another criterium I use to define what goes together is the lifecycle of the resources. We create component resources bundling all resources which need to be set up together and cleaned up together. We do not care if this goes over a provider boundary. E.g. we have a microservices abstraction spanning 4 providers: Google Cloud (for IAM), Kubernetes (for Deployment & Service), Hashicorp Vault (for secrets), Datadog (for the service monitoring) I think it is clear we do not use any Helm/Kustomize/YAML stuff. We go full-stack Pulumi.
đź‘Ť 1
m
Thanks all for your answers. Unfortunately there are not many open source samples (especially for .NET with Azure provider) that demonstrate these concepts which seem very interesting.
p
2 Views
Open in Slack
PreviousNext
Powered by