Series · 16 parts
One Shop, Every Shape
DevMentors built the same e-commerce shop twice - once as a monolith, once as nine services - with two gateways and two frontends. This series reads the whole estate as one artefact.
Topic
Azure & DevOps
77 articles filed under this topic.
Series in Azure & DevOps
Series · 15 parts
Terraform Module Catalog
Opening the Terraform Module Catalog with the library's flagship: how an App Service module bundles VNet integration, dual managed identities and Key Vault TLS into a surface app teams can fill in but not opt out of.
Series · 12 parts
Terraform on Azure
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.
Series · 18 parts
The Database Is the Message Bus
Five executables, zero queues - how an attendance platform coordinated a web app, three Azure Functions and a console job through one SQL database, and what that choice bought and cost. Part 1 of the series.
Series · 15 parts
Two Gateways and a Nervous System
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.
Standalone articles
Deploying ASP.NET Core to Azure App Service with GitHub Actions
A practical walkthrough of the pipeline that ships this very website: from push to production on Azure App Service, with secrets kept out of the repository and zero manual steps.
A Gateway in YAML and Its Twin in Code
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.
One YAML Flag Turns REST Into a Message
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.
Subscribing to Everything Without Referencing Anything
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.
Two Gateways and a Nervous System
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.
The Event Hubs Module: Maps of Hubs, Rules and Consumer Groups
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.
Naming Is Your API
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.
Cartography of an Estate
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 Cosmos DB Module: Where the Module Call Meets Raw Resources
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.
The Observability Stack of 2018
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.
A Pedagogy Ladder of Dockerfiles
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.
A Service Registry Made of Key Vault Secrets
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.
The Blazor App That Signs You Up Behind Your Back
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.
The Angular App That Forgot Its Auth Header
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.
Two Frontends, One API
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.
The Push Channel Nobody Plugged In
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.
One Storage Module, Five Thin Wrappers
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.
The Security Inversion
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.
Stock Modules Give You Resources; Glue Modules Give You a Platform
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.
The Header That Names the Future
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.
A Gateway Written in YAML
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.
One Shop, Two Front Doors
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 App Service Plan Module: Small Enough to Fail Loudly
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 Buy Path That Never Worked
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.
The Operator Console and the Maturity Ladder
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.
Who Creates the Customer?
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.