Backstageの簡単な紹介
Backstageとは
先日、本ブログ内で「Platform Engineering」に関する記事が投稿されました。
今日ご紹介する Backstage はPlatform Engineeringを実現するツール・サービスの１つです。 BackstageはSpotifyが開発し、その後CNCFに寄贈されたものです。実際にSpotify内部で利用されています。
BackstageはPlatform Engineeringで構築するIDP（Internal Developer Platform / Portal）の１つです。 そのビジョンは「最高の開発者体験を提供すること」です。開発者はさまざまなインフラストラクチャツールの専門家である必要はなく、インフラストラクチャを抽象化することで、安全かつ迅速に構築・スケールできるようにします。Backstageは「開発者体験におけるKuberentesのような位置付けのサービスとなる」ことを目指しています。 実際に立ち上げてみるとわかりますが、まさに開発ポータルを実現するものになっています。 （主に表示関係の内容になっていますが、デモサイトが公開されていますので雰囲気はそちらで確認することができると思います。）
何を実現しようとしているか
Backstageがどういったことを実現しようとしているか、中心となる３つの機能を見ていきましょう。
Catalog機能
Microservice Architectureを採用しているチームを考えてみましょう（私自身が普段経験している内容をベースにしています）。Microservice Architectureは１つのシステムを複数のプログラムに分割しています。こうした場合、チームが開発で使用するソースコードリポジトリも分割されていることが多いかと思います。リポジトリが複数に分割している場合
- Pull Requestが滞っていないか、複数のリポジトリを見て回らなければならない
- CIツールなどでなにかエラーが起きていないか、それぞれのリポジトリごとに確認が必要
- 各プログラムのAPIの内容の確認のため、それぞれのリポジトリにアクセスしなければならない。
と、何事もリポジトリ毎に分割されることが多くなり、あちこちのリポジトリを見て回る作業が発生します。 もちろんCI実行完了時やPull Requestが作成されたタイミングでチャットツールに通知が出るようなしかけをしていますが、見落としがあったりするので、どうしても状況確認は必要になってきます。
BackstageではSoftware Catalogという機能が用意され、こうしたリポジトリの情報を管理することができます。 このCatalog情報画面でPull Request一覧やCIの実行結果などが確認できたらわざわざ各リポジトリへ確認に回らなくて済みます。
（開発・検証中の画面です）
Template機能
Microservice Architectureでは機能拡張時新たなプログラムを追加することも多いと思いますが、基本となる部分はそれほど変わらないため言語やフレームワークが要ししている初期コード作成ツール（Spring Initialzrのようなもの）を利用するか、既存のソースコードからコピーすることが多くあります。また、CIの設定やワークフロー定義などもコピーするなどして用意しなければなりません。こうした作業を行い、実際のビジネスロジック開発に着手するまでに意外と時間がかかることがあります。
こうしたとき初期状態のテンプレートがあったらいいのに、と思うのではないでしょうか。Backstageではその名もずばりTemplate機能というものが用意されています。
これはGit Repository上に用意されているテンプレートをもとに新しいリポジトリを作成（またはMerge Requestを作成）してくれる機能です。このテンプレートで初期状態のソースコードや必要なLint設定やCIワークフロー定義などを用意しておけば、時間を取らずにすぐにビジネスロジック開発に着手することができます。
TechDocs機能
新規にチームにジョインしたメンバーのオンボーディングや、APIの内容の確認など、システム設計・利用に関するドキュメントをMarkdown形式でリポジトリに保持しているところは多いと思います。
さきほどのCatalog機能の課題の中で 各プログラムのAPIの内容の確認のため、それぞれのリポジトリにアクセスしなければならない。 というものがありましたが、これもそうしたドキュメントを参照する機会のひとつです。
また、もしこうしたチームが複数ありそれぞれのシステムが連携している場合など、別のチームに利用法を伝えるためにもこうした情報が必要になったりするでしょう。
こうした場合にリポジトリ等にわざわざいかないといけないというのは面倒です。BackstageではTechDocsというMarkdownファイルをBackstage側にImportする機能があります。
Backstageにいけば、すべてのドキュメントを確認できますので探しにいく手間が省けます。また検索機能もありますので、「どのリポジトリにあったのか忘れた」という場合でもすぐに探し出すことができます。
より詳細に内容を確認したい、という場合もそのドキュメントがどのCatalogに紐付いたものなのかがすぐに分かりますので、リポジトリ内容の確認や開発チームへのコンタクトなどもできるようになります。
Pluginで拡張可能なBackstage
このように開発チームの成果物をCatalogなどでまとめてくれるのがBackstageの主要機能ですが、これだけではありません。 様々な機能・サービスと連携できるようになっています。すでにいくつものサービスとの連携機能が開発・公開されています。
以下は公開されているBackstage Pluginの一部です。DataDocやArgo CDなども用意されています。 毎回そうしたツールにアクセスしなくても、まずはBackstageで確認し、必要に応じてDataDocやArgo CDなどにアクセスして対処することができるようになります。
まさにBackstageは開発チームのポータル（玄関口）として様々な機能を果たしてくれるのです。
私たちの取組み
現在私たちのチームではBackstageを立ち上げ、よりよい利用方法を開拓しています。さらに、よりよい開発体験を提供すべく独自のBackstage Pluginなども開発していければ、とも考えています。（まずはAzure環境をベースに検討中です）
また、このBackstageはTeam Topologiesの概念とも相性がよいものです。
Backstageが解決しようとしている課題は、開発チームのIntrinsic、Extraneousに該当する認知負荷に関するものです。 これらを低減するためのPlatformがBackstageをはじめとしたIDPであり、Platform Engineeringの結果とも言えるのです。 私たちはさらにもう一歩Team Topologiesの要素を取り込んで、開発チーム間の連携をしやすくする環境としてもBackstageを活用できればと考えています。
もし興味がある方がいらっしゃればぜひご連絡ください。
また、実際BackstageをAKS上に立ち上げていますが、立ち上がるまでにAKS側の設定やBackstageの設定、連携対象であるAzureやGitHubの連携方法など、ドキュメントではさらっとしか書かれていないのですが苦労が多々ありました。 そうした情報も機会があればこちらのBlogでご紹介していければと思います。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。 実はTeam Topologiesもこうした内製化支援の一部です。
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
