Azure Greenfield Infrastructure
You know what's rare in our industry? Getting to build something completely from scratch. No legacy code to work around, no "well, that's how it's always been done" constraints. Just you, a blank canvas...
The Blank Canvas
You know what's rare in our industry? Getting to build something completely from scratch. No legacy code to work around, no "well, that's how it's always been done" constraints. Just you, a blank canvas, and the chance to do things right from day one.
That's exactly what I got to do with this Azure project. The company was all-in on .NET technologies, and they needed their entire cloud infrastructure built from nothing. My lead had this philosophy I really respected - we weren't going to copy someone else's architecture. We were going to make our own decisions based on what actually made sense for our needs.
The thing is, when everything is a first and nothing is documented, you're essentially pioneering. Every choice you make becomes the foundation that other teams will build on for years. That's both exciting and terrifying.
.webp&w=3840&q=75)
.webp&w=3840&q=75)
Starting with Nothing But Possibilities
I mean, literally nothing existed. No resource groups, no networks, no databases - just an empty Azure subscription and a lot of requirements. We had to build everything using Terraform because infrastructure-as-code wasn't just a nice-to-have here - it was going to be the only way to manage what we were creating.
The .NET applications were straightforward enough at first. Azure and .NET go together like peanut butter and jelly, right? We started building out the basic infrastructure - App Services, SQL databases, storage accounts. Standard stuff. The Terraform modules were clean, the deployments were smooth.
Then came the curveball - "Oh, by the way, we need real-time communication through WebSockets."
When WebSockets Changed Everything
You know how some requirements completely change your architecture? WebSockets was that requirement. Suddenly, our nice, stateless REST API design had to accommodate persistent, stateful connections. In Azure, that meant diving into SignalR Service.
But here's the thing about WebSockets - they're not just another API endpoint. They're long-lived connections that need special handling for scaling, load balancing, and failover. Our API Gateway setup, which was perfect for REST APIs, needed major rethinking to handle WebSocket traffic properly.
I spent weeks figuring out the right architecture. How do you handle connection state when your app scales horizontally? What happens when a pod dies with active WebSocket connections? How do you gracefully handle reconnections without losing messages? These weren't theoretical problems - they were real issues that would affect user experience.
.webp&w=3840&q=75)
.webp&w=3840&q=75)
The Terraform Provider Gap That Nobody Talks About
And then I hit a wall that really frustrated me. We needed Azure Event Grid for our event-driven architecture. Makes sense, right? Modern cloud architecture, event-driven patterns, should be standard stuff.
Except Terraform's Azure provider didn't fully support Event Grid namespaces. Like, at all. Some resources were partially supported, others were completely missing. Here I was, trying to build everything through infrastructure-as-code, and Terraform was basically saying "sorry, can't help you with that."
So I did what any engineer would do - I got creative. I built a hybrid approach that honestly felt dirty at first. Some resources managed by Terraform, others provisioned through Azure CLI commands embedded in our pipelines. It wasn't elegant, but it worked.
Building Patterns That Last
What I learned from this project is that greenfield doesn't mean "do whatever you want." It means "establish patterns that will scale." Every decision I made had to consider not just the immediate need, but how it would work when we had 10x the traffic, 10x the developers, 10x the complexity.
The hybrid Terraform/CLI approach became our template for handling cutting-edge Azure services. We documented the patterns, created reusable modules, and established guidelines for when to use each approach. What started as a workaround became a strategic advantage.
By the end of the project, we had a fully automated, scalable, event-driven architecture running on Azure. WebSocket connections handled gracefully, Event Grid processing millions of events, all managed through code. It wasn't just infrastructure - it was a platform that enabled the business to move fast.
What This Greenfield Project Taught Me
Building from scratch is a privilege and a responsibility. Every decision you make echoes through the organization's future. There's no legacy code to blame, no previous architect's decisions to work around. It's all on you.
I learned that perfect architecture doesn't exist, but good-enough architecture that ships features does. Our hybrid Terraform/CLI approach wasn't textbook clean, but it let us use cutting-edge Azure services while maintaining infrastructure-as-code principles where it mattered.
That's the thing about building from scratch - you don't just create infrastructure. You create possibilities. You establish patterns that influence how an entire organization thinks about cloud architecture. And sometimes, just sometimes, you get to build something that stands the test of time.
Questions People Actually Ask
You know, after sharing this project, I keep getting the same questions. So here are the real answers to the things people actually want to know.