Capacity statt Lizenz-Tetris

Wer eine moderne Datenplattform betreibt, kennt die Frage, die im Jahres-Budget-Gespräch regelmäßig auftaucht: "Was kostet uns die Lösung nächstes Jahr?" Die Antwort in einer klassischen, werkzeugzentrierten Plattformwelt ist ehrlich — und unbefriedigend: "Das kommt drauf an."

Drauf an, wie viele Teams wachsen. Drauf an, wie viele Pipelines täglich laufen. Drauf an, ob Compute-Ressourcen sauber heruntergefahren werden oder unbemerkt weiter ticken. Und ob man Lizenzen für Peak-Last oder Durchschnittslast beschafft hat. Beides ist teuer — nur auf unterschiedliche Arten.

Microsoft Fabric begegnet dieser Frage mit einem grundlegend anderen Ansatz: dem Capacity-Modell. Was das bedeutet, wo es hilft — und wo Anforderungen bestehen bleiben — ist Thema dieses Beitrags.

Das klassische Modell: Lizenz plus Infrastruktur plus Betrieb

Eine konventionelle Datenplattform besteht aus Einzelkomponenten. Ein Data Warehouse hier, ein ETL-Tool dort, ein BI-Layer obendrauf, dazu Compute in der Cloud für Transformationen und Storage für die Rohdaten. Jede Komponente hat ihr eigenes Preismodell:

Lizenzkosten: Per User, per Core, per Node — vertraglich gebunden

Cloud-Compute: Pay-as-you-go: jede Pipeline, jeder Spark-Job, jede Query

Cloud-Storage: Pro GB gespeichert + pro GB gelesen/geschrieben

Betrieb & DevOps: Monitoring, Patching, Skalierung, Incident-Handling

Netzwerkkosten: Datentransfer zwischen Diensten, Regionen, Egress

Das Ergebnis ist eine Kostenstruktur mit mehreren variablen Anteilen. Einige davon sind planbar wie etwa Lizenzen für eine bekannte Nutzerzahl. Andere sind es kaum: Wie viele GB werden nächsten Monat transformiert? Wie viele Ad-hoc-Queries schickt das Analysten-Team ab? Wie viel Rendering entsteht, wenn ein neues Reporting-Dashboard live geht?

Zwei Strategien, beide mit Haken

Unternehmen begegnen dieser Unsicherheit typischerweise mit einer von zwei Strategien — oder einer Kombination aus beiden.

Die erste Strategie ist Überprovisionierung: Man beschafft Ressourcen für die erwartete Spitzenlast. Das stellt sicher, dass kein Engpass entsteht — aber im Normalbetrieb läuft ein erheblicher Teil der bezahlten Kapazität leer. Klassisches Beispiel: Ein dediziertes SQL-Warehouse, das auf den Monatsabschluss ausgelegt ist, aber 27 von 30 Tagen halb ausgelastet ist.

Die zweite Strategie ist aktives Ressourcen-Management: Man konfiguriert Auto-Scaling, Plant Shutdown-Zeitfenster, setzt Budget-Alerts und schult Teams darin, Ressourcen sauber zu starten und zu beenden. Das funktioniert aber erfordert dauerhaften Aufwand wie ein zuverlässiges Monitoring über alle Dienste hinweg und die Disziplin konsequent dabei zu bleiben.

• Überprovisionierung
  Sicher, aber teuer — Kapazität für den Peak, der selten eintritt
• Aktives Management
  Flexibel, aber aufwändig — kontinuierliches Monitoring & Steuerung
• Das Ergebnis
  Beide Wege schaffen Budget-Unsicherheit und operativen Overhead

Das Fabric Capacity-Modell: eine Größe, die atmet

Microsoft Fabric ersetzt dieses Mosaik durch eine einzige Steuerungsgröße: die Fabric Capacity, gemessen in Capacity Units (CU). Eine Capacity deckt alle Workloads ab, die innerhalb der zugeordneten Workspaces laufen — Data Engineering, Data Warehousing, Real-Time Analytics, Power BI, Data Science und mehr. Es gibt keine separaten Infrastrukturkosten, keinen Cloud-Betriebsaufwand, keine Egress-Überraschungen. Plattformbetrieb ist im SaaS-Preis enthalten.

Der einzige verbleibende Kostenblock mit direkter Abhängigkeit zur Nutzung sind die gespeicherten Daten im OneLake — dieser ist der am einfachsten planbare Anteil und der günstigste im Vergleich zu Compute.

Der fundamentale Unterschied zur klassischen Welt: Das Capacity-Modell wird nicht auf Peak ausgelegt, sondern auf den erwarteten Durchschnitt. Was passiert, wenn dieser Durchschnitt überschritten wird — z.B. durch einen großen Ladevorgang oder eine intensive Analyse-Session — regelt der Mechanismus von Burst und Smoothing.

Burst und Smoothing: Kapazität, die Schulden macht und tilgt

Wenn ein Workload vorübergehend mehr CU verbraucht als die Capacity-Größe nominell erlaubt, greift Fabric nicht sofort ein. Stattdessen wird die Überschreitung als interne Schuld verbucht. Die Plattform lässt den Burst zu — und gleicht ihn in Phasen geringer Auslastung wieder aus, indem weniger Kapazität beansprucht wird, als vorhanden wäre.

Prinzip: Burst & Smoothing über die Zeit

• Capacity-Limit: 100 %
• Peak-Last – Burst: Schulden entstehen
• Glättung – Smoothing gleicht aus
• Durchschnitt – Planungsbasis
• Idle – Schulden werden abgebaut

Dieses "Atmen" macht die Capacity-Größe zur Planungsbasis für den Durchschnitt — nicht für den Worst Case. Solange Lastspitzen zeitlich begrenzt sind und sich mit Ruhephasen abwechseln, bleibt die Plattform stabil, ohne dass man skalieren muss.

Wichtig: Die Schulden-Toleranz ist nicht unbegrenzt. Wenn akkumulierte Burst-Schulden einen Schwellwert erreichen, reagiert Fabric gestaffelt: Zunächst werden neue Tasks verzögert (Throttling), bei weiterer Überschreitung werden sie abgewiesen (Rejection). Das Monitoring dieser Schwellen ist deshalb ein wesentlicher Bestandteil des Capacity-Managements.

Planung auf Durchschnitt: das gleiche Grundproblem — anders gelöst

Man sollte ehrlich sein: Das Problem der Lastabschätzung löst das Capacity-Modell nicht. Auch hier muss man abschätzen, wie intensiv die Plattform im Schnitt genutzt wird. Diese Schätzung ist besonders am Anfang schwierig — und bei dynamisch wachsenden Datenlandschaften bleibt sie eine Herausforderung. Das Modell kann aber „auf Sicht“ gefahren werden.

Das Capacity-Modell bietet deutlich mehr Reaktionsfähigkeit: Wenn die Capacity zu klein gewählt wurde, kann sie in wenigen Klicks hochgesetzt werden. Wenn sie dauerhaft übergroß ist, kann man downsizen. Es gibt keine Vertragslaufzeiten pro Einzelkomponente, keine Wartezeiten auf Cloud-Ressourcen, keine Verhandlungsrunden. Ein Schieberegler an der Capacity im Azure Portal für den Admin genügt.

Workspace-Struktur als Hebel: Workload-Management

Ein oft unterschätzter Vorteil des Capacity-Modells liegt in der Möglichkeit, mehrere Capacities zu betreiben und Workspaces flexibel zuzuordnen. Das eröffnet eine neue Dimension der Steuerung: Workload-Management auf Organisationsebene.

Konkret bedeutet das: Eine Organisation kann unterschiedliche Capacities für unterschiedliche Nutzungsprofile anlegen. Eine große Capacity für die tägliche, intensive Produktion. Eine kleinere für Entwicklung und Testing. Eine dedizierte für zeitkritische Echtzeit-Analysen. Wenn ein Projekt endet oder ein Team in eine neue Phase übergeht, wird der Workspace einfach einer anderen Capacity zugeordnet — ohne Datenmigration, ohne neue Konfiguration.

BEISPIEL: CAPACITY-ZUORDNUNG NACH NUTZUNGSPROFIL

• Produktion (F64)
  Tägliche Pipelines, Reporting, Echtzeit — hohe Auslastung, stabil
• Entwicklung (F8)
  Experimente, neue Features, Datenprodukten — diskontinuierlich
• Burst-Reserve (F16)
  Monatsabschluss, Batch-Läufe, saisonale Spitzen — temporär

Diese Flexibilität erlaubt es, die teuren Kapazitäten dort zu konzentrieren, wo sie gerade gebraucht werden — und die Gesamtkosten über das Portfolio zu optimieren, statt jede Anwendung einzeln überzuprovisionieren.

Monitoring bleibt, aber mit einem Cockpit

Auch wenn das Capacity-Modell die Kostenkomplexität stark vereinfacht: Auf Monitoring kann und sollte man nicht verzichten. Die Fabric Capacity Metrics App ist das zentrale Instrument dafür. Sie zeigt in nahezu in Echtzeit, wieviele CU verbraucht werden, welche Workloads die meiste Kapazität beanspruchen, wann Burst-Schulden entstehen und ob man sich Schwellwerten nähert.

Monitoringziel und Handlungsstrategie im Capacity-Modell

• Dauerhaft hohe Auslastung: Capacity upscaling — ein Schritt, kein Vertrag
• Burst-Schulden häufen sich: Lastverteilung prüfen oder Workspace neu zuordnen
• Einzelner Workload dominiert: Workspace in eigene Capacity auslagern
• Kapazität dauerhaft niedrig: Downsizing — Kosten senken ohne Dienstunterbrechung
• Schwellwert-Annäherung: Alert-Konfiguration für proaktives Eingreifen nutzen

Der wesentliche Unterschied zur klassischen Welt: Man überwacht nicht mehr viele verschiedene Dienste mit unterschiedlichen Metriken und Dashboards. Ein Cockpit, eine Metrik-Familie, eine Handlungslogik. Das reduziert den kognitiven Aufwand erheblich — und macht Alerting gezielter.

Wo das Modell Grenzen kennt: Items mit fester Ressourcenzuweisung

Das Capacity-Modell mit Burst und Smoothing setzt voraus, dass Workloads nach Bedarf gestartet und beendet werden können — also ein serverless Betriebsmodell unterstützen. Für viele Fabric-Workloads ist das der Fall: Dataflows, Notebooks, Pipeline-Ausführungen oder Power BI-Queries laufen on-demand und geben Ressourcen frei, wenn sie fertig sind.

Einige Fabric-Items funktionieren aber anders. Sie benötigen dauerhaft laufende Infrastruktur — und reservieren daher einen festen CU-Anteil innerhalb der zugeordneten Capacity:

Item/Service – Grund für feste CU-Reservierung

• Eventstreams: Kontinuierliche Stream-Verarbeitung, keine Pause möglich
• Spark-Cluster (always-on): Warme Cluster für minimale Latenz beim Job-Start
• SQL-Datenbanken (Fabric DB): Persistente Query-Engine muss jederzeit antworten
• Echtzeit-Dashboards (KQL): Niedrige Query-Latenz erfordert bereitstehende Compute

Für diese Items gilt: Man muss beim Capacity-Design einkalkulieren, wie viel CU sie dauerhaft belegen — und den verbleibenden "freien" Anteil für die dynamischen, serverless Workloads disponieren. Eine zu kleine Capacity kann hier dazu führen, dass der Spielraum für Burst-Toleranz eng wird.

Empfehlung: Items mit fester CU-Reservierung in der Capacity Metrics App explizit tracken. Der "Background"-Verbrauch dieser Items ist vorhersehbar — und bildet die Baseline, auf die alle dynamischen Workloads aufgeschlagen werden.

Der direkte Vergleich auf einen Blick

• Dimension: Kostenbasis
  Klassisches Modell: Lizenz + Infrastruktur + Betrieb
  Fabric Capacity: Eine Capacity-Einheit (CU)

• Dimension: Skalierungslogik
  Klassisches Modell: Auf Peak-Last ausgelegt — oder manuell gesteuert
  Fabric Capacity: Auf Durchschnittslast ausgelegt, Peak durch Burst

• Dimension: Spitzenlasten
  Klassisches Modell: Sofortige Kosten oder manuelle Drosselung nötig
  Fabric Capacity: Burst + Smoothing: Schulden werden intern ausgeglichen

• Dimension: Reaktionsfähigkeit
  Klassisches Modell: Neue Verträge / Ressourcen beschaffen
  Fabric Capacity: Up-/Downsizing der Capacity in wenigen Klicks

• Dimension: Workload-Steuerung
  Klassisches Modell: Je Tool individuell konfigurierbar
  Fabric Capacity: Workspace-basiertes Kapazitätsmanagement

• Dimension: Planbarkeit Budget
  Klassisches Modell: Unsicherheitskorridor durch variable Anteile
  Fabric Capacity: Festes Budget, vorhersehbare Monatskosten

• Dimension: Monitoring
  Klassisches Modell: Mehrere Tools, unterschiedliche Metriken
  Fabric Capacity: Fabric Capacity Metrics App — ein Cockpit

• Dimension: Feste Ressourcen
  Klassisches Modell: Dedizierte Tier-Größen pro Service
  Fabric Capacity: Item-spezifische CU-Reservierung möglich

Fazit: Ein anderes Denken, nicht nur ein anderes Preismodell

Das Capacity-Modell von Microsoft Fabric ist kein bloßer Lizenzwechsel. Es verändert, wie man über Kosten einer Datenplattform nachdenkt. Statt Ressourcen für jeden Dienst einzeln zu beschaffen, zu überwachen und zu optimieren, arbeitet man mit einem einzigen Budget-Hebel — der Capacity-Größe — und einem klaren Mechanismus für Lastdynamik: Burst und Smoothing.

Das bedeutet nicht, dass alle Fragen verschwinden. Die Abschätzung der durchschnittlichen Last bleibt eine Herausforderung. Monitoring und Alert-Handling sind weiterhin notwendig. Und für Items mit dauerhaftem Ressourcenbedarf gilt es, Reservierungen sorgfältig einzuplanen.

Was sich aber grundlegend ändert: Die Handlungsoptionen werden schneller, die Kostentransparenz größer und die organisatorische Steuerung flexibler. Capacity kann täglich angepasst werden. Workspaces können neu zugeordnet werden. Und das Budget-Gespräch bekommt endlich eine ehrliche, planbare Antwort.