Fassen wir die 12 Punkte der „The Twelve-Factor App“-Methode zunächst einmal zusammen:
1. Die Codebasis
Die Codebasis einer 12-Faktor-App ist immer mit einem Codeverwaltungssystem wie git, svn, cvs, mercurial verbunden. Es kann keine multiplen Codebasen für eine App geben. Gleichzeitig wird es aber üblicherweise mehrere Deployments, mehrere laufende Instanzen einer App geben – etwa in Produktion, auf Staging-Seiten, Kopien für Entwickler auf lokalen Maschinen, etc.
2. Abhängigkeiten
Anwendungen haben explizit deklarierte Dependencies. Eine 12-Faktor-App verlässt sich niemals auf die implizite Existenz von System-Packages.
3. Konfigurationen
Eine 12-Faktor-App benötigt eine strikte Trennung zwischen Konfigurationsanweisungen und Code. Niemals wird eine config-Anweisung als Konstante im Code gespeichert. Die Annahme ist, dass Config-Anweisungen sich von Deployment zu Deployment verändern, während der Code konstant bleibt.
4. Backing Services
Behandle Backing Services (Datenbanken, Messaging-Systeme, SMTP-Services, Caching-Systeme) als angehängte Ressourcen. Die Idee dahinter: Solche Ressource sollten einfach ausgetauscht werden können.
5. Build, release, run
Eine 12-Faktor-App trennt strikt zwischen Build-, Release- und Run-Zuständen. Beispielsweise ist es undenkbar, Code-Änderungen zur Runtime durchzuführen, da diese nicht in die Build-Instanz zurückportiert werden können.
6. Prozesse
Führe die App als einen oder mehrere zustandslose Prozesse aus. 12-Faktor-Apps sind immer zustandslos (Shared Nothing Architecture). Daten, die persistiert werden müssen, müssen in einem entsprechenden Backing Service abgelegt werden.
7. Port binding
Exportiere Services via Port Binding.
8. Concurrency
Skaliere die App über das Prozess-Modell. 12-Faktor-Apps sind horizontal partionierbar, sodass nebenläufige Prozesse leicht hinzugefügt werden können. Die Prozesse stützen sich dabei immer auf den Betriebssystem-eigenen Process Manager.
9. Verfügbarkeit
Prozesse einer 12-Faktor-App sollten schnell gestartet und gestoppt werden können. Das ermöglicht elastisches Skalieren, schnelles Deployment von Code- oder Config-Änderungen und stärkt die Robustheit von Production Deploys.
10. Übereinstimmung zwischen Entwicklung und Produktion
Halte Development, Staging und Production so ähnlich wie möglich. 12-Faktor-Apps sollten sich beispielsweise der Versuchung widersetzen, verschiedene Backing Services in Development und in Produktion anzuwenden.
11. Logs
Behandle Logs wie Event-Streams. Eine 12-Faktor App kümmert sich nie selbst um das Routen oder Speichern ihrer Output-Streams.
12. Admin-Prozesse
Führe Admin/Management-Aufgaben als One-off Prozesse aus
Best Practices für wen?
Entstanden sind die Prinzipien im Umfeld der Heroku-Plattform, was David Zülke dadurch unterstrich, dass er die Prinzipien Live durch das Aufsetzen einer Heroku-App demonstrierte. Das war durchaus beeindruckend. Der Heroku-Kontext lässt dann natürlich aber die Frage aufkommen, inwiefern es sich hier um allgemeine Prinzipien handelt, die auch jenseits der Heroku-Plattform Sinn haben.
Im Manifest steht geschrieben, dass die Best Practices grundsätzlich in jeder Programmiersprache und mit beliebigen Kombinationen von Backing Services funktionieren. Bei den Code-Samples auf http://12factor.net/, wo jeder der 12 Punkte nochmals im Detail beschrieben sind, überwiegen aber PHP- und Ruby-Beispiele.
Wie dem auch sei, als Synthese der Erfahrungen beim Bauen von SaaS-Anwendungen auf Heroku sind diese Best Practices erst einmal valide und durchaus wertvoll. Vieles davon ist gerade für PHP-Entwickler auch Common Sense – beispielsweise das horizontale Skalieren. „Nicht aber unbedingt für Ruby-Leute“, fügte Zülke mit einem Augenzwinkern hinzu.
Aber Scherz beiseite, schaut Euch die Methoden auf http://12factor.net/ an und urteilt selbst. Inspiriert ist die Form des Manifests übrigens von Martin Fowlers Klassikern Patterns of Enterprise Application Architecture und Refactoring. Ob es eine vergleichbare Wirkungsmacht wie diese entfalten kann, oder lediglich einige bekannte Konzepte geschickt auf den Nenner bringt, um mit Heroku die passende Lösung zu präsentieren, bleibt abzuwarten.
