# Your Fabric Capacity Strategy Determines Everything

## Метаданные

- **Канал:** Guy in a Cube
- **YouTube:** https://www.youtube.com/watch?v=qWgt4-7tpGI
- **Источник:** https://ekstraktznaniy.ru/video/44581

## Транскрипт

### Segment 1 (00:00 - 04:00) []

Yooo, what is up everyone? Today I want to start at the top of the stack. I've been talking about architecture, but I wanna start at the top of the stack for Microsoft Fabric, and that's at the capacity because that's usually where accountability is either designed in. Or what? Completely ignored, overlooked. Nobody thinks about it. When we start evaluating our data platform, the capacity is the first place you need to look. So what I'm gonna do is walk you through why, so you know what you like to do. Enough of all this talking. Let's do what, let's head over to my laptop. So the first thing you wanna do is if you're in Fabric, click on the gear or the admin portal. And you choose capacity settings and you'll see your capacities. In our case, we have two capacities. Who's responsible for these capacities? Who sees the bill? Who explains the overage? Who answers if performance degrades? And so you can see here, let me just click on this one. You can see we have an F64 or P1. Why did we choose to SKU? Who decided it was the right size? It probably was Adam. Is there a clear accountable owner or, let's scroll down a little bit. Do we just have a list of admins? If the answer to that question is IT handles it, that's not ownership. That's outsourcing the accountability. If no one clearly owns the capacity, then guess what? No one owns the cost of that capacity, and when cost is not owned optimization, it becomes completely optional. So now we hopefully know who owns it, but let's see what's attached to that capacity. So if we scroll down a little further, you'll see which workspaces are running, are assigned to this capacity. And you can see like we have lots of workspaces. We're not monitoring any of them. We have like five, six pages of workspaces. If I go back to page one, are the dev and prod workspace is isolated from each other on separate capacities, or are multiple domains sharing the exact same capacity? If one workload spikes, is that because of a noisy neighbor who feels that if everything shares the same compute, risk? Your capacity decision defines. The blast radius. And the blast radius in this case is architectural 'cause it's built in. Now that we know what's attached to the capacity, we need to see what's going on under the hood. And to do that, we look at the fabric capacity metrics app. And so you can see we have some fabric capacities that I have paused, but you can see we have some reserve capacities that we're using here. And it's just not a lot. There's not a lot going on our capacity, but if I'm looking at this capacity metrics app, I'm trying to see what the utilization looks like. Are there spikes? It's usually predictable. Who reviews this? Is it reviewed daily, weekly, or only when something breaks? Can the cost be tracked back to the domain, or is it one shared bill that just quietly gets absorbed? If cost isn't attributable, behavior won't change. People optimize what they own. I own my car. I go get my car fixed. I make sure my car runs, but if no one owns it, no one optimizes it. Again, not governance structure. Let's talk about scaling. Who decides when we need to scale up our capacity? Is it tied to measurable thresholds or does someone increase capacity when performance drops? So in other words, is scaling reactive. If scaling is reactive, accountability wasn't designed in, don't use Surge Protection as a solution for your bad performance. Surge Protection is just a bandaid. Capacity isn't just infrastructure. It's an architectural bound area. You know how I call semantic models that are not properly designed with star schema, ugly babies. If your capacity doesn't have an owner, your capacity is now an ugly baby. If you don't intentionally design your capacities, accountability does not exist. So what do you think? Any questions, comments? Next time I'm gonna move from the capacity down into the workspace. Let's continue the conversation. We're in the comments below. If you wanna learn more about Fabric, Power BI more architect stuff, more AI stuff, probably a video flying above my head. And as always, Marthe, Adam, this guy. Thanks for watching. See you the next video.