Platform Engineering Notebook

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: ...

At first, Terraform was just a way to create resources. It lived next to the platform. It supported it. It automated it. Then, quietly, Terraform became the platform. The Shift Was Subtle There was no announcement. No rewrite. No big migration moment. It happened when: new environments required Terraform first access flowed through Terraform definitions changes without Terraform felt unsafe platform discussions started with code Terraform stopped being an implementation detail. It became the source of truth. ...

Terraform does something uncomfortable very well. It preserves mistakes. At first, that feels like a problem. Over time, it becomes one of its biggest strengths. Before Terraform, Mistakes Were Ephemeral Before infrastructure lived in code, mistakes were scattered. Someone changed a setting in the portal. Someone applied a hotfix directly. Someone clicked a checkbox to make something work. Those mistakes disappeared into history. They could not be explained. They could not be repeated. They could not be intentionally fixed. ...

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.” ...

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.” ...

After we moved one workload out of Azure Functions, a reasonable question came up. Why not move everything? The answer was simple. Some things were still working exactly as intended. Serverless did not fail us. We just learned where it fit. Not All Functions Are Equal One of the easiest mistakes to make with Azure Functions is treating them as interchangeable units. They are not. Some functions want to be long lived. Some want tight performance guarantees. Some want deep observability. ...

Azure Functions are often introduced as the simplest way to run code in Azure. You write a function. Azure handles the rest. For a while, that is true. Then, at some point, Functions stop feeling serverless. They start feeling like infrastructure. The Early Days Feel Magical Early on, Azure Functions are hard to beat. No servers to manage Easy triggers Automatic scaling Minimal deployment overhead They are especially attractive for: ...

For a long time, this Azure Function felt like a success story. It was small. It was event-driven. It scaled automatically. On paper, it was exactly the kind of workload serverless is built for. Eventually, we moved it out of serverless anyway. Not because it was broken. Because it stopped being the right fit. The Function That Kept Growing The function started simple. It processed inbound data, did some validation, and pushed results downstream. Execution time was short. Volume was low. Failures were rare. ...

Where Key Vault belongs and where it does not. Secrets often get treated like infrastructure. They are stored with infra. Managed by infra. Reviewed with infra. That is usually a mistake. Why Secrets Feel Like Infrastructure Secrets feel permanent. They feel critical. They feel risky. So they end up bundled with infrastructure decisions. But secrets change more often than infrastructure. They also belong closer to applications. Infrastructure teams often manage Key Vault because it lives in Azure alongside virtual networks, storage accounts, and databases. It gets deployed with Terraform or Bicep. It has firewall rules and access policies. It looks and feels like infrastructure. ...