
1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
ポートフォリオを出荷します。2 製品が収益を生み、10 製品はおとなしいまま。アプリ単位のクラウドなら 12 個全部に支払います。Hoody なら、$49 サーバー 1 台に 50 個のコンテナを積み、おとなしい 10 製品はすでに払っている家賃に上乗せでほぼ無コスト。
twelve apps · one server · one line item on the card
製品はサーバーではなく、おおよそ 4 つのコンテナです — フロントエンド、バックエンド、データベース、ワーカー。12 製品で 50 コンテナ。退屈な部分はカーネルが重複排除するので、ボックスは気付きません。
各アプリは小さなスタックです。Next.js のフロント、小さな API、Postgres または SQLite、ワーカー。/api/v1/projects/[id]/containers に 4 つコンテナを POST し、製品名に対応する project_alias を付ければ完了です。12 製品で 50 コンテナと予備が少々。
Hoody はコンテナを VM ではなく LXC で動かします。Kernel Samepage Merging が同じ Debian ベースで動くコンテナ間で同一 RAM ページを見つけ、glibc の 50 コピーを 1 つにします。BTRFS のコピーオンライトはディスクで同様のことを行います。アイドルなコンテナはベースからの差分のみを消費し、丸ごと 1 ボックスにはなりません。
サーバーマーケットプレイスから Hetzner AX52 か同等品を選びます — 本物のベアメタル、64 GB RAM、1 TB NVMe、月額約 $49。それが請求額です。51 番目のコンテナは追加コストゼロです。
Containers API によると、すべてのコンテナは /api/v1/containers/[id]/stats で自身の CPU、メモリ、ディスク、ネットワークを報告します。マーケティング上の事実は、こうした stats エンドポイント 50 個が単一ホスト上で苦もなく動き続けるということです。
アイドル製品が本当に無料のときだけ意味をなす 3 つのこと。
停止中のコンテナは CPU と RAM をゼロ消費 — ファイルシステムは BTRFS 上に差分コストでただ存在します。ユーザー 12 人の水槽ログアプリは何も燃やしていません。良心の呵責を覚えるために殺さなくても済みます。
コンテナは Linux 名前空間であり、コントロールプレーン上の共有テナントではありません。mortgage-calc-pro のバグが chord-finder のデータベースを覗くことはできません。tenant_id 列も、共有スキーマも、「あのテナントが暴走した」インシデントもありません。分離はカーネルが担います。
11 番目の製品が伸びたら、再プラットフォーム化はしません。コンテナのリソースを PATCH してコアを増やし、/copy 経由でレプリカを追加するだけ。トラフィックが来た場所で既に動いているので、ダイヤルを開けるだけです。
請求単位はサーバー — コンテナではなく、製品でもなく。12 番目の製品を追加しても請求額は変わりません。チャートは相対的なリソースフットプリント — コスト列はすべて同じ数字です。なぜなら請求単位がサーバーだから。
数値は Hetzner AX52 クラスホストの説明用です。サーバーが請求単位 — より多くのコンテナを追加しても請求項目は増えません。より大きいボックスへのアップグレードはコストが増えます。ボックス内のコンテナ追加はコストが増えません。
ポートフォリオモデルはかつて請求書のスプレッドシートでした。今は明細 1 行です。
これらは単一製品をひとつのビジネスのように価格付けします。12 製品のポートフォリオはアプリ単位の料金を 12 倍払うことになります。ベアメタルモデルは 1 度だけ請求します。
アイドルが無料なら、次のアイデアは予算の議論ではなく POST です。