Ein erfolgreiches SaaS-Produkt zu entwickeln bedeutet nicht, einfach eine funktionierende Webanwendung zu veröffentlichen. Das Produkt muss seine Performance halten, während es neue Kunden gewinnt, Kundendaten sicher voneinander trennen, sich unterbrechungsfrei aktualisieren lassen und die Kosten der wachsenden Nutzung nachhaltig im Griff behalten.
Skalierbarkeit ist daher kein Infrastrukturproblem, das man erst angeht, wenn das Produkt gewachsen ist. Sie ist eine grundlegende Designentscheidung, die das gesamte Produkt betrifft – vom Geschäftsmodell über die Datenarchitektur und die Nutzererfahrung bis hin zur Preisgestaltung.
Ein guter Ansatz für die SaaS-Softwareentwicklung beantwortet die folgende Frage:
Kann das Produkt sicher, beherrschbar und wirtschaftlich bleiben – sowohl bei zehn Kunden als auch bei Hunderten oder Tausenden?
In diesem Leitfaden zeigen wir, wie Sie ein skalierbares SaaS-Produkt planen sollten – mit Blick auf Produktstrategie, mandantenfähige Architektur, Datenisolation, Sicherheit, DevOps und Betrieb.
Was ist SaaS-Software?
SaaS steht für „Software as a Service“. Dabei wird die Software nicht in der Umgebung des Kunden installiert, sondern vom Dienstleister betrieben und über das Internet bereitgestellt.
Nutzer greifen in der Regel über ein Abonnement- oder nutzungsbasiertes Bezahlmodell auf das Produkt zu. Infrastruktur, Updates, Sicherheit und Betrieb der Software werden vom Team verantwortet, das den Dienst anbietet.
Ein SaaS-Produkt kann einige oder alle der folgenden Merkmale aufweisen:
- Zentraler Zugriff über das Internet
- Abonnement- oder nutzungsbasierte Preisgestaltung
- Automatisierte Anlage von Kunden und Benutzern
- Bereitstellung für mehrere Kunden über dieselbe Plattform
- Rollen- und Berechtigungsverwaltung
- Nutzungsmessung und Abrechnung
- Zentrale Updates und Versionsverwaltung
- Kundenspezifisches Reporting und individuelle Konfiguration
SaaS und Multi-Tenant-Architektur sind nicht dasselbe. SaaS ist ein Geschäfts- und Bereitstellungsmodell; Multi-Tenancy ist dagegen einer von mehreren Architekturansätzen, um mehrere Kunden zu bedienen. Bei einem SaaS-Produkt können einige Komponenten gemeinsam genutzt werden, während andere kundenspezifisch laufen.
Was bedeutet ein skalierbares SaaS-Produkt?
Ein skalierbares SaaS-Produkt kann die Servicequalität auf einem akzeptablen Niveau halten, wenn die Zahl der Nutzer, Kunden, Daten oder Transaktionen steigt.
Echte Skalierbarkeit bedeutet jedoch mehr, als die Serverkapazität zu erhöhen. Sie umfasst mindestens fünf verschiedene Dimensionen:
Technische Skalierbarkeit
Das System muss wachsenden Traffic sowie steigende Daten- und Transaktionsvolumen bewältigen können.
Operative Skalierbarkeit
Für jeden neuen Kunden dürfen keine manuelle Einrichtung, keine manuell angelegte Datenbank und keine Codeänderung nötig sein.
Organisatorische Skalierbarkeit
Wenn das Team wächst, dürfen Entwicklungs-, Test- und Release-Prozesse nicht unbeherrschbar werden.
Finanzielle Skalierbarkeit
Mit steigender Kundenzahl dürfen die Infrastrukturkosten nicht schneller wachsen als der Umsatz.
Produktskalierbarkeit
Unterschiedliche Kundenanforderungen dürfen nicht zu einer unkontrollierten Individualisierung des Kernprodukts führen.
Eine erfolgreiche SaaS-Architektur betrachtet diese Dimensionen nicht isoliert voneinander. Ein Produkt, das technisch schnell läuft, aber für jeden Kunden manuellen Betrieb erfordert, ist wirtschaftlich nicht skalierbar.
Wie sollte die SaaS-Entwicklung beginnen?
1. Geschäftsmodell und Zielgruppe klären
Bevor Sie eine Technologie auswählen, sollten Sie festlegen, an wen das Produkt verkauft wird, welches Problem es löst und über welches Modell es vertrieben wird.
Zu Beginn sollten folgende Fragen beantwortet werden:
- Handelt es sich um ein B2B-, B2C- oder Hybridmodell?
- Wie viele Benutzer kann ein Kundenkonto umfassen?
- Nach welchen Funktionen werden die Kunden in Pakete eingeteilt?
- Erfolgt die Preisgestaltung nach Benutzern, Transaktionen, Nutzung oder festen Paketen?
- Werden Unternehmenskunden besondere Sicherheits- oder Integrationsanforderungen stellen?
- Müssen Kundendaten in einem bestimmten Land gespeichert werden?
- Welches Wachstum und welches Nutzungsvolumen strebt das Produkt an?
Diese Entscheidungen beeinflussen die gesamte technische Architektur – vom Tenant-Modell über die Datenstruktur bis hin zu Autorisierung und Abrechnung.
2. MVP-Umfang richtig festlegen
Das Ziel eines Minimum Viable Products ist nicht, möglichst wenig Code zu schreiben, sondern die zentrale Geschäftsannahme mit möglichst geringem Risiko zu validieren.
Ein gut geplantes SaaS-MVP:
- löst das Kernproblem des Nutzers,
- testet das zentrale Wertversprechen des Produkts,
- erzeugt messbare Nutzungsdaten,
- lässt sich anhand von Feedback anpassen,
- legt die zukünftige Architektur des Produkts nicht vollständig fest.
Wer in der ersten Version jede denkbare Funktion entwickelt, verlängert die Time-to-Market. Grundlegende Themen wie Sicherheit, Datenisolation und Autorisierung komplett aufzuschieben, kann dagegen später hohe Umbaukosten verursachen.
Ziel ist es, Architekturfehler zu vermeiden, die das Wachstum behindern würden, ohne Komplexität aufzubauen, die noch gar nicht gebraucht wird.
Wie entwirft man eine Multi-Tenant-SaaS-Architektur?
In einer Multi-Tenant-Architektur bedient eine einzige Softwareplattform mehrere Kunden, also Tenants. Die Tenant-Struktur muss dabei jedoch nicht in jeder Komponente identisch sein.
Es gibt im Wesentlichen drei Ansätze.
Gemeinsame Anwendung und gemeinsame Datenbank
Alle Kunden nutzen dieselbe Anwendung und dieselbe Datenbankinfrastruktur. Die Datensätze werden in der Regel über ein Feld wie tenant_id getrennt.
Vorteile:
- Niedrige Infrastrukturkosten
- Zentrale Updates
- Einfache gemeinsame Ressourcennutzung
- Hohe operative Effizienz
Risiken:
- Die Datenisolation muss auf Anwendungsebene sorgfältig umgesetzt werden
- Risiko von Datenlecks zwischen Kunden durch fehlerhafte Abfragen
- Ein Kunde mit hoher Last kann andere beeinträchtigen
- Schwierige Sicherung und Wiederherstellung pro Kunde
Gemeinsame Anwendung und getrennte Datenbanken
Die Anwendungsschicht wird gemeinsam betrieben, während für jeden Kunden eine eigene Datenbank oder ein eigenes Schema verwendet wird.
Vorteile:
- Stärkere Datenisolation
- Einfachere Sicherung und Wiederherstellung pro Kunde
- Möglichkeit, Unternehmenskunden dedizierte Ressourcen anzubieten
- Kontrolliertere Abgrenzung von Performance-Auswirkungen
Risiken:
- Steigender Betriebsaufwand mit wachsender Zahl an Datenbanken
- Verwaltung von Schema-Updates
- Zunehmend komplexeres Verbindungs- und Ressourcenmanagement
- Höhere Infrastrukturkosten pro Kunde
Hybrides Tenant-Modell
Standardkunden nutzen die gemeinsame Infrastruktur, während Kunden mit hohem Volumen oder besonderen Compliance-Anforderungen auf separate Ressourcen verlagert werden können.
Der hybride Ansatz bietet wachsenden B2B-SaaS-Produkten Flexibilität. Wie Kunden zwischen gemeinsamen und dedizierten Umgebungen migriert werden, sollte jedoch von Anfang an geplant werden.
Das passende Tenant-Modell wählen Sie, indem Sie Kundenanzahl, Datenvolumen, Sicherheitserwartungen, Anpassungsbedarf und die angestrebten Kosten pro Kunde gemeinsam bewerten.
Modularer Monolith oder Microservices?
Ein häufiger Fehler in SaaS-Projekten ist es, die erste Version des Produkts früher als nötig in Microservices aufzuteilen.
Die Microservice-Architektur bietet wichtige Vorteile wie unabhängige Skalierung und Bereitstellung. Sie bringt jedoch auch folgende Kosten mit sich:
- Verteiltes Datenmanagement
- Kommunikation zwischen Services
- Netzwerkfehler und Latenz
- Bedarf an Observability
- Probleme bei Messaging und Konsistenz
- Komplexere Test- und Release-Prozesse
- Hoher DevOps-Aufwand
Für viele SaaS-Produkte in der Frühphase kann ein modularer Monolith mit sauber gezogenen Grenzen der ausgewogenere Start sein. Mit dem Wachstum des Produkts lassen sich nur jene Module in eigenständige Services auslagern, die unterschiedliche Skalierungs- oder Betriebsanforderungen haben.
Die Architekturentscheidung sollte nicht auf Trends beruhen, sondern auf den tatsächlichen Anforderungen des Systems.
Wie baut man eine skalierbare Datenarchitektur auf?
Das Wachstum eines SaaS-Produkts wird häufig eher von der Datenschicht begrenzt als vom Anwendungscode. Das Datenmodell sollte daher nicht nur die heutigen Tabellen abbilden, sondern auch künftige Nutzungs- und Isolationsanforderungen unterstützen.
Tenant-Kontext zentral verwalten
Jede Operation muss wissen, für welchen Kunden sie ausgeführt wird. Die Tenant-Information sollte nicht einfach anhand eines Parameters aus der Oberfläche bestimmt werden, sondern sicher aus dem Authentifizierungs- und Autorisierungsfluss abgeleitet werden.
Datenisolation nicht den Abfragen überlassen
Strukturen, bei denen Entwickler jeder Abfrage manuell einen Tenant-Filter hinzufügen müssen, erhöhen das Fehlerrisiko. Eine gemeinsame Datenzugriffsschicht, richtlinienbasierte Filterung oder Sicherheitsmechanismen auf Datenbankebene sollten in Betracht gezogen werden.
Lese- und Schreiblasten trennen
Wenn Reporting-Abfragen und alltägliche operative Vorgänge dieselben Ressourcen beanspruchen, kann es mit wachsendem Produkt zu Performance-Problemen kommen. Hier bieten sich Caching, Lese-Replikate, analytische Datenspeicher oder ereignisbasierte Datenströme an.
Grenzen für Partitionierung und Sharding festlegen
Sharding ist zu Beginn nicht immer erforderlich. Man sollte jedoch überlegen, nach welchem Schlüssel die Daten künftig aufgeteilt werden. In SaaS-Anwendungen ist die Tenant-ID häufig einer der natürlichen Kandidaten für die Partitionierung.
Sharding kann die Kapazität erhöhen, bringt aber zusätzliche Komplexität für Prozesse wie die Zuordnung von Tenant und Datenbank, Datenmigration, Sicherung und Reporting mit sich.
Wie skaliert man die Anwendungsschicht?
Stateless-Services entwerfen
Wird die Benutzersitzung oder ein temporärer Zustand im Arbeitsspeicher eines einzelnen Anwendungsservers gehalten, wird die horizontale Skalierung schwierig. Bei zustandslosen Services lassen sich neue Anwendungsinstanzen je nach Bedarf einfach hinzuschalten.
Persistenter oder gemeinsam genutzter Zustand sollte in einer geeigneten Datenbank, einem verteilten Cache oder Objektspeicher-Diensten verwaltet werden.
Lange Vorgänge in den Hintergrund verlagern
Vorgänge wie Berichtserstellung, Verarbeitung großer Dateien, Massenversand von E-Mails oder die Synchronisation mit externen Systemen sollten nicht innerhalb der Web-Anfrage des Nutzers abgeschlossen werden.
Message Queues und Hintergrund-Worker:
- verkürzen die Antwortzeit für den Nutzer,
- fangen plötzliche Lastspitzen ab,
- ermöglichen die Wiederholung fehlgeschlagener Vorgänge,
- unterstützen die unabhängige Skalierung von Workloads.
Cache kontrolliert einsetzen
Richtig eingesetzt, reduziert ein Cache die Datenbanklast und die Antwortzeit. Werden Kundendaten jedoch mit falschen Schlüsseln zwischengespeichert, kann es zu Datenlecks zwischen Tenants kommen.
Cache-Schlüssel sollten den Tenant-Kontext enthalten; Gültigkeitsdauer und Regeln zur Datenaktualisierung müssen klar definiert sein.
Rate Limiting einsetzen
Wenn ein einzelner Kunde oder eine einzelne Integration unkontrolliert Traffic erzeugt, kann das die Erfahrung der anderen Kunden beeinträchtigen, die dieselben Ressourcen nutzen. Tenant- oder paketbasierte Ratenlimits, Kontingente und Nutzungsrichtlinien sollten definiert werden.
Sicherheit ist ein zentraler Bestandteil des SaaS-Produkts
SaaS-Sicherheit ist kein Test, der nach Abschluss des Projekts durchgeführt wird. Sie muss im gesamten Produktlebenszyklus verankert sein.
Authentifizierung und Autorisierung trennen
Die Authentifizierung bestimmt, wer der Nutzer ist, die Autorisierung, welche Aktionen er ausführen darf. Zugriffsregeln auf Ebene von Benutzer, Rolle, Team, Tenant und Ressource sollten jeweils separat entworfen werden.
Bei Unternehmensprodukten können folgende Funktionen erforderlich sein:
- Mehrfaktor-Authentifizierung
- Single Sign-on
- Rollenbasierte Zugriffskontrolle
- Detaillierte Berechtigungsverwaltung
- Sitzungs- und Geräterichtlinien
- Verwaltung des Benutzerlebenszyklus
Daten bei der Übertragung und Speicherung schützen
Kommunikationskanäle sollten verschlüsselt werden; sensible Daten in Datenbanken, Dateien und Backups müssen mit geeigneten Verfahren geschützt sein. Schlüssel und Zugangsdaten dürfen nicht im Quellcode gespeichert werden.
Audit-Logs erstellen
Bei kritischen Vorgängen muss nachvollziehbar sein, wer wann welche Änderung an welcher Ressource vorgenommen hat. Audit-Logs sind sowohl für Sicherheitsprüfungen als auch für die Compliance-Erwartungen von Unternehmenskunden wichtig.
Einen sicheren Entwicklungsprozess etablieren
Code-Reviews, automatisierte Sicherheitsscans, Abhängigkeitsprüfungen, Scans nach Geheimnissen und regelmäßige Penetrationstests sollten Bestandteil des Entwicklungsprozesses sein.
Warum sind DevOps und automatisierte Auslieferung wichtig?
Im SaaS-Modell nutzen alle Kunden das zentral betriebene Produkt, sodass ein Fehler im Release-Prozess weitreichende Auswirkungen haben kann. Deshalb ist es ebenso wichtig, sicher zurückrollen zu können, wie häufig zu aktualisieren.
Ein ausgereifter Auslieferungsprozess sollte Folgendes umfassen:
- Automatisierte Tests
- Reproduzierbare Einrichtung der Umgebungen
- Continuous Integration
- Kontrolliertes Deployment in die Produktion
- Verwaltung von Datenbankmigrationen
- Versions- und Feature-Flags
- Canary- oder stufenweise Releases
- Szenarien für automatisches Rollback
Die Verwaltung der Infrastruktur als Code verringert die Unterschiede zwischen Entwicklungs-, Test- und Produktionsumgebungen. Neue Umgebungen müssen nicht von Hand aufgebaut werden, sondern lassen sich aus denselben Definitionen reproduzieren.
Ohne Observability lässt sich Skalierung nicht steuern
Ein SaaS-Produkt sollte nicht nur danach überwacht werden, ob es „läuft“ oder „nicht läuft“. Das Systemverhalten muss im Kontext von Kunde und Geschäftsergebnis verstanden werden.
Technische Metriken
- Antwortzeiten
- Fehlerraten
- Transaktionsvolumen
- CPU- und Speicherauslastung
- Datenbankverbindungen
- Warteschlangenlänge
- Cache-Trefferquote
Tenant-bezogene Metriken
- Nutzung pro Kunde
- Ressourcenverbrauch
- Fehler- und Latenzraten
- Überschreitung von Kontingenten
- Ressourcenintensivste Vorgänge
- Kosten pro Kunde
Produktmetriken
- Aktivierungsrate
- Funktionsnutzung
- Nutzerbindung
- Wechsel von der Testphase zum kostenpflichtigen Paket
- Kundenabwanderung
- Customer Lifetime Value
Monitoring-Daten ohne Tenant-Kontext erschweren es, in einer gemeinsamen Infrastruktur zu erkennen, welcher Kunde von einem Problem betroffen ist. Personenbezogene oder sensible Daten dürfen jedoch nicht unkontrolliert in Logs und Metriken geschrieben werden.
Wie behält man die SaaS-Kosten im Griff?
Automatische Skalierung darf nicht bedeuten, dass Ressourcen unbegrenzt genutzt werden. Bei einem skalierbaren SaaS-Produkt sollte die Auswirkung jeder technischen Entscheidung auf die Unit Economics gemessen werden.
Zu den Kennzahlen, die Sie im Blick behalten sollten, gehören:
- Infrastrukturkosten pro Kunde
- Kosten pro Benutzer oder Transaktion
- Bruttomarge pro Paket
- Tenants mit hohem Ressourcenverbrauch
- Ungenutzte Kapazität
- Kosten für Datenspeicherung und ausgehenden Traffic
Preisgestaltung und Infrastrukturverbrauch sollten miteinander verknüpft werden. Verursachen beispielsweise die Speicherung großer Dateien, intensives Reporting oder eine hohe API-Nutzung Kosten, können die Paketlimits entsprechend gestaltet werden.
Beim FinOps-Ansatz geht es nicht nur darum, die Cloud-Rechnung zu senken, sondern die wirtschaftlichen Auswirkungen der Produktnutzung sichtbar zu machen.
Häufige Fehler bei SaaS-Produkten
Skalierbarkeit mit zusätzlichen Servern gleichsetzen
Ein schlechtes Datenmodell, synchron laufende lange Vorgänge und unkontrollierte Integrationen lassen sich nicht allein durch größere Server tragfähig machen.
In der Frühphase eine überdimensionierte Architektur aufbauen
Für ein noch nicht validiertes Produkt zahlreiche Microservices und eine komplexe Infrastruktur aufzubauen, kann den Markteintritt verlangsamen.
Tenant-Isolation nachträglich hinzufügen
Wird der Kundenkontext nicht von Anfang an in das Datenmodell und das Autorisierungssystem eingebaut, ist ein späterer Umbau teuer und riskant.
Für jeden Kunden individuellen Code entwickeln
Unkontrollierte Kundenanpassungen erschweren die Aktualisierung des Kernprodukts. Unterschiedliche Anforderungen sollten möglichst über Konfiguration, Feature-Flags und erweiterbare Integrationen abgedeckt werden.
Das Monitoring auf Infrastrukturmetriken beschränken
Dass der Server gesund aussieht, heißt nicht, dass alle Kunden das Produkt problemlos nutzen. Kennzahlen auf Ebene von Transaktion, Tenant und Produkt sollten gemeinsam überwacht werden.
Backups mit einem Disaster-Recovery-Plan verwechseln
Ein vorhandenes Backup allein genügt nicht. Es muss regelmäßig getestet werden, ob sich die Daten tatsächlich innerhalb der angestrebten Zeit wiederherstellen lassen.
Roadmap für die SaaS-Softwareentwicklung
Eine beispielhafte Roadmap für ein skalierbares SaaS-Produkt kann aus folgenden Phasen bestehen:
- Validierung des Geschäftsziels und des Nutzerproblems
- Festlegung von Produktumfang und Erfolgskennzahlen
- Gestaltung der Nutzererfahrung und der zentralen Abläufe
- Aufbau des Tenant-, Daten- und Autorisierungsmodells
- Auswahl von Technologie und Cloud-Architektur
- Entwicklung des MVP in agilen Iterationen
- Aufbau von automatisierten Tests und Auslieferungsinfrastruktur
- Durchführung von Sicherheits- und Performance-Tests
- Go-live mit einer begrenzten Nutzergruppe
- Weiterentwicklung des Produkts anhand der Nutzungsdaten
- Regelmäßige Optimierung von Kosten- und Kapazitätsmodell
Jede Phase sollte ein messbares Ergebnis liefern. Erfolg bemisst sich nicht nur daran, dass das Produkt pünktlich veröffentlicht wird, sondern am Nutzen für die Anwender und an einem nachhaltigen Betrieb.
Wie geht Tekno Danışman an SaaS-Projekte heran?
Tekno Danışman betrachtet die SaaS-Softwareentwicklung nicht nur als Programmierarbeit. Geschäftsmodell, Nutzererfahrung, Architektur, Sicherheit, Integration und Live-Betrieb werden in derselben Produkt-Roadmap bewertet.
Je nach Anforderungen des Projekts kann der Prozess folgende Leistungen umfassen:
- Produkt- und Technologie-Discovery
- MVP-Scoping
- UX-Design
- SaaS- und Tenant-Architektur
- Entwicklung von Web- und Mobile-Anwendungen
- API- und Systemintegrationen
- Zahlungs- und Abonnement-Abläufe
- Cloud-Infrastruktur und DevOps
- Automatisierte Tests und Sicherheit
- Monitoring, Wartung und kontinuierliche Verbesserung
Das Ziel ist nicht nur, eine funktionierende erste Version zu entwickeln, sondern ein steuerbares und messbares digitales Produkt zu schaffen, das mit steigender Nutzung sicher mitwachsen kann.
Fazit
Ein skalierbares SaaS-Produkt braucht vor leistungsstarken Servern zunächst richtige Produktentscheidungen, klare Architekturgrenzen und messbare Betriebsprozesse.
Werden Tenant-Isolation, Datenarchitektur, Sicherheit, automatisierte Auslieferung und Kostenkontrolle von Anfang an gemeinsam gedacht, wird das Wachstum des Produkts besser planbar. Sie müssen nicht jede Eventualität am ersten Tag lösen; entscheidend ist ein Fundament, das künftige Veränderungen nicht blockiert, überprüfbar ist und sich schrittweise weiterentwickeln lässt.
Haben Sie eine neue SaaS-Idee, oder stößt Ihr bestehendes Produkt beim Wachstum an technische Grenzen?
Planen wir Ihr Projekt gemeinsam
Lassen Sie uns gemeinsam Ihr Geschäftsziel, Ihre Nutzeranforderungen und die aktuellen technischen Rahmenbedingungen bewerten und den umsetzbaren ersten Schritt für Ihr Produkt festlegen.
Häufig gestellte Fragen
Wie lange dauert die SaaS-Softwareentwicklung?
Die Dauer hängt von Produktumfang, Integrationen, Benutzerrollen und Sicherheitsanforderungen ab. Ein validierbares MVP lässt sich in mehreren Phasen entwickeln, während umfassende Unternehmensplattformen eine längere Produktreise erfordern.
Ist der Einsatz von Microservices für ein SaaS-Produkt zwingend?
Nein. Viele Produkte können mit einem gut gestalteten modularen Monolithen starten. Microservices sollten in Betracht gezogen werden, wenn ein konkreter Bedarf entsteht, etwa unabhängige Skalierung oder Teamverantwortung.
Muss jedes SaaS-Produkt mandantenfähig sein?
Nein. SaaS ist ein Geschäftsmodell, Multi-Tenancy dagegen eine Architekturentscheidung. Ein Produkt kann eine gemeinsame, kundenspezifische oder hybride Infrastruktur nutzen.
Wie werden Kundendaten in einem SaaS-Produkt getrennt?
Die Daten können in gemeinsamen Tabellen mit Tenant-ID, in getrennten Schemata oder in kundenspezifischen Datenbanken gehalten werden. Die passende Methode wird anhand der Anforderungen an Sicherheit, Kosten, Skalierung und Betrieb gewählt.
Kann eine bestehende Software in ein SaaS-Modell überführt werden?
Ja. Lizenzierung, Tenant-Isolation, Autorisierung, Abonnement, Datenmigration und Betriebsprozesse müssen jedoch gemeinsam betrachtet werden. In den meisten Fällen bietet eine schrittweise Modernisierung einen kontrollierteren Ansatz als eine komplette Neuentwicklung in einem Zug.
