Die Zwölf-Faktoren-App: Die Methodik hinter Cloud-nativen SaaS-Anwendungen
The Twelve-Factor App
Die Zwölf-Faktoren-App ist eine Methodik zur Entwicklung von Software-as-a-Service-Anwendungen, die auf den Erfahrungen der Entwickler der Heroku-Plattform basiert. Sie definiert zwölf Prinzipien, die von der Codebasis über Konfiguration und Prozesse bis hin zu Logs reichen, um Anwendungen portabel, skalierbar und für kontinuierliches Deployment geeignet zu machen. Die Methodik zielt darauf ab, die Divergenz zwischen Entwicklung und Produktion zu minimieren und die Kosten der Software-Erosion zu vermeiden.
Die zwölf Faktoren der App sind eine Triangulation idealer Praktiken für die Anwendungsentwicklung, die besonders die Dynamik des organischen Wachstums einer App im Laufe der Zeit und die Dynamik der Zusammenarbeit zwischen Entwicklern berücksichtigt.
- nebezb
Immer noch unglaublich relevant. Selbst wenn man es nicht anwendet, gibt es so viel zu lernen, wenn man das in 15 Minuten liest.
Der einzige Kritikpunkt, den ich habe, ist Kapitel 3: Config [1]
„Store config in the environment“, „Credentials to external services such as Amazon S3 or Twitter“
Neben der Tatsache, dass es ein schlechter Ratschlag ist, hatte dies den sekundären Effekt, dass Entwickler glaubten, sie könnten alle ihre lokalen Umgebungsgeheimnisse in ~/.bashrc-Dateien packen.
Hört damit auf. Macht die anderen 11,5 Faktoren.
- browningstreet
Ich habe wirklich gedacht, das wäre eine 12-Schicht-MFA-Demo, die die Absurdität unserer aktuellen schmerzhaften und nicht nachhaltigen MFA-Trends zeigt.
- dec0dedab0de
Heroku schien damals die Zukunft zu sein. Jedes Mal, wenn ich mich dabei ertappe, wie ich versuche, irgendeinen Unsinn in Azure zu verstehen, träume ich von der einfacheren Zukunft, die wir verloren haben.
- sandeepkd
Es ist interessant, wie sich das damals so natürlich und richtig angefühlt hat, Software zu entwickeln. Ich erinnere mich, dass Leute es als den Nordstern bezeichneten. Und dann kamen die Leute ihm allmählich nahe, aber gingen darüber hinaus. Persönlich denke ich, dass diese Konzepte eine generalistische Denkweise erfordern, auch bekannt als Anwendungsarchitekt. Was wir heute haben, sind viele Produktentwickler in Teams, Produktmanager und Management. Die Produktentwickler haben nicht immer genug Einfluss oder Anreize, um solche Konzepte voranzutreiben.
Und gleichzeitig fühlen sich diese Konzepte so in Stein gemeißelt an, dass sie auf die eine oder andere Weise von jedem immer wieder entdeckt werden.
- theozero
.env ist, wie wir wissen, voller Probleme... ABER! Schaut euch varlock (https://varlock.dev) an - es ist kostenlos und Open Source, und wir haben die vertraute Syntax (eine kleine DSL obendrauf) wirklich modernisiert und angepasst, um sie viel besser zu machen.
Es hat eingebaute Validierung, Typsicherheit, Komposition über Funktionen, Laden mit Plugins, Leck-Prävention und vieles mehr.
- RKearney
Der Titel sollte (2011) enthalten.
- mermadicsolutio
Ich überlege auch, welche Kompromisse ich beim Geheimnis-Management in meiner App eingehen soll. Das Speichern ist einfach, man braucht nur Verschlüsselung und es ist meistens gut. Aber die Zustellung ist knifflig. Die Zustellung über env ist sicherlich einfach, kann aber durchsickern. Der andere Weg wäre eine auf den Job begrenzte Signatur, aber das hindert den Job nicht daran, das Geheimnis auszudrucken, es verkleinert nur den Schadensradius.
Aber wenn man das Geheimnis löscht, nachdem der Job abgeschlossen oder das Deployment fertig ist, ist es so ziemlich dasselbe Ergebnis.
- imglorp
Gute Best Practices, meistens, aber ich habe das Gefühl, dass das 12FA-Modell den Zustand völlig ausgelassen hat, indem es ihn als außerhalb des Rahmens definiert hat: „Zustand ist da drüben in diesem externen Dienst, Drei-Affen-Emoji“.
Ja, aber manchmal ist der Zustand der springende Punkt und man muss ihn selbst verwalten, und dann müssen einige deiner Prozesse als Ergebnis Faktor 9 oder 10 sein.