Last week I needed the owner of a payment-adjacent API before a release freeze. Three Slack threads, two Confluence pages last edited in 2019, and a Wiki that still pointed at a team that no longer exists. The service was fine. Our map of the service was not.

That is the quiet tax of a growing .NET estate: dozens of ASP.NET Core APIs, a few workers, Helm charts in three repos, docs in a fourth place, and ownership living only in someone’s head. Platform teams are supposed to fix the infrastructure. Lately I keep hearing a different answer — internal developer portals — and Spotify’s Backstage is the name that shows up in every architecture review deck this summer.

Every architecture review this year seems to end the same way. Someone draws a box labeled “Lambda” or “Azure Functions,” someone else draws a Kubernetes cluster, and the room splits into camps. One side talks about never patching a server again. The other side talks about cold starts and the 15-minute wall. Both are right about something. Neither is right about everything.

I write ASP.NET Core services for a living. I have shipped the same kind of work as a zip-deployed function, as a container on a managed orchestrator, and as a plain old App Service. The choice stopped being ideological for me the day a “cheap” serverless path cost more than the always-on pod it replaced — and the day a “simple” cluster burned a week of ops time for a webhook that runs twice an hour.

A few years ago every architecture review had the same slide: three cloud logos, arrows pointing both ways, and the words “avoid vendor lock-in.” Nobody wanted to be the person who said “we are an AWS shop” out loud. Multi-cloud sounded like insurance. Cheap insurance, even — Terraform speaks every provider, right?

I have spent enough nights staring at terraform plan output that spans two clouds to admit the hangover. The insurance premium was not the invoice. It was the cognitive tax, the state files, and the lie that one HCL dialect makes three platforms feel the same.

I got into the GitHub Copilot technical preview a few months after it shipped, and for a while I treated it like a party trick. Type a method name, Tab through a full body, feel slightly guilty. Then I started using it on real ASP.NET Core work — tests, boilerplate mappers, the dull glue between services — and the guilt shifted. Not “is this cheating,” but “am I still reading what I ship?”

We are still in preview as I write this. No paid SKU yet, waitlist energy, grey ghost text in the editor. It is already changing how I start a blank file.

Security still shows up in architecture reviews as a network diagram with a thick line around “us” and a thinner one around “them.” VPN on, you are inside. Inside, the payment API will talk to the reporting API because they share a subnet and a long-lived service account someone checked in years ago.

That model has been fraying for a while — cloud, contractors, WFH laptops that never see the office again — and the slide decks all say “zero trust” now. I have been trying to translate the buzzword into things a .NET team can actually change without waiting for a five-year platform programme.

We spent the first half of the year getting better at how code lands in prod — pipelines, GitOps, flags so deploy and release are not the same button. The question that keeps coming up in incident reviews is different: when are we allowed to keep shipping, and when should we put the brakes on?

Uptime dashboards full of green do not answer that. Neither does “we should be more careful.” What finally helped our team was treating reliability like a budget you can spend, not a vibe you argue about after every outage.