Newest first, grouped by year. Search or filter by topic.
Pacco ships a second API gateway built on Ocelot that hand-rolls everything the Ntrada YAML declares - auth bypass, async bus routes, edge-minted IDs, correlation headers - plus the estate's only circuit breakers. It is instructive, revealing, and deployed by absolutely nothing.
Pacco's Ntrada gateway is ninety lines of C# and five hundred of YAML, and swapping one route key - use downstream for use rabbitmq - turns the same HTTP surface from a proxy into a bus publisher answering 202. The two compose files disagree about which one you get.
Pacco's Operations service listens to all eighty messages in the estate while owning zero contract classes - it reads a JSON registry and forges the CLR types at runtime with Reflection.Emit. The estate's answer to the shared-contracts problem, and the drift it cannot see.
Thirteen repositories, one umbrella that runs twelve of them, two interchangeable API gateways and a service that watches everything - the Pacco estate read as a system of systems, and the fifteen-part series it earns.
How one Terraform template models an entire Event Hubs estate as nested lookup maps - hubs, capture, boolean-triplet authorization rules and consumer groups - and the type-unification trap hiding in its empty environments. Part 6 of the Terraform Module Catalog.
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.
The retrospective that closes three series on DShop - the whole map drawn once, the services wired into nothing, the skew across seventeen repos, and what reading someone else's estate end to end actually teaches.
The catalog's data-tier entry draws an unusually good boundary - the module owns the account and its security posture, raw resources own the data model - and its commented-out option menu doubles as accidental documentation.
DShop wires Serilog, App.Metrics and Jaeger through one shared kernel, propagates a trace span on the message envelope, and hangs its Consul health check on an endpoint no controller defines. A tour of pre-OpenTelemetry observability.
DShop.Api ships three Dockerfiles - plain, multistage, and multistage.advanced - as a teaching ladder. The top rung is broken, and all three share an ENTRYPOINT that quietly defeats graceful shutdown.
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.
DShop.Blazor is a Blazor 0.7 preview app whose naive choices - component classes as singletons, a silent auto-signup, a shared HttpClient - all work because of the runtime they run on. A study in patterns that are only correct by accident.
DShop.Web is a well-structured Angular 6 SPA whose plumbing leaks at every joint - an auth header discarded, PUT and DELETE that both GET, a paged result that starts empty. A tour of bugs that only survive because nobody ran the code.
DShop has an Angular 6 SPA and a Blazor 0.7 WASM app over the same gateway. One has the right architecture and broken plumbing; the other has naive architecture and a working shop. The contrast is the lesson.
DShop runs a whole SignalR service to push operation results to the browser in real time - JWT handshake, per-user groups, Redis backplane. No frontend connects to it, and both UIs sleep through eventual consistency instead.
The storage catalog entry is really five templates over one base module - blob, file, queue, table and static website - and the least-used wrapper is where every copy-paste defect in the estate went to hide.
DShop puts all its authorization at the gateway and none in the services behind it - then publishes every service port to the host. The compose file quietly defeats the entire security model.
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.
DShop's gateway answers a write with 202 Accepted and a header pointing at an operation that hasn't happened yet. Reading the contract shows a clean async-REST design - and two small bugs that undercut it.
DShop.Api.Next rebuilds the whole code-first gateway as Ntrada configuration - a 17-line Program.cs and a folder of YAML. Reading both side by side shows exactly what you trade when a gateway becomes data.
DShop's gateway reads over HTTP and writes over a message bus - two dispatch mechanisms behind one controller. Reading it shows how a gateway can be a router and a publisher at the same time.
The smallest module in the catalog teaches the two biggest lessons: strict lookups that refuse to pass null downstream, and shared plans as standalone stacks that dozens of apps reference by nothing but a name.
The DShop monolith was abandoned with a NotImplementedException sitting directly in the order path. Reading its honest ledger is a masterclass in what an unfinished codebase confesses about itself.
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.
In DShop a customer is born in two steps - a record on sign-up, then a completed profile. Following both across the monolith and the swarm shows how a consistency model quietly rewrites a user flow.
