Skip to main content

Nov 2022 - Mar 2023 • Technical Deep Dive

Azure Greenfield Infrastructure

Deep technical implementation details and lessons learned.

Technical Implementation

Technical details coming soon...

Frequently Asked Questions

Why Azure instead of AWS for a greenfield project?

" The company had deep Microsoft partnerships and expertise. Their entire development stack was .NET, they used Active Directory extensively, and Azure's native .NET support meant less friction. Plus, Azure's hybrid cloud capabilities aligned perfectly with their IoT edge requirements. Sometimes the best cloud is the one that fits your organization, not the one with the most market share. "How did you handle Terraform provider limitations?" We created what I called "infrastructure bridges" - wrapper scripts that provided Terraform-like interfaces to Azure CLI commands. These scripts were versioned, tested, and integrated into our deployment pipelines. We also contributed to the Terraform Azure provider where possible, though enterprise timelines rarely align with open source contribution cycles. "What was your disaster recovery strategy?" We built active-passive configurations for critical services with automated failover. Every piece of infrastructure was defined as code, so we could rebuild entire environments from scratch. We tested this quarterly - literally destroying environments and rebuilding them. The IoT edge devices were designed to operate independently during cloud outages, syncing state when connectivity returned. "How did GitOps work with IoT devices in practice?" Each device had a desired state defined in Git. The devices ran a lightweight agent that periodically checked for configuration updates. When changes were detected, they'd download and apply the new configuration. We used Azure IoT Hub for device management and monitoring. The beautiful part was rollbacks - just revert the Git commit and devices would automatically return to the previous configuration. "What about security for WebSocket connections?" Every WebSocket connection required authentication through our standard OAuth flow. We implemented per-message authorization for sensitive operations. SignalR connections were encrypted end-to-end, and we used Azure Private Endpoints to keep traffic within our virtual network. Connection tokens expired after set periods, forcing re-authentication. "How did you manage costs with all these Azure services?" We implemented aggressive auto-scaling policies and used Azure Reserved Instances where possible. The SignalR Service scaled based on concurrent connections. IoT Hub used the appropriate tier based on message volume. We built cost monitoring into our Terraform modules, so every resource deployment showed estimated monthly costs. This transparency helped teams make informed decisions. 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. The WebSocket implementation taught me to embrace stateful services in cloud-native architectures. Not everything can be stateless, and fighting against that reality just creates complexity elsewhere. Build for the requirements you have, not the ones you wish you had. GitOps transformed from a buzzword to a practical operational model that I now recommend for any distributed system. When you can't touch your infrastructure directly - whether it's in the cloud or on edge devices - GitOps provides the control and auditability you need. Why This Project Still Matters This project became a template for how I approach greenfield development. Start with solid patterns, be pragmatic about tool limitations, and always think about the engineers who'll maintain this system after you're gone. The infrastructure we built is still running, still evolving. Other teams built on our patterns, extended our modules, and improved our approaches. That's the mark of good foundational work - it enables others to build great things on top of it. You know what's funny? I still check in on some of the design decisions we made. The WebSocket architecture scaled to handle way more traffic than we initially imagined. The IoT edge patterns became the standard for other edge computing projects. The hybrid infrastructure approach, weird as it seemed at the time, proved to be exactly the flexibility the organization needed. 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. Looking back, this project taught me that the best architects aren't the ones who build perfect systems. They're the ones who build systems that solve real problems, adapt to real constraints, and enable real innovation. Even if that means mixing Terraform with Azure CLI and calling it a day.

How did you handle Terraform provider limitations?

" We created what I called "infrastructure bridges" - wrapper scripts that provided Terraform-like interfaces to Azure CLI commands. These scripts were versioned, tested, and integrated into our deployment pipelines. We also contributed to the Terraform Azure provider where possible, though enterprise timelines rarely align with open source contribution cycles. "What was your disaster recovery strategy?" We built active-passive configurations for critical services with automated failover. Every piece of infrastructure was defined as code, so we could rebuild entire environments from scratch. We tested this quarterly - literally destroying environments and rebuilding them. The IoT edge devices were designed to operate independently during cloud outages, syncing state when connectivity returned. "How did GitOps work with IoT devices in practice?" Each device had a desired state defined in Git. The devices ran a lightweight agent that periodically checked for configuration updates. When changes were detected, they'd download and apply the new configuration. We used Azure IoT Hub for device management and monitoring. The beautiful part was rollbacks - just revert the Git commit and devices would automatically return to the previous configuration. "What about security for WebSocket connections?" Every WebSocket connection required authentication through our standard OAuth flow. We implemented per-message authorization for sensitive operations. SignalR connections were encrypted end-to-end, and we used Azure Private Endpoints to keep traffic within our virtual network. Connection tokens expired after set periods, forcing re-authentication. "How did you manage costs with all these Azure services?" We implemented aggressive auto-scaling policies and used Azure Reserved Instances where possible. The SignalR Service scaled based on concurrent connections. IoT Hub used the appropriate tier based on message volume. We built cost monitoring into our Terraform modules, so every resource deployment showed estimated monthly costs. This transparency helped teams make informed decisions. 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. The WebSocket implementation taught me to embrace stateful services in cloud-native architectures. Not everything can be stateless, and fighting against that reality just creates complexity elsewhere. Build for the requirements you have, not the ones you wish you had. GitOps transformed from a buzzword to a practical operational model that I now recommend for any distributed system. When you can't touch your infrastructure directly - whether it's in the cloud or on edge devices - GitOps provides the control and auditability you need. Why This Project Still Matters This project became a template for how I approach greenfield development. Start with solid patterns, be pragmatic about tool limitations, and always think about the engineers who'll maintain this system after you're gone. The infrastructure we built is still running, still evolving. Other teams built on our patterns, extended our modules, and improved our approaches. That's the mark of good foundational work - it enables others to build great things on top of it. You know what's funny? I still check in on some of the design decisions we made. The WebSocket architecture scaled to handle way more traffic than we initially imagined. The IoT edge patterns became the standard for other edge computing projects. The hybrid infrastructure approach, weird as it seemed at the time, proved to be exactly the flexibility the organization needed. 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. Looking back, this project taught me that the best architects aren't the ones who build perfect systems. They're the ones who build systems that solve real problems, adapt to real constraints, and enable real innovation. Even if that means mixing Terraform with Azure CLI and calling it a day.

What was your disaster recovery strategy?

" We built active-passive configurations for critical services with automated failover. Every piece of infrastructure was defined as code, so we could rebuild entire environments from scratch. We tested this quarterly - literally destroying environments and rebuilding them. The IoT edge devices were designed to operate independently during cloud outages, syncing state when connectivity returned. "How did GitOps work with IoT devices in practice?" Each device had a desired state defined in Git. The devices ran a lightweight agent that periodically checked for configuration updates. When changes were detected, they'd download and apply the new configuration. We used Azure IoT Hub for device management and monitoring. The beautiful part was rollbacks - just revert the Git commit and devices would automatically return to the previous configuration. "What about security for WebSocket connections?" Every WebSocket connection required authentication through our standard OAuth flow. We implemented per-message authorization for sensitive operations. SignalR connections were encrypted end-to-end, and we used Azure Private Endpoints to keep traffic within our virtual network. Connection tokens expired after set periods, forcing re-authentication. "How did you manage costs with all these Azure services?" We implemented aggressive auto-scaling policies and used Azure Reserved Instances where possible. The SignalR Service scaled based on concurrent connections. IoT Hub used the appropriate tier based on message volume. We built cost monitoring into our Terraform modules, so every resource deployment showed estimated monthly costs. This transparency helped teams make informed decisions. 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. The WebSocket implementation taught me to embrace stateful services in cloud-native architectures. Not everything can be stateless, and fighting against that reality just creates complexity elsewhere. Build for the requirements you have, not the ones you wish you had. GitOps transformed from a buzzword to a practical operational model that I now recommend for any distributed system. When you can't touch your infrastructure directly - whether it's in the cloud or on edge devices - GitOps provides the control and auditability you need. Why This Project Still Matters This project became a template for how I approach greenfield development. Start with solid patterns, be pragmatic about tool limitations, and always think about the engineers who'll maintain this system after you're gone. The infrastructure we built is still running, still evolving. Other teams built on our patterns, extended our modules, and improved our approaches. That's the mark of good foundational work - it enables others to build great things on top of it. You know what's funny? I still check in on some of the design decisions we made. The WebSocket architecture scaled to handle way more traffic than we initially imagined. The IoT edge patterns became the standard for other edge computing projects. The hybrid infrastructure approach, weird as it seemed at the time, proved to be exactly the flexibility the organization needed. 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. Looking back, this project taught me that the best architects aren't the ones who build perfect systems. They're the ones who build systems that solve real problems, adapt to real constraints, and enable real innovation. Even if that means mixing Terraform with Azure CLI and calling it a day.

How did GitOps work with IoT devices in practice?

" Each device had a desired state defined in Git. The devices ran a lightweight agent that periodically checked for configuration updates. When changes were detected, they'd download and apply the new configuration. We used Azure IoT Hub for device management and monitoring. The beautiful part was rollbacks - just revert the Git commit and devices would automatically return to the previous configuration. "What about security for WebSocket connections?" Every WebSocket connection required authentication through our standard OAuth flow. We implemented per-message authorization for sensitive operations. SignalR connections were encrypted end-to-end, and we used Azure Private Endpoints to keep traffic within our virtual network. Connection tokens expired after set periods, forcing re-authentication. "How did you manage costs with all these Azure services?" We implemented aggressive auto-scaling policies and used Azure Reserved Instances where possible. The SignalR Service scaled based on concurrent connections. IoT Hub used the appropriate tier based on message volume. We built cost monitoring into our Terraform modules, so every resource deployment showed estimated monthly costs. This transparency helped teams make informed decisions. 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. The WebSocket implementation taught me to embrace stateful services in cloud-native architectures. Not everything can be stateless, and fighting against that reality just creates complexity elsewhere. Build for the requirements you have, not the ones you wish you had. GitOps transformed from a buzzword to a practical operational model that I now recommend for any distributed system. When you can't touch your infrastructure directly - whether it's in the cloud or on edge devices - GitOps provides the control and auditability you need. Why This Project Still Matters This project became a template for how I approach greenfield development. Start with solid patterns, be pragmatic about tool limitations, and always think about the engineers who'll maintain this system after you're gone. The infrastructure we built is still running, still evolving. Other teams built on our patterns, extended our modules, and improved our approaches. That's the mark of good foundational work - it enables others to build great things on top of it. You know what's funny? I still check in on some of the design decisions we made. The WebSocket architecture scaled to handle way more traffic than we initially imagined. The IoT edge patterns became the standard for other edge computing projects. The hybrid infrastructure approach, weird as it seemed at the time, proved to be exactly the flexibility the organization needed. 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. Looking back, this project taught me that the best architects aren't the ones who build perfect systems. They're the ones who build systems that solve real problems, adapt to real constraints, and enable real innovation. Even if that means mixing Terraform with Azure CLI and calling it a day.

What about security for WebSocket connections?

" Every WebSocket connection required authentication through our standard OAuth flow. We implemented per-message authorization for sensitive operations. SignalR connections were encrypted end-to-end, and we used Azure Private Endpoints to keep traffic within our virtual network. Connection tokens expired after set periods, forcing re-authentication. "How did you manage costs with all these Azure services?" We implemented aggressive auto-scaling policies and used Azure Reserved Instances where possible. The SignalR Service scaled based on concurrent connections. IoT Hub used the appropriate tier based on message volume. We built cost monitoring into our Terraform modules, so every resource deployment showed estimated monthly costs. This transparency helped teams make informed decisions. 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. The WebSocket implementation taught me to embrace stateful services in cloud-native architectures. Not everything can be stateless, and fighting against that reality just creates complexity elsewhere. Build for the requirements you have, not the ones you wish you had. GitOps transformed from a buzzword to a practical operational model that I now recommend for any distributed system. When you can't touch your infrastructure directly - whether it's in the cloud or on edge devices - GitOps provides the control and auditability you need. Why This Project Still Matters This project became a template for how I approach greenfield development. Start with solid patterns, be pragmatic about tool limitations, and always think about the engineers who'll maintain this system after you're gone. The infrastructure we built is still running, still evolving. Other teams built on our patterns, extended our modules, and improved our approaches. That's the mark of good foundational work - it enables others to build great things on top of it. You know what's funny? I still check in on some of the design decisions we made. The WebSocket architecture scaled to handle way more traffic than we initially imagined. The IoT edge patterns became the standard for other edge computing projects. The hybrid infrastructure approach, weird as it seemed at the time, proved to be exactly the flexibility the organization needed. 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. Looking back, this project taught me that the best architects aren't the ones who build perfect systems. They're the ones who build systems that solve real problems, adapt to real constraints, and enable real innovation. Even if that means mixing Terraform with Azure CLI and calling it a day.

How did you manage costs with all these Azure services?

" We implemented aggressive auto-scaling policies and used Azure Reserved Instances where possible. The SignalR Service scaled based on concurrent connections. IoT Hub used the appropriate tier based on message volume. We built cost monitoring into our Terraform modules, so every resource deployment showed estimated monthly costs. This transparency helped teams make informed decisions. 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. The WebSocket implementation taught me to embrace stateful services in cloud-native architectures. Not everything can be stateless, and fighting against that reality just creates complexity elsewhere. Build for the requirements you have, not the ones you wish you had. GitOps transformed from a buzzword to a practical operational model that I now recommend for any distributed system. When you can't touch your infrastructure directly - whether it's in the cloud or on edge devices - GitOps provides the control and auditability you need. Why This Project Still Matters This project became a template for how I approach greenfield development. Start with solid patterns, be pragmatic about tool limitations, and always think about the engineers who'll maintain this system after you're gone. The infrastructure we built is still running, still evolving. Other teams built on our patterns, extended our modules, and improved our approaches. That's the mark of good foundational work - it enables others to build great things on top of it. You know what's funny? I still check in on some of the design decisions we made. The WebSocket architecture scaled to handle way more traffic than we initially imagined. The IoT edge patterns became the standard for other edge computing projects. The hybrid infrastructure approach, weird as it seemed at the time, proved to be exactly the flexibility the organization needed. 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. Looking back, this project taught me that the best architects aren't the ones who build perfect systems. They're the ones who build systems that solve real problems, adapt to real constraints, and enable real innovation. Even if that means mixing Terraform with Azure CLI and calling it a day.