この記事はジェームズ・アークハート（James Urquhart）が執筆したブログの翻訳版です。
企業のソフトウェア開発組織の管理者にとって、ソフトウェアのサプライチェーン、すなわちソフトウェアを「原材料」から「完成品」へと導く一連のソースおよびアクションという概念は、あまりに抽象的に感じられるかもしれません。この定義は本質的に正しくても、サプライチェーンがいかに既存の継続的インテグレーションと継続的デプロイメント（CI/CD）環境を補完するものであるかの説明には不十分です。
ソフトウェア開発プロセスのスピードと、そのプロセスを通過するアプリケーションの数が増加すると、アプリケーション チームとそのステークホルダー間で調整すべき内容も指数関数的に増加します。しかし、ほとんどの CI/CD ツールは、一度に 1 つのアプリケーションを提供するプロセスを定義するように構築されています。（多くのお客様が社内にお持ちの）品質重視のリリース エンジニアリング チームに、各アプリケーション プロセスの詳細の管理において、開発者とのやり取りにどれくらい時間がかかっているのか聞いてみると良いでしょう。きっと、かなりの時間を費やしている、と答えるはずです。
本番環境へのパスとは、ソフトウェア プロジェクトの構想段階から、ユーザー（消費者、患者、従業員など）に価値をもたらすまでのプロセスおよび活動全体を指します。今日これは、堅牢に相互連携された入力、アクション、リリース自動化という一連の作業により、テスト、セキュリティ検証、監査対応のガバナンス データの取得などを処理することを意味します。ビジネス オーナー、ゼネラル マネージャ、エンタープライズ アーキテクト、SRE、情報セキュリティ チームなどの誰もが、ソフトウェアがユーザーに安全かつ確実に届くまでのプロセスに関わるステークホルダーといえます。
ここで、現在の CI/CD ツールの「1 チームにつき 1 プロセス」という直線的で連続したアプローチには限界が出てきます。多くのプロセスを作成／実行することはできますが、一度に数百のプロセスを監視または変更するとなると、これらのツールは役に立ちません。VMware は、セキュリティ、運用、開発チームとのミーティングに多くの時間を費やしているリリース エンジニアリング マネージャやプラットフォーム エンジニアとよく会話をします。彼らは、プロセスのルーティングやポリシーの変更を各アプリケーションに適用し、複数のアプリケーションが更新されたときの想定外の影響に備えようと努めています。しかし、全社的にこれらの活動をより効率的に、より少ない労力で調整できないことに不満を感じています。
さらに、ほとんどの大企業がマルチクラウドやハイブリッドクラウドのプラットフォーム モデルに移行しているという事実もあります。これにより、各開発チームが使用するツールやサービスにばらつきがあると、本番環境へのパスの全社的な管理はより難しくなります。さまざまなプロセス定義、ツール、サービス、ポリシーの組み合わせによって、管理すべきシナリオは膨大な数になります。
ソフトウェア サプライチェーンによるスケーラビリティの実現
このような話は、以前にもありました。私たちがこれらの仕組みを通じて本番環境に提供しているアプリケーションは、それ自体がより大規模なアプリケーション システムの一部です。共有データにアクセスし、変更するには、共通のサービスが必要です。メッセージングとイベント ストリーミングのインフラは、アプリケーション間の重要な活動を通知する方法として、ますます重要な役割を果たすようになっています。多くのアプリケーションがさまざまな環境で実行されており、その運用も、それぞれの環境で刻々と変化する機能に対応していかなくてはなりません。
このように常に進化するシステムの管理は難しいため、この 10 年の間に、ソフトウェアの構築と運用の方法についていくつかの変革がありました。その中でも特に目立った動きが、マイクロサービス アーキテクチャと Kubernetes API による共通プロビジョニングです。
- マイクロサービス：的確なマイクロサービス戦略によって、大規模な組織はさまざまなビジネス ドメイン オーナー間で異なる課題を明確に分離し、システムの各部分への変更を、他の部分に影響を与えず行えます。また企業の IT 管理者は、チームの人員配置、トレーニング、作業を、企業ポートフォリオ内の他のアプリケーションと常に調整することなく実施可能となります。
- Kubernetes による自動調整：Kubernetes によって実現する極めて強力なコンセプトの 1 つは、あるリソース（例：サプライチェーンの活動）を管理するマネージャに、関連するリソース（例：任意のアクションの出力）に対する理想的な状態を伝えておくことができ、その状態に変化が生じるとリソース マネージャが望ましい状態に戻そうとするトリガーになることです。この考え方は、GitOps の重要な理念とされています。
この 2 つを組み合わせて本番環境へのパスを構築すると、各組織はそれぞれ独立して動ける能力を保ちながら、プラットフォームから提供されるアプリケーションの数を増やすことができます。俊敏性を失うことなくガバナンスを実現できるため、優れたデジタル組織の実現につながります。
まず、マイクロサービスによって組織全体にサービスを提供できるようになり、本番環境へのパスに関わる各種チームはさらなる俊敏性を獲得できます。たとえば、セキュリティ チームはコードとイメージのスキャンをサービスとして提供できます。一方で運用チームは、アーキテクチャやコンプライアンス体制など異なるアプリケーション カテゴリの要件に合わせて調整されたデプロイ ツールを実行できます。このような各種サービスは、オープンソースのプロジェクト Cartographer や、VMware Tanzu Application Platform に含まれる商用版のサプライチェーン コレオグラファーなどを通じて調整できます。サプライチェーン コレオグラファーの詳細については、RedMonk のインタビューをご覧ください。
各チームは、利用するサプライチェーンのリファクタリングを一切必要とせず、必要に応じてサービスを更新できます。開発チームや運用チームはさまざまなツールから、特定のワークロードに最適なものを選択できるようになります。Linux のテキスト処理ツールがパイプを使って連結できるように、サプライチェーンもコンポーザブルになります。
この図は、ここまで説明した多くの要素を組み合わせたサプライチェーンの一例です。ビルド プロセスには既存の Jenkins CI プロセスを使用すること、イメージ スキャンに対応するサプライチェーン オプションにはそれぞれ要求しきい値があること、プラットフォーム運用チームがサプライチェーン全体の流れを管理すること、開発者にはコード-イメージプロセスのコントロール権限が与えられること、セキュリティ運用チームが最終的なコードとイメージ スキャンに責任を持つことを確認してください。
実際、これらのアプリケーション カテゴリでも、各アプリケーションに必要なカスタマイズが可能なベースライン サプライチェーンを持つことができます。同じサービスを使用しても、おそらくアプリケーションによっては追加のテストが実行されたり、別の承認プロセスが起動されたりします。
このように課題に応じた分離をサポートするため、VMware は Tanzu Application Platform にコンベンション サービスを搭載しています。コンベンションとは、基本的にサプライチェーンを通過する際にあらゆるアプリケーションに適用できる設定に対する注釈（アノテーション）です。したがって、すべての PCI 対応アプリケーションでネットワーキングに特定の Ingress ルールが求められる場合、セキュリティ チームは PCI アプリケーション用にあらゆるサプライチェーンで適用されるコンベンションを作成することができます。コンベンションはサプライチェーンから独立して管理されるため、バージョン管理および展開も独立して実施できます。
これらのメリットを享受するために、既存の CI/CD ツールを置き換える必要はありません。既存のプロセスを、サプライチェーンに含まれるサービスに変えることができます。また、サプライチェーンの残りの部分が実行される前に CI 出力に自動調整が適用されるため、その出力の正確性を自動で検証できます。既存の CD 自動化は適切なサプライチェーン条件が満たされたときにトリガーされ、検証済みのアプリケーションのみが確実に本番環境にデプロイされます。ほとんどのユーザーは既存のツールの統合を行ってから、他のサプライチェーン管理の比較した際に感じられるこの CI の強みを活かし、本番環境までのパスにおける各種要素を段階的に進化させていくでしょう。
これらすべてを組み合わせて構築された環境では、アプリケーションごとに各ステップをすり合わせる必要がなく、多くのアプリケーションの高度な開発が可能であり、拡張も容易です。
より良い組織構造を実現するサプライチェーン
コンポーザブルなソフトウェア サプライチェーンを活用すると、より良い組織構造を作り、迅速かつアジャイルにソフトウェアを提供できることがおわかりいただけたと思います。このモデルでは非常に柔軟に、さまざまな方法でチームを編成することができます。
開発チームがビルド プロセスを自ら管理したい場合は、プラットフォーム チームにそのためのツールを提供してもらい、セキュリティ、運用、統合のタスクを自動化して、開発者の労力を軽減します。あるいは、開発者がコードをプッシュするだけですべてが自動的に行われるようにしたい場合は、リリース管理チームを編成して、そのような自動化環境を作り出すことに専念させます。リソース消費量の基準をより柔軟に設定／変更したい場合は、開発者体験に変化を加えることなく、ツールを提供できます。
サプライチェーン コレオグラフィー アプローチのポイントは、VMware が複雑なアプリケーション システムの構築に採用してきたのと同様のアーキテクチャ原則、すなわちマイクロサービスと共通のインフラ抽象化をシンプルに活用することです。このようにコンポーザブルな環境によって、極めて柔軟にソフトウェアサプライチェーンとそのステークホルダーを組織化／最適化しながら、製品としてのプラットフォームを強力に維持できるようになります。
関連ホワイトペーパーのダウンロード：Why You Should Treat Platform as a Product（プラットフォームを製品として扱うべき理由）
多くの組織が、主要なガードレールやフィードバック ループを壊すことなく変化に適応できるかという課題に直面しています。優れたソフトウェアのサプライチェーンの活用によって、この課題に対処し、スピーディに革新的な顧客体験を創造できるソフトウェア提供手法を確立できます。
