OPAによる開発者の自由とガバナンスのバランス

おいしいビールに加えて、開発者の幸福度に関わる次なる最大要素は、仕事を迅速かつ効果的に行うためのツールとプロセスにアクセスできることです。

エンタープライズ ソフトウェアにおいて、「開発者エクスペリエンス」ほど流行しているバズワードはありません。過去10年間で、組織が速度を上げてビジネスの俊敏性を高めるためにDevOpsモデルに移行するにつれて、Ops中心の考え方からDev中心のアプローチへと進化したことは驚くべきことです。開発者中心のアプローチへの移行は、クラウドおよびプラットフォームエンジニアリングへの多額の投資も促進しています。

企業における開発者のエクスペリエンスを向上させることは、非常に困難な作業です。歴史的に、ほとんどのエンタープライズ環境では、新しい開発者がエンタープライズ環境で真の生産性を発揮するために必要なツール、システム、およびプロセスを理解し、生産性を高めるのに通常６カ月以上かかります。

開発者を幸せにするものは何ですか?

おいしいビールに加えて、開発者の幸福度に関わる次なる最大要素は、仕事を迅速かつ効果的に行うためのツールとプロセスにアクセスできることです。かつてほとんどの企業では、開発者は悪質なレガシーツールを使用する必要がありました。それらはオンプレミスのインフラストラクチャーを遅らせることになり、年次または四半期ごとのイベントへの本番リリースを遅らせるレビュープロセスを、複雑で入り組んだものにしていました。

インフラストラクチャーとパイプラインの自動化に即座にアクセスできるクラウドネイティブの世界しか知らず、「開発者がデリバリーの自動化を制御できなかった」という過去のパラダイムを受け入れなくなった、新しいタイプの開発者がいます。これらの「クラウドで生まれた開発者」は、企業が引き付けようとしており、かつ、雇い続けるのに苦労している人たちです。

では、開発者が望むもの全て、無条件で提供するのはどうでしょうか？

プラットフォーム エンジニアリングのジレンマ

ソフトウェア配信サービスを構築するプラットフォームエンジニアリングチームは、開発者に王国への鍵を与えて、邪魔をしないことだけを望んでいます。課題は、セキュリティー、ガバナンス、および可用性を強化しながら、チームに制御を与えることです。古くから、プラットフォームエンジニアリングチームが開発者に自由を与えることは非常に困難でした。Harnessは、2017年に強化されたガバナンスコントロールを備えたサービスとしてのCDを導入して、その問題の一部を解決するのに役立ちました。ただし、きめ細かい役割ベースのアクセス制御とテンプレートを使用しても、ほとんどの規制環境では、本番環境に関係するパイプラインステージは厳密に制御されていました。では、ソフトウェア配信の共有サービスに関しては、どの程度の成熟度があるのでしょうか?このブログでは、配信の成熟度のさまざまな段階と、各段階の特徴に焦点を当てます。

ソフトウェア配信成熟度フェーズ

フェーズ 1: フリーフォーオール

このレベルの成熟度は、スタートアップの初期段階を除いてめったに見られませんが、継続的インテグレーション (CI) が導入された当初はかなり一般的でした.各開発チームには、標準化やガバナンスがほとんど、またはまったくない独自のソフトウェア配信ツールがありました。他のチームが配信プロセスに関与していた場合、アーティファクトを効果的に実行、またはトラブルシューティングする方法に関するドキュメントがほとんど、またはまったくない状態で、アーティファクトが壁を越えて投げ出されることは珍しくありませんでした。

フェーズ 2: ロックダウン

フェーズ１で何かが発生した後 （通常は主要な本番インシデント）、成熟度の次のレベルは、ソフトウェア配信の完全なロックダウンです。これは、プラットフォームエンジニアリングチームがプロセスを引き継ぐ場所ですが、ビジネスに直面しているチームはプロセスをほぼ、またはまったく制御ができません。パイプラインの変更には、プラットフォームエンジニアリングへのチケットと長い待ち時間が伴います。実際、Droneの創設者であるBrad RyzenskiがCIツールを構築する動機の１つは、彼が勤務していた銀行で静的Jenkins ランナーへのライブラリーの変更に数カ月かかることでした。このタイプのソフトウェア配信シナリオは、昨今でも多くの規制された組織で非常に一般的です。

フェーズ 3: アンクレット

これはおそらく、プラットフォームエンジニアリングチームが継続的デリバリー（CD）のために専用の料金を導入している大企業にとって、最も一般的なソフトウェア配信シナリオです。開発者がパイプラインを変更してニーズに合わせてカスタマイズできるようにする権利がありますが、運用レベルの環境に触れるパイプラインまたはパイプラインステージは厳しく規制されています。開発者は環境の下位ステージを変更できますが、本番パイプラインを変更するのは少数の選ばれた人だけです。これにより、ビジネスユニットとプラットフォームエンジニアリングの間に多くの摩擦が生じ、通常はリリース速度が遅くなります。

フェーズ 4: ポリシードリブンのセルフサービス

これは、プラットフォームエンジニアリングチームがソフトウェア配信のために達成できる最高レベルの成熟度です。この成熟度レベルでは、運用リリースの要件を定義するポリシーベースのガバナンスアプローチによって、運用への道が切り開かれます。セキュリティースキャン、機能テスト、変更管理の承認、および製品リリースのその他の要件は、Policy as Codeとして定義されます。ソフトウェア配信サービスを使用するビジネスユニットは、デリバリーパイプラインを完全に制御でき、ガバナンスの実施は、そのPolicy as Codeによって一元的に管理されます。

OPAで真の開発者セルフサービスを実現 

真の開発者セルフサービスを実現するために、Policy as Codeを導入するだけでよいのであれば、なぜこれがプラットフォームエンジニアリング チームによって広く導入されないのでしょうか？組織によるPolicy as Codeの導入を妨いでしまう要因はたくさんあります。ポリシーコードの標準としてOpen Policy Agent（OPA）が作成されるまで、ソフトウェア配信でPolicy as Codeを実装する簡単な方法はありませんでした。ポリシードリブンのセルフサービスを妨いでいるもう 1 つの要因は、多くの組織におけるCDは、依然としてほとんどの組織でスクリプトをオーケストレーションするCIツールであるという事実です。CDへの宣言型アプローチを持つことは、ポリシードリブンのソフトウェア配信の要件です。

OPAは、Policy as Codeを定義し、セキュリティーポリシーをアプリケーションリリースから分離して、真のポリシーベースのガバナンスを大規模に実現する強力な宣言型の方法です。Harnessは、ガバナンスに対するOPA中心のアプローチを持つ最初のソフトウェア配信プラットフォームです。Harnessよりも前は、パイプラインがポリシーベースのチェックを統合する唯一の方法は、プラグインまたはソースコードリポジトリーフックを使用することでした。これは通常、ユーザーエクスペリエンスのまとまりのなさと導入の抑制につながります。

HarnessプラットフォームにおけるOPAポリシーは、プラットフォーム全体にガバナンスを適用するのに役立つ第一級オブジェクトです。ポリシーの作成はネイティブに構築されており、パイプラインの保存と実行の両方にポリシーを適用する機能により、組織はコンプライアンス違反のパイプラインが最初から作成されるのを防ぐことができます。

Policy as Codeは、Harnessプラットフォームの他の機能にまたがるパイプラインを超えています。パイプライン外でのOPA適用の好例は、 Harness Feature Flagsです。ほとんどの企業は、フィーチャーフラグを導入するためにシェアードサービスアプローチを導入し始めたばかりであり、さまざまなビジネスユニット間で標準管理することは非常に困難な場合があります。OPAポリシーとHarness Feature Flagsを使用して、シェアードサービスチームはフラグの命名基準と要件を適用できます。

採用されている最も一般的なポリシーの 1 つは、特定の下位環境では有効になっていないフラグを本番環境で有効にできないようにする機能です。テストされていない機能トグルが機能停止 (Knight Capital Groupの場合は倒産) を引き起こした例が広く公表されているため、ポリシーベースのガバナンスは、機能管理を採用する組織にとって必須です。

OPAで開発者を解放しよう

これは開発者中心の世界であり、強固なプラットフォームエンジニアリング基盤は、開発者と製品所有者を高いリリース速度で満足させるための差別化要因です。ソフトウェア配信における究極の成熟度は、ポリシーベースのガバナンスへのアプローチであり、開発者がガードレールを使用して本番環境へのパスを自由に変更できるようにします。Harnessは、OPAをネイティブ機能として採用することにより、ポリシーベースのガバナンスに全体的なアプローチを取っている業界で唯一のソフトウェア配信プラットフォームです。

詳細については、 Harness OPA機能のデモをご覧ください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。