©️2025 Created by Anuradha Samaranayake
Which architecture style fits your workload?
CLOUD DIARY
AZURE · ARCHITECTURE · 2026
#Azure
#LandingZone
#Migration
#AppService
#CloudArchitecture
Which architecture style
fits your workload?
Assessment is done, the landing zone is ready, and someone asks the real question: what shape should this workload actually take in Azure?
There are six answers that cover almost everything we deploy. Each one comes with its own diagram, its own Azure services, and its own bill. Here's how to tell them apart, and how to pick without a three-meeting debate.
✍️ Anuradha · short on time? The picker near the bottom gets you to an answer in about 30 seconds.
📐 What a "style" actually decides for you
A style is not a product and not a reference architecture. It's a small set of rules about which building blocks the workload gets, and how they're allowed to talk to each other.
That sounds abstract until you notice how much it drives downstream. The style decides your subnet layout, whether you need private endpoints or a message broker, how many pipelines you maintain, what your on-call looks like, and where the cost lands. Pick it early — changing it after go-live is expensive.
The useful part: there are only six shapes worth knowing, and most workloads announce which one they are within a few questions.
🥞 N-tier
the one you'll meet on almost every migration
complexity
release speed
Layers stacked on top of each other: web, business logic, data. Each layer only calls the layer below it. This is what most on-premises line-of-business apps already are, which is exactly why it dominates lift-and-shift work.
↔ scroll the diagram on mobile · moving dots show the direction traffic flows
Where you'll meet it
A three-tier app on VMware moves to Azure. Web servers become App Service or VMs behind Application Gateway, the app tier keeps its own subnet, the database becomes Azure SQL. The shape doesn't change — only the hosting does.
What it means for the landing zone
Maps cleanly onto a spoke VNet with a subnet per tier and NSGs between them. Easiest style to explain to a security team, because the tiers are also network boundaries.
✓ existing layered apps moving to Azure✓ clear network segmentation per tier✓ teams new to cloud — familiar shape
! one change often touches every layer! slow release cycles! tiers scale together, so you overpay at the edges
🎫 Web-Queue-Worker
the PaaS default for a modernised app
complexity
release speed
A web front end answers users fast. Anything slow — reports, image processing, batch emails — goes onto a queue, and a worker picks it up in the background. Front end and worker scale independently.
↔ scroll the diagram on mobile · moving dots show the direction traffic flows
Where you'll meet it
The classic 'modernise while you migrate' target. You move an app to App Service, then pull the heavy jobs out of the request path into Functions so the site stops timing out under load.
What it means for the landing zone
Mostly PaaS, so the landing zone work shifts from subnets to private endpoints, managed identity, and outbound control through Front Door or a firewall.
✓ a simple domain with a few heavy jobs✓ you want managed services, not VMs✓ unpredictable spikes in background work
! both halves can quietly grow into monoliths! queue depth needs its own alerting! duplicate messages must be handled
🧩 Microservices
powerful, and the easiest one to get wrong
complexity
release speed
The application is split by business capability into small services. Each one is deployed on its own and owns its own data. They talk through APIs and messaging — never by reaching into each other's database.
↔ scroll the diagram on mobile · moving dots show the direction traffic flows
Where you'll meet it
Usually a rebuild rather than a migration. It shows up when several teams need to release independently and the existing monolith has become the bottleneck.
What it means for the landing zone
This is where landing zone maturity gets tested: container platform, private DNS, service-to-service identity, centralised logging, and a real CI/CD pipeline per service.
✓ complex domain, several teams✓ you need to release parts independently✓ failure of one capability must not stop the rest
! needs mature DevOps before it pays off! distributed data means eventual consistency! shared database = distributed monolith
📡 Event-driven
when something happens, several things must react
complexity
release speed
Producers publish events. Consumers subscribe and react, in near real time, without knowing about each other. Adding a new consumer doesn't require touching the producer.
↔ scroll the diagram on mobile · moving dots show the direction traffic flows
Where you'll meet it
IoT platforms, telemetry pipelines, order and payment flows, anything where one action must trigger several downstream reactions.
What it means for the landing zone
Throughput and retention sizing matter more than subnets. Plan for private endpoints on Event Hubs, dead-letter handling, and who owns each consumer.
✓ IoT and device telemetry✓ real-time dashboards and alerting✓ you keep adding new reactions to the same event
! event order is not guaranteed! consumers must tolerate duplicates! harder to trace end to end without good instrumentation
🗄️ Big data
two speeds, one place to report from
complexity
release speed
Data that is too large or too varied for one database. History is processed in batches, live data is processed as it arrives, and both land in a store that reporting and machine learning can query.
↔ scroll the diagram on mobile · moving dots show the direction traffic flows
Where you'll meet it
Data platform projects, IoT analytics, and the very common 'our reports take nine hours and nobody trusts them' conversation.
What it means for the landing zone
Storage layout, network isolation for the analytics workspace, and identity for pipelines matter far more than compute here. Fabric now removes a lot of the plumbing.
✓ reporting on large or mixed datasets✓ machine learning on historical data✓ live and historical views needed together
! many moving parts — start with managed services! cost is driven by storage tier and refresh frequency! governance is a project, not a checkbox
⚙️ Big compute
rent a supercomputer for an afternoon
complexity
release speed
One very large calculation split into many smaller ones that run at the same time across hundreds or thousands of cores. Some tasks are fully independent; others need to talk to each other constantly.
↔ scroll the diagram on mobile · moving dots show the direction traffic flows
Where you'll meet it
Engineering simulation, financial risk runs, seismic processing, rendering. Often a burst workload from an on-premises HPC cluster that has run out of capacity.
What it means for the landing zone
Quota and capacity planning come first. Then dedicated subnets, low-latency networking for coupled jobs, and a hard budget guardrail so a runaway job doesn't run all weekend.
✓ simulation, modelling, rendering✓ on-premises HPC that needs to burst✓ work that splits into independent tasks
! cost climbs fast — set budgets and auto-shutdown! tightly coupled jobs need InfiniBand-capable VM sizes! quota requests can take days, plan ahead
🎯 Pick a style for one workload
Answer for the workload in front of you, not the platform you wish you had.
📋 The six, side by side
How each one splits the work, and the Azure services you'd reach for first.
| style | how the parts are split | typical Azure services |
|---|---|---|
| 🥞 N-tier | Horizontal tiers, usually one subnet each | App Gateway · App Service / VMs · Azure SQL |
| 🎫 Web-Queue-Worker | Front end and background jobs, split by a queue | App Service · Service Bus · Functions · Redis |
| 🧩 Microservices | By business capability, one database each | AKS / Container Apps · APIM · Service Bus |
| 📡 Event-driven | Producers and consumers, fully independent | Event Hubs · Event Grid · Functions · Stream Analytics |
| 🗄️ Big data | Large datasets in chunks, batch plus stream | Fabric · Data Lake · Databricks · Power BI |
| ⚙️ Big compute | One calculation across many cores | Azure Batch · HPC VM sizes · Blob Storage |
🚦 The rules are the product
Every style is a trade: you accept some constraints, and in return you get properties you couldn't buy otherwise. Keep the label but drop the constraints, and you keep none of the benefits. Microservices is the clearest example.
WHAT YOU AGREE TO
- 📌 One service covers one capability
- 📌 Services don't depend on each other's internals
- 📌 Each service keeps its own data private
WHAT YOU GET BACK
- ✅ Deploy one service without a full regression cycle
- ✅ Faults stay inside one capability
- ✅ Release far more often
- ✅ Try new tech in one small blast radius
Let two services share one database "just for now" and you've built a distributed monolith: the operational cost of microservices with the release speed of a monolith. It's the most common way this style fails.
Being practical beats being pure. Bending a rule on purpose is fine — bending it by accident is what hurts. Write down which constraint you relaxed and why.
⚖️ Four trade-offs to check before you commit
Every style sends a bill along with the benefits.
🎚️
Complexity has to match the domain
Too much structure for a simple workload burns months. Too little for a complex one and dependencies quietly turn into a big ball of mud.
⏳
Async buys resilience, costs certainty
Queues and events let you retry and scale, but data becomes eventually consistent and messages can arrive twice. Design for both from day one.
🕸️
Every split adds network calls
What looks clean on a diagram shows up later as latency, retries and chatty east-west traffic. Watch it in the first load test, not in production.
🔧
Someone runs this at 2 AM
Monitoring, deployments, patching, on-call. If the operating model doesn't fit the team you actually have, the style is wrong regardless of how good it looks.
💬 How I choose on a real project
🧭
Start with the workload, not the tech
What does it do, who uses it, how critical is it, and how often does it change? The style usually falls out of those four answers.
👥
Match it to the team you have
Microservices without pipelines and platform skills is a slow-motion outage. The right style is the one the team can still run in six months.
🔄
Migrate first, then modernise
Rehost the N-tier app, get it stable, then pull the heavy jobs into a queue. Trying to do both at once is where timelines die.
📌 Mixing is normal. One landing zone happily hosts an N-tier finance app, an event-driven telemetry pipeline and a Fabric workspace. Choose per workload, not per organisation.
📚 Reference
Architecture styles →
N-tier →
Web-Queue-Worker →
Microservices →
Event-driven →
Big data →
Big compute →
Landing zones →
Diagrams drawn for this post using the official Microsoft Azure architecture icon set.
#Azure
#CloudArchitecture
#Microservices
#EventDriven
#Fabric
#HPC
#LandingZone
#AzureMigration