Devops

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

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

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

Complexity always finds a way in. Our CI/CD pipeline started with a few scripts. Build the code. Run the tests. Deploy the artifact. It worked well. For a while. Then requirements accumulated. Quietly. Complexity Did Not Arrive All at Once No one decided to make the pipeline complicated. It happened incrementally: add a security scan support another environment introduce feature flags handle hotfixes add approvals support rollback Each change made sense in isolation. ...