「優れた」プラットフォームエンジニアリングとは何ですか?

オープンソースの中国コミュニティチームは、共有の名のもとに、オープンソースの中国コミュニティの背後にあるストーリーを伝える初のライブブロードキャストを行いました。」

プラットフォームエンジニアリングのアプローチにより、開発者の時間が節約され、チームは開発者からの日常的なリクエストのカテゴリ全体を排除できます。

著者 Dormain Drewitz の『Platform Engineering: What Does 'Good' Look Like?』より翻訳。

開発者のエクスペリエンスを向上させるために、ますます多くの組織がプラットフォームエンジニアリングに注目して、退屈な作業を削減し、収益を生み出す機能とイノベーションに焦点を当てています。

プラットフォームエンジニアリングは 2 つの主な利点をもたらします。 1 つ目は、組織内の人々が新しいソフトウェアを試せるセルフサービス機能の導入です。 2 つ目は、適切に管理された環境で実験が確実に実施されるように、自動化されたインフラストラクチャ運用を組み込むことです。

このメリットは非常に大きいため、2026 年までに大規模なソフトウェアエンジニアリング組織の 80% がプラットフォームエンジニアリングチームを持つようになるだろうとGartner は予測しています。しかし、誇大広告の背後には何があるのでしょうか?

プラットフォームエンジニアリングとは何ですか?

プラットフォームエンジニアリングのアプローチはDevOps を補完します。「プラットフォーム」とは、開発者が安全で準拠した環境でソフトウェア (アプリケーション、ツール、ワークフローなど) を構築および実行するために作成された内部環境です。

プラットフォームエンジニアリングの主な目的は、セキュリティと可用性のリスクを軽減しながら、開発者の作業を効率的に拡張することです。開発者プラットフォームは、大規模な開発に伴う膨大なコストと複雑さに対処します。これらのコストが発生する最も一般的な理由は、開発者がプロジェクトごとに (またはプロジェクト内の個別のテストケースでも) 個別の環境を立ち上げることです。もう 1 つの利点は、統合プラットフォーム内で動作する運用プロセスを自動化できるため、大規模な作業が可能になる可能性が高まることです。

このアプローチを成功させるには、ソフトウェアを同じプラットフォーム内に展開する必要があります。表面的には、プラットフォームエンジニアリングのアプローチは生産性の制約のように見えるかもしれませんが、実際には開発者の創造性を解放し、日々の退屈な作業を大幅に軽減することができます。

構築と購入: 組織はそれをどのように実装しますか?

プラットフォームプロジェクトを成功させるには、プラットフォームが正しく実装されている必要があります。組織はプラットフォームに合わせてカスタマイズする必要があるため、既製の製品を単純に購入することはできません。同時に、実稼働環境でソフトウェアをデプロイして実行するときに発生する無数のインフラストラクチャ、CI/CD、セキュリティ、その他の「実行すべき仕事」に対処するために利用できるポイント製品やオープンソースプロジェクトが多数存在します。

これは、組織が購入した製品や導入したオープンソースソフトウェアに対して何らかのエンジニアリング作業を行う必要があることを意味します。しかし問題は、自分のデザインのどの程度が適切なのかということです。プラットフォームエンジニアリングは、これらの組織の差別化を促進するのではなく、ビジネス目標から気をそらしてしまう可能性があります。

この問題の解決策は、組織が可能な限り無駄のないプラットフォームを構築することです。プラットフォームエンジニアリングチームは、最初からプラットフォームを構築するべきではなく、他のプラットフォームの上に構築する必要があります。組織は、ソフトウェアチームがサーバーの接続から製品の提供まですべてを行うことを期待していませんし、プラットフォームエンジニアリングチームがゼロからプラットフォームを完全に実装することを期待すべきではありません。

代わりに、これらのチームは巨人の肩の上に築く必要があります。このアプローチを推進するには、組織はできるだけ多くのサービスとしてのプラットフォーム (PaaS) ツールとサービスとしてのソフトウェア (SaaS) ツールを購入し、それらをバンドルして完成した実行可能なプラットフォームを構築する必要があります。最も基本的なプラットフォームエクスペリエンスを維持、統合、更新するには十分な作業が必要です。これには、社内エンジニアが使用するインターフェイスと API の構築が含まれており、ベンダーロックインを軽減できます。

このモデルでは、各組織のプラットフォームはカスタム構築されていますが、サポートされている購入可能な既存のツールの上に置かれます。このアプローチにより、組織は構築と購入のジレンマから逃れ、組織のニーズを満たすためにプラットフォームを微調整することに集中できます。

それが標準になるためには何が起こる必要があるのでしょうか？

多くの組織は、役割と責任が膨大に思えるため、DevOps を導入する際に苦労しています。開発者が毎日実稼働環境でスタック内のすべてに責任を負っている場合、ビジネス価値をもたらさない退屈な作業に行き詰まってしまう可能性があります。しかし、従来のアーキテクチャおよび運用チームは開発者の効率を測定しないことが多いため、開発者はチケットを送信して待つことしかできません。

プラットフォームエンジニアリングを成功させるには、組織の全面的なサポートが必要です。内部ユーザーにとってより良いエクスペリエンスを構築するには、サイロを排除する必要があります。プラットフォームエンジニアリングを成功させるには、独自のチームが必要です。これを単に IT の延長として捉えることはできません。

運用上の変更に加えて、プラットフォームエンジニアリングでは、個々の機能に加えて使いやすさやセキュリティなどの非機能要件を優先するために、開発チームの文化的な変化が必要です。プラットフォームは正しいことを簡単にするのに役立つ必要がありますが、責任はリーンプラットフォームチームとそのユーザー (ソフトウェア開発チーム) の間で共有される必要があります。

組織が業務プロセスを全面的に見直すときは常にそうであるが、中途半端に物事を進めるだけでは十分ではない。企業は、組織内のすべての開発者の全面的なサポートと上級チームメンバーの賛同がなければ、プラットフォームエンジニアリングを成功裏に実装することはできません。

なぜ開発者が気にする必要があるのでしょうか?

大規模なソフトウェアエンジニアリング組織は、大規模で複雑なテクノロジスタックを容易に保有できます。これにより、メンテナンスが悪夢のようになり、リリースサイクルが長く遅くなり、ストレスの多い停止が発生する可能性があります。プラットフォームエンジニアリングを採用すると、複雑さと引き換えにスタックがよりスリムになり、重要でない部分や面倒な部分が削除されます。意思決定者は、ツールを廃止したり、不要な環境をシャットダウンしたりすることを恐れてはなりません。開発者が使用しているプラットフォームを信頼したら、このプロセスを自動化することさえ可能です。実際、自動化により廃止作業がプラットフォームのライフサイクルの一部となり、それを既存のプロセスに統合して時間とコストを節約できます。

プラットフォームエンジニアリングのアプローチは、開発者だけでなく、インフラストラクチャおよび運用チームの時間を大幅に節約することもできます。これらのチームは、開発者からの日常的なリクエストのカテゴリ全体を排除できます。プラットフォームチームは、新しい環境の立ち上げ、インフラストラクチャの管理、リポジトリの作成と構成、CI/CD パイプラインの処理などの日常的で反復的なタスクを自動化し、開発サイクルを円滑化し、退屈な作業を削減します。

開発者は、作業をプラットフォームにオフロードすることで時間と労力を節約でき、既存のアプリケーションをプラットフォームに移行する大きな動機となります。これらの利点は、開発者の生産性が向上し、サービスを強化するための追加の請負業者やスタッフの必要性がなくなるため、企業の大幅なコスト削減にもつながります。

未来に向けたプラットフォームエンジニアリング

最終的に、プラットフォームエンジニアリングの目標は、チームや部門に関係なく、開発者がプラットフォームの外で実験するのではなく、プラットフォームを使用することを奨励することです。ツールチェーンとワークフローが完全に実装されたこのセットアップのフレームワーク内で作業する場合、開発者はインフラストラクチャを気にせずにコーディングに集中できます。これにより、日々の仕事量が大幅に軽減され、ただ生き残るだけでなく成長できるようになります。

この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。