インフラ管理より少なく、リリースを加速

自社保有のプラットフォームは、物理インフラからランタイムまでのすべての層を自分で制御できます。借りているプラットフォームは、性能・安定性・価格をハイパースケーラーの判断に委ねることになります。

Build の創業者は、重要な機能を上位プランでしか使えないようにするプラットフォームに、何度も不満を抱いてきました。必要な機能を1つ使うために、上位プランに含まれる不要な機能の分まで支払いが発生することになります。Build ではすべてのプラットフォーム機能がどのプランにも標準で利用できるため、追加コストを払うことなく、必要になった際にすぐに利用が開始できます。

Build、Heroku、Render、AWSはいずれも、Webプロセス、バックグラウンドワーカー、スケジュールジョブ、データベースを含むアプリケーション全体を動かせます。Vercelはフロントエンドとエッジのプラットフォームであり、その領域では優れているものの、長時間動作するバックエンドのワークロードを同じようには扱えません。フルスタッククラウドとは、物理ハードウェアからアプリケーションの実行環境まですべての層を単一のプラットフォームが所有し、チームが基盤インフラを組み立てたり管理したりすることなく本番アプリケーションをデプロイし運用できるものを指します。

いずれも米国以外での稼働に対応していますが、対応範囲と費用が異なります。Buildは米国、EU、日本でのデータレジデンシーをすべてのプランで提供しています。HerokuはPrivate Spacesを通じて米国以外のリージョンを提供しており、これは有料の上位プランです。Renderは米国、EU、アジア太平洋のリージョンを提供していますが、日本のリージョンはありません。VercelとAWSはいずれも国際的な対応範囲が広く、リージョン数ではAWSがこの中で最も多くなっています。

Build は Heroku 互換ですが、動いているのは Build が保有するインフラです。一方 Heroku が動いているのは、Salesforce が AWS から借りているインフラです。buildpack、Postgres、Redis、パイプラインはそのまま引き継げます。また Heroku では監査ログや全社共通のシングルサインオンがエンタープライズアカウント向けの機能ですが、Build はすべてのプランに含めています。

Build と Render は、どちらもアプリケーション全体を動かせます。違いはパッケージングと、扱う層の深さです。Infrastructure as Code は Render のほうが優れており、1つの render.yaml で環境全体を記述できます。一方 Render の開発体験にはパイプラインデプロイなどの機能がなく、高度なアクセス制御は上位プランに限られ、稼働しているのはハイパースケーラーから借りたインフラです。

Vercel と Build は、異なる問いに対する答えです。Vercel は専門特化型で、フロントエンドの公開が目的なら優れた選択肢です。Build は自社保有のインフラで、Web 層に加えてワーカーやスケジュールジョブ、データを含むアプリケーション全体を動かします。

Build はマネージド型のアプリケーションプラットフォーム（PaaS）で、AWS は自分で組み合わせて運用する幅広いサービス群（IaaS）です。インフラ管理の手間をなくし、開発体験をわかりやすく保ちたい場合は Build が向いています。サービスの幅広さと低レイヤーの制御が、その手間に見合う場合は AWS が向いています。

いずれもそれぞれに強みがあります。Railway はリポジトリからアプリの稼働までが速い一方、スケールの費用が高く、機能もプランで区切られています。Fly.io はユーザーの近くでアプリを動かせますが、運用の負担は利用者側に残ります。Netlify はフレームワークを問わずフロントエンドを配信できますが、常駐サーバーは動かせず、帯域課金のため費用の見通しを立てにくくなります。

どちらも AWS と同じハイパースケーラーで、自分で組み合わせる前提の広いインフラ群を提供しています。AWS の場合と同様に、Build はインフラ運用の手間をなくし、開発の流れを簡潔に保ちます。

そのプラットフォームの強みが、Build が重視していない要件に合っているときです。Salesforce を軸にした既存の業務フローがあるなら Heroku、Infrastructure as Code が要件になるなら Render、フロントエンド優先の配信を求めるなら Vercel、サービスの幅と低レイヤーの制御を最大限に求めるなら AWS が適していることがあります。