Posts

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

Human approval does not scale the way you think. Manual gates sound responsible. Someone reviews. Someone approves. Nothing risky slips through. In practice, they fail quietly. Approvals Become Rituals Over time, manual approvals turn into habits. Approve because: the build looks normal nothing failed this is routine people are waiting Approval loses meaning. It becomes a checkbox. The first few times you approve a production deployment, you take it seriously. You check the changeset. You review test results. You verify that everything looks correct. You ask questions if something seems off. ...

Consistency beats flexibility at scale. Early on, we let teams build their own pipelines. It felt empowering. It felt flexible. It felt fast. It did not scale. Flexibility Creates Variance When every team builds pipelines independently: conventions diverge checks differ deployments behave differently failure modes multiply That variance is invisible at first. It becomes painful later. Team A used Azure Pipelines. Team B used GitHub Actions. Team C used Jenkins because they inherited a project that already had it. All three were valid choices. ...