BuildとAWSの比較

AWSはIaaSの代表的なプラットフォームであり、GCPやAzureも同じ基本モデルの上に成り立っています。強力なインフラサービス群を、チーム自身が組み立てて使うというモデルです。Buildは、アプリケーションプラットフォームを完成した製品として提供することで、この組み立て作業そのものをなくします。

Buildはフルスタッククラウドプラットフォームです。ハードウェアからランタイムまでを自社で所有・運用しています。AWSも自社でインフラを所有しているため、ここでの違いは所有形態ではありません。違いは、その上に乗るプラットフォームをどこまで自分で組み立てる必要があるかです。

AWS上の一般的なSaaSアプリケーションは、EC2・ECS・EKSによるコンピュート、RDSによるデータベース、VPCとRoute 53によるネットワーキング、IAMによるアクセス制御、CloudWatchによる可観測性、そしてAWSまたはサードパーティのツールによるデプロイを組み合わせて構成されます。

これは珍しい構成ではありませんし、間違った構成でもありません。ただし、それはプロダクトと並行して、チーム自身がプラットフォームを構築し運用しているということでもあります。

AWSはサービスの幅、対応地域の広さ、そしてインフラの制御性で優れています。

コンピュートやネットワーキングからデータベース、可観測性、セキュリティに至るまで、インフラチームがアーキテクチャを選択できる幅はBuildよりはるかに広く、グローバルの拠点数でも上回ります。

インフラの設計と運用を自分たちで最大限にコントロールしたいチームには、AWSの方が適しています。

プラットフォームはすでに組み上がっています

AWSでは、アプリケーションを書き始める前に作業が発生します。アプリケーションが動く土台となるプラットフォームを選定し、つなぎ合わせ、一貫した形にするまで、何もリリースできません。

Buildではその作業がすでに完了しています。本番運用の土台が初日から用意されているため、チームはインフラではなくアプリケーションから着手できます。

立ち上げが速く、決めるべきことが少なく、デプロイ・監視・管理をひとつの場所で行えます。

インフラの請求額は、コストの一部にすぎません

AWS上でアプリケーションが動き始めても、作業は終わりません。誰かがIAMとネットワーキングを管理し、環境の整合性を保ち、サービスを監視し、インフラの変更をレビューし、請求額について説明する必要があります。

アカウントが大きくなるほど、監視すべきシステムも、維持すべき判断も増えていきます。クラウドの請求額は目に見えますが、その周りで費やされるエンジニアの時間は見えません。

Buildはこの運用レイヤーの多くを引き受けます。プロダクトチームが管理するのは、インフラサービスの集合体ではなくアプリケーションそのものになります。

必要なときの深さを、インフラから始めることなく

BuildはAWSよりも方針が定まっていますが、閉じた抽象化ではありません。より深いところに踏み込むために、別の場所へ移る必要はありません。

• BuildpackまたはDockerfileによるデプロイ
• 自身のKubernetesネームスペースへの直接アクセス
• 標準のワークロードと併用できる仮想マシン

AWSははるかに幅広いインフラコンポーネントを提供します。その柔軟性と引き換えに、運用責任も大きくなります。Buildが前提としているのは、多くのプロダクトチームがその深さを必要とするのは1つか2つのサービスであって、アプリケーション全体ではない、ということです。

AWSは、アーキテクチャが適切に設計され、継続的に最適化・保守されていれば、非常にコスト効率の高い選択肢になり得ます。

AWSはコンピュート、データベース、ストレージ、ネットワーキング、データ転送、可観測性をそれぞれ個別に課金します。細かく制御できる反面、コストを最適に保つには適切なサービスを選び、適切なサイズを設定し、使用率を継続的に監視し続ける必要があります。その注意が途切れると、過大なインスタンス、不要なサービス、想定外のデータ転送料金が静かに積み上がっていきます。

Buildはアプリケーションインフラを予測可能な月額キャパシティとしてまとめ、アドオンクレジット、人数無制限のシート、すべてのプラットフォーム機能を含めて提供します。

インフラ単体の費用ではAWSの方が安くなることもありますが、総コストはコンピュートだけではありません。既存チームの工数であれ、専任のDevOps人材の採用であれ、すべてを管理・最適化するために必要なエンジニアの時間を加えると、AWSの方が全体として大幅に高くつくことがあります。

同等のワークロードをすでにAWSで運用されている場合は、現在の請求書をお送りください。Buildはその金額を下回る価格をご提示し、12か月間その価格を維持します。

コンテナ、Postgres、Redis、標準的なネットワーキングで構成された一般的なSaaSアプリケーションは、多くの場合Buildに適しています。

アプリケーション本体は、再設計をほとんど、あるいはまったく伴わずに移行できることが少なくありません。その周辺にあるAWSインフラの多くは、プラットフォームが管理するデプロイ、ネットワーキング、可観測性、アクセス制御に置き換わります。

専門的なAWSサービスが関わる場合も、Buildのエンジニアが移行を一緒に進めます。エンジニアによる移行サポートは、すべてのお客様に標準で含まれています。