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.

We got better at shipping code this year. Pipelines build, tests run, images land in the registry, and — if you bought into the GitOps story — the cluster eventually matches Git. That is deploy. What still bites us is treating deploy and release as the same button.

I spent the last couple of sprints putting Microsoft.FeatureManagement in front of a few half-finished ASP.NET Core endpoints. Not because flags are fashionable. Because product wanted a quiet soak with internal users, and ops wanted a kill switch that did not involve a Friday rollback train.

Our deploy pipeline used to end with a job that ran kubectl apply -f against a folder of rendered YAML. It worked. Until it didn’t. Someone would fix a ConfigMap by hand at 11pm, forget to commit it, and three days later the next pipeline run would “helpfully” overwrite the fix. Or the opposite: Git said one thing, the cluster said another, and nobody could tell which was deliberate.

I have been watching the GitOps wave for a while — Flux from Weaveworks, Argo CD from the Intuit folks, now both under the CNCF umbrella. This week Argo CD shipped 2.0. That felt like a good moment to write down what actually changed in how I think about deploys.