Das Schreiben von Anwendungscode ist älter als die meisten Cloud-Lösungen – Lösungen, die die meisten Anwendungsprogrammierer speziell für diese Tage schreiben.

Um mit dieser Dissonanz umzugehen, ist die 12-Faktor-App-Methodik entstanden. The 12 factors ist ein Ansatz, der Programmierern hilft, moderne Apps auf deklarative Weise zu schreiben, indem klare Verträge verwendet werden, die über die Cloud bereitgestellt werden.

In diesem Artikel werde ich die 12-Faktor-App-Methodik vorstellen und eine Zusammenfassung ihrer Prinzipien auf hoher Ebene anbieten.

Was ist die 12-Faktor-App-Methodik?

Im Jahr 2012 debütierten Programmierer bei Heroku die 12-Faktor-App-Methodik. Diese Programmierer haben Hunderte von Apps mit dieser Methodik entwickelt und bereitgestellt und dabei auf ihre Erfahrung zurückgegriffen, SaaS-Apps „in freier Wildbahn“ zu sehen.

Diese Gruppe betrachtet die Methodik als eine Triangulation von:

• Ideale Praktiken zur Unterstützung der App-Entwicklung
• Die Dynamik, die auftritt, wenn eine App organisch wächst
• Die Beziehung und Zusammenarbeit zwischen Codebase-Entwicklern

Ihre Ziele:

• Um Software-Erosionskosten zu vermeiden
• Um das Bewusstsein für systemische Probleme zu schärfen, die sie in der modernen App-Entwicklung beobachtet haben

Die Gruppe verweist auf zwei inspirierende Quellen, Patterns of Enterprise Application Architecture und Refactoring, beide vom professionellen Entwickler Martin Fowler.

Und nun werde ich jeden der 12 Faktoren vorstellen.

Prinzip I. Codebasis

„Eine Codebasis in der Revisionskontrolle verfolgt, viele Deploys“

Ihre Codebasis sollte über ein logisches Versionskontrollsystem verfügen, das leicht zu verstehen ist.

Jede Bereitstellung sollte über ein eigenes Code-Repository verfügen, das in mehreren Umgebungen bereitgestellt werden kann. Vermeiden Sie es, mehrere Anwendungen im selben Repository unterzubringen. Dies macht die Versionskontrolle fast unmöglich zu verstehen und Versionen werden sich verheddern, was zu nicht wertschöpfender Arbeit führt.

Prinzip II. Abhängigkeiten

„Abhängigkeiten explizit deklarieren und isolieren“

Dieses Prinzip besagt, dass Sie sich niemals auf die implizite Existenz systemweiter Pakete verlassen sollten. Stattdessen“

• Stellen Sie sicher, dass app-spezifische Bibliotheken verfügbar sind
• Stellen Sie sicher, dass das Betriebssystem geschält wird
• Stellen Sie sicher, dass benötigte Systembibliotheken wie curl oder ImageMagick verfügbar sind. (Es gibt keine Garantie, dass diese auf jedem System vorhanden sind, auf dem die App in Zukunft ausgeführt werden könnte.)

Insgesamt muss eine 12-Faktor-App autark sein. Die Anwendung sollte ausreichend isoliert sein, um Interaktionen mit Konfliktbibliotheken zu vermeiden, die auf dem Hostcomputer installiert sind.

Schauen wir uns ein Beispiel an. In Python können Sie Deklaration und Isolation mit Pip bzw. Virtualenv erreichen. Um dieses Prinzip zu erfüllen, müssen Sie immer sowohl die Abhängigkeitserklärung als auch die Isolation verwenden. Verwalten Sie Abhängigkeiten innerhalb der Anwendung, nicht von einer externen Quelle. Abhängigkeiten sollten in einem Repository innerhalb der App gehostet werden

Prinzip III. Config

„Store config in the environment“

Eine Anwendung und ihre Konfiguration sollten völlig unabhängig sein. Außerdem sollte das ständige Speichern von Konfigurationen im Code vollständig vermieden werden.

Ihre Konfigurationen sollten eine separate Datei haben und nicht im Code-Repository gehostet werden. Eine separate Konfigurationsdatei erleichtert das Aktualisieren der Konfigurationswerte, ohne die eigentliche Codebasis zu berühren, sodass keine erneute Bereitstellung Ihrer Anwendungen erforderlich ist, wenn Sie bestimmte Konfigurationswerte ändern.

Wenn Konfigurationen in der Umgebung und nicht in der App als Variablen vorhanden sind, können Sie sie problemlos in eine andere Umgebung verschieben, ohne den Quellcode zu berühren. Zwölf-Faktor-Apps speichern Konfigurationen als Variablen, sodass es unwahrscheinlich ist, dass sie versehentlich „in das Repository eingecheckt werden“. Ein weiterer Bonus: Dann sind Ihre Konfigurationen unabhängig von Sprache und Betriebssystem.

Prinzip IV. Backing Services

„Behandeln Sie Backing Services als angehängte Ressourcen“

In einer 12-Faktor-App müssen alle Dienste, die die Kern-App nicht unterstützen, als Dienst aufgerufen werden. Zu diesen nicht wesentlichen Diensten können gehören:

• Datenbanken
• Externer Speicher
• Nachrichtenwarteschlangen
• usw.

Diese können als Ressource behandelt werden. Auf diese sollte als Dienst über HTTP oder eine ähnliche Anforderung zugegriffen und dann in der Konfiguration angegeben werden. Auf diese Weise kann die Quelle des Dienstes geändert werden, ohne den Kerncode der App zu beeinträchtigen.Zum Beispiel ist eine App, die ein Message-Queuing-System verwendet, am besten, wenn sie einfach von RabbitMQ zu ZeroMQ zu ActiveMQ wechseln kann, indem sie nur die Konfigurationsinformationen ändert.

Prinzip V. Build, Release, run

„Streng getrennte Build- und Run-Phasen“

Bei einer 12-Faktor-App werden die drei Phasen des Erstellens, Freigebens und Ausführens streng voneinander getrennt.

Starten Sie den Erstellungsprozess, indem Sie die App in der Quellcodeverwaltung speichern und dann ihre Abhängigkeiten erstellen. Wenn Sie die Konfigurationsinformationen trennen, können Sie sie mit dem Build für die Release—Phase kombinieren – und dann ist sie bereit für die Run-Phase. Es ist auch wichtig, dass jede Version eine eindeutige ID hat.

Prinzip VI. Prozesse

„Führen Sie die App als einen oder mehrere zustandslose Prozesse aus“

Speichern Sie alle Daten, die erforderlich sind, um in einem zustandsbehafteten Sicherungsdienst wie Datenbanken bestehen zu bleiben. Die Idee ist, dass der Prozess zustandslos ist und absolut nichts teilt.

Während viele Entwickler an „klebrige Sitzungen“ gewöhnt sind, widerspricht das Speichern von Informationen in der Sitzung, in der erwartet wird, dass die nächste Anforderung vom selben Dienst stammt, dieser Methodik.

Prinzip VII. Port binding Prinzip

„Export services via port binding“

12-Faktor Apps müssen immer unabhängig von weiteren Anwendungen sein. Jede Funktion sollte ein eigener Prozess sein – in voller Isolation.

In einer traditionellen Umgebung gehen wir davon aus, dass unterschiedliche Prozesse unterschiedliche Funktionalitäten handhaben. Daher kann man leicht davon ausgehen, dass diese Funktionen über ein Webprotokoll wie HTTP verfügbar sind, was es wahrscheinlich macht, dass Apps hinter Webservern wie Apache oder Tomcat ausgeführt werden. Dies widerspricht jedoch der 12-Faktor-Methodik.

Fügen Sie stattdessen eine Webserver-Bibliothek oder ähnliches zur Core-App hinzu. Dies bedeutet, dass die App Anforderungen an einem definierten Port warten kann, unabhängig davon, ob es sich um HTTP oder ein anderes Protokoll handelt.

Prinzip VIII. Parallelität

„Skalierung über das Prozessmodell“

Eine echte 12-Faktor-App ist für die Skalierung ausgelegt. Erstellen Sie Ihre Anwendungen so, dass die Skalierung in der Cloud nahtlos ist. Wenn Sie die App so entwickeln, dass sie gleichzeitig ausgeführt wird, können Sie mühelos neue Instanzen in der Cloud hochfahren.

Um mehr Kapazität hinzuzufügen (zusätzliche Prozesse auf zusätzlichen Computern zu starten), sollte Ihre App in der Lage sein, mehr Instanzen anstelle von mehr Speicher oder CPU auf dem lokalen Computer hinzuzufügen.

Grundsatz IX. Disposability

„Maximieren Sie die Robustheit mit schnellem Start und ordnungsgemäßem Herunterfahren“

Das Konzept der Disposable—Prozesse bedeutet, dass eine Anwendung jederzeit sterben kann, den Benutzer jedoch nicht beeinträchtigt – die App kann durch andere Apps ersetzt oder neu gestartet werden. Wenn Sie Disposability in Ihre App integrieren, wird sichergestellt, dass die App ordnungsgemäß heruntergefahren wird: Sie sollte alle verwendeten Ressourcen bereinigen und reibungslos heruntergefahren werden.

Wenn die App so konzipiert ist, wird sie schnell wieder angezeigt. Wenn Prozesse beendet werden, sollten sie ihre aktuelle Anforderung beenden, eingehende Anforderungen ablehnen und beenden.

Prinzip X. Dev/prod-Parität

„Entwicklung, Staging und Produktion so ähnlich wie möglich halten“

Anwendungen, die für Entwicklung und Produktion bereitgestellt werden, sollten Parität aufweisen. Im Wesentlichen sollte es nur den geringsten Unterschied zwischen beiden Bereitstellungen geben.

Ein großer Unterschied kann zu unbeabsichtigten Kompatibilitätsproblemen zwischen Entwickler- und Produktionscode führen. Beim Erstellen einer 12-Faktor-App müssen die Sicherungsdienste zwischen dev und prod identisch sein; ein Unterschied hier könnte später zu erheblichen Problemen führen.

Prinzip XI. Protokolle

„Protokolle als Ereignisströme behandeln“

Im Gegensatz zu monolithischen und herkömmlichen Apps, die Protokollinformationen in einer Datei speichern, wird nach diesem Prinzip beibehalten, dass Sie Protokolle an einen ausgewählten Speicherort streamen und nicht einfach in eine Protokolldatei ablegen sollten.

Normalerweise befinden sich Protokolle nicht nach jedem Brennen an derselben Stelle in Cloud-basierten Umgebungen. Wenn neue Prozesse gestartet werden oder Ihre App abstürzt, werden die Protokolle auf mehrere Cloud-Computer verteilt.

Lösen Sie dieses Problem, indem Sie einen gemeinsamen Ort für das Streamen der Protokolle benennen. In einigen Fällen können Sie Stdout einfach in eine Datei umleiten. Wahrscheinlicher ist jedoch, dass Sie einen Protokollrouter wie Fluentd bereitstellen und die Protokolle in Hadoop oder einem bestimmten Dienst wie Splunk speichern möchten.

Prinzip XII. Admin-Prozesse

„Führen Sie Admin- / Management-Aufgaben als einmalige Prozesse aus“

Das letzte 12-Faktor-App-Prinzip schlägt vor, administrative Aufgaben vom Rest Ihrer Anwendung zu trennen. Diese Aufgaben können das Migrieren einer Datenbank oder das Überprüfen von Datensätzen umfassen.

Obwohl die Administratorprozesse getrennt sind, müssen Sie sie weiterhin in derselben Umgebung und gegen den Basiscode und die Konfiguration der App selbst ausführen. Der Versand des Admin-Tasks-Codes zusammen mit der Anwendung verhindert Drift.

Weiterführende Literatur

• BMC DevOps Blog
• Agile vs Waterfall SDLCs: Was ist der Unterschied?
• Deployment Pipelines (CI/CD) im Software Engineering
• Was ist Extreme Programming (XP)?
• Wie & Warum eine Softwarefabrik werden
• Top Konferenzen für die Programmierung & Softwareentwicklung