「Twelve-Factor App」とは？SaaS開発のベストプラクティスを12の原則で解説
The Twelve-Factor App
Herokuの開発者たちが数百のアプリ開発と数十万のアプリ運用の経験から導き出した、SaaSアプリ開発のための方法論「Twelve-Factor App」。宣言的なセットアップ、OSとの明確な契約、クラウドプラットフォームへの適合、開発と本番の乖離最小化、スケールアップの容易さなど12の原則を紹介。あらゆる言語とバックエンドサービスに適用可能で、ソフトウェアの侵食を防ぐための共通語彙を提供する。
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
HNでの議論
109- nebezb
今でも非常に relevante だ。たとえ適用しなくても、これを15分で読むだけで学べることがたくさんある。
私がこれに対して唯一不満があるのは、第3章のConfig [1]だ。
「設定を環境変数に保存する」「Amazon S3やTwitterなどの外部サービスの認証情報」
悪いアドバイスであることに加えて、開発者がローカルの環境変数の秘密情報をすべて ~/.bashrc ファイルに入れてもいいと信じるようになるという二次的影響があった。
これはやめよう。他の11.5個のファクターはやろう。
- browningstreet
これは12層のMFAデモで、現在の苦痛で持続不可能なMFAのトレンドの不条理を示しているのかと本当に思った。
- dec0dedab0de
Herokuは当時、未来になるかのように思えた。Azureで何か意味不明なことに遭遇するたびに、私たちが失ったよりシンプルな未来を夢見てしまう。
- sandeepkd
これがとても自然で、ソフトウェア開発の正しい方法だと感じられたのは興味深い。人々がこれを北極星として参照していたのを覚えている。そして徐々に人々はこれに近づいたが、それを超えていった。個人的には、これらの概念にはゼネラリストの考え方、つまりアプリケーションアーキテクトが必要だと感じる。今日私たちが持っているのは、チーム内の多くのプロダクトエンジニア、プロダクトマネージャー、そして経営陣だ。プロダクトエンジニアは、こうした概念を推進するための十分な権限やインセンティブを常に持っているわけではない。
それでも同時に、これらの概念はまるで石に刻まれたかのように感じられ、何らかの形で誰もが再発見し続けることになるだろう。
- theozero
.envは私たちが知っている通り、問題だらけだ... しかし！ varlock (https://varlock.dev) をチェックしてみてほしい。無料でオープンソースだ。私たちは馴染みのある構文（その上に小さなDSL）を現代的に適応させて、はるかに良くした。
組み込みの検証、型安全性、関数による合成、プラグインによるロード、漏洩防止などが組み込まれている。
- RKearney
タイトルは (2011) と書くべきだ。
- mermadicsolutio
自分のアプリでもシークレット管理のトレードオフについて議論している。保存は簡単で、暗号化すればほぼ問題ない。しかし配信が厄介だ。環境変数による配信は確かにシンプルだが、漏洩する可能性がある。もう一つの方法はジョブスコープの署名だが、これではジョブがシークレットを出力するのを防げず、爆発半径を縮小するだけだ。
しかし、ジョブが完了した後やデプロイが完了した後にシークレットを削除すれば、結果はほぼ同じだ。
- imglorp
良いベストプラクティスだが、ほとんどはそうだ。しかし、12FAモデルは状態をスコープ外と定義することで完全に回避していると感じる。「状態はあそこの外部サービスにある、三匹の猿の絵文字」
そう、でも時には状態こそがすべてであり、自分で管理する必要がある。その結果、一部のプロセスは9番目または10番目のファクターにならざるを得ない。