Azure

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

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

Why permission models rot over time. Azure RBAC feels simple at first. Assign a role. Pick a scope. Move on. The problems show up later. RBAC Accumulates History Permissions tend to grow, not shrink. Temporary access becomes permanent. Emergency grants never get revisited. Roles pile up across scopes. Over time, no one remembers why access exists. They only remember that removing it feels risky. I have audited Azure subscriptions where people had role assignments from three jobs ago. Former contractors still had Contributor access years after their contracts ended. Service principals created for one-off migrations still had Owner access to production. ...

Practical IAM, not zero trust theater. Access control often swings between two extremes. Everything open. Everything locked down. Neither works. Why Overly Restrictive IAM Fails When access is too hard to get: engineers work around it secrets get shared permissions creep quietly reviews become rubber stamps Security that blocks work does not create safety. It creates shadow systems. I have seen this pattern repeat across multiple teams. Access requests take days or weeks to get approved. The approval process requires three levels of sign-off, none of which understand the technical need. Engineers get frustrated and find workarounds. ...

How secrets sprawl happens and how to stop it. Key Vault feels deceptively simple. If something is sensitive, put it in the vault. Problem solved. That logic is how secret sprawl starts. How the Vault Becomes a Junk Drawer It usually begins with good intentions. A new service needs a secret. A developer adds it to Key Vault. Permissions are granted. Everyone moves on. Repeat this enough times and suddenly: ...