なぜいま Heroku なのか

開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。

• 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった
  • これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため¹
  • 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している
• だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか
  • 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず
  • また、Service Worker が先読みしていれば画面遷移も爆速
  • 実際に dev.to はこの組み合わせで Heroku にもかかわらず insanely fast を実現している
    • ref. dev.toがなぜinsanely fastを実現出来ているか - Qiita
• 各社を見ていてもインフラエンジニアは慢性的に不足ぎみ
  • Heroku ならばインフラエンジニアの手をあまり借りなくても運用できそう
• こんなもん Heroku で十分だろってサービスに自前でインフラ構築して運用で苦労を買ってる事例をよく見かける
  • もちろん Heroku では無理な領域もある
    • 例えばリアルタイム対戦するゲームのサーバーサイドなんかは明らかに Heroku では無理
    • アドテクとか 50ms or die. の世界で Heroku を使うのももちろん無理
  • でもウェブメディアとか Heroku で十分じゃない？
• インフラを学習することは重要なのでインフラを分かってない人が最初から Heroku 使うのは良くない
  • ひと通りのことを既に分かっている人が手を抜くために Heroku 使うのが良い
• また、Heroku で十分なものであっても k8s とか学習したくて敢えて自前で構築するのは良いんじゃないですかね
  • 新しい技術を学習するのは重要なこと
    • Too Much とか気にすんな
• Heroku Review App が神すぎる
  • Pull Request ごとに自動で確認環境を作ってくれる機能
    • Pull Request を merge/close すると勝手に削除される
    • デプロイした Review App へのリンクを bot が Pull Request に貼ってくれるのでコードレビューが捗る
    • Heroku Review App のためだけに開発環境に Heroku 使うっていうのもアリかも
    • Docker で同様の仕組みを自前で作ることも出来るけど結構大変そう

関連記事

• 部分SSR: SPAでSSRするけどサイドバーだけは非同期で取得したい - Qiita
• Fastly 前提で設計したほうがいい理由 - Qiita

1. ただ、レイテンシを理由に Heroku を選ばなかったというプロジェクトで、実際にレイテンシが問題になるほどパフォーマンスチューニングできているかと言うと僕の観測範囲では出来ている例をほとんど見たことがないです... ↩