昨日、Heroku Meetup #22 "Heroku Masamune" が開催されました。EC-CubeとDocker話をメインコンテンツに、その他、5つのLTが行われました。私も普段どおりの宣伝だけに近いLTを開催しましたが、それはまた別のお話。

そのLTの中で、とても良いコンテンツがありましたので、紹介します。@shokai さんの 「大切なことはだいたいHerokuで学んだ」です。

ところで Heroku とは

Heroku は、Platform as a Services (PaaS)です。Ruby、Java、Javascript、PHPなどのメジャーなプログラミング言語から、Go言語、Scala などまで幅広く8種類のプログラミング言語の動くWebアプリケーションプラットフォームです。いわゆる PaaS の中では歴史は古く、2007年よりサービスが開始されています。Heroku プラットフォームの特長は、Heroku Founder の "Adam Wiggins" が執筆した、アプリケーション開発の方法論 "The Twelve Factor App" がベースとなっていることです。

Heroku でアプリケーション開発を行った場合、"The Twelve Factor App" に従った Webアプリケーションを開発することに適している、と言いますか、それを矯正させられます。例えば、Gitと密接なソースコード管理、依存関係の明確化、個別の設定は環境変数、ポートバインディングされたサービスの公開、シェアドナッシング(ステートレス)によるプロセスのスケールアウト、開発・本番環境の一致...など、Heroku を利用されたことのある人には、その強制力に驚かされた人もいるでしょう。ステートレスを強制し、廃棄容易性を追求してセキュリティを高めた結果、ローカルにファイルを永続的に配置することはできず、データベースやオブジェクトストレージへの保存が必要不可欠です。

レガシーなアプリケーション開発に携わったことのある方にとっては、制限・制約の多いプラットフォームと思われるかもしれません。ですが、モダンなWebアプリケーション開発として、とても優れています。

ようやくの本編ですが、「大切なことはだいたいHerokuで学んだ」では、この強制力によって、次の２つの点でよかったと述べられています。

1. 悪い設計をさせてくれない
2. 運用しやすい設計になる

1. 悪い設計をさせてくれない 

Heroku は、"The Twelve Factor App" を強制してくるプラットフォームのため、この制限から外れると、それは「エラー」として表面化してきます。そもそもデプロイできないようなケースもあるでしょう。また、24時間+αの時間が経過して Heroku Dyno (アプリケーションの稼働するコンテナのこと)が自動リスタートしたあと、アプリケーションが正常に動作しないケースも発生するかもしれません。

「なんで、24時間でリスタートするんだよ」とお思いかもしれません。しかし、このお陰で Security Patch が迅速に適用され、安全な環境をすばやく提供しています。そして、障害テストを常に実施していると見れば、この仕掛けがあるからと言って、なんの問題もないはずです。対障害性の高いアプリケーションとして設計されていれば、不意のアプリケーションの停止や再起動が発生しても、サービスに影響は与えないでしょう。可用性の高いアプリケーションとして設計されていれば、そもそも問題にもなりませんよね。

要するに、「良い設計を強制する」仕組みを提供するプラットフォームでもあるということです。

このように「悪い設計をさせてくれない」アプリケーションが開発できれば、多くのプログラマーが良い設計のアプリケーションを開発することができるようになるでしょう。また、可搬性高く、どこのプラットフォームでも動かすことができるというメリットも生まれます。"The Twelve Factor App"で組まれたアプリケーションであれば、開発時の共通言語にもなります。開発者同士での対話でも、良し悪しや目標を共通化しやすいという価値が生まれます。

2. 運用しやすい設計になる

良い設計で構成されていれば、必然的に「運用しやすい」デザインともなるでしょう。

障害が発生しても、オートヒーリングさせやすく復旧しやすい。アクセス過多や、処理量の増加により、リソースが足りなくなれば、瞬時にスケールアウトして対応できる。ログは全て決められたイベントストリームから排出されてくるならば、それだけを追っておけばすべてのログを確認できる。ソースコードベースなので、いつでもデプロイできるし、すぐにロールバックもできる。

「大切なことはだいたいHerokuで学んだ」でも述べられているように、良いデザインで設計されたアプリケーションは、Heroku が全てマネージしてくれるため、運用専門のメンバーを準備せずとも運用可能です。

継続的な開発のために Heroku Pipelines と Heroku CI を組み合わせた CI/CD 環境を準備しておけば、開発者は Github へのコードコミットとプルリクエストだけできれば、Heroku へ自動的にアプリケーションがデプロイ&リリースされます。

まとめ

Heroku でアプリケーションを開発すると、「良い設計」を強制され、「可搬性の高い」アプリケーションを開発することができるようになります。

かと言って、さぁ他のプラットフォームでも動かそうかと言うと、ベンダーロックインされてもいないのに、「Herokuで動かそう」という気持ちになります。これは、Heroku 自体のデザインを、開発者が、開発者のために行い、開発者が使いやすいように作っているからと言えるでしょう。開発者こそ、Heroku プラットフォームに共感を得ることはできるのではないでしょうか。

最後に、もう一つ文章を引用して終わりにします。

> (Herokuは)「根底に[技術的正しさ、公正さ]を感じるので、信頼できる」