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.
77 articles filed under this topic.
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.
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.
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.
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.
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.
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.
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 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.
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.
The monolith and the microservices share the same command names. Decomposition here was one substitution - resolve a local handler, or publish to a broker - and reading both dispatchers shows exactly what changes.
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.
DShop exists as one deployable and as nine services built from the same requirements. Read side by side, the two builds show which decisions were decisions and which were defaults.
The catalog's finale: three child modules fanned out over locals maps turn AAD groups, APIM products and OpenAPI-imported APIs into reviewable code, map keys double as URL routing taxonomy, and policy XML gets environment-templated by a blunt string replace - plus a retrospective on what fifteen modules taught. Part 15 of the Terraform Module Catalog.
The public DNS template exposes every record type - A, AAAA, CAA, CNAME, MX, PTR, SRV, TXT - as an optional object list on a single module, and its twelve-kilobyte README quietly becomes the reference manual. When one module with optional shapes beats fifteen micro-modules, and when it stops being true. Part 13 of the Terraform Module Catalog.
The catalog's cautionary tale: an empty variables.tf, no platform JSON, UPDATE placeholders for every value, one pvars file for four declared workspaces, a subscription ID hardcoded into the provider, and a pipeline with a leftover debug step - what shipping a half-finished golden template does to the two hundred copies made from it, and a checklist for done. Part 14 of the Terraform Module Catalog.
The classic Front Door template does global entry properly - custom domains behind WAF policies, Key Vault TLS, HTTP-to-HTTPS redirect rules - and then teaches by counterexample: a hardcoded ARM resource ID where a lookup map should be, and a missing environment key silently swallowed by a forgiving default. Part 12 of the Terraform Module Catalog.
The catalog's most divergent template - a different module-source depth, extra pipeline-fed variables, a computed cluster name, CMK from a second Key Vault and a renamed provider alias - and what its dated Kubernetes pins say about version governance. Part 10 of the Terraform Module Catalog.
Inside the module with the biggest surface in the catalog: listener, pool, settings and probe objects cross-referenced by name, Key Vault TLS through a user-assigned identity, a private-by-default frontend - and a deliberately invalid placeholder IP that turns an unfilled template into a loud failure. Part 11 of the Terraform Module Catalog.
A search template that ships with "TBD" where partition and replica counts belong - so it cannot apply until someone makes a sizing decision - plus a three-way diagnostics choice documented entirely in commented-out code. Part 9 of the Terraform Module Catalog.
The smallest template in the catalog - a hundred lines of Redis cache config - as a study in what even the simplest secure-PaaS wrapper must still carry, and the one pipeline typo that quietly broke environment isolation. Part 8 of the Terraform Module Catalog.
A Data Factory template whose most important code is not HCL - after apply, an Azure CLI step finds the factory and a PowerShell step PATCHes the ARM resource to enable CMK and disable public network access, because the provider couldn't. Part 7 of the Terraform Module Catalog.
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.
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 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 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.
Reading the Function App module against its App Service sibling: the shared secure-hosting chassis, the runtime storage account and version knobs that are genuinely new, and what half-populated prod values teach about templates.
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.
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.