Platform-Engineering

Boundaries matter more with AI than with humans. Trust is contextual. We trust engineers with secrets because they are accountable. We do not trust AI with secrets because it is not. That distinction matters more than people admit. AI Has No Sense of Boundary AI does not understand intent. It does not understand sensitivity. It does not understand consequences. It only understands inputs and outputs. If a secret appears in a prompt, the model treats it as data, not as something to protect. ...

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

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