Michael Heider hatte sich spontan mit einem Wunschthema gemeldet: Seit der letzten Konferenz beschäftigt er sich intensiv mit Microservices – und damit, wie sich beim Arbeiten mit AI Tokens sparen und zugleich die Sicherheit erhöhen lässt. Was er zeigte, ist ausdrücklich noch ein Prototyp, aber die Idee dahinter überzeugte die Runde.

Die Grundidee

Den Anstoß lieferte der spanische Referent Nicolás Franco Cerame auf der EngageU in Malmö, sinngemäß: Lass ein LLM das tun, was es gut kann – Texte verarbeiten und JSON zurückliefern –, und erledige alles andere ohne AI. Michael ist dem nachgegangen und hat sich zunächst per AI eine ganze Reihe kleiner Dienste erstellen lassen. Den Code hat er vielfach gelesen, “aber ich hätte die selber jetzt nicht in ein paar Tagen zusammengekriegt”.

Was ist ein Microservice?

Ein Microservice ist eine kleine, spezialisierte Anwendung, die auf einem bestimmten Port auf Anfragen wartet und genau eine Aufgabe erfüllt – die aber in der Regel sehr gut. Michaels Dienste laufen als Python-Anwendungen auf einem Mac mini M2 und werden über REST angesprochen. Das Prinzip ist deutlich älter als der AI-Trend; neu ist nur, wie leicht man solche Dienste heute bauen lassen kann.

André Kopietz fühlte sich an Skills erinnert. Adam ordnete ein: Gedanklich lässt sich durchaus eine Brücke schlagen – Skills enthalten ja oft ebenfalls Skripte als Artefakte. Der entscheidende Unterschied liegt aber im Zweck: Microservices halten die AI gezielt aus dem Spiel. Michael ergänzte, warum etwa die Pseudonymisierung gerade kein Skill sein darf: Sobald ein Skill greift, sind die Daten bereits beim LLM.

Die Dienste im Überblick

Michael stellte seine Sammlung in einer FileMaker-Oberfläche vor, die als Orchestrator dient – in der Mitte, passend zum Abend, ein Web Viewer. Zu den Diensten gehören unter anderem:

  • PDF-Konverter – holt Texte und Inhalte aus PDFs und Bildern, komplett lokal und ohne LLM
  • Transkript – erzeugt aus Audio- und Videodateien Texte, ebenfalls ohne LLM
  • Pseudonymizer – ersetzt vor dem Versand an ein LLM Namen, Straßen, Vertragstitel und mehr und setzt die Originale in der Antwort wieder ein
  • Extrakt – zieht bestimmte Informationen aus bestimmten Dokumenten
  • Codecheck – prüft eingesetzten Code, etwa HTML-Seiten oder Python-Skripte, auf versteckte Funktionen wie das Weiterleiten von Daten an fremde Adressen
  • Modell-Rechner – ermittelt, welche Modelle auf der vorhandenen Hardware sinnvoll laufen, bevor ein zu großes Modell durch Auslagerungen “schnarchlangsam” wird
  • Belegerkennung – eine Kette mehrerer Dienste: PDF in PNG wandeln, Text auslesen, als JSON zurückgeben
  • Ausgabe – erzeugt lokal Kalendereinträge, Markdown, Mindmaps, Excel-Dateien, Webseiten, Prozessmodelle und Texte

Nur wenige Dienste greifen überhaupt auf ein LLM zu. Der LLM-Dienst kennt mehrere lokale und externe Server; bei jeder Anfrage lässt sich wählen, wohin sie geht. Lokal läuft auf einem eigenen Server LM Studio, derzeit mit einem Qwen-Modell – “kein besonders tolles Modell, aber für meine Tests reicht es”.

Pseudonymisierung als Standard

Für Michael ist der Datenschutz mindestens so wichtig wie die Kostenersparnis. Standardmäßig wird pseudonymisiert, sobald ein Cloud-Dienst im Spiel ist, bei lokalen Diensten nicht. Grundlage ist eine frei verfügbare Python-Bibliothek, in der sich detailliert einstellen lässt, was ersetzt werden soll – bis hinunter zu Städtenamen und Postleitzahlen. Eine Zuordnungstabelle sorgt dafür, dass die Antwort beim Eintreffen per Code wieder in die Originaldaten übersetzt wird.

Nachvollziehbare Ketten

Wichtig ist Michael vor allem die Transparenz: Wenn mehrere Dienste zu einer Kette verbunden werden, soll jederzeit nachvollziehbar sein, welcher Aufruf mit welchen Parametern wohin geht und was zurückkommt. Die Architektur ist offen – weitere Dienste lassen sich nach Bedarf ergänzen. Und wie bei Adams Widgets entstand auch hier vieles durch beschreibendes Programmieren: Claude sagen, was man haben will, das Ergebnis prüfen, einsetzen.

Warum sich der Aufwand lohnt

Adam brachte die Motivation auf den Punkt: Es geht nicht darum, dass die AI diese Aufgaben schlechter könnte – ein Word-Dokument kann sie inzwischen auch erzeugen. Aber das kostet Tokens, während eine seit Jahren ausgereifte Bibliothek dasselbe kostenlos erledigt. Auch wenn Tokens später vielleicht deutlich teuer werden, ist dieser Ansatz sinnvoll. Entweder mit lokalen Modellen, die eher Strom als Tokens kosten, oder eben mit Microservices.

Holger Herbst ergänzte den Gedanken der zentralen Bereitstellung: Solche Dienste können nicht nur aus FileMaker, sondern aus jeder Webanwendung genutzt werden – etwa für die einheitliche Prüfung von E-Mail-Adressen oder Telefonnummern. Ob die Bibliotheken in Python, JavaScript oder Go geschrieben sind, spielt dabei keine Rolle. Entscheidend ist nur, dass die Dienste nicht öffentlich im Internet erreichbar sind.

Dirk Schittko betreibt bereits einige Microservices direkt auf FileMaker Servern. Der Vorteil: Endlich wird die Hardware richtig ausgelastet, statt dass nur ein einzelner Kern arbeitet.

Unterm Strich ein spannender Ansatz, wo es sich lohnt, sich näher damit zu befassen.