NatusAI
Die Debatte „Monolith oder Microservices“ beginnt oft mit dem Deployment-Diagramm. Ein Kasten oder viele? Die nützlichere Frage kommt aber früher: Welche Komplexität sollte Ihr Team selbst tragen – und welche sollte die Plattform übernehmen?
Ein kleines Team braucht ein klares Modell und einen kurzen Weg von der Idee zur funktionierenden Anwendung. Eine wachsende Organisation braucht zudem Kapazität, Ausfallsicherheit und Freiraum, damit Teams unabhängig arbeiten können. Diese Bedürfnisse hängen zusammen, sind aber nicht dieselben.
Cygnus erkundet eine andere Balance: Anwendungslogik und Daten in einem logischen Modell halten und dann weiterentwickeln, wie dieses Modell platziert und ausgeführt wird. Ziel ist es, die Integrationsarbeit zu verringern, die Entwicklungsteams immer wieder rund um getrennte Datenbanken, Dienste und KI-Werkzeuge aufbauen.
01 / Die Architekturentscheidung
Monolithen und Microservices lösen unterschiedliche Probleme.
Ein Monolith verpackt eine Anwendung als eine einzige deploybare Einheit. Er kann modular sein, sorgfältig getestet und hinter einem Load Balancer repliziert werden. Sein Reiz ist praktischer Natur: lokale Aufrufe, unkompliziertes Debugging und weniger bewegliche Teile. Seine Grenzen zeigen sich oft bei gemeinsamen Releases, Zuständigkeitsgrenzen oder ungleichem Ressourcenbedarf.
Microservices teilen eine Anwendung in unabhängig deploybare Dienste auf. Sie sind nützlich, wenn Domänen und Teams eigene Release-Zyklen, Skalierungsrichtlinien oder Betriebsgrenzen brauchen. Diese Unabhängigkeit bringt Arbeit mit sich: Netzwerkaufrufe, versionierte Verträge, Beobachtbarkeit, Fehlerbehandlung und oft Konsistenz über getrennte Datenspeicher hinweg.
Keines von beiden ist automatisch schneller oder skalierbarer. Ein gut entworfener Monolith kann eine große Workload bedienen. Ein schlecht partitioniertes Microservice-System kann seine Engpässe verteilen und sie schwerer sichtbar machen.
Monolith
Ein einziges Deployment. Interne Grenzen hängen vom Design des Codes ab.
Microservices
Unabhängige Dienste und Zuständigkeiten. Netzwerkverträge verbinden die Teile.
Cygnus-Design
Ein einheitliches Entwicklungsmodell. Verteiltes Deployment ist eine Richtung über v1 hinaus.
Die Unterscheidung ist wichtig, weil die Verteilung des Deployments und die fachliche Modularität getrennte Entscheidungen sind. Man kann Module ohne separate Dienste haben – und viele Server, ohne das logische Modell der Anwendung zu zersplittern.
02 / Ein logisches Modell
Datenbank und Backend näher zusammenbringen.
Cygnus ist das geplante Sprach-, Datenbank- und Backend-Fundament von NatusAI. Das Design bringt typisierte Anwendungslogik, persistente Daten und bereitgestellte Funktionen in eine kohärente Umgebung. Statt an jeder Grenze ein eigenes Mapping zu pflegen, arbeiten Entwicklungsteams mit vernetzten Objekten und den Funktionen, die auf ihnen operieren.
Das ist besonders für einen digitalen Zwilling oder eine operative Anwendung relevant. Ein Schiff, ein Gebäude oder eine Industrieanlage hat Identität, Beziehungen, Standort, Messwerte, Dokumente und eine Historie. Wer jede Sicht in ein eigenes, unverbundenes System auslagert, muss Verbindungen neu aufbauen, die im Unternehmen längst bestehen.
Ein einheitliches Modell soll diese Verbindungen bewahren. Zugleich erhält die Laufzeitumgebung mehr Informationen über Daten, Abfragen und Ausführung – Informationen, die künftige Entscheidungen zu Platzierung und Koordination unterstützen können.
Ein Modell für die Anwendung.
Mehr Optionen dafür, wo sie läuft.
Das ist ein Designprinzip, kein Versprechen, dass jede Workload transparent skaliert. Partitionsschlüssel, Abfragemuster, Transaktionsgrenzen und Latenz beeinflussen weiterhin, wie eine Anwendung gebaut werden sollte.
03 / Vier Wege zu wachsen
Anfragen und Daten als getrennte Anforderungen skalieren.
„Wir müssen skalieren“ kann mehr gleichzeitige Anfragen bedeuten, einen größeren Datenbestand, bessere Verfügbarkeit – oder alles drei. Replikation und Sharding adressieren unterschiedliche Teile dieses Problems. Die folgende Übersicht veranschaulicht die verteilte Designrichtung von Cygnus; sie ist kein laufender Cluster und keine veröffentlichte Deployment-Funktion.
01 · Einzelner Knoten
Mit einer kohärenten Anwendung beginnen
Anwendungslogik und der vollständige Datenbestand liegen gemeinsam auf einem Server. Das ist der Umfang des geplanten Deployment-Profils von Cygnus v1.
Einfachstes Betriebsmodell. Kapazität und Verfügbarkeit hängen von einem Server und seinen Wiederherstellungsverfahren ab.
02 · Replikate
Das Modell auf mehrere Knoten kopieren
In der verteilten Designrichtung tragen die Knoten denselben Anwendungscode und eine vollständige Kopie der Daten. Replikation kann Redundanz und zusätzliche Anfragekapazität unterstützen – abhängig vom Konsistenz- und Schreib-Routing-Modell.
Kopien müssen Aktualisierungen koordinieren. Mehr Replikate vervielfachen nicht automatisch den Schreibdurchsatz.
03 · Shards
Die Daten aufteilen, das Modell behalten
Der Anwendungscode bleibt gemeinsam, während jeder Knoten eine Partition der Daten verantwortet. Die Platzierung könnte je nach Workload Geografie, Zeitbereichen oder Schlüsselbereichen folgen.
Routing und partitionsübergreifende Abfragen brauchen explizite Regeln. Ungleich verteilte Daten oder Zugriffsmuster können Hotspots erzeugen.
04 · Beides
Jede Partition replizieren
Kapazität über Shards mit Redundanz innerhalb jedes Shards kombinieren. Die angestrebte Entwicklererfahrung bleibt eine logische Datenbank mit einem Backend, während die Laufzeitumgebung eine komplexere physische Topologie übernimmt.
Platzierung von Replikaten, Failover, Rebalancing und verteilte Transaktionen erfordern eine Qualifizierung. Dies ist eine Designrichtung über v1 hinaus.
vollständige Kopie der Daten eine Partition der Daten · Nur Illustration: kein laufender Cluster und keine veröffentlichte Deployment-Funktion.
Auf einem Knoten beginnen
Das geplante v1-Profil beginnt mit einem Server. Anwendungscode und Daten liegen zusammen – so bleibt das erste Deployment überschaubar. Backups, Wiederherstellung, Berechtigungen und Ressourcengrenzen bleiben Teil eines verantwortungsvollen Betriebs.
Replizieren für Redundanz und Anfragekapazität
Im künftigen verteilten Modell könnten mehrere Knoten denselben Code und eine vollständige Kopie des Datenbestands tragen. So entstehen mehr Stellen, an denen geeignete Anfragen bedient werden können, und das System kann einzelne Knotenausfälle verkraften. Das Ergebnis hängt von Routing, Replikationsverzögerung, Konsistenzgarantien und davon ab, welche Operationen auf welchen Replikaten laufen können.
Sharding für Datenkapazität
Wenn der Datenbestand einem Server entwächst, lösen zusätzliche vollständige Kopien das Speicherproblem nicht. Sharding verteilt die Daten auf mehrere Knoten. Eine Workload könnte nach Geografie, Zeitbereich oder Schlüsselbereich partitioniert werden. Abfragen über diese Partitionen hinweg brauchen Routing und manchmal verteilte Ausführung.
Eine einfache Kapazitätsrechnung: 30 TB logische Daten benötigen mindestens acht Server mit je 4 TB – noch vor Replikaten, Indizes, betrieblichen Reserven oder sonstigem Mehraufwand. Das ist Arithmetik, keine Kapazitätsmessung von Cygnus.
Beides kombinieren
Jeder Shard kann eigene Replikate haben. Shards liefern die gesamte Datenkapazität; Replikate ergänzen Redundanz und Möglichkeiten, Anfragen zu bedienen. Diese kombinierte Topologie meinen viele, wenn sie sich eine über eine Flotte verteilte Datenbank vorstellen.
Mit dem Bedarf wachsen und schrumpfen
Die längerfristige Richtung ist, diese Entscheidungen entlang von Workload-Richtlinien zu automatisieren: Kapazität ergänzen, wenn der Bedarf wächst, die Ausführung zu den benötigten Daten verlagern und Kapazität freigeben, wenn der Bedarf sinkt. Ziel ist, das logische Modell der Anwendung zu bewahren, während sich die Platzierung ändert.
Beim Herunterskalieren muss zuerst laufende Arbeit abgeschlossen werden, und die benötigten Datenkopien müssen sicher verlagert oder erhalten werden. Scheduling, Rebalancing, Konsistenz und Wiederherstellung brauchen explizite Regeln und eine Qualifizierung. Automatisches Hoch- und Herunterskalieren sind künftige Designziele für Cluster, außerhalb des geplanten Single-Server-Release v1.
04 / Die Verantwortung der Laufzeitumgebung
Koordination in die Plattform verlagern.
Die angestrebte Cygnus-Erfahrung behält eine Anwendungscodebasis und eine logische Datenbank, während sich das Deployment weiterentwickelt. Eine von der Laufzeitumgebung verwaltete Verteilung würde Platzierung, Routing, Replikation und die Mechanik der Koordination beteiligter Knoten übernehmen.
Diese Mechanik verschwindet nicht. Netzwerke bringen Latenz und Partitionen mit sich. Aktualisierungen brauchen Konsistenzregeln. Transaktionen über mehrere Shards brauchen ein definiertes Protokoll. Die Wiederherstellung muss wissen, was committet wurde, und Rebalancing darf die Zuständigkeit für Daten nicht verlieren, während sie verschoben werden.
Die Chance liegt darin, diese Aufgaben einmal in der Plattform umzusetzen – mit expliziten Verträgen und Betriebswerkzeugen –, statt jede Anwendung ihre eigene Variante zusammenbauen zu lassen. Die Anwendung braucht trotzdem Grenzen, die zu ihrer Workload passen.
05 / Daten im Zeitverlauf
Ein vernetztes Modell braucht ein Gedächtnis.
Viele Geschäftsfragen haben eine zeitliche Dimension, auch wenn niemand sie ausspricht. Wo war diese Anlage vor einem Vorfall? Welche Organisation hatte damals die Kontrolle? Was wusste das System, als es diese Empfehlung gab?
Das Cygnus-Design verbindet Graphbeziehungen, Geodaten, Vektoren, Tripel, Zeitreihen und Volltextsuche im selben logischen Fundament. Das sind Wege, ein Thema zu erkunden – keine getrennten Definitionen dessen, was dieses Thema ist.
- Graph & Tripel
Was ist verbunden – und wie?
- Geodaten
Wo war sie zu einem bestimmten Zeitpunkt?
- Zeitreihen
Wie haben sich ihre Messwerte entwickelt?
- Volltext & Vektoren
Welche Datensätze passen – oder bedeuten etwas Ähnliches?
Konzeptmodell. Historische Antworten brauchen zusätzlich aufbewahrte Quellversionen sowie die Herkunft von Retrieval, Modell und Prompt.
Historie für Daten – und Herkunftsnachweise für KI
Zeitbezogene Daten können beschreiben, wie sich eine Anlage, ihre Messwerte oder ihre Beziehungen verändern. Eine historische KI-Antwort erfordert mehr. Sie hängt auch von den Quelldokumenten, Embeddings, der Retrieval-Konfiguration, der Modellversion und dem Prompt ab, mit denen sie erzeugt wurde.
Eine aufbewahrte Datenhistorie bewahrt nicht automatisch jeden Vektorindex und reproduziert keine frühere Modellantwort. Ein sinnvolles Design verknüpft diese Versionen und protokolliert ihre Herkunft bewusst – damit eine Antwort auf die Belege und den Kontext verweisen kann, auf denen sie beruht.
Ein Fundament für Anwendungen und Tools
Die geplanten nativen MCP- und Chat-Fähigkeiten bieten Wege, erlaubte Funktionen bereitzustellen und vernetztes Wissen abzufragen. Ein Tool oder eine Dialogoberfläche sollte mit demselben Modell und derselben Zugriffsrichtlinie arbeiten wie die Anwendung. Eine historische Abfrage kann dann nach einem gewählten Zeitpunkt fragen und zugleich erklären, welche Belege und welche KI-Konfiguration für diese Antwort verfügbar sind.
Hier wird ein einheitliches Backend zu mehr als einer einfacheren Deployment-Geschichte: Es kann ein gemeinsames Fundament für operative Daten, Unternehmenshistorie und KI-gestützte Arbeit bieten.
06 / Die Grenzen wählen
Die Architektur an der Arbeit ausrichten.
Microservices bleiben sinnvoll, wenn unabhängige Teams, getrennte Sicherheitsgrenzen oder unterschiedliche Betriebsanforderungen sie rechtfertigen. Ein modularer Monolith bleibt sinnvoll, wenn ein gemeinsames Deployment das Team produktiv hält. Die Richtung von Cygnus ergänzt eine weitere Option: ein einheitliches Anwendungs- und Datenmodell, dessen Verteilung tiefer in der Laufzeitumgebung verwaltet wird.
Die richtige Wahl beginnt bei der Workload. Welche Anfragen dominieren? Wie schnell müssen Aktualisierungen sichtbar werden? Welche Daten gehören zusammen? Was passiert bei einem Netzwerkausfall? Welche Aufgaben brauchen eine unabhängige Zuständigkeit?
Unser Anspruch ist, dass Entwicklungsteams mehr Zeit für diese wesentlichen Entscheidungen haben und weniger Zeit damit verbringen, die Verbindungen zwischen ihren Werkzeugen neu aufzubauen. Mit einem kohärenten Modell beginnen. Die Geschäftsbeziehungen intakt halten. Das physische Deployment ausbauen, wenn Workload und Plattform bereit sind.
Weiterführende Literatur
- Martin Fowler: Monolith First (externe Website) – wie sich Architektur mit einem besseren Verständnis der Domänengrenzen weiterentwickeln kann.
- PostgreSQL: Warm Standby (externe Website) – ein Beispiel für Replikation, Standby-Betrieb und die Abwägungen zwischen synchronen und asynchronen Aktualisierungen.
- Microsoft Azure Architecture Center: Sharding pattern (externe Website) – Partitionsschlüssel, Routing und Überlegungen zur Verteilung von Daten.
- Umfang von Cygnus v1 und spätere Profile – der öffentliche Umfang und Status hinter dieser Designperspektive.