1.1　Platform Engineering

　BackstageはPlatform Engineeringの実現を補佐、加速するためのツールのひとつです。Backstageの説明の前に、Platform Engineeringについて簡単におさえておきましょう。

　Platform Engineeringとは近年急速に注目を浴びつつある技術分野であり、Gartner社による2024年の戦略的技術トレンドTop10¹に入るなど、非常に期待されている考え方です。Platform Engineeringは、開発者の認知負荷の軽減と生産性の向上を目的としています。

Platform Engineeringの必要性

　Platform Engineeringの考え方が登場するより前、開発・インフラ・QA・運用保守などが組織ごとに独立していた時代は、組織間のコミュニケーションコストが高く、ボトルネックが発生しやすい状況であり、組織のサイロ化が課題となっていました。その後、ソフトウェア開発とデリバリーを継続的に行うDevOpsの導入により、組織のサイロ化などの問題はある程度解決されました。しかしながら、クラウドの普及、クラウドネイティブ技術の登場、マイクロサービス化の流れは、エンジニアの責任範囲を広げ、認知負荷の増大と生産性の低下を引き起こしています。つまり、開発者がエンドツーエンドでアプリケーションのデプロイや運用まで責任を持つと、多岐にわたるスキルセットが求められるため、依然として大きな課題となっています。

　たとえば、アプリケーションを開発して公開するまでのプロセスを考えてみましょう。アプリケーションを開発し、そのアプリケーションをクラウド上でデプロイするとして、AWSやAzure、Google Cloudといったメガクラウド、Vercelのようなアプリケーションプラットフォーム、Cloudflareなどが提供するエッジコンピューティングのサービスなど、さまざまな選択肢があります。デプロイ先のプラットフォームを絞ったとして、デプロイするための環境としてVMや Kubernetes環境、サーバーレス環境などさまざまな選択肢が存在し、自身にとって最適な選択肢を選ぶことが求められます。デプロイ環境だけでなく、CI/CDのパイプラインであったり、セキュリティーの設定、モニタリングの設定、ログの収集、アラートの設定など、アプリケーションを運用するための設定も多岐にわたり、考慮事項は山積みです。

解決策としてのPlatform Engineering

　開発者がエンドツーエンドでアプリケーションのデプロイや運用まで責任を持つことに課題がある状況を受けて登場したのが、Platform Engineeringです。Platform Engineeringは開発者の認知負荷軽減と生産性向上を第一の目的とし、負荷の根源となっている諸々を解決する基盤＝プラットフォームを構築・運用する、また、それを行う専任チームを作っていく考え方です。

　Platform Engineeringでは専任のプラットフォームチームを組織し、開発チームを「顧客」と見立てて開発者体験を向上させて、開発者の認知負荷の低減を目指します。そのために開発者が求める機能をプラットフォームの形で提供し、開発チームへのヒアリング・フィードバックをうけて、継続的にプラットフォームを改善していく役目を担います。

　プラットフォームチームには、開発者がスムーズに開発を行えるようにするための、たとえば以下のような機能の提供が求められます。

　・開発の助けとなるような情報を整理する

　・開発にスムーズに取り組めるようにオンボーディングの仕組みを整える

　・必要に応じて勉強会やワークショップの開催を行う

　・開発者からの質問や問い合わせに対して対応する

　・開発者の体験や生産性を向上するためのあらゆるタスクを自動化し、開発者がセルフサービスで利用できるプラットフォームを提供する

　プラットフォームとプラットフォームチームの背景・要件については、CNCFが出しているCNCF Platforms White Paper²に非常によくまとまっています。Platform Engineeringを知るうえで、一度目を通してみるとよいでしょう。

1.2　Internal Developer Portal

　開発者が開発を始めるために必要な要素は何でしょうか。まずは開発を行うためのツールやプラットフォーム、つまり開発環境が必要です。チーム開発を行う上では開発者が守るべきルールが必要ですし、与えられた環境で開発を行うためのノウハウも必要です。

　従来の基盤チームは主に開発環境の提供に注力していましたが、開発環境だけがあってもそのほか扱うべきものが多く、開発者にとっては認知負荷の高い状態が続いていました。そこで、 Platform Engineeringでは開発環境のほか、開発環境を扱うためのルールやノウハウの提供も同様に重要となっています。

Golden Pathの重要性

　Platform Engineeringで開発環境のほかに開発環境を扱うためのルールやノウハウを提供するうえでは、「Golden Path」という考え方が重要になってきます。「Golden Path」とは、開発のベストプラクティスとそれを実装するための環境を開発者に提供することにより、迷わず効率的に仕事を進められるようにする考え方です。

　Golden Pathには、実際に動くサンプルアプリとそのソースコード、アプリの開発に必要なCIパイプラインやGitOps環境、そしてGolden Pathによって構築された環境の可観測性や、Golden Pathの価値を正しく理解して活用するためのドキュメントが含まれます。プラットフォームチームからのGolden Pathの提供により、開発者に守ってほしいルールを付与しつつ、実際に動くアプリとコードにより開発者のノウハウ習得をサポートできます。

　Golden Pathを提供することが、プラットフォームチームの主要なミッションのひとつとも言えます。

Internal Developer PlatformとInternal Developer Portal

　プラットフォームチームが開発者に機能を提供するためのアプローチとして、Internal Developer Platform（内部開発者プラットフォーム）/ Internal Developer Portal（内部開発者ポータル）という考え方があります。内部開発者プラットフォームはアプリケーションが動作する環境を抽象化し、開発チームが必要とする機能/仕組みを整備します。一方で内部開発者ポータルは、開発チームがプラットフォームを操作するためのインターフェースを提供し、セルフサービスでの利用を可能にします。

　このうち、内部開発者ポータルがGolden Pathによってつくられたドキュメントやテンプレートの公開先として、また各種プラットフォーム機能へのリンク等を記載する先として、開発者にとっての窓口となります。

　内部開発者ポータルの代表例として、「Backstage」があります。Backstageは、Platform Engineeringのノウハウの集大成を展開するためのPortalといえます。

　では、Backstageはどのような背景で生まれ、どのような目的を持っているのでしょうか。

1.3　Backstageの目的と解決する課題

　Backstageはもともと音楽配信サービスのSpotify社で開発され、開発者がSpotifyのソフトウェアを効率的に管理、作成、探索できるように設計されたプラットフォームでした。2020年9月にオープンソースソフトウェア（OSS）としてCloud Native Computing Foundation(CNCF)に寄贈されています³。

　数年前、Spotify社ではエンジニアリングチームの拡大とともに、製品開発スピードの維持に課題が生じていました⁴。開発者は文書化されていない組織的な知識の不足に直面しており、新しいコンポーネントの作成方法の伝達、システムのメンタルモデルの維持、そして将来的な再利用性の確保が大きな課題となっていたのです。これらの課題は、成長する組織のスケールと製品開発の速度を同時に維持することを難しくしていました。コンテキストの切り替えと認知の過負荷が日々エンジニアの生産性を下げており、Spotifyはインフラやツールのあらゆる側面に精通しなくとも、エンジニアが仕事をしやすくする必要性に迫られていたのです。Backstageはこれらの課題に対して、インフラと開発者ツールを抽象化し、エンドツーエンドのソフトウェア開発を一元化して簡素化するために開発されました。

　Backstageは、すべてのソフトウェアとその所有者を一元的に管理し、発見可能にすることを目的としています。つまり、個々のコンポーネントがどのように動作し、誰によって管理されているかにかかわらず、インフラ全体を網羅する開発者ポータルとして機能することを目的としています。Backstageのビジョン⁵は、「最高の開発者体験の提供」です。このビジョンのもと、開発者は多様なインフラストラクチャーツールに深い知識を持つ必要がなくなり、インフラストラクチャーの抽象化を通じて、安全かつ迅速にシステムを構築、スケールアップできるようになります。

コンセプトと哲学

　Backstageは、プラグインアーキテクチャを採用しており、以下の3つの主要な構成要素から成り立っています。BackstageインスタンスはNode/Reactアプリであり、コミュニティーやプライベートのプラグインをインストールするBackstageのコアライブラリーの上に構築されます。

　・Core（コア）

　　─オープンソースプロジェクトのコア開発者によって構築された基本機能

　　─CLI、ユーティリティツール、API定義などを含む複数のパッケージで構成される

　・App（アプリ）

　　─組織のエンドユーザーが利用する開発者ポータル部分、コア機能と追加のプラグインを結合する

　・Plugin（プラグイン）

　　─Backstageアプリを特定の企業のニーズに合わせて拡張するための追加機能

　　─企業固有のものからオープンソースで再利用可能なものまでさまざま存在する

　　─基本機能もプラグインとして抽象化されており、カタログを含むいくつかのプラグインを常に使用している

　　─独自のプラグインも作成可能

　また、Backstageには、3つの核となる哲学があります。

　・Backstage is the interface

　・Backstage embraces autonomy

　・Backstage demands clear ownership

Backstage is the interface

　ひとつ目の哲学は、『インターフェイスとして一元化を行う』です。

　開発において多くのインフラツールが扱われますが、Backstageはこれらを同一のインターフェイスを通じて一元化することを目的としています。重要なのは、Backstageはインフラツールを再実装するものではない点です。たとえば、CI/CDのビルドステータスの表示は可能ですが、詳細なトラブルシューティングにはCI/CDツールを直接確認することが推奨されます。

　つまり、Backstageはインフラのすべてを置き換えるのではなく、インフラの上にレイヤーを追加し、外部ソースからの情報源を集約して単一のインターフェイスにまとめて提供します。

Backstage embraces autonomy

　ふたつ目の哲学は、『開発者の自律性の支援を行う』です。

　Backstageを通して、開発者は必要な環境をセルフサービスで利用できます。Backstageでは、プラットフォームチームからこの環境を使うこと、といったトップダウンでの環境の強制は推奨されません。つまり、開発チームは独立して行動し、自身のチームに合った環境を選択できます。Backstageはそのプラグインアーキテクチャを通じて、トップダウン式の全体プラットフォーム実装ではなく各チームの自律性の支援を目指しています。

Backstage demands clear ownership

　3つ目の哲学は、『明確な所有権の確立』です。

　Backstageは所有権を明確にして集中的な管理を避けることで、情報の透明性とアクセス性の向上を目指しています。Backstageで管理する各ソフトウェアコンポーネントには、明確に所有チームを紐づける必要があります。所有権の明確化により、誰がそのソフトウェアをメンテナンスしているのか、依存関係は何かが明確になり、情報の検索容易性が上がります。つまり、特定のソフトウェアについて知りたいときの窓口が明確になります。

1.4　Backstageによる3つのユースケース

　Backstageは、「Create」「Manage」「Explore」の3つのユースケースにフォーカスして開発者を支援します⁶。Backstageは上記3つのユースケースを通して今日の開発における障壁を取り除き、開発サイクルを合理化して開発者が本当にやりたいこと、つまり優れた機能を構築するためのビルディング・ブロックの提供を目指しています。

　それぞれのユースケースについて、具体例を考えてみましょう。各ユースケースを実現するBackstageの機能については、次章以降で詳しく解説します。

Create

　現代のアプリケーション開発においては、多様なツールを使用することが一般的となっています。多用なツールを使用するがゆえに、開発プロジェクトの立ち上げからアプリケーションリリースまでのプロセスは複雑化し、長い時間を要するようになっています。

　新しいマイクロサービスの構築を始める準備をしているところを想像してみましょう。フレームワークは何を選択すればよいでしょうか。サービスを本番稼働させるためのキャパシティはどのように確保すればよいでしょうか。また、CI/CDの管理はどのように行う必要があるのでしょうか。

　Backstageでは、Software TemplatesとTechDocsによってCreateのユースケースを実現します。Software Templates機能を利用し、あらかじめよく利用されるマイクロサービス、モバイル機能、データパイプラインなどをテンプレートとして用意しておくことで、アプリケーション開発者は新しいプロジェクトを立ち上げる際に、テンプレートから数クリックで新しいプロジェクトを開始できます。テンプレート中に個社固有のベストプラクティスやセキュリティーポリシーを組み込むことで、開発者が必要なポリシーを遵守することのサポートもできます。また、TechDocsという機能でドキュメントを集約できます。新しい開発を始めるためのオンボーディングドキュメントやAPIの内容などを、それぞれのリポジトリーに移動せず、Backstage上で一元的に確認できます。

Manage

　開発したアプリケーション資産を管理することもまた、開発者にとって重要なタスクです。12個のサービスを所有する小規模なチームに所属しているとしましょう。所有しているサービスをアップデートしたりデプロイをしようとするたび、クラウドベンダーのコンソール、CIツール、セキュリティーダッシュボード、CLIを切り替えて、作業を行っている姿が想像できるのではないでしょうか。

　Backstageでは、Software CatalogによってManageのユースケースを実現します。Software Catalogは、チームのソフトウェアコンポーネントを一箇所で管理するための機能です。チームのソフトウェアコンポーネントはすべて、Software Catalogのひとつのページにまとめられています。Software Catalogから任意のサービスのページに移動すると、そのサービスのCI/CDステータス、Kubernetesデプロイステータス、ドキュメント、セキュリティーチェック結果など、そのサービスに関連するすべてが、必要な情報だけを表示するシームレスなインターフェイスにまとめられています。これにより、コンテキストの切り替えや複数の管理ツール間の移動が不要になり、効率的な運用が可能になります。また、Backstageでは、KubernetesプラグインによってKubernetes上で動作するサービスの管理ができます。当該のサービスがKubernetes上で稼働しているケースにおいて、PodやDeployment等がどのようなステータスなのかを一元的に確認できます。

Explore

　新しい機能を開発している途中で、ほかのチームが開発しているであろう汎用的なライブラリーを再利用したいと考えたことはありませんか。しかしそのライブラリーがどこにあるのか、誰が作成したのか、どのように使うのか、といった情報を見つけられないということはありませんか。

　Backstageでは、Software CatalogのList機能によってExploreのユースケースを実現します。チームのソフトウェアコンポーネントはすべて、Software Catalogのひとつのページにまとめられています。情報の集約により、誰でも組織内の他の人が作成したツール、ライブラリー、フレームワーク、ドキュメントを見つけられるようになり、ライブラリーやサービスのページに行けば、所有者やドキュメント、APIや、必要に応じて拡張する方法まで把握できます。これにより、コラボレーションが促進され、同じ問題に対する複数の解決策の開発を防ぎます。

1.5　まとめ

　本章ではPlatform Engineeringが登場した背景や、その中でのBackstageの立ち位置、解決しようとしている課題について解説しました。次章からは、具体的なBackstageの導入方法や各機能について解説します。