Build Blog
なぜマネージドインフラがDIYクラウド構成を置き換えつつあるのか
より多くのエンジニアリングチームが、DIYクラウドからマネージドインフラやプラットフォームエンジニアリングツールへと移行しています。なぜそのシフトが起きているのか、そしてそれがあなたのチームにとって何を意味するのかをご紹介します。
長年、DIYクラウド構成はエンジニアリングチームにとってデフォルトの選択肢でした。いくつかのVMを立ち上げ、サービスを繋ぎ、モニタリングを後から追加し、進めながら反復する。少なくとも初期は、柔軟で、力を与えてくれ、コスト効率が良く感じられました。
しかし、チームがスケールするにつれて、そのアプローチは崩れ始めます。
今日、より多くの組織が手作業で構築したインフラから離れ、複雑さを減らし、信頼性を高め、チームがシステムの保守ではなくプロダクトの構築に集中できるマネージドプラットフォームやプラットフォームエンジニアリングツールへと移行しています。
このシフトは、制御を諦めることではありません。制御が実際に価値を生む場所を再定義することなのです。
DIYクラウドの隠れたコスト
DIYクラウド環境は自由を約束しますが、静かに運用上の負債を蓄積していきます。
いくつかのTerraformファイルとスクリプトから始まったものが、はるかに管理困難なものへと成長する傾向があります。時間が経つにつれて、チームは、誰のものでもないツールの寄せ集め、暗黙知に依存する脆弱な環境、新しいエンジニアの遅いオンボーディング、そして何かが壊れたときの不明確な責任を抱えることになります。
インフラが成長するにつれて、それを運用するために必要な認知負荷も成長します。エンジニアは機能を提供するよりもプラットフォームを保守することに多くの時間を費やし、信頼性を保証するのがより困難になります。
ここで多くのチームは、自分たちが単にインフラを構築したのではなく、それを適切にサポートする専任チームやツールなしに、偶然に内部プラットフォームを構築してしまったことに気づきます。
DIYクラウドの根本的な問題は、それが機能しなくなることではありません。それを機能させ続けるコストが上がり続けることです。追加される新しいサービス、オンボードされる新しいチームメンバー、そして解決されるすべてのインシデントが、プロダクトとして設計されたわけではないシステムにさらなる複雑さを追加します。それは出発点として設計されたものでした。
成長の初期にあるチームにとって、その出発点は良いものです。しかし、意味のある規模で運用するチームにとって、DIYクラウドはエンジニアリングの速度への税金になります。
プラットフォームエンジニアリングはトレンドではなく、応答である
プラットフォームエンジニアリングは、チームがより多くの抽象化を望んだから登場したわけではありません。DIYクラウドがチームとともにスケールしなくなったから登場したのです。
プラットフォームエンジニアリングの目標は、インフラをプロダクトとして扱う内部システムを作ることです。すべてのチームが独立してインフラの意思決定を行い、同じパターンを再発明する代わりに、プラットフォームエンジニアリングはそれらの懸念事項を再利用可能で適切に管理されたコンポーネントに一元化します。
実践において、プラットフォームエンジニアリングツールは、組織全体のインフラパターンを標準化し、終わりのない設定の選択肢の代わりに明確な前進の道筋を提供し、環境間の運用上のばらつきを減らし、チームやプロジェクトによって変わらない一貫した開発者体験を作ることを目指します。
すべてのスクワッドが独自のデプロイパイプラインを構築したり、独自の環境設定をデバッグしたりする代わりに、プラットフォームエンジニアリングはチームに、ただ動く共有の基盤を提供します。
今日プラットフォームエンジニアリングに投資しているチームは、それが流行っているからそうしているのではありません。代替案、つまりインフラの複雑さを抑制せずに複利的に増やすことが、持続不可能になりつつあるからそうしているのです。
なぜマネージドインフラがこのシフトに適合するのか
マネージドインフラは、プラットフォームエンジニアリングの目標と自然に一致します。
内部チームにすべてを自分たちで構築し保守するよう求める代わりに、マネージドプラットフォームは、すぐに使える本番対応の環境、組み込みのセキュリティとコンプライアンスのコントロール、明確な所有権と説明責任、そして予測可能なパフォーマンスと信頼性を提供します。
多くの組織にとって、このアプローチは、完全な内部プラットフォームチームを構築し運用するオーバーヘッドなしに、プラットフォームエンジニアリングのメリットを提供します。プラットフォーム会社になることなく、プラットフォームを手に入れるのです。
これはまさにBuildが位置する場所です。チームにインフラをゼロから組み立てたり、カスタムツールを保守したりすることを要求する代わりに、Buildは、初日から本番対応の環境、自動化されて一貫性のあるデプロイ、そして手動の介入なしに起こるスケーリングを備えたマネージドプラットフォームを提供します。
Buildを使うチームは、その基盤を自分たちで構築するために必要な内部エンジニアリング投資なしに、プラットフォームエンジニアリングが約束する標準化と信頼性を得ることができます。プラットフォームが差別化されない作業を処理するので、チームは自分たちのプロダクトに集中し続けることができます。
プラットフォームエンジニアリングツールは認知負荷を減らす
現代のプラットフォームエンジニアリングツールの最も過小評価されているメリットのひとつは、それが何を追加するかではありません。何を取り除くかです。
インフラの選択に関する絶え間ない意思決定疲労を取り除きます。機能をリリースするだけのために、スタックのすべての層を深く理解する必要性を取り除きます。既に会社を去った人々によって構築された独自システムに伴う深夜の火消しを取り除きます。新しいエンジニアを迅速に立ち上げるのを困難にするオンボーディングの遅延を取り除きます。
インフラが予測可能に動作するとき、チームはより自信を持ってより速く動けます。その信頼性は時間とともに複利で効いてきます。開発者がインフラについて考える時間が少ないほど、プロダクトを実際に差別化するものを構築することに費やす時間が増えます。
これがプラットフォームエンジニアリングツールの中核となる価値提案です。インフラを簡単にするのではなく、インフラを見えなくするのです。最高のインフラとは、開発者が決して考える必要のないものです。
Buildはこの原則を念頭に置いて設計されています。インフラはバックグラウンドで静かに動作し、自動的にスケールし、修復するべきです。そうすることで、エンジニアリングチームは注意を本来向けるべき場所に向けることができます。
制御 vs. 所有権
マネージドインフラに対するよくある懸念は、制御の喪失です。実際には、多くのチームが制御と所有権を混同していますが、それらは同じものではありません。
DIYクラウドは、すべての所有権を与えます。すべての障害モード、深夜2時のすべてのインシデント、そして1人のエンジニアだけが完全に理解している、ドキュメント化されていないすべての設定を含みます。
マネージドプラットフォームはその負担を移します。チームはまだ、アプリケーションがどう動作し、スケールし、デプロイされるかを制御します。彼らが手放すのは、競争優位性を生まないすべての低レベルのインフラ上の決定に対する責任です。
ほとんどのチームにとって、そのトレードオフは損失ではありません。レバレッジです。
インフラを管理しないことで解放されるエンジニアリングの時間は、機能の構築、アプリケーション層での信頼性の向上、そしてより速いリリースに向けることができる時間です。問題は、マネージドインフラがあなたに与える制御が少ないかどうかではありません。あなたが手放している制御が、そもそも持つ価値があったかどうかです。
未来は意図的なプラットフォーム
DIYクラウドから離れる動きは、利便性についてのものではありません。成熟度についてのものです。
システムがより複雑になるにつれて、成功する組織は、インフラをプロダクトとして扱い、終わりのないカスタマイズよりも一貫性に投資し、チーム間の摩擦を減らすためにプラットフォームエンジニアリングツールを使い、差別化が重要でない領域でマネージドソリューションを選ぶ組織です。
マネージドインフラは、プラットフォームエンジニアリングが理論上だけでなく、日々の運用で実際に機能するための基盤になりつつあります。このモデルを採用するチームは、同じシステムを繰り返し再構築するのをやめ、プロダクト自体への投資を複利的に増やし始めます。
DIYクラウド構成は、規模が小さく、チームが密接だったとき、チームが速く動くのを助けました。しかし、今日の現実は、信頼でき、安全で、成長をサポートするために意図的に設計されたインフラを要求しています。
そのため、現代のエンジニアリング組織全体で、プラットフォームエンジニアリングツールとその背後にあるマネージドインフラがDIYクラウド構成を置き換えつつあります。チームがより少ない力を望んでいるからではなく、本当に重要なものを構築することからの気を散らすものを少なくしたいからです。
Buildは、その基盤であるために存在しています。エンジニアリングチームがプロダクトのリリースに集中し、自信を持ってスケールし、摩擦なく動けるよう、インフラの複雑さを処理するプラットフォームです。