Posts

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

Container Apps are great for compute. But the observability story is rough. Here is what works, what does not, and what we did instead. The Logs Exist, But Finding Them Is Hard Container Apps send logs to Log Analytics. That sounds good. Until you try to use it. The logs are scattered across multiple tables: ContainerAppConsoleLogs for stdout/stderr ContainerAppSystemLogs for platform events AppEnvSpringCloudGatewayLogs if you use specific add-ons We spent time writing Kusto queries just to see what our application logged. ...

We thought Container Apps networking would be simple. We were wrong. Here is what we learned after hours of troubleshooting. Internal vs External Environments Are Not What You Think Container Apps have two environment types: internal and external. We assumed: external means public internet internal means private network That is partially true, but incomplete. External environments get a public IP and can accept traffic from the internet. They can also be restricted to your VNET. ...

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

Functions seemed like the obvious choice. Until we hit the constraints that Container App Jobs do not have. Functions Work Until They Do Not We started with Azure Functions for our batch workloads. The model is simple: write code deploy it trigger it on a schedule or event It worked well for small jobs. Then we needed longer execution times. Functions have limits. We needed custom dependencies. The runtime felt restrictive. ...

Hard-earned hindsight. If we rebuilt our pipelines today, we would not start with tools. We would start with principles. What We Would Do Differently We would: standardize earlier automate more validation avoid manual gates by default version pipelines intentionally design for change, not perfection Most importantly, we would assume growth. Standardize earlier. We let teams build custom pipelines for too long. The cost of standardization increases with every unique pipeline. If we started over, we would establish standard templates from day one. Customization would be the exception, not the norm. ...

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

From tooling to ownership. At first, CI/CD was just tooling. Something teams used. Something infra supported. Something no one owned end to end. Then it became critical. The Shift Happened Gradually CI/CD became part of the platform when: changes without it felt unsafe environments depended on it access flowed through it incidents traced back to it Pipelines stopped being optional. Early on, you could deploy manually if needed. SSH into a server. Copy files. Restart services. It was discouraged but possible. The pipeline was a convenience, not a requirement. ...

How small differences turn into big problems. Pipeline drift rarely starts intentionally. It starts with a small change. A special case. A temporary workaround. Then it sticks. Drift Is Hard to See Two pipelines look similar. They are not. Different flags. Different versions. Different checks. No one notices until behavior diverges. You have a standard pipeline template. Version 1.2. Most teams use it. A few are still on 1.1. One team forked it months ago and never updated. Another team copy-pasted the template and made “minor adjustments.” ...

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