プラットフォームをプロダクトとして扱う

第3章 オーケストレーション オーケストレーション、自動化だけではないプラットフォームの本当の仕組み

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

Backstageのような開発者ポータルとArgo Workflowsのようなワークフローエンジン、あるいはGitHub ActionsのようなCI/CDパイプラインだ。これらのツールは強力でよく理解されており、成熟したプラットフォームのように作成される。しかし、見かけは欺くことができる。

UIと自動化の薄いレイヤーはプラットフォームのように見えるが、実世界のスケールをサポートする基盤となる調整、ガバナンス、ライフサイクル管理が欠けている。これは、プラットフォームのように見えるが、現実のスケールをサポートする根本的な調整とガバナンス、ライフサイクル管理が欠如している薄いUIとオートメーションの層である。

オーケストレーションでプラットフォームのファサードを脱却する

オーケストレーションがなければ、このようなプラットフォームは衰退してしまう。では、"プラットフォーム・オーケストレーション "とは具体的に何を意味するのかを探ってみよう。

パイプラインとワークフローエンジンの限界

CI/CDツールとワークフローエンジンは、ステップ・バイ・ステップのタスクを自動化する。デプロイの実行、再試行の処理、並列性の座標などに優れている。しかし、それらは基本的に一過性のシステムである。永続的な状態を管理したり、時間をかけてポリシーを適用したり、所有権を追跡したりすることはできない。

例えば、パイプラインはデータベースやアプリケーションをデプロイすることはできるが、誰がそれを所有しているのか、現在のポリシーに準拠しているのか、6ヶ月後にまだ使用されているのかを知ることはできない。チームがプロビジョニングをパイプラインだけに依存すると、可視性やライフサイクルの保証を共有できない、何十、何百もの単独タスクを作成することになる。

これはオーケストレーションではない。バラバラの自動化だ。

ポータル幻想

開発者向けポータルは、発見しやすさを改善し、プラットフォーム機能へのユーザフレンドリーなエントリ点を提供する。しかし、舞台裏でのオーケストレーションがなければ、ポータルは脆弱なオートメーションを実行するための洗練されたUIに過ぎない。

ボタンをクリックしてサービスをプロビジョニングすることは、セルフサービスのように感じるかもしれない。しかし、サービスが管理されないまま放置され、アップグレードパス、ポリシーの実施、ライフサイクルの追跡が行われない場合、ポータルは効率化を実現できない。それは、ドリフトとリスクを可能にしている。

これはよく「クリスマスの子犬」問題と呼び出される。開発者はボタンをクリックし、ピカピカの新しい環境、データベース、サービスを受け取る。しかし、クリックした後はどうなるのか？誰が子犬に餌をやるのか？誰が子犬をトレーニングし、子犬の後始末をし、子犬の成長に合わせて首輪がフィットするようにするのか？ソフトウェアの用語で言えば、誰がサービスのコンプライアンスを保証し、リソースが不要になったら非推奨にし、要件が変わったらアップグレードを実行するのだろうか？

答えは「誰もいない」ことが多い。そしてそれはエンパワーメントではない。それは放棄である。

自動化からオーケストレーションへ

このような罠を避けるために、プラットフォームチームは個々のステップを自動化する以上のことをしなければならない。 ...