Twelve Factor App
今日は、オルターブースさん主催のイベントに参加させて頂いた。
オルターブースさんには、JAWS-UG福岡のもくもく会の会場を提供して頂いていたので、毎週のように通ってたけれど、実は社員の方とはあまり接点がなかったりする。
なので、一番お会いしているのはゴエモンさんかな。ついこの間までは。
去年、自分のマインドが変わったのを実感したのだけれど、そこに至るまでの景色を振り返ると、そこにはオルターブースさんの部屋があった。なので勝手に陰ながら応援している。
閑話休題。
イベントのテーマは「The Twelve-Factor App」。クラウド上でWebアプリやサービスを作る方法論。
土台のガイドラインとしては、これくらいのボリュームや抽象的で十分だと思う。 なぜなら、アプリケーションについては、他にもクリーンアーキテクチャ、DDD、マイクロサービスやサーバレスなどなど考えることがまだまだあるので、ボリュームが大きすぎて理解が追いつかなかったり、具体的すぎてサービスの成長の制限になっては本末転倒だから。
今回僕は、自分の12FAの理解が登壇者の方と大きく外れていないか？という確認と、各クラウドベンダのサービスが12FAにどうプロットされるのか？の事例や紹介のインプットを目的に参加をした。
抽象的な12FAを、事例やプロダクト、サービス、Demoを通して、具象化してのお話となっており、とても理解がしやすかった。（と同時に僕の勉強不足も痛感したw）
一つ気づいたのは、アプリケーションの何かを変更し1つのFactorを満たしたら、ここで安心しないで他の11Factorについても改めて確認するべきということ。変更が他のFactorを満たさなくなってるかも知れない。
例えば『「ステートレスにするためにRedisを使うことにした」場合、ステートレスについて述べているのは「6.プロセス」なのだけれど、Redisが「4.バックエンド」を満たしているか？や、その「1.設定」はどこに定義するか？、「2.依存関係」のあるライブラリはあるのか？』のように。
当たり前といえばそうだけど、自分の中では大きな気付きだった。
せっかく、この事に気づけたので、実際の開発のサイクルにうまく取り入れたいところ。
間違いなくギャップがあるので、そこは積極的に改善策を提案していこう。
うちのおかんがね「ソースコード解析およびレポートに従った開発をユーザー自身の開発サイクルの中に組み込むことで、スケーラブルなアプリケーションを構築することができるサービス」があるって言とった。
あ。その特徴はもう完全にKOSMISCHやね。
