Get in touch
Open to principal-scope roles · Phoenix, Arizona · Remote or hybrid
Open to principal-scope roles · Phoenix, Arizona · Remote or hybrid
Playbook 05 · A landing zone that can carry a thousand tenants
The platform underneath everything else: landing zones, tenant isolation, tiering, resilience and cost, with the questions, the Azure build in order, and what it looked like at 1,000+ tenant databases.
Tap a tool for a quick explanation.
What is it?
A repeatable Azure foundation for identity, networking, governance and subscriptions.
Think of it as
The prepared site before you construct the buildings.
What is it?
Folders above Azure subscriptions that let you apply shared governance across them.
Think of it as
The organisation chart for your subscriptions.
What is it?
Rules that audit or enforce how Azure resources are configured.
Think of it as
Guardrails for what can be built and how.
What is it?
Infrastructure-as-code tools that describe resources so deployments can be reviewed and repeated. Bicep targets Azure; Terraform uses providers for many platforms.
Think of it as
A version-controlled construction plan.
What is it?
A network design with shared connectivity in a hub and separate workload networks in spokes.
Think of it as
A central interchange serving separate neighbourhoods.
What is it?
Multiple Azure SQL databases sharing a bounded pool of compute resources, useful when their demand varies.
Think of it as
Separate apartments sharing a utility budget.
What is it?
Azure Kubernetes Service runs a managed Kubernetes control plane for container workloads. You still own workload configuration and operations.
Think of it as
A managed control tower for your container fleet.
What is it?
Managed hosting for web applications and APIs, with platform features such as scaling and deployment slots.
Think of it as
A managed home for a web app.
What is it?
Managed container hosting for services and jobs, with scaling options and less direct cluster administration.
Think of it as
Run the container without operating your own Kubernetes cluster.
What is it?
Collects and analyses metrics, logs and traces, and supports alerts about your systems.
Think of it as
The instrument panel and alarm system.
What is it?
Tools for analysing cloud spending, allocating costs and setting budget alerts. An alert does not automatically stop spending.
Think of it as
The spending dashboard, not a hard spending lock.
What is it?
Discovery, assessment and migration tooling for planning and moving workloads to Azure.
Think of it as
Survey the estate, then plan the move.
What is it?
Replicates supported workloads and orchestrates disaster-recovery failover. Recovery still needs planning and testing.
Think of it as
A rehearsed route to a recovery site.
Every workload in an estate inherits its foundation: how subscriptions are organised, how networks connect, which rules the platform enforces, how tenants are kept apart, and how cost is attributed. When the foundation is right, teams ship into it without asking permission. When it is wrong, every project rebuilds a worse version of it. This playbook is the foundation I build for enterprises and for ISVs running multi-tenant SaaS, where the same questions arrive with a thousand customers attached.
The answers describe the estate as it is, which is usually different from the diagram on the wall.
The platform is built once, as code, and every workload lands into it. The tenant model is designed before the first tenant is migrated, because it is the one thing that is expensive to change later.
Subscriptions and management groups first because scope is what makes everything else cheap. A policy assigned at the right management group governs a thousand resources with one line. Assigned at the resource group, it governs that resource group.
Connectivity before code because the network is the thing most likely to be hand-built and never reproducible. Putting it in code second, after it exists, usually means it never happens.
Code before tenants because the tenant migration will be the biggest change the platform ever absorbs, and absorbing it on a hand-built foundation means every tenant inherits a slightly different environment.
The isolation model before migration because it is the one decision that cannot be reversed cheaply. Moving from row-level to database-per-tenant later is a data migration for every customer at once.
Compute by operability because the most expensive outage I have seen in SaaS was not a capacity problem. It was a platform the team could not debug at two in the morning.
Graduation criteria in writing because without them the top tier fills with tenants who complained loudest, and the economics of the long tail quietly stop working. On a 1,000+ database estate, explicit Business Critical criteria were the difference between predictable cost and a performance complaint queue nobody could reproduce.
Recovery tested on a calendar because every recovery objective is fiction until the restore has been run, timed, and signed by the person who would have to run it in a real incident.
Cost attributed by tag because a bill that cannot be explained gets cut by percentage, and percentages land on the wrong teams. Attribution turns cost from a complaint into a decision.
A SaaS estate on 1,000+ Azure SQL tenant databases. An ISV with unreproducible performance complaints and unpredictable cost. I classified the workloads, defined explicit Business Critical graduation criteria, worked the noisy-neighbour and CPU risk directly, and laid a staged path toward Fabric and AI readiness on a foundation that could carry it. The result was a stabilised estate with a tiering model the business could price.
A business-value assessment across roughly 3,000 employees. Applications, data, infrastructure, identity, security, cost and dependencies mapped onto a single view, with 32 gaps documented and each connected to a cloud or services decision. It surfaced $4.5M in cost avoidance, almost none of it from renegotiation and nearly all of it from finding what the organisation was doing twice. That single view is what a foundation assessment should produce.
HILUM Systems, a multi-tenant platform I am building. A clinical practice stood up in minutes: patient portal, admin console, scheduling, notifications. Identity, patient context, authorisation, audit and workflow are shared platform services, so specialty applications extend the platform instead of becoming silos. The tenant model was designed before the first screen, for the reasons above.
One subscription for everything with Owner granted to the team that got there first. A network drawn in a diagram and built by hand, so nobody dares change it. Tenants isolated by a column, with a query that forgot the filter once. A top tier defined by who complained. Backups that have never been restored. A bill that arrives as one number. And a Fabric or AI initiative that stalls in month two because the foundation cannot say which data belongs to which tenant. These are the findings that fill a foundation assessment, and each one maps to a gate in the method.
The subscription and management group design with every owner named. The policy set and the platform code in a repository, deployed by a pipeline, with the subscription vending process documented. The tenant isolation model with the tiers, the graduation criteria, and the price implications written down. Recovery objectives per tier and the date and duration of the last tested restore. A cost model attributed by product, tenant, and environment with budgets and owners. And the staged path to Fabric and AI, with the first step small enough to start next quarter.
Every playbook here follows the same five moves: Scope, Harden, Anchor, Measure, Sustain. The SHAMS Method is where they come from, and the gate check is how you find out which one your project is missing.
Next
How I take a product from a blank repository to something people depend on: data model, API, auth, front end, pipeline, observability and cost, with the questions, the build in order, and three products I ship myself.