Azure

Azure App Service doesn’t get much love. It’s not shiny. It’s not trendy. It doesn’t give you the satisfaction of saying “we’re fully containerized.” And yet, it’s where some of our most reliable production workloads live. After running App Services, Functions, and Container Apps side by side, I’ve reached a conclusion that feels almost unpopular in 2025: Boring infrastructure is often the best infrastructure. The Problem With Exciting Compute When teams evaluate Azure compute options, the conversation usually starts with features: ...

Soft delete saved us once. Purge protection blocked us twice. Here is what we learned about Key Vault deletion safeguards. Soft Delete Is Enabled by Default Now Soft delete used to be optional. Now it is mandatory for all new Key Vaults. When you delete a vault, it is not really deleted. It is soft-deleted. It stays in a deleted state for 90 days by default. You can recover it during that time. ...

We thought more vaults meant better security. It just meant more complexity. Here is what we should have done instead. The Logic Seemed Sound Each app gets its own Key Vault. Perfect isolation. Clear ownership. No shared access. It sounded like best practice. We created: one vault per microservice one vault per environment one vault per team Within six months, we had over 100 Key Vaults. Management Became Impossible Every vault needed: ...

We spent hours debugging connectivity when the real issue was authentication. Here is why identity failures masquerade as network failures. The Error Message Lies Your app cannot connect to Azure SQL. The error says: “Connection timeout.” You check: firewall rules network security groups VNET configuration DNS resolution Everything looks correct. The issue is not networking. It is identity. The Managed Identity does not have permissions on the database. But the error said “timeout,” not “access denied.” ...

The role assignment is correct. The scope is right. Access is still denied. Here are the hidden reasons why. Propagation Delay Is Real You add a role assignment. You test immediately. It fails. Azure RBAC changes are not instant. Propagation can take up to 30 minutes, though it is usually faster. We spent hours debugging issues that fixed themselves while we investigated. Now we wait five minutes before testing any new role assignment. ...

The first Terraform refactor is never about improvement. It is about reckoning. You usually start with good intentions. Clean things up. Add structure. Maybe extract a module or two. Then you run plan. And suddenly you are staring at changes you do not remember making, resources you did not know were connected, and behaviors you cannot confidently explain. That is the real start of Terraform. The Moment Reality Shows Up Early Terraform setups tend to grow organically. ...

Retries feel comforting. Something failed. The system tried again. Eventually it worked. That story sounds reassuring, but it hides a lot of risk. Retries are not a safety net. They are a design decision. Why Retries Feel Harmless Most platforms make retries easy. Azure Functions retry automatically. Azure Storage Queues redeliver messages. HTTP clients retry transient failures. Early on, this feels like free resilience. You do not have to think deeply about failure. The platform will “handle it.” ...

Role assignments multiply faster than you expect. Here is how we went from structured permissions to chaos, and how we fixed it. It Starts With One Exception You build a clean RBAC model. Groups for teams. Roles at the right scope. Least privilege enforced. Then someone needs access for a demo. Just this once. You add a direct role assignment to their account. You plan to remove it later. You forget. ...

Service principals never clean themselves up. And no one remembers why they exist. Here is how we ended up with hundreds of them. They Start With Good Intentions Someone needs to deploy an app. They create a service principal. Someone needs a CI/CD pipeline. Another service principal. Someone needs cross-tenant access. One more. Each one made sense at the time. Each one solved a real problem. None of them had an expiration date. ...

Terraform did not make our Azure environment simpler. It did something more important. It made it understandable. That distinction matters more than most teams realize. Azure Was Already Complex Before Terraform, Azure already had: dozens of resource types implicit dependencies hidden defaults behaviors that only showed up at scale The Azure portal made it feel manageable. It did not make it explainable. When something broke, the answer was often: “Someone changed something at some point.” ...