はじめに
私は今まで、webサービスのインフラ（まだクラウド環境がない時代のことです）の面倒を見たり、AWSを初めとしたクラウド環境の構築をしたりしてきました。しかし現在、自分の会社でメインで使っているのはHerokuです。どうしてHerokuを選ぶに至ったのか、経緯についてお話しします。
背景
現在私は自分で会社（合同会社テンマド）を経営しています。事業としては2つあって、1つはビジネス支援事業。社外CTOや技術顧問などのアドバイザー業と、いわゆる受託のお仕事をしています。もう1つはサービス開発事業。irucaやmimemo、conasuなど、webサービスを中心に企画・開発・運営を行っています。
インフラで楽をしたい
webサービスを作ることを決めたとき、初めに考えたのはプログラミング言語やフレームワークのことでした。でもすぐに、どこでその運用をするのか考えないといけなくなります。
選択肢は多いです。最初のwebサービス（conasu）を作るときは、手慣れたPHPで作ろうと考えていました。PHPの場合、格安のレンタルサーバーですら動作環境が用意されていますし、VPSを利用しても、AWSを利用してもよいのです。
ただ、今のところ、100%のリソースを自社サービスに割けるわけではありません。ビジネス支援事業の割合が大きいので、その時間の合間を縫って開発したり、メンテナンスしたりしなければいけないわけです。
そう考えると、例えばOSやミドルウェアのメンテナンス、アップデートを考えなければならないのは面倒なことでした。できることならそこに手はかけたくありません。プロダクトとしてのwebサービスを作ることに集中したい。その思いが強くありました。
Herokuを選んでみて
そうしたとき、Rubyコミュニティーで使われ始めていたHerokuを思い出したのです。調べてみると、PHPにもきちんと対応していました。しかもバージョンを選べたり、必要な拡張（extension）を入れるための仕組みもcomposerをベースにしっかりしたものが用意されています。
最初、東京リージョンを選択できないので、レイテンシが気になりました。USリージョンを選択したものの、どうしても往復の時間はかかります。でも実際のwebアプリケーションを試しに動かしてみたら、体感的にそこまで気になるような時間がかかってしまうようなことはありませんでした。
PostgreSQLやRedisといったアドオンが用意されていて、すぐに使えるのも大きなメリットです。SendgridやPapertrailなど、機能を簡単に増やしていけるのもとても助かります。
そして何より、The Twelve-factor Appの考え方に則ってwebアプリケーションを作っていくという考え方は、当時のPHP開発の中では画期的なものでした（今でこそ当たり前になっていますが）。
The Twelve-factor Appの考え方がもたらすものは、コードのシンプルさだけではありません。例えば将来的にHerokuではないプラットフォームで動かすことになったとしても、ちょっとした環境さえ整えてあげれば動かすことができるようになります。
今はHerokuで動かしていても、将来的にレイテンシなどを考えてAWSに移設することは十分にあり得ます。webアプリケーションとしてのポータビリティーが確保しやすいというのは、とても魅力的なことでした。
まとめ
そういうわけで、Herokuを選んでwebサービスを始めました。
その後に作られたwebサービス（iruca、mimemo）はPHPではなくNode.jsで作られています。これもHerokuのおかげで、特段インフラに気を遣うことなく違うプログラミング言語を選ぶことができた例だと言えるでしょう。
例えば100%自社サービスの開発に時間を当てられたり、専任のインフラ担当のエンジニアがいるような環境であればまた違った選択をしたかもしません。でも現在の状況を考えると、Herokuが一番使いやすかった、ということです。
この先、例えばDockerのコンテナとしてwebプリケーションを動くようにしていけば、ポータビリティーはさらに高まるでしょう（Herokuの元々の仕組みを使うより面倒は増えてしまいますが）。時代がHerokuに追いついてきた、ということかもしれませんね。