
Was sind die Vorteile des Zwölf-Faktor-Prinzips
-
- Codebasis
Jeder Microservice basiert auf einem eigenen Programm-Code, der jeweils unabhängig gespeichert und verwaltet wird. Von diesem Programm-Code können beliebig viele Services gleichzeitig erstellt werden.
- Abhängigkeiten
Jeder Microservice kann unabhängig angepasst und verändert werden. So musst du bei Änderungswünschen oder Optimierungen nicht das gesamte System anfassen. Abhängigkeiten müssen explizit deklariert und isoliert werden, damit bei Änderungen keine Überraschungen auftreten.
- Konfiguration
Konfiguriert wird nie ein spezifisches System, sondern umgebungsunabhängig. Damit ist sicher, dass deine Services in der Cloud überall laufen können.
- Unterstützende Dienste
Deine Services wie beispielsweise Cashes, Nachrichtenbroker oder Datenspeicher werden als angehängte Ressourcen behandelt. Damit sind sie von der Anwendung entkoppelt und somit austauschbar.
- Build, Release, Run
Die Phasen der Erstellung und der Nutzung eines Services werden durch den Release-Prozess strikt voneinander getrennt. Dadurch werden in der Cloud keine Entwicklungswerkzeuge mehr benötigt und dein Service auf das minimal Nötige reduziert – das erhöht die Sicherheit und spart Kosten im Betrieb.
- Stateless
Um einen Service jederzeit austauschen oder skalieren zu können, müssen Services selbst ohne gespeicherte Zustände funktionieren. Nur so ist ein Zero-Downtime-Update ohne Datenverluste möglich.
- Codebasis
-
- Bindung an Ports
Dienste müssen durch das Binden an Netzwerk-Ports bereitgestellt werden, um dadurch die Isolation von anderen Microservices zu erreichen. So stellst du sicher, dass deine Anwendung in der Cloud skaliert werden kann.
- Parallelität
Wenn die Kapazität erhöht werden muss, kannst du sie horizontal über mehrere identische Services hinweg hochskalieren. Dies ist die größte Stärke der Cloud-native Architektur – automatische Anpassung an die gerade erforderliche Leistung.
- Austauschbarkeit
Microservices können schnell gestartet und problemlos gestoppt werden. Diese Austauschbarkeit macht es möglich, bei einem Service-Ausfall in kürzester Zeit einen Ersatz bereit zu stellen oder hoch und herunter zu skalieren, wie es gerade nötig ist.
- Dev-Prod Parity
Möglichst identische Umgebungen in Entwicklung, Staging und Produktion helfen dabei, alles vorab zu testen und vermeidbaren Probleme nicht erst im Produktionsbetrieb zu entdecken. Dabei wird nicht nur auf technische Nähe geachtet, sondern auch auf zeitliche (kurze Zeit von Entwicklung zu Deploy) und personelle Nähe (Entwickler sind für Betrieb mitverantwortlich – DevOps-Kultur).
- Logs
Logs sollten als „event stream“ behandelt und archiviert werden. In einer Cloud-native-Anwendung dient dafür nicht mehr die klassische Log-Datei, sondern ein über Netzwerk-Ports angebundener Service. Die zentrale Erfassung aller Logs des gesamten Systems ermöglicht dem DevOps-Team Fehler zu erkennen, noch bevor Störungen im Betrieb auftreten.
- Admin-Prozesse
Du solltest Admin-Aufgaben wie Datenbank-Updates als einmalige, unabhängige Vorgänge auslegen. Während ein Deploy den Produktionscode des Microservice automatisch in Betrieb nimmt, werden administrative Aufgaben von diesem Prozess unabhängig ausgelöst. Der notwendige Programm-Code für diese Aufgaben ist im Produktionscode mit enthalten, die Ausführung erfolgt aber davon unabhängig.
- Bindung an Ports
Mach´s einfach digital