Azure Solutions Architecture · AZ-305 · Architecture Case Studies · by Raushan Ranjan, MCT
The Problem: A Company's Cloud Challenge
Imagine a company called Tailwind Traders. They sell two main things: clothes (Apparel) and sports gear (Sporting Goods). They're like a store with two big sections.
Inside each section, they have different teams: a team that designs the products (Product Development), a team that advertises them (Marketing), and a team that sells them (Sales).
Now, all these teams and sections are starting to use a new service called Azure, which is a giant online computer service (the "cloud"). They're using it to build new websites, apps, and tools.
The big problem is:
- Who's paying for what? The company's boss (the CFO) wants to know exactly how much each section (Apparel, Sporting Goods) and each team (Marketing, Sales) is spending on Azure. They need a clear way to see the bill for everyone.
- A new project needs rules. The company is starting a brand new project to get customer feedback. The boss has two special rules for this project:
- Rule 1: Be cheap during testing. When the team is just testing the new project, they must use the cheapest computers available on Azure.
- Rule 2: Name things correctly. All the "computers" (called Virtual Machines or VMs) for this project must have a specific name, like Project-Feedback-VM-01.
The company needs a simple plan to solve both these problems. This is where we come in.
Part 1: Solving the "Who's Paying" Problem
Step 1: The Analogy - A Company's Budget System
Think of the company's problem like managing a big family's spending. The family has different members (Dad, Mom, Kids). Each person has their own projects and expenses.
You, the family's financial manager, want to know how much each person is spending.
- You also want to know the total family spending at the end of the month.
How would you set this up? You'd give each person their own bank account!
- Dad's Account: For Dad's projects.
- Mom's Account: For Mom's projects.
- Kids' Account: For the kids' stuff.
You'd also have a master bank account to see the total money flowing in and out of the family.
In Azure, we use a similar system:
- Subscriptions are like the individual bank accounts. Each one tracks the costs for a specific team or project.
- Management Groups are like the main family budget system. They hold all the individual accounts together. You can see the total spending and set rules for everyone from this level.
Step 2: Designing the Solution
We have to organize Tailwind Traders' "bank accounts" (Subscriptions) and "budget systems" (Management Groups) to match their real-life company structure.
We have two good options:
Option A (The Best Way): The "Department-First" Approach
- Top Level: A big container for the whole company, "Tailwind Traders." This is our main family budget system.
- Next Level: We create a container for each big section. We'll call them Management Groups.
- Management Group: Apparel
- Management Group: Sporting Goods
- Inside each container: We'll create individual "bank accounts" for each team. These are our Subscriptions.
- Inside "Apparel," we create three subscriptions: Apparel-Development, Apparel-Marketing, Apparel-Sales.
- Inside "Sporting Goods," we do the same: SportingGoods-Development, SportingGoods-Marketing, SportingGoods-Sales.
This is the best solution because it perfectly matches the company's structure. It's super easy to see the bill for the Apparel section, and within that, the bill for the Marketing team. The company's IT team can see the total cost for everything at the top level.
Option B (The "Simple" Way): The "Environment-First" Approach
- Top Level: "Tailwind Traders" container.
- Next Level: We create a container for "live" projects and "testing" projects.
- Management Group: Production (for things that are live and customers use)
- Management Group: Non-Production (for things that are still being built or tested)
- Inside each container: We might put just one or two subscriptions.
This is simpler, but it creates a problem. If the Apparel team and the Sporting Goods team both have live projects, their costs are all mixed together in the "Production" subscription. The CFO would have to spend a lot of time and effort to separate the costs, which defeats the purpose.
Conclusion: We recommend Option A because it’s the clearest and most direct way to solve the cost-tracking problem. It's a perfect match for the company's needs.
Part 2: Solving the "New Project Rules" Problem
Step 1: The Analogy - A Digital "Rule Enforcer"
The company needs to make sure the new project team follows two rules: use cheap computers and name them correctly.
Imagine a strict supervisor who sits at a desk. Whenever a team wants to create a new "computer" on Azure, they have to go to this supervisor first.
The supervisor looks at their request.
- Rule Check 1: Is the computer a cheap model? If yes, "approved." If no, "sorry, denied!"
- Rule Check 2: Is the computer's name correct? If yes, "approved." If no, "sorry, denied!"
This automated "supervisor" exists in Azure. It's a service called Azure Policy. It's our digital rule enforcer.
Step 2: Designing the Solution
We need to tell Azure Policy what rules to enforce for the new project.
First, for cost tracking: We'll use Tags. A tag is just a small digital sticker you can put on any resource. We'll tell the team to put a sticker that says Project: CustomerFeedback on everything they build. This is the simplest way to track costs, like putting a label on every expense slip.
Next, for the rules: We'll use Azure Policy.
We have two ways to enforce the rules:
Option A (The Best Way): The "Strict Deny" Approach
We create two rules with Azure Policy.
- Rule 1: "Only allow cheap computer models." We set this policy to Deny. This means if a developer tries to create an expensive computer, Azure will automatically stop them. It won't even let the computer exist.
- Rule 2: "Make sure the name starts with proj-cf." We also set this policy to Deny. If a developer tries to use the wrong name, Azure will block the request.
Why it's the best: This is a proactive solution. It prevents mistakes before they happen. The company can be 100% sure that no expensive computers are running and all resources are named correctly, which prevents headaches and wasted money later.
Option B (The "Gentle Audit" Approach)
We create the same two rules, but we set the policy to Audit instead of Deny.
What this does: It doesn't stop the developer. It just creates a report that says, "Hey, someone created an expensive computer," or "This computer has the wrong name."
Why it's not the best: The company still has the problem! The developer can create the expensive computer, and someone from the IT team has to manually go to them and say, "Please delete this and do it again." This is inefficient and can lead to a lot of wasted money and effort.
Conclusion: We recommend Option A because it's automated, strict, and guarantees the rules are followed without any extra work. It's the simplest and most effective way to solve the problem.
Summary of the Solution
- For the money problem: We'll organize the Azure accounts (Subscriptions) and management systems (Management Groups) to perfectly match the company's structure (Apparel, Sporting Goods, etc.). This makes cost tracking super easy and clear.
- For the project rules: We'll use a special Azure service called Azure Policy to automatically enforce the rules. We'll set it to block anyone who tries to use an expensive computer or a wrong name. This is a simple, no-fuss solution. We will also use Tags to easily track all the costs for this new project.