Infrastruktur für kleine Produkte: was Sie wirklich brauchen

Die Infrastrukturfrage wird bei kleinen Produkten meist an zwei Extremen beantwortet. Entweder wird alles auf eine Plattform gelegt, die alles von allein macht und bei Erfolg unangenehm teuer wird – oder es wird von Beginn an ein Aufbau gewählt, der für tausend gleichzeitige Nutzer gedacht ist, während es tatsächlich vierzig sind.

Dazwischen liegt der Bereich, in dem die allermeisten Geschäftsanwendungen richtig aufgehoben sind: ein bis zwei ordentliche Server, Container, eine verwaltete oder selbst betriebene Datenbank, Sicherungen, die geprüft wurden, und eine Überwachung, die Sie weckt, bevor der Kunde anruft.

Dieser Beitrag beschreibt, was dazugehört, was es kostet und wo die Fehler liegen, die später wehtun.

Die Grundausstattung

Ein Produkt im Betrieb braucht sechs Dinge. Nicht mehr, aber auch nicht weniger.

Ein Ort, an dem die Anwendung läuft. Ein virtueller Server bei einem europäischen Anbieter reicht für die meisten Fälle sehr lange. Vier Kerne, acht bis sechzehn Gigabyte Arbeitsspeicher, NVMe-Speicher – das kostet zwischen 15 und 50 € im Monat und trägt eine Anwendung mit einigen hundert aktiven Nutzern problemlos. Wer hier zu früh skaliert, bezahlt Kapazität, die er nicht braucht.

Eine Datenbank. Die wichtigste Entscheidung ist nicht welche, sondern ob verwaltet oder selbst betrieben. Verwaltet kostet mehr, nimmt Ihnen aber Sicherungen, Aktualisierungen und Ausfallsicherheit ab. Selbst betrieben ist günstiger und gibt Ihnen die volle Kontrolle – mit der vollen Verantwortung. Für Produkte mit echten Kundendaten, die nicht verloren gehen dürfen, würde ich im Zweifel zur verwalteten Variante raten, solange niemand im Team Datenbankbetrieb wirklich beherrscht.

Container. Die Anwendung als Abbild zu verpacken, ist heute Standard und löst ein reales Problem: Das, was auf dem Entwicklungsrechner läuft, läuft auch auf dem Server. Ohne Container ist jede Serverumstellung ein Abenteuer.

Ein Weg, Neues auszuliefern. Idealerweise: Code wird eingecheckt, gebaut, getestet, ausgeliefert – automatisch. Wenn das zu viel ist, reicht anfangs ein Skript, das Sie von Hand starten. Was nicht reicht: Dateien per FTP auf den Server schieben und hoffen.

Sicherungen. Dazu gleich mehr, denn hier wird es ernst.

Überwachung. Sie müssen wissen, dass etwas kaputt ist, bevor Ihr Kunde es Ihnen sagt. Das ist keine technische Frage, das ist eine Frage der Glaubwürdigkeit.

Sicherungen: der Punkt, an dem Produkte sterben

Wenn Sie aus diesem Beitrag nur einen Abschnitt mitnehmen, dann diesen.

Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung. Sie ist eine Datei, von der Sie annehmen, dass sie funktioniert. Diese Annahme ist in etwa jedem dritten Fall falsch – wegen unvollständiger Dateien, fehlender Berechtigungen, einer Verschlüsselung, deren Schlüssel niemand mehr findet, oder weil das Skript seit sieben Wochen mit einem Fehler abbricht, den niemand liest.

Was eine brauchbare Sicherungsstrategie ausmacht:

• Automatisch und täglich, ohne dass jemand daran denken muss
• Getrennt vom Server gelagert. Eine Sicherung auf derselben Maschine schützt vor einem gelöschten Datensatz, aber nicht vor einem Ausfall oder einem Verschlüsselungsangriff
• Aufbewahrungsstufen: die letzten sieben Tage, die letzten vier Wochen, die letzten zwölf Monate. Beschädigte Daten fallen oft erst nach Wochen auf
• Verschlüsselt, wenn personenbezogene Daten enthalten sind – und der Schlüssel liegt nicht neben der Sicherung
• Regelmäßig geprüft. Einmal im Quartal eine Sicherung in eine leere Umgebung zurückspielen und schauen, ob die Anwendung damit startet

Der letzte Punkt kostet zwei Stunden im Quartal. Ohne ihn haben Sie keine Sicherung, sondern ein gutes Gefühl.

Und dann die Frage, die niemand gern beantwortet: Wie lange darf Ihr Produkt ausfallen, und wie viele Daten dürfen verloren gehen? Eine Kita-App, die einen halben Tag steht, ist ärgerlich. Eine Pflegedokumentation, die vier Stunden Datenverlust bedeutet, ist ein Problem mit rechtlicher Dimension. Diese beiden Zahlen bestimmen, wie viel Infrastruktur Sie brauchen – nicht die Nutzerzahl.

Überwachung: drei Ebenen genügen

Es braucht keine große Werkzeugkette. Drei Dinge reichen weit:

Ist es erreichbar? Ein Dienst, der alle paar Minuten eine Adresse aufruft und Alarm schlägt, wenn keine Antwort kommt. Das kostet wenige Euro im Monat oder nichts und fängt die offensichtlichen Fälle ab.

Was ist kaputtgegangen? Ein Fehlersammler, der Ausnahmen aus der Anwendung einsammelt, gruppiert und meldet. Ohne das erfahren Sie von Fehlern nur, wenn ein Nutzer sich die Mühe macht, sie zu melden – und die meisten machen sich diese Mühe nicht, sie benutzen die Funktion einfach nicht mehr.

Wie geht es dem Server? Speicherplatz, Arbeitsspeicher, Prozessorlast. Der volle Datenträger ist der Klassiker: Protokolldateien wachsen, niemand schaut hin, und irgendwann nimmt die Datenbank keine Schreibvorgänge mehr an.

Wichtiger als das Werkzeug ist, dass die Meldung jemanden erreicht, der handeln kann und will. Eine Warnung in einem Postfach, in das niemand schaut, ist keine Überwachung.

Datenschutz und Standort

Für Produkte mit personenbezogenen Daten – und das sind in unseren Bereichen praktisch alle – gilt: Serverstandort in der EU ist die einfachste Antwort auf die meisten Fragen. Nicht, weil es außerhalb rechtlich unmöglich wäre, sondern weil es die Prüfung kürzer macht und weil Kunden im öffentlichen Sektor und im Gesundheitsbereich sonst nachfragen.

Was dazugehört:

• Auftragsverarbeitungsverträge mit allen Dienstleistern, die Zugang zu Daten haben – Hoster, Sicherungsdienst, Fehlersammler, Mailversand. Der Fehlersammler wird dabei regelmäßig vergessen, obwohl er im Zweifel komplette Datensätze in einer Fehlermeldung überträgt
• Verschlüsselung auf dem Transportweg ist selbstverständlich, auf dem Datenträger je nach Datenart
• Löschkonzept: Nicht nur, dass gelöscht werden kann, sondern nach welcher Frist automatisch gelöscht wird
• Protokollierung von Zugriffen bei besonderen Datenkategorien – wer hat wann welchen Datensatz gesehen

Bei Gesundheits- und Kinderdaten würde ich zusätzlich darauf achten, dass Fehlermeldungen keine Inhalte enthalten. Ein Fehlerbericht mit dem Namen eines Kindes im Klartext ist ein meldepflichtiger Vorfall.

Was das im Monat kostet

Eine realistische Aufstellung für ein Produkt mit einigen hundert Nutzern:

Posten	Monatlich
Anwendungsserver	20–50 €
Datenbank, verwaltet	25–60 €
Sicherungsspeicher, getrennt	5–15 €
Erreichbarkeitsprüfung	0–10 €
Fehlersammler	0–30 €
Mailversand	5–20 €
Domain und Zertifikate	2–5 €
Summe	60–190 €

Das ist weniger, als die meisten erwarten. Was die Rechnung nach oben treibt, ist selten der Server, sondern sind Dienste, die pro Nutzer oder pro Vorgang abrechnen – und die bei Wachstum überproportional zulegen.

Nicht in dieser Tabelle steht der Posten, der tatsächlich am meisten kostet: Ihre Zeit oder die eines Dienstleisters. Rechnen Sie mit einem halben bis einem Tag im Monat für Aktualisierungen, Sicherheitspatches, Prüfungen und die kleinen Dinge, die immer anfallen. Das ist der eigentliche Betriebsaufwand.

Der Fehler, den wir am häufigsten sehen

Nicht zu wenig Infrastruktur, sondern zu viel. Ein Team richtet für ein Produkt mit fünfzig Nutzern einen Aufbau ein, der für hunderttausend gedacht ist: Orchestrierung, mehrere Umgebungen, aufwendige Auslieferungsketten, verteilte Zwischenspeicher. Das Ergebnis ist ein System, das niemand im Team vollständig versteht, das bei jeder Änderung Angst macht und dessen Betrieb mehr Zeit frisst als die Weiterentwicklung.

Die Gegenfrage, die wir in solchen Gesprächen stellen: Was passiert, wenn der Server für zwei Stunden ausfällt? Wenn die Antwort „dann rufen ein paar Leute an" lautet, brauchen Sie keine Ausfallsicherheit über mehrere Rechenzentren. Sie brauchen gute Sicherungen und einen Weg, den Server in einer Stunde neu aufzusetzen.

Diesen Weg sollten Sie allerdings tatsächlich haben – aufgeschrieben, nicht im Kopf. Eine Anleitung, mit der ein fremder Entwickler die Anwendung in einer neuen Umgebung zum Laufen bringt, ist mehr wert als jede Hochverfügbarkeit.

Warum bei uns der Kunde betreibt

Wir bauen Produkte und richten sie in der Infrastruktur des Kunden ein – auf seinen Servern, in seinem Cloud-Konto, unter seinen Verträgen. Das hat einen unbequemen und einen guten Grund.

Der unbequeme: Betrieb ist eine eigene Disziplin mit eigener Verantwortung, inklusive Rufbereitschaft. Wer das nebenbei macht, macht es schlecht.

Der gute: Der Kunde bleibt unabhängig. Code, Daten und Zugänge gehören ihm, er kann jederzeit mit jemand anderem weiterarbeiten. Bei Software, die den Kernprozess eines Betriebs trägt, ist das kein Detail – das ist die Frage, ob er in fünf Jahren noch handlungsfähig ist.

Was wir dafür liefern müssen, ist mehr Sorgfalt bei der Übergabe: eine dokumentierte Einrichtung, nachvollziehbare Sicherungen, eine Anleitung, die auch jemand versteht, der nicht dabei war. Das ist Arbeit, die in vielen Projekten schlicht nicht stattfindet – und der Grund, warum so viele Unternehmen an einen Dienstleister gebunden sind, ohne es je entschieden zu haben.

Die Kurzfassung

Fangen Sie klein an. Ein Server, eine Datenbank, Container, geprüfte Sicherungen, drei Ebenen Überwachung. Das trägt weiter, als die meisten glauben, und Sie verstehen jeden Teil davon.

Investieren Sie die gesparte Zeit in die zwei Dinge, die wirklich zählen: Sicherungen, die Sie zurückgespielt haben, und eine Anleitung, mit der ein Fremder das System neu aufsetzen kann. Alles andere lässt sich nachrüsten, wenn es so weit ist.

Umgebungen: wie viele braucht man wirklich

Die Lehrbuchantwort lautet: Entwicklung, Test, Abnahme, Produktion. Für ein kleines Produkt ist das zu viel – jede Umgebung will gepflegt, aktualisiert und bezahlt werden.

Was in der Praxis gut funktioniert, sind zwei: die Produktion und eine Vorschauumgebung, die ihr so ähnlich wie möglich ist. Dieselbe Datenbankversion, dieselbe Konfiguration, andere Daten. Dort landet jede Änderung, bevor sie zum Kunden geht.

Der entscheidende Punkt ist die Ähnlichkeit. Eine Vorschauumgebung, die mit anderen Versionen und anderer Konfiguration läuft, beweist nichts. Sie erzeugt nur das Gefühl, getestet zu haben.

Für die Daten in der Vorschau gilt eine Regel ohne Ausnahme: keine echten Personendaten. Eine Kopie der Produktionsdatenbank in die Testumgebung zu spielen, ist bequem und datenschutzrechtlich heikel. Entweder erzeugte Testdaten oder eine Kopie, die vorher zuverlässig anonymisiert wurde – und zuverlässig heißt hier mehr, als Namen zu ersetzen.

Zugangsdaten: der häufigste vermeidbare Fehler

Datenbankpasswörter, Schlüssel für Zahlungsanbieter, Zugangsdaten für den Mailversand. Diese Dinge landen erstaunlich oft dort, wo sie nicht hingehören: im Repository.

Das Tückische daran ist die Dauerhaftigkeit. Ein Passwort, das einmal eingecheckt wurde, bleibt in der Versionsgeschichte, auch wenn es im nächsten Schritt entfernt wird. Wer Zugriff auf das Repository hat, hat Zugriff auf die Historie.

Der Mindeststandard ist unspektakulär:

• Zugangsdaten kommen aus Umgebungsvariablen, nicht aus dem Code
• Die Datei mit den echten Werten ist von der Versionierung ausgeschlossen – und man prüft das, statt es anzunehmen
• Eine Beispieldatei ohne Werte liegt dabei, damit nachvollziehbar ist, welche Variablen es gibt
• Produktion und Vorschau haben getrennte Zugangsdaten
• Wer das Projekt verlässt, verliert seine Zugänge, und geteilte Passwörter werden gewechselt

Der letzte Punkt wird fast immer vergessen. Ein Dienstleisterwechsel ohne Passwortwechsel bedeutet, dass jemand, der nicht mehr beteiligt ist, weiterhin an die Produktionsdaten kommt.

Wann Skalierung wirklich zum Thema wird

Die ehrliche Antwort: viel später, als die meisten denken.

Ein einzelner ordentlicher Server verarbeitet mehrere hundert Anfragen pro Sekunde, wenn die Anwendung nicht grob ineffizient ist. Für eine Geschäftsanwendung mit fünfhundert Nutzern, von denen vielleicht fünfzig gleichzeitig arbeiten, ist das um Größenordnungen mehr als nötig.

Wenn es doch eng wird, liegt es in neun von zehn Fällen nicht an der Serverleistung, sondern an der Datenbank – und dort meist an einem der drei Klassiker:

• Fehlende Indizes. Eine Abfrage, die bei tausend Datensätzen unmerklich war, braucht bei einer Million zwanzig Sekunden.
• Abfragen in Schleifen. Eine Liste mit fünfzig Einträgen, für die je eine weitere Abfrage läuft – aus Sicht des Codes unauffällig, aus Sicht der Datenbank einundfünfzig Vorgänge statt zwei.
• Fehlende Begrenzung. Eine Ansicht, die alle Datensätze lädt, weil es zur Entwicklungszeit nur dreißig waren.

Alle drei lassen sich messen und beheben, meist in Stunden. Das ist deutlich günstiger als ein größerer Server – und sehr viel günstiger als ein verteilter Aufbau.

Unsere Empfehlung: Bevor Sie Infrastruktur vergrößern, messen Sie, wo die Zeit verbraucht wird. In den allermeisten Fällen ist die Antwort eine einzelne Abfrage.

Protokolle: nützlich oder Datenhalde

Protokolldateien sind das erste, was man vermisst, wenn etwas schiefgeht – und das erste, was den Datenträger füllt.

Drei Regeln haben sich bewährt. Erstens: strukturiert protokollieren, nicht als Fließtext. Ein Eintrag, der Zeitpunkt, Schweregrad, Nutzer und Vorgang als getrennte Felder führt, ist durchsuchbar. Freitext ist es nicht.

Zweitens: keine personenbezogenen Daten ins Protokoll. Kein Klarname, keine Adresse, kein Inhalt einer Dokumentation. Eine Kennung reicht, um einen Vorgang nachzuvollziehen. Protokolle werden selten so gut geschützt wie die Datenbank, liegen oft bei Drittanbietern und fallen trotzdem unter dieselben Regeln.

Drittens: automatisch aufräumen. Eine Aufbewahrung von dreißig Tagen ist für die Fehlersuche reichlich. Ohne diese Grenze ist der volle Datenträger nur eine Frage der Zeit.

Eine Übergabe, die diesen Namen verdient

Weil wir Produkte in der Infrastruktur des Kunden einrichten, ist die Übergabe bei uns Teil des Projekts und keine E-Mail zum Schluss. Was dazugehört:

• Repository-Zugang für den Kunden, mit vollständiger Historie
• Alle Konten auf seinen Namen – Server, Domain, Zertifikate, Dienste, Store-Konten
• Eine Einrichtungsanleitung, mit der ein fremder Entwickler das System in einer leeren Umgebung aufsetzen kann
• Die Liste aller Umgebungsvariablen mit Erklärung, was jede bewirkt
• Die Sicherungsstrategie, schriftlich, samt der Anleitung zum Zurückspielen
• Ein durchgeführter Rückspieltest, protokolliert

Der letzte Punkt ist der, der den Unterschied macht. Eine Übergabe, bei der einmal gemeinsam eine Sicherung zurückgespielt wurde, ist eine echte Übergabe. Alles andere ist eine Sammlung von Dokumenten.