13 Apps, 1 Entwickler, eine Architektur

Vom Prototyp zur autonomen Infrastruktur: Wie ich 13 Apps ohne Team betreibe

Vor zwei Jahren stand ich vor einem CTO. Wir diskutierten über meine aktuelle Projektarchitektur. Sein Urteil war eindeutig und hart: "Was du da baust, funktioniert vielleicht als Prototyp. In Produktion brauchst du ein Team."

Das war eine typische Reaktion in der IT-Branche. Die Annahme war, dass Komplexität unvermeidlich ist, wenn man Systeme skalieren will. Mehr Nutzer, mehr Daten, mehr Features, das erfordert mehr Menschen, die wach bleiben, um die Systeme am Laufen zu halten.

Heute läuft eine andere Realität. Ich betreibe 13 aktive Anwendungen in der Produktion. Dahinter stehen 85 Container und 25 Datenbanken. Das Gesamtsystem läuft stabil, hochverfügbar und ohne ein einziges zusätzliches Teammitglied. Ich mache das allein.

Ich sage das nicht, um die Arbeit von DevOps-Teams oder SREs abzuwerten. Große Unternehmen brauchen diese Strukturen. Ich sage es, weil eine Architektur, die sich selbst überwacht und korrigiert, die Spielregeln für kleine Teams und Solo-Entrepreneure fundamental verändert. Es geht nicht darum, Menschen zu ersetzen, sondern um die Schaffung einer Infrastruktur, die intelligent genug ist, um Fehler zu erkennen, bevor sie zum Ausfall werden.

Die statische Verteidigung: 182 Regeln gegen Chaos

Das Herzstück meines Ansatzes ist die strenge Automatisierung. Man kann KI-Modelle nicht einfach loslassen und hoffen, dass sie die richtige Entscheidung treffen. Man braucht Leitplanken.

Mein System nutzt 182 automatische Prüfregeln. Diese Regeln kontrollieren jede einzelne Aktion, bevor sie in die Produktion übergeht. Es ist ein starrer, deterministischer Filter, der vor der kreativen, aber potenziell chaotischen KI-Logik steht.

Ein typischer Ablauf sieht so aus: Ein Hintergrund-Job erkennt, dass ein Update fällig ist. Er fragt das KI-Modell um eine Empfehlung. Die KI schlägt eine Konfigurationsänderung vor. Bevor diese Änderung ausgeführt wird, durchsucht das Prüfungsframework jede Variable gegen die 182 Regeln. Wird eine Regel verletzt, wird die Aktion blockiert und ein Alarm ausgelöst.

Diese Regeln sind nicht statisch. Sie lernen. Wenn ein Agent in der Vergangenheit einen Fehler gemacht hat, wird daraus eine dauerhafte Schutzregel generiert. Das System wird mit der Zeit defensiver. Es vergisst keine Fehler.

Das Jahr der nächtlichen Weckrufe

Einfach war das nicht. Im ersten Jahr meines Aufbaus habe ich dreimal in der Nacht aufgestanden. Der Grund war immer derselbe: Ein Cron-Job hatte Daten überschrieben.

Ich hatte die Automatisierung zu früh und zu weit geöffnet. Ich hatte dem System vertraut, ohne ihm Grenzen zu setzen. Die Lektion war schmerzhaft, aber lehrreich. Automatisierung ohne klare Leitplanken schafft mehr Probleme, als sie löst. Sie multipliziert Fehler.

Ich habe gelernt, dass Vertrauen in Software bedeutet, dass man das System misstrauisch behandeln muss. Jede Aufgabe, die wiederholt wird, muss idempotent sein. Jede Änderung muss rückgängig machbar sein.

Hier ist ein Ausschnitt aus meinem aktuellen Backup-Skript, das nach dieser Lektion entstanden ist. Es prüft die Integrität der Daten vor der Synchronisation:

#!/bin/bash
# integrity_check.sh

SOURCE_DB_URI="${1}"
TARGET_DB_URI="${2}"
CHECKSUM_FILE="/var/backups/integrity.log"

# Calculate checksum of source table
SOURCE_SUM=$(psql "$SOURCE_DB_URI" -t -c "SELECT md5(string_agg(col1 || col2, ',')) FROM critical_table;")
TARGET_SUM=$(psql "$TARGET_DB_URI" -t -c "SELECT md5(string_agg(col1 || col2, ',')) FROM critical_table;")

# Log the check
echo "$(date): Source=$SOURCE_SUM Target=$TARGET_SUM" >> "$CHECKSUM_FILE"

# Abort if mismatch exceeds threshold
if [ "$SOURCE_SUM" != "$TARGET_SUM" ]; then
    echo "CRITICAL: Data integrity mismatch detected. Aborting sync." | mail -s "DB Alert" [e-mail]
    exit 1
fi

# Proceed with sync only if safe
echo "Integrity check passed. Starting sync."
rsync -avz --progress /data/db/ /backup/db/

Dieses Skript ist langweilig. Es ist deterministisch. Es macht keine kognitiven Fehler. Es ist die Grundlage, auf der die KI darauf aufbauen kann.

Drei Modelle, zwei Server, null Monopole

Die zweite große Entscheidung war die Diversifikation der KI-Anbieter. Heute laufen drei verschiedene KI-Modelle parallel in meiner Infrastruktur.

Ich habe mich bewusst dagegen entschieden, nur einen Anbieter zu nutzen. Wenn ein API-Provider ausfällt, sich die Preise ändert oder die Tonalität der Antworten sich verschiebt, sollte mein System nicht kollabieren.

• Claude wird für komplexe architektonische Entscheidungen und die Analyse von Codebasen genutzt. Seine Fähigkeit, lange Kontexte zu verstehen, ist ideal, um Abhängigkeiten in alten Code-Strukturen zu erkennen.
• Gemini übernimmt die Code-Reviews. Es ist schnell und identifiziert stilistische Probleme und potenzielle Sicherheitslücken sehr gut.
• DeepSeek verarbeitet die Routine-Aufgaben. Log-Analysen, das Generieren von einfachen Bugfixes und das Schreiben von Dokumentation laufen hier.

Alles läuft auf zwei Hetzner-Servern in Deutschland. Das hat zwei Gründe. Erstens ist die Latenz niedrig, was für interaktive Development-Zyklen wichtig ist. Zweitens kontrolliere ich den physischen Speicherort meiner Daten.

Die Hardware ist nicht hochspezialisiert. Es sind Standard-Server mit SSH-Zugang und einem gut konfigurierten Docker-Setup. Die Magie liegt nicht in der Hardware, sondern in der Orchestrierung.

Wie die Hintergrund-Jobs arbeiten

Die 252 Hintergrund-Jobs, die rund um die Uhr laufen, sind das Nervensystem des Systems. Sie schauen nicht nur auf die Server, sondern auch auf die externe Welt.

Ein Beispiel: Ein Job überwacht die API-Antwortzeiten aller 13 Apps. Wenn die Antwortzeit einer spezifischen Endpunkt-Gruppe über 200 Millisekunden steigt, wird dies nicht nur geloggt. Der Job triggert eine Analyse.

Die KI bekommt den Log-Extrakt und die aktuellen Metriken. Sie muss entscheiden: Ist das ein transientes Netzwerkproblem oder ein Code-Regressionsfehler?

Wenn es ein Code-Fehler ist, erstellt die KI einen Pull Request mit einem fix-Vorschlag. Der menschliche Entwickler (ich) prüft diesen PR. In 90 Prozent der Fälle ist der Vorschlag korrekt oder zumindest ein guter Ausgangspunkt.

Hier ist die Python-Konfiguration, die diese Workflow steuert:

import asyncio
from ai_agents import CodeReviewer, LogAnalyst

class ProductionMonitor:
    def __init__(self):
        self.log_analyst = LogAnalyst(model="claude-3-sonnet")
        self.code_reviewer = CodeReviewer(model="gemini-pro")

    async def check_health(self, app_id: str):
        metrics = await self.fetch_metrics(app_id)

        if metrics['latency_ms'] > 200:
            # Trigger deep analysis
            log_context = await self.get_recent_logs(app_id, hours=1)

            # Step 1: Understand the problem
            diagnosis = await self.log_analyst.analyze(metrics, log_context)

            # Step 2: Propose a fix
            if diagnosis['severity'] == 'high':
                proposed_fix = await self.code_reviewer.generate_patch(
                    file_path=diagnosis['suspected_file'],
                    error_description=diagnosis['summary']
                )

                self.create_pr(proposed_fix)
                self.notify_team("Potential regression detected in " + app_id)

async def main():
    monitor = ProductionMonitor()
    await monitor.check_health("app-01")

if __name__ == "__main__":
    asyncio.run(main())

Die menschliche Rolle in der autonomen Architektur

Es ist ein Irrtum zu glauben, dass der Mensch in diesem Setup redundant ist. Im Gegenteil. Meine Rolle hat sich geändert. Ich bin nicht mehr der, der den Code schreibt. Ich bin der, der die Regeln definiert.

Ich bin der Architekt der Leitplanken. Ich entscheide, welche Aktionen die KI autonom ausführen darf und welche eine menschliche Freigabe erfordern. Ich überwach die Metriken der KI-Modelle selbst. Wenn Claude anfängt, schlechtere Vorschläge zu machen, sehe ich das an den Verwerfungsquoten im Dashboard.

Ich lerne, loszulassen. Aber ich lerne auch, zu kontrollieren. Diese Balance ist schwierig. Zu viel Kontrolle macht das System langsam. Zu wenig Kontrolle macht es unsicher.

Wichtigste Erkenntnisse

Wer ein solches System aufbaut, sollte einige Dinge beachten. Erstens: Startet deterministisch. Baut die 182 Regeln auf, bevor ihr die KI integriert. Zweitens: Diversifiziert eure KI-Modelle. Seit euch nicht an einen Anbieter fest. Drittens: Dokumentiert jede autonome Entscheidung. Wenn die KI etwas ändert, muss es eine Audit-Trail geben, die erklärt, warum.

Vierteins: Akzeptiert, dass es Nachtschichten geben wird. Aber sie werden seltener, je besser eure Leitplanken sind.

Ich habe in den letzten zwei Jahren gelernt, dass Technologie keine Magie ist. Es ist Werkzeug. Und wie jedes Werkzeug kann es benutzt werden, um Arbeit zu sparen oder um Chaos zu stiften. Der Unterschied liegt in der Architektur.

Die Frage an euch ist nicht, ob ihr ein Team braucht. Die Frage ist, ob eure Architektur so robust ist, dass sie ohne Team funktionieren kann. Wenn die Antwort nein lautet, dann baut ihr gerade erst an den Fundamenten.

Ich beschreibe diese Reise, die technischen Details und die mentalen Hürden ausführlich in meinem neuen Buch. Dort findet ihr die vollständigen Konfigurationen, die Bash-Skripte und die Strategien, die hinter den 13 Apps stehen.

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

---

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.