先日、議論の場所で「heroku を作って提供すればいいんですよ」的な発言をした。

これだけ聞くと無理だろとなるのだけど、個人的なコンテキストを多分に含んだ発言だったので補足しておく。

heroku を作る = 一連の開発体験を作るということ

heroku が提供しているのは開発体験であるというのが個人的見解である。

言い換えると「Rails のアプリを開発すればその他に何も考えずにサービスを展開できる」という体験を提供している、と解釈している。

つまり、ここでいう heroku という言葉は、「heroku.com が提供する PaaS」を指すのではなく、「アプリケーション開発者が得る体験」を指すことになる。

誰のために heroku を作るのか

アプリケーション開発者のために行われるものである。heroku.com の開発者のために heroku.com は開発されていないよね！

そのため、アプリケーション開発者とのタッチポイントを機能要件、その他プラットフォーム運用に必要なものは非機能要件に分類できる。

開発体験に含まれるもの

アプリケーション開発をする際に行われる作業には、以下のことが含まれる。

• 開発自体
  • デプロイ
    • 開発環境
    • ステージング環境
    • 本番環境
  • イテレーションサイクル
    • デプロイ後に環境に入り rails c する
• 運用
  • 監視
    • メトリクス収集
      • 周期を捉えて比較する
    • アラート設定
      • インシデント管理とのインテグレーション
      • ノイジーの抑制
  • スケール調整
    • 需要予測
    • スケールアウト、イン、スケールアップ、ダウン
• トラブルシュート
  • ログ調査
  • audit
  • 障害対応
    • 止血対応
    • 応援の召喚と迅速な権限付与

網羅性に欠けるけど、この辺が実装できていれば「heroku を作る」ということができたのではないかと思う。一部本物の heroku でも不十分な項目があるね！

自分ならどうするか

自分なら、コマンドラインツールで対応したい。仮に名前を appctl とすると、以下のようなインターフェースと動作にすると思う。

# 対話インターフェースで設定する
appctl setup

# datadog logs の URL をブラウザで開く
appctl logs

# デプロイの GitHub Actions workflow をディスパッチする
appctl deploy --production

# コンソールに入る
appctl exec

さらに、appctl deploy を最初に実行したら、datadog がセットアップされて監視とアラートが自動でセットアップされるように実装すると思う。

よしなにデプロイされて、監視もされて、ログもすぐに見れる。そこまでできたらそれは heroku と呼べるのではないか。