In today’s world, businesses are increasingly reliant on software to deliver their products and services. As software becomes more complex, it becomes more difficult to keep track of its performance and behavior. his can lead to problems such as outages, performance degradation, and security vulnerabilities. This is where observability comes in. Observability is the ability to understand what is happening inside a system from the knowledge of the external data it produces.

Finance forwarded the Azure invoice again this week. Not a polite FYI — a “can you explain the jump” thread with three managers CC’d. The honest answer was ugly: we could name the subscriptions, not the owners. Half the line items were tags like rg-temp-demo and a node pool nobody had touched since the last migration spike.

That used to be background noise. Cloud was the flexible thing that scaled when we shipped. This fall it feels different. Budgets are tighter, leadership is asking about ROI, and the bill is no longer weather that just happens. It is a product decision we forgot to staff.

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.