Azure Infrastructure Templates That Work With AI: My Experience Building a Reusable Pulumi Solution
The Problem I Was Trying to Solve
I kept finding myself copy-pasting infrastructure code between projects. Every new microservice meant recreating the same Azure resources – App Services, Function Apps, Storage Accounts, SQL databases. And then connecting them all together, managing secrets, keeping naming consistent… it was getting old fast.
I wanted something where I could just tell an AI “create another service like App1 but call it OrderService” and have it actually work. Not just generate code that looks right, but code that follows the same patterns and integrates properly with shared resources.
So I built this template. It’s a reusable Azure infrastructure setup using Pulumi and C#, designed to work well with AI code generation.
GitHub Repository: https://github.com/Shaieb524/pulumi-azure-microservices-solution
How It’s Structured
The whole thing is built around this idea: one shared infrastructure project, plus individual projects for each microservice. Everything connects through Pulumi ESC (their environment/secrets management thing).
SharedResources/ # SQL Server, API Gateway, Container Registry App1/ # Template microservice App2/ # Another template microservice
Each project is its own C# Pulumi project, but they all share configuration through the same Pulumi environment. So your SQL connection strings, Docker registry credentials, all that stuff gets set once in SharedResources and everyone else can use it.
The architecture looks like this:
- SharedResources: SQL Server, API Management, Container Registry, Application Insights
- Each App: App Service, Function App, Storage Account, Event Grid Topic
Everything dockerized, everything monitored, everything connected.
The Configuration Approach
Here’s what I think makes this work well with AI – the YAML configuration files look exactly like the JSON config files developers already know. Instead of weird infrastructure syntax, you get this:
App1Infrastructure:
ResourcesNames:
ResourceGroupName: app1-rg
App1ApiAppServiceName: app1-apis
App1FnAppName: app1-functions
App1ApiAppSettings:
HealthCheck: /health
AllowedHosts: "*"
Common:
ApiKey: "app1-api-key"
TimeoutInMinutes: 30
It’s structured like appsettings.json, so AI models understand it better. When you ask AI to create a new service, it can read the YAML and figure out what resources to create and how to name them.
The File Structure That Works
Every project follows the same pattern:
App1/
├── stack/ # Pulumi infrastructure code
│ ├── App1Stack.cs
│ ├── App1Stack.App1ApiAppService.cs
│ ├── App1Stack.App1FunctionApp.cs
│ ├── App1Stack.App1StorageAccount.cs
│ └── App1Stack.App1EventsEventGrid.cs
├── helpers/ # Configuration classes
│ ├── App1DeploymentConfigs.cs
│ └── App1SecretAccess.cs
└── pre-deploy-scripts/ # PowerShell setup scripts
└── add-secrets.ps1
The key insight here is consistency. Every resource type gets its own partial class file. Every project has the same folder structure. AI can pattern match on this and generate new services that follow the same conventions.
How to Actually Use This
Getting started takes 7 steps. I automated most of it with PowerShell scripts:
1. Create the Pulumi project In Pulumi Cloud: Source = Pulumi, Cloud = Azure, Language = C#, Name = something like “proj1-client1”
2. Set up your environment config Edit client-env-configs.txt with your org details:
PulumiOrganization=YourOrg PulumiProject=proj1-client1 PulumiEnv=dev ClientName=Client1 Location=UAENorth
3. Run the ESC setup script
cd SharedResources/pre-deploy-scripts .\setup-pulumi-esc.ps1
4. Configure secrets
cd SharedResources .\pre-deploy-scripts\add-client1-secrets.ps1
5. Deploy shared infrastructure
pulumi stack init your-org/client1-dev pulumi up
6. Update ESC with deployment outputs
cd SharedResources/post-deploy-scripts .\update-sql-esc.ps1 .\update-docker-esc.ps1 .\update-apim-esc.ps1
7. Deploy each microservice
cd App1 .\pre-deploy-scripts\add-secrets.ps1 pulumi stack init your-org/client1-dev pulumi up
The post-deploy scripts are important – they take outputs from your infrastructure deployment (like SQL server names, container registry credentials) and store them in Pulumi ESC so other projects can use them.
The AI Integration Part
Here’s where it gets interesting. Once you have this structure, you can create new microservices by just asking AI:
"Now create the full stack of App2 following the exact same template of App1 but using the configs from yamls in App2. Follow the exact same structure of App1. For example folders should be helpers, stack and pre-deploy-scripts and the stack class should be App2Stack instead of App1Stack etc. You can define what resources you should create by checking the 'ResourcesNames' in the pulumi.client1-dev.yaml in App2 project"
The AI will generate all the C# code, PowerShell scripts, and configuration following the same patterns. It works because:
- The structure is predictable – same folders, same naming conventions
- The YAML config tells it exactly what resources to create
- The helper classes handle configuration parsing consistently
- The connection to SharedResources happens automatically through ESC
I’ve tested this with Claude and GPT-4, and it consistently generates working code that deploys successfully.
What You Actually Get
SharedResources gives you:
- SQL Server with databases (configurable list)
- Container Registry with admin access
- API Management with monitoring
- All the shared configuration and secrets
Each App template gives you:
- App Service for your API (containerized)
- Function App for background processing
- Storage Account for app-specific data
- Event Grid Topic for events
- Application Insights for monitoring
Everything is connected. Your apps automatically get connection strings to the shared SQL server, credentials for the container registry, and monitoring setup.
Why This Works
The combination of Pulumi + PowerShell + AI creates something that’s more than the sum of its parts:
- Pulumi gives you proper infrastructure as code with type safety
- PowerShell handles all the setup and glue between components
- AI generates implementation following proven patterns
Instead of learning Pulumi syntax, you describe what you want and AI writes the code. Instead of manually wiring up shared resources, the scripts handle it automatically.
The template structure makes AI code generation reliable. When everything follows the same pattern, AI can confidently generate code that works.
The Multiplier Effect: Frameworks + Scripts + AI
Here’s what I didn’t expect when I started this – the productivity gain isn’t just additive, it’s multiplicative.
Before this setup, creating a new microservice meant:
- 2-3 hours writing Pulumi infrastructure code
- 30 minutes configuring secrets and connection strings
- 20 minutes setting up monitoring and logging
- 15 minutes debugging naming conflicts or missing dependencies
- Another hour testing and fixing issues
Total: Half a day minimum, often more.
With this template:
- 2 minutes writing the YAML configuration
- 1 minute giving AI the prompt
- 5 minutes reviewing and adjusting the generated code
- 3 minutes running the deployment scripts
Total: About 10 minutes, and it works the first time.
That’s not a 3x improvement, it’s a 20x improvement. The frameworks give you the foundation, the scripts handle the automation, and AI eliminates the manual coding. Each piece makes the others more powerful.
The real game changer is reliability. Before, I’d spend time debugging typos, missing configurations, or forgetting to wire up shared resources. Now the AI follows the exact same patterns every time, and the scripts ensure everything is connected properly.
It’s like having a senior infrastructure engineer who never makes mistakes and works at AI speed.
What I Learned
Building this taught me that the key to good AI integration isn’t just clean code – it’s predictable patterns. The more consistent your structure, the better AI gets at extending it.
The YAML configuration approach was a game changer. Making infrastructure config look like application config means developers immediately understand it, and AI models have tons of training data on JSON/YAML structures.
The automation scripts are critical. Without them, you’re back to manual copy-paste hell. With them, deploying a new microservice is just configuration + AI prompt + a few commands.
Try It Yourself
The template is designed to evolve. Start with the basic structure, then extend it as you need more Azure resources or different configurations.
Get the code: https://github.com/Shaieb524/pulumi-azure-microservices-solution
The whole point is that once you have this foundation, adding new services becomes trivial. Define your resource names in YAML, ask AI to generate the code, run the deployment scripts, and you’re done.
Infrastructure deployment shouldn’t be the hard part of building microservices. This template tries to make it the easy part.
