Twelve Factor App
Zwölf Regeln für Anwendungen in der Cloud
Die Idee und ihr Nutzen
Eine Versicherung betreibt ihren Schadendienst, das Programm für die Bearbeitung von Schäden, in zwei Umgebungen: in einer Testumgebung, in der neue Versionen ausprobiert werden, und in der Produktionsumgebung, die echte Kunden nutzen. In beiden Umgebungen soll genau derselbe Programmstand laufen, hier Version 8. Was sich zwischen den Umgebungen unterscheidet, teilt die jeweilige Umgebung dem Schadendienst beim Start mit, statt dass es fest im Programmcode steht. Dazu gehören die Adresse der Datenbank und die Zugangsdaten. Das ist eine von zwölf Regeln für Entwicklung und Betrieb, die Entwickler der Cloud-Plattform Heroku aufgeschrieben haben. Auf Heroku betreiben Firmen ihre Anwendungen auf gemieteten Servern. Die Regeln helfen besonders bei Anwendungen, die häufig neu ausgeliefert und auf wechselnden Servern gestartet werden. Die Sammlung heißt Twelve Factor App, auf Deutsch Zwölf-Faktoren-Anwendung. Faktor steht dabei für eine der zwölf Regeln.
Wie funktioniert es?
Das Team, das den Schadendienst entwickelt und betreibt, baut aus dem Quellcode einmal das Paket für Version 8. Das Paket enthält das fertige Programm und alle Programmbibliotheken, also fertigen Code anderer Entwickler, den der Schadendienst nutzt. Zuerst startet das Team dieses Paket in der Testumgebung. Die Testumgebung gibt dem Schadendienst beim Start die Adresse der Testdatenbank und einen Zugang mit, der nur für diese Datenbank gilt. Das geschieht zum Beispiel über Umgebungsvariablen, also Einstellungen, die das Betriebssystem einem Programm beim Start mitgibt. Der Schadendienst meldet sich damit bei der Testdatenbank an und arbeitet mit Testdaten. Nach erfolgreichen Tests startet das Team genau dasselbe Paket in der Produktionsumgebung. Die Produktionsumgebung gibt dem Schadendienst die Adresse der Produktionsdatenbank und einen anderen Zugang mit. Am Programmcode ändert niemand etwas. Der Schadendienst liest und schreibt die Schadenakten in der Produktionsdatenbank. Auf seinem Server speichert der Schadendienst nichts Wichtiges. Seine Betriebsmeldungen, also Einträge über Starts, Fehler und bearbeitete Anfragen, schickt der Schadendienst als fortlaufenden Datenstrom an die Betriebsplattform, also Zeile für Zeile, sobald eine Meldung entsteht. Die Betriebsplattform ist das System, das die Einstellungen je Umgebung verwaltet, die Programme startet und die Betriebsmeldungen sammelt und speichert.
Weil am Programmcode niemand etwas ändert, liegen Unterschiede im Verhalten zwischen Testumgebung und Produktionsumgebung an der Umgebung und nicht am Programmstand. Am Schadendienst zeigen sich vor allem die Regeln 3, 5, 6 und 11. Die Regeln sind eine Prüfliste für Entwurfsentscheidungen und kein Programm, das man installiert. Knapp zusammengefasst lauten die zwölf Regeln so:
- Regel 1, Codebasis: Eine Anwendung hat genau einen Quellcodebestand, und das Paket für jede Umgebung wird aus diesem Bestand gebaut. Der Quellcodebestand liegt in einer Versionsverwaltung, einem Programm, das jede Änderung am Code festhält.
- Regel 2, Abhängigkeiten: Alle benötigten Programmbibliotheken sind ausdrücklich aufgelistet und werden mitgeliefert, statt vorauszusetzen, dass sie auf dem Server schon vorhanden sind.
- Regel 3, Konfiguration: Die Konfiguration, also alles, was sich zwischen Umgebungen unterscheidet, kommt von außen, häufig über Umgebungsvariablen. Beim Schadendienst sind das Datenbankadresse und Zugang.
- Regel 4, Unterstützende Dienste: Datenbanken, Warteschlangen und ähnliche Dienste werden nur über ihre Adresse angesprochen und lassen sich durch Ändern der Einstellung austauschen, so wie beim Schadendienst die Testdatenbank gegen die Produktionsdatenbank.
- Regel 5, Bauen, Freigeben, Ausführen: Aus dem Code wird ein Paket gebaut. Das Paket wird mit der Konfiguration einer Umgebung zu einer Freigabe verbunden, also zu einem startbereiten Stand für genau diese Umgebung. Dann wird die Freigabe gestartet. Diese drei Schritte sind streng getrennt, und Version 8 wird nur einmal gebaut.
- Regel 6, Prozesse: Die Anwendung läuft als Prozess, also als laufendes Programm, das sich zwischen Anfragen nichts Wichtiges im eigenen Speicher merkt. Dauerhafte Daten liegen in unterstützenden Diensten, zum Beispiel in einer Datenbank. Beim Schadendienst sind das die Schadenakten in der Produktionsdatenbank.
- Regel 7, Bindung an Ports: Die Anwendung nimmt Anfragen selbst unter einer Portnummer an, also unter einer Nummer, über die ein Programm auf seinem Server erreichbar ist. Die Anwendung muss dafür nicht in einen Webserver eingebaut werden, ein fremdes Programm, das Anfragen aus dem Netz annimmt und an eingebaute Anwendungen weitergibt.
- Regel 8, Nebenläufigkeit: Mehr Last wird bewältigt, indem weitere Prozesse desselben Programms starten. Das geht, weil nach Regel 6 kein Prozess etwas Wichtiges bei sich speichert und deshalb jeder Prozess jede Anfrage bearbeiten kann.
- Regel 9, Wegwerfbarkeit: Prozesse starten in wenigen Sekunden und lassen sich jederzeit beenden. Beim Beenden nimmt ein Prozess keine neuen Anfragen mehr an und schließt die laufenden ab.
- Regel 10, Gleichheit der Umgebungen: Entwicklungsumgebung, Testumgebung und Produktionsumgebung sollen sich so wenig wie möglich unterscheiden.
- Regel 11, Protokolle: Die Anwendung schreibt ihre Betriebsmeldungen als fortlaufenden Datenstrom auf die Standardausgabe, den normalen Ausgabekanal eines Programms. Die Betriebsplattform sammelt und speichert die Betriebsmeldungen.
- Regel 12, Verwaltungsaufgaben: Einmalige Aufgaben laufen als eigene Prozesse mit demselben Code und derselben Konfiguration wie die Anwendung. Eine solche Aufgabe ist zum Beispiel das Umbauen einer Datenbanktabelle.
Fällt der Server aus, auf dem der Schadendienst läuft, oder steigt die Last, startet das Team oder die Betriebsplattform Version 8 auf einem anderen oder zusätzlichen Server mit denselben Einstellungen. Weil die Schadenakten in der Produktionsdatenbank liegen und nicht auf dem Server, fehlen dabei keine Daten.
Twelve-Factor App: dieselbe Version 8, andere Einstellungen je Umgebung
Wann ist es sinnvoll und wann nicht?
Die zwölf Regeln helfen
- Eine Webanwendung oder ein Dienst wird oft neu ausgeliefert und läuft in mehreren Prozessen desselben Programms gleichzeitig, deren Zahl sich nach der Last richtet. Ohne Regel 6 merkt sich ein Prozess des Schadendienstes zum Beispiel Daten in seinem eigenen Speicher, und ein zusätzlich gestarteter Prozess kennt diese Daten nicht. Mit den Regeln 6 und 8 kann jeder Prozess jede Anfrage bearbeiten, und bei mehr Last startet das Team einfach weitere Prozesse.
- Dieselbe Version soll in mehreren Umgebungen laufen, ohne dass Einstellungen von Hand geändert werden. Ohne die Regeln passiert zum Beispiel Folgendes: Ein Entwickler hat den Schadendienst auf seinem Laptop gebaut und getestet. In der Testumgebung startet der Schadendienst nicht, weil im Code ein Dateipfad steht, den es nur auf dem Laptop gibt, und weil die Testdatenbank eine andere Adresse hat. Das Team ändert die Einstellungen von Hand. Beim Wechsel in die Produktionsumgebung passiert dasselbe noch einmal, und diesmal wird eine Einstellung vergessen. Tritt danach ein Fehler auf, weiß niemand genau, ob er am Programm liegt oder an einer von Hand geänderten Einstellung.
- Fällt ein Server aus, sollen keine Daten verloren gehen. Ohne Regel 6 fehlen einem Dienst nach dem Start auf einem anderen Server oft wichtige Dateien, weil sie nur auf dem ausgefallenen Server liegen.
- Ein Team baut eine neue Anwendung für eine Cloud-Plattform und sucht eine Prüfliste für Entwurfsentscheidungen. Ohne eine solche Prüfliste fällt oft erst beim ersten Start auf einem anderen Server auf, dass die Anwendung zum Beispiel Dateien auf ihrem Server ablegt. Mit den zwölf Regeln prüft das Team solche Entscheidungen schon beim Entwurf.
Die zwölf Regeln helfen nicht
- Eine ältere Anwendung hält wichtige Daten im eigenen Arbeitsspeicher oder ist fest auf einen bestimmten Server zugeschnitten. Regel 6 und Regel 8 ließen sich dann nur mit einem Umbau umsetzen, nach dem die Anwendung nichts Wichtiges mehr im eigenen Arbeitsspeicher oder auf ihrem Server hält. Das Team, das die Anwendung betreut, setzt dann nur einzelne Regeln um, vor allem die Trennung von Code und Konfiguration (Regel 3) und möglichst gleiche Umgebungen (Regel 10). Die übrigen Regeln stellt das Team bewusst zurück. So spart sich das Team diesen Umbau, und die Anwendung läuft weiter als ein einzelner Prozess auf ihrem Server.
- Die Regeln sollen als vollständige Prüfliste für Entwicklung und Betrieb dienen. Sicherheit und fachliche Datenqualität behandeln sie kaum, und wer die Regeln nur abhakt, übersieht diese Themen. Das Team ergänzt die Prüfliste dann um eigene Punkte. Für einen Teil davon gibt es Vorschläge: Kevin Hoffman ergänzt in seinem Buch „Beyond the Twelve-Factor App“ drei weitere Regeln. Schnittstellen sollen zuerst entworfen werden. Messdaten sollen von Anfang an erhoben werden. Anmeldung und Berechtigung sollen von Beginn an eingeplant sein.
- Zugangsdaten, die über die Umgebung übergeben werden, gelten als ausreichend geschützt. Das sind sie nicht automatisch, denn Umgebungsvariablen landen zum Beispiel leicht in Fehlerausgaben. Dann richtet das Team Secrets Management ein: Ein eigenes Programm bewahrt die Zugangsdaten verschlüsselt auf und gibt sie nur berechtigten Programmen heraus. Die Zugangsdaten stehen dann nicht mehr offen in den Einstellungen der Umgebung.
- Ein Programm läuft fest installiert auf einem einzelnen Gerät und wird selten geändert. Ein Beispiel ist ein Steuerprogramm an einer Maschine. Regel 8 zur Nebenläufigkeit hilft dann nicht, weil auf dem Gerät nie ein zweiter Prozess für mehr Last startet. Regel 11 zu Protokollen setzt eine Betriebsplattform voraus, die Betriebsmeldungen sammelt. Das Team, das das Steuerprogramm entwickelt, lässt das Programm seine Betriebsmeldungen deshalb in eine Datei auf dem Gerät schreiben und spart den Betrieb einer Betriebsplattform.
Nachteile und typische Fehler
Für ältere Anwendungen erfordert die Umstellung oft erheblichen Aufwand, zum Beispiel wenn Dateien auf dem Server oder Einstellungen im Code liegen. Der Betrieb braucht außerdem eine Betriebsplattform.
Typische Fehler und woran man sie erkennt:
- Einstellung im Code: Ein Dateipfad oder eine Datenbankadresse steht weiterhin im Programmcode. Steht dort zum Beispiel die Adresse der Testdatenbank, sucht der Schadendienst auch in der Produktionsumgebung die Testdatenbank. Erreicht der Schadendienst die Testdatenbank von dort nicht, startet er nicht. Erkennbar ist das an Programmänderungen, die nur nötig werden, weil die Umgebung wechselt.
- Daten auf dem Server: Der Schadendienst legt hochgeladene Dokumente in einem Ordner auf dem Server ab statt in einem unterstützenden Dienst. Nach einem Serverausfall fehlen die Dokumente. Erkennbar ist das an Akten mit Verweisen auf Dokumente, die nach einem Neustart auf einem anderen Server nicht mehr abrufbar sind.
- Offen liegende Zugangsdaten: Zugangsdaten werden als Umgebungsvariablen übergeben. Bei einem Fehler beim Start schreibt der Schadendienst alle Umgebungsvariablen in seine Betriebsmeldungen, und die Betriebsplattform speichert diese Betriebsmeldungen. Erkennbar ist das an Passwörtern in den Protokollen der Betriebsplattform.
- Abweichende Umgebungen: Die Testumgebung verwendet eine andere Art von Datenbank als die Produktionsumgebung. Eine Abfrage des Schadendienstes, die die Testdatenbank richtig beantwortet, lehnt die Produktionsdatenbank ab, und der Fehler zeigt sich erst in der Produktionsumgebung. Erkennbar ist das an Fehlern, die sich in der Testumgebung nicht nachstellen lassen.
- Ausfall des unterstützenden Dienstes: Die gemeinsame Produktionsdatenbank fällt aus, und alle Prozesse des Schadendienstes stehen still, egal wie viele laufen. Erkennbar ist das an Fehlern aller Prozesse zugleich, während die Server selbst fehlerfrei laufen.
Weiterführend
Verwandte Ansätze
- Stateless Services: beschreibt Dienste, die sich zwischen zwei Anfragen nichts merken. Das entspricht Regel 6 zu Prozessen.
- Configuration Server: ein gemeinsames Programm, von dem alle laufenden Prozesse einer Anwendung ihre Einstellungen laden. Der Configuration Server kann die Einstellungen je Umgebung statt Umgebungsvariablen bereitstellen oder Umgebungsvariablen für Regel 3 ergänzen.
- Immutable Infrastructure: ersetzt Server, statt sie zu verändern. Das passt zur strengen Trennung von Bauen, Freigeben und Ausführen in Regel 5.
- Observability: beschreibt, wie Messwerte, Protokolle und Ablaufspuren erhoben werden. Die Protokolle als Datenstrom aus Regel 11 sind eine Grundlage dafür.
Quellen
- Adam Wiggins: The Twelve-Factor App: die ursprüngliche Beschreibung der zwölf Regeln, entstanden aus der Erfahrung mit Anwendungen auf der Cloud-Plattform Heroku. Jede Regel hat eine eigene Seite mit Begründung.
- Microsoft: Defining cloud native: ordnet die zwölf Regeln als Grundlage für Anwendungen in der Cloud ein und nennt die drei zusätzlichen Regeln aus Kevin Hoffmans Buch „Beyond the Twelve-Factor App“.