Newest first, grouped by year. Search or filter by topic.
The honest retrospective that closes the series - how template scaffolding metastasizes mistakes, why version pinning without governance curates a museum, what secrets in locals really cost, and the upgrade list I would run on this estate today. Part 12 of the Terraform on Azure series.
Three manually-run pipelines, one JSON config bag and a TDE certificate wrinkle - how live SQL Server databases moved into Azure SQL Managed Instance with LRS, and why all the project risk compresses into the sixty seconds around cutover. Part 11 of the Terraform on Azure series.
Azure Blueprints driven from Terraform with forty templated parameters, platform-level delete locks, twelve-hour timeouts and PowerShell bookends on both sides of the apply - how the estate's most dangerous resource got its most governed deployment. Part 10 of the Terraform on Azure series.
local-exec key minting, external data sources wrapping PowerShell, and a post-apply ARM PATCH - the imperative seams that held a declarative Azure estate together, and the idempotency, portability and security bills they ran up. Part 9 of the Terraform on Azure series.
Each Logic App in this Azure estate was split across four sibling stacks - runtime, workflows, APIM registration and service discovery - a clean lifecycle separation that quadrupled the folder, pipeline and state count per integration. Part 8 of the Terraform on Azure series.
The most-consumed custom module in an Azure Terraform estate wrote one Key Vault secret per service - a JSON record carrying a URL, a credential and a type - and quietly became the runtime service registry for scores of Function Apps and Logic App workflows. How it worked, what it got right, and where a registry with no registry starts to strain. Part 6 of the Terraform on Azure series.
With no terraform_remote_state anywhere in 230 stacks, every cross-stack reference in this Azure estate was a literal name string - a taxonomy you could read from ls, a coupling with zero runtime dependencies, and a silent-drift hazard on every rename. Part 7 of the Terraform on Azure series.
Nine thin custom Terraform modules carried the entire platform-integration story of an Azure estate. This part dissects the APIM-publication half - key minting through local-exec, SAS-splitting through PowerShell, twin modules one hyphen apart, and a typo frozen into dozens of source strings. Part 5 of the Terraform on Azure series.
Two generations of Terraform pipeline in one Azure estate - manual parameterized plan-and-apply consoles beside gated plan-artifact promotion - and why applying the exact plan you approved is the rung that matters. Part 4 of the Terraform on Azure series.
Empty backend blocks, per-environment storage accounts and a state file for every stack-environment pair - how one Azure estate partitioned a thousand Terraform states for blast radius, and what that sprawl cost. Part 3 of the Terraform on Azure series.
How workspace-keyed lookup maps and a single platform-facts JSON file let hundreds of Terraform stacks run identically in dev, staging and prod - and when a forgiving lookup default is the wrong kind of kindness. Part 2 of the Terraform on Azure series.
The conventions that let one Terraform sample library serve hundreds of Azure deployments - a five-file layout, workspace-indexed environments, pinned golden modules and pipeline-first delivery. Part 1 of a series on Terraform for the Azure estate.
Retention as a first-class column: how ArchiveKit stamps ExpiresAt at archive time from a TtlDays attribute, hard-deletes expired rows in bounded batches, and runs the whole thing on Lambda with the hosted services switched off. Also, the rows TTL doesn't clean yet. Part 8 of the Archive-on-Delete with ArchiveKit series.
The read side of archive-on-delete: querying archives through promoted typed columns, digging into jsonb payloads for everything else, polling snapshots with a 202 pattern, and an honest accounting of the restore path ArchiveKit doesn't have yet. Part 9 wraps up the Archive-on-Delete with ArchiveKit series.
ArchiveKit's snapshot service assembles a full JSON tree of a deleted object graph using nothing but archive rows - the primary data is already gone. Job tickets, a four-state machine, retries with a terminal Failed state, and the single-table assembly limitation I still owe a fix for. Part 7 of the Archive-on-Delete with ArchiveKit series.
Correlation ids and cascade archiving in ArchiveKit - how one Guid per save turns scattered archive rows into a reconstructable object graph, why cascade happens through the EF change tracker rather than the database, and two honest limits: a naive root heuristic and a CascadeArchive flag the interceptor doesn't read yet. Part 6 of the Archive-on-Delete with ArchiveKit series.
How ArchiveKit wires itself up - the [Archivable] attribute's three knobs, an assembly scanner that fails fast at startup instead of quietly at delete time, the static registry behind every lookup, and the AddArchiveKit configuration surface. Plus an honest note about the source generator that doesn't exist yet. Part 5 of the Archive-on-Delete with ArchiveKit series.
The storage design behind ArchiveKit - typed queryable columns and a jsonb payload from a single write, why the archive's EntityId is an index but deliberately not a foreign key, and the reflective model configuration that builds every archive table from one method call. Part 4 of the Archive-on-Delete with ArchiveKit series.
Why ArchiveKit's inline archive limit defaults to exactly 14, how EF Core's MaxBatchSize turns archiving into arithmetic, and an honest inventory of every deletion path the interceptor cannot see - synchronous saves, ExecuteDelete, and raw SQL. Part 3 of the Archive-on-Delete with ArchiveKit series.
The anatomy of ArchiveKit's SaveChangesInterceptor - detecting soft-deleted entities in the change tracker, building archive rows with zero extra database reads, and the one line of state-flip ordering that keeps EF from cascade-deleting the archive you just wrote. Part 2 of the Archive-on-Delete with ArchiveKit series.
Hard deletes destroy the audit trail; soft deletes clutter live tables forever. Introducing ArchiveKit, a .NET library that intercepts deletions and stores immutable archive snapshots with TTL policies and cascade archiving.
Archive tables are meant to empty out - a background worker migrates their rows into the current table while live traffic reads and write-through updates race it. This part walks the EF backfill's insert-then-conditional-delete choreography and the timestamp that keeps it honest. Part 9 of the Entity Versioning with VersionKit series.
Static registries, Activator-created migrators, a Postgres accent, a flag that does nothing, and no test project - the closing part of the VersionKit series itemises every trade-off in the library, says when you should not use it, and sketches what comes next. Part 10 of the Entity Versioning with VersionKit series.
A point lookup that might hit any of three tables, a list query that should span them all, and writes that must keep a registry honest - this part walks VersionKit's version-aware reader and writer, and the generated UNION view that makes every schema era queryable as if it were current. Part 8 of the Entity Versioning with VersionKit series.
JSON payloads can migrate lazily because the reader controls the shape - relational rows cannot, because the table is the shape. VersionKit's EF Core answer is table-per-version - archive Orders as Orders_v2 on a schema bump, track every row's home in a registry, and let old rows stay old until something moves them. Part 7 of the Entity Versioning with VersionKit series.
