ども、@kimihom です。
今日の Heroku Meetup で、The Twelve-Factor App について語ってきたので記事にしておく。
アプリケーションエンジニアにとっての The Twelve-Factor App
Twelve-Factor Appを読んでみると、Heroku を使えば何も意識しなくても要件を満たすことのできる内容と、Heroku を使っていても意識しなければならない内容の2つのパターンに分かれることがわかる。
Heroku を使えば気にすることのない例として、Deploy は否応無く Git を使ってデプロイすることになるし、ログ管理は アドオンを使って勝手にイベントストリームとして扱ってくれる。これらの Factor は、インフラエンジニアが自前で サーバー用意するときに必要になる知識である。でも、Heroku を使っているアプリケーションエンジニアでも、「あぁ Heroku を使ってるからこういうのを全部やってくれてるんだな」ということを改めて理解することができる。
それよりも重要なのが Heroku を使っていてもやらかしがちな点が散りばめられているという点である。このやらかしがちな点に関して、今回の Meetup で情報を共有した次第である。
上記スライドで記したアプリケーションエンジニアにとっての The Twelve-Factor App は、まさに私がやらかした経験に基づいている。というより、事前に The Twelve-Factor App を知らなければ、ほとんど誰もが同じ過ちを犯すことになるだろう。
今回紹介した内容は、実は小規模の時点でアプリケーションを開発している間にはそこまでデメリットに感じないというのがまた厄介な点だ。しかも手軽に実装できてしまうので、しばらくコードが放置された状態になり、やがて元に戻すのが手間になるくらいの悪い方向性に向かっていくことになる。それが、やがて Heroku を使っていたとしてもスパゲッティコードになっていってしまう。
あなたの作るイノベーティブなアプリケーションがそうなって欲しくはない。The Twelve-Factor App は、今まで先人が何度も通った過ちなのである。
人数が増えた時の ベストプラクティス
Heroku はチームで開発する上での最適化も強化されてきている。チーム全員がアプリケーション開発に集中できるようになっている。そして"インフラエンジニア" が不要になる。
チームでは開発するそれぞれがデプロイに関わり、誰がどんな開発をしたのかを瞬時に Heroku Pipeline 上の Web アプリとして確認できるようになる。エンジニア以外の人でも素早くフィードバックと改善のループに立ち入ることが可能になる。
Heroku を使わないインフラエンジニアを抱えるあらゆる企業が、Pipeline や CI のようなインフラ構成を作ろうと躍起になっている(Heroku を使えばいいのに )。私たちが Heroku を使うことで、その開発の最先端をすぐに始めることが可能だ。
このチーム開発における Heroku 利用のベストプラクティスは、まだまだこれからシェアされていく分野だ。今回の Meetup でも、そうした内容がシェアされていた。
終わりに
今年は 5回、Heroku Meetup を開催することができた。
来年も Heroku を使った最先端のアプリケーション開発を通して、私は自社のサービスを高品質なものに保ち続けていく。
私と同じように Heroku にポテンシャルを感じた方は、今からでもできるところからシステムを The Twelve-Factor App に則った Herokuへ移し始めていこう。その英断がゆくゆくはそのシステムやあなた自身を、 Hero へと向かわせてくれるだろう。