Microservices gelten als der moderne Weg, Software zu bauen. Für ein einzelnes Haus sind sie zunächst das Gegenteil: teurer und im Betrieb anspruchsvoller. Sie rechnen sich erst, wenn die Dienste bereits existieren und mehrere Anwendungen sie sich teilen.
Genau das ist unser Ausgangspunkt. Das SOLUTIONS Framework besteht aus zehn Diensten, die produktiv laufen und von jeder Anwendung mitbenutzt werden. Sie zahlen nicht dafür, dass dieser Unterbau entsteht, sondern dafür, dass Sie ihn benutzen. Die folgenden Abschnitte erklären, warum dieser Unterschied den Ausschlag gibt.
Eine große Anwendung oder viele kleine
Klassisch gebaute Unternehmenssoftware ist ein zusammenhängendes Programm. Auftragserfassung, Benutzerverwaltung, Auswertung und Mailversand liegen im selben Code, nutzen dieselbe Datenbank und werden gemeinsam ausgeliefert. Fachleute nennen das einen Monolithen, was abwertender klingt, als es gemeint ist: So ein System ist einfach zu entwickeln und zu betreiben.
Die Schwächen zeigen sich mit der Zeit. Jede Änderung an einem Teil erfordert, das Ganze neu auszuliefern. Wenn dienstags um zehn vierhundert Leute Aufträge erfassen und parallel die Monatsauswertung läuft, konkurrieren beide um dieselben Ressourcen, obwohl nur eines knapp ist. Und eine zweite Anwendung im Haus fängt bei null an.
Eine Microservice-Architektur schneidet dasselbe Problem anders: Jeder Baustein wird ein eigenständiger Dienst mit klarer Aufgabe und eigener Datenhaltung. Das löst die drei Probleme, und es schafft neue.
Warum Microservices meistens ein Kostentreiber sind
Wer eine Anwendung in Dienste zerlegt, verteilt nicht nur Code, sondern auch Arbeit. Was im Monolithen einmal existiert, existiert danach fünfmal. Dazu kommen die Verbindungen dazwischen: Deutsche Softwarehäuser veranschlagen in eigenen Kostenübersichten 3.500 bis 21.000 Euro pro Schnittstelle, und eine solche Landschaft besteht zu einem guten Teil aus Schnittstellen.
Der größte Aufwand entsteht nicht im Bau, sondern im Betrieb: Ein Team, das bisher eine Anwendung betrieben hat, betreibt danach ein verteiltes System. Eine nie zuvor betriebene Technologie in einen geschäftskritischen Pfad zu heben, ist erfahrungsgemäß das größte Einzelrisiko. Entscheidend ist deshalb, wer den Aufbau bezahlt und wie viele Anwendungen ihn sich danach teilen.
Selbst bauen oder unseren Unterbau mitbenutzen
Ob sich die Architektur lohnt, hängt fast vollständig davon ab, ob die Dienste schon existieren. Links steht, was ein Haus auf sich nimmt, das sie selbst baut; rechts, was bei uns bereits läuft.
Selbst bauen
bei uns
Die Dienste, die jede neue Anwendung mitbenutzt
Bei uns ist dieser Aufbau bezahlt. Das SOLUTIONS Framework besteht aus zehn eigenständigen Diensten, die produktiv laufen und geteilt werden. Eine neue Fachanwendung erbt SOLUTIONS.user, SOLUTIONS.email, SOLUTIONS.transformer und SOLUTIONS.dashboard am Tag ihrer Entstehung.
Anmeldung, Rollen, feingranulare Zugriffsregeln, Zwei-Faktor-Verfahren. Mehr über SOLUTIONS.user
Anbindung an Active Directory: Anmeldung und Gruppen aus der bestehenden Struktur. Mehr über SOLUTIONS.connect_LDAP
Benachrichtigungen und Freigaben, mit fachlich gepflegten Vorlagen. Mehr über SOLUTIONS.email
Import und Abgleich mit Fremdsystemen, grafisch zusammengesteckt. Mehr über SOLUTIONS.transformer
Auswertungen über die Daten jeder angebundenen Anwendung. Mehr über SOLUTIONS.dashboard
Verschlüsselte Ablage für Passwörter; in Listen taucht der Wert nie auf. Mehr über SOLUTIONS.vault
Erzeugt PDF-Dokumente aus Vorlagen, ausgelöst durch einen Vorgang. Mehr über SOLUTIONS.file
Zentrale Stelle für die Konfiguration aller Anwendungen, dazu eine Übersicht, welche gerade läuft. Mehr über SOLUTIONS.admin
Rechtegeprüfter Zugriff für Werkzeuge und Sprachmodelle, mit denselben Rechten wie in der Oberfläche. Mehr über SOLUTIONS.mcp
Sammelt die Texte aller Anwendungen ein und gibt sie Übersetzern in einer Weboberfläche. Mehr über SOLUTIONS.translate
Wie die Dienste miteinander sprechen
Zwischen den Diensten liegt ein Nachrichtenweg, wir verwenden dafür das quelloffene NATS. Er funktioniert wie eine interne Poststelle: Ein Dienst legt eine Nachricht mit einem Betreff ab, und wer dafür zuständig ist, greift sie ab. Mal wartet der Absender auf Antwort, etwa bei der Frage, ob ein Benutzer etwas darf. Mal wird nur mitgeteilt, dass etwas geschehen ist.
Entscheidend ist, was nicht geteilt wird: die Datenbank. Braucht eine Fachanwendung Benutzerdaten, greift sie nicht in die Datenbank von SOLUTIONS.user, sondern bekommt die Modelle über den Nachrichtenweg gereicht. Deshalb lässt sich ein Dienst austauschen, ohne nachzusehen, wer sonst in seine Tabellen schreibt. Die Bausteine darunter sind bewusst gewöhnlich: Angular, NestJS, MongoDB, Docker und Kubernetes für den Betrieb. Mehr dazu steht im Aufbau einer Fachanwendung.
So hängt Ihre Anwendung an den Diensten
Ihre Fachanwendung steht mitten im SOLUTIONS Framework und nicht daneben. Über den Nachrichtenweg erreicht sie jeden der zehn Dienste, ohne dass in ihrem Code mehr steht als die Angabe, welche sie braucht. Das Modell dazu entsteht im SOLUTIONS.designer. Wie das Modellieren funktioniert
Was der Betrieb kostet und wann ein Monolith bleibt
Ein verteiltes System ist im Betrieb anspruchsvoller; das lässt sich nicht mit einem Werkzeug wegkaufen. Der Unterschied zur selbst gebauten Landschaft ist nur, dass dieser Aufwand bei uns einmal getragen wurde und nicht je Projekt anfällt.
Die Dienste sind dabei keine Bedingung, sondern eine Wahl: Was eine Anwendung nicht braucht, wird nicht zugeschaltet. Wer keinen Verzeichnisdienst betreibt, lässt die Anbindung weg und führt seine Benutzer in SOLUTIONS.user selbst; wer keine Auswertungen braucht, bekommt keine. Anmeldung und Rechte bleiben in jedem Fall, denn ohne die gibt es keine Fachanwendung.
Und was davon erhalten Sie? Ihre Anwendung und die Basisbibliotheken in der Fassung Core gehen mit Quellcode über, ebenso SOLUTIONS.user und SOLUTIONS.vault, weil an ihnen die Anmeldung hängt. Die übrigen Dienste brauchen ein eigenes Nutzungsrecht und laufen nach Vertragsende im vorhandenen Stand weiter. Der vollständige Schnitt steht unter Lizenzmodell und Quellcode.
Was ein verteiltes System zusätzlich braucht
Was sich ab dem zweiten Dienst nicht mehr weglassen lässt.
Das lässt sich nicht wegkonstruieren, nur einplanen. Schreibende Vorgänge werden bei Verbindungsverlust zwischengespeichert und wiederholt, allerdings nur bei Fehlern, bei denen das Sinn ergibt.
Eine Anfrage über vier Dienste ist ohne Hilfsmittel nicht zu analysieren. Deshalb sind alle Dienste mit OpenTelemetry ausgestattet, dem offenen Standard für Ablaufverfolgung: Jeder Aufruf trägt seine Kennung weiter, und die Spur zeigt, welcher Dienst wie lange gebraucht hat. Wohin die Daten fließen, steht in SOLUTIONS.admin.
Jeder Container beantwortet alle 15 Sekunden eine Gesundheitsabfrage. Fällt sie aus, ersetzt die Orchestrierung ihn, ohne dass um drei Uhr nachts jemand angerufen wird.
Ein Dienst muss sich beim Neustart sauber verabschieden: offene Verbindungen schließen, laufende Nachrichten zu Ende bringen, erst dann beenden. Wer das übersieht, merkt es nicht am Fehler, sondern an Neustarts, die länger dauern als nötig. Deshalb gehört das Beenden bei uns zum Bauplan jedes Dienstes und nicht zur Feinarbeit danach.
Angaben zum Betrieb: eigener Stand August 2026.
Weiterlesen
Statt einer großen Anwendung besteht das System aus mehreren eigenständigen Diensten. Jeder hat eine klare Aufgabe und eigene Daten. Ein Fehler in der Auswertung legt nicht die Auftragserfassung lahm.
Wer die Dienste selbst bauen müsste, fährt mit einer einzelnen Anwendung meist besser mit einem Monolithen. Diese Rechnung stellt sich bei uns aber nicht: Der Unterbau existiert und läuft, Sie schalten davon zu, was Ihre Anwendung braucht. Damit bekommen Sie die Vorteile der Trennung, ohne den Aufbau zu bezahlen, schon bei der ersten Anwendung.
Drei, und für alle drei gibt es bei uns eine Antwort. Ein Netzwerkaufruf zwischen zwei Diensten kann fehlschlagen, ein Aufruf im selben Programm nicht; schreibende Vorgänge werden deshalb zwischengespeichert und wiederholt. Die Fehlersuche über mehrere Dienste braucht durchgängige Ablaufverfolgung; alle Dienste sind mit OpenTelemetry ausgestattet, das Ziel steht in SOLUTIONS.admin. Und der Betrieb ist anspruchsvoller; er läuft auf Kubernetes, wahlweise bei uns. Der Aufwand dafür ist einmal angefallen, nicht je Projekt.
Zwingend nicht, jeder unserer Dienste ist ein Docker-Container. Ab einer Handvoll Diensten wird es ohne Orchestrierung aber mühsam: Neustart nach Absturz, Lastverteilung. Wir betreiben die Dienste auf Kubernetes, bei uns oder bei Ihnen.
Es fällt der Teil aus, der ihn braucht, nicht die ganze Anwendung. Steht SOLUTIONS.email, arbeiten Ihre Mitarbeiter weiter. Bei zentralen Diensten wie SOLUTIONS.user ist der Unterschied kleiner, als es in Prospekten klingt. Sie laufen deshalb mehrfach.
Sprechen Sie mit uns.