インフラストラクチャ チームは、標準化と自動化の大幅な増加から大きな恩恵を受け、作業指示が不要になります。
著者 Luca Galante のThis Is Why Infra Teams Should Care About Platform Engineeringから翻訳。
特に企業のインフラストラクチャ チームはますますプレッシャーにさらされており、多くのエンジニアリング組織が運用崩壊の瀬戸際に陥っています。これらのインフラストラクチャ チームのほとんどは数年前にモダナイゼーションとクラウド移行の取り組みを任されていましたが、それらの取り組みは頓挫することが多かったです。
現在、開発者のセルフサービスを可能にするクラウド プロバイダー コンソールと競合しながら、オンプレミスとクラウドの両方のセットアップを管理する必要があります。もちろん、このようなコンソールでは開発者のセルフサービスは不可能であり、インフラストラクチャ チームは、増え続ける開発者のリクエストとチケットに対処する必要があります。
開発者は、ますます複雑化するクラウドネイティブ ツールチェーンを処理する際の長い待ち時間と高い認知負荷について不満を抱いています。市場投入までの時間が長くなっており、経営陣はインフラストラクチャチームがボトルネックになっていることが原因だとしている。
これはほとんどの人にとってあまりにも馴染み深いものに聞こえるかもしれません。しかし、ここに興味深い点があります。過去数年にわたり、プラットフォーム エンジニアリングはこれらの問題の多くを解決し、単にインフラストラクチャの上に UI 層を追加するのではなく、真の開発者の大規模なセルフサービスを可能にし、同時に潜在的な圧力を緩和すると約束してきました。施設チーム。しかし、私が話を聞いた多くのインフラストラクチャ チームは、プラットフォーム エンジニアリングが問題の解決策であるとは考えていないようです。なぜ？
なぜなら、彼らはそれを開発者エクスペリエンス (DevEx) とすぐに結びつけるからですが、実際にはそれが彼らの興味ではないからです。結局のところ、インフラストラクチャ チームとしてインフラストラクチャとサービスの提供について心配する必要があるのに、なぜ気にする必要があるのでしょうか?
開発者に社内開発者プラットフォーム (IDP)を提供することで、待ち時間をなくし、チケット アクションの波を防ぐことができるからです。実際には、同じ Postgres DB の N 番目のインスタンスを起動する代わりに、新しいリソースやインフラストラクチャの追加 (そして、正直に言うと、もっと楽しいこと) などの重要なことに集中できます。管理者の目から見ると、あなたは問題の一部 (ボトルネックである) から解決策の一部へと移行するため、注意する必要があります。
インフラストラクチャ + プラットフォーム エンジニアリング = インフラストラクチャ プラットフォーム エンジニアリング
プラットフォーム エンジニアリングとは、企業組織内で流通しているすべてのテクノロジーとツールをまとめてゴールデン パスにバンドルし、開発者のセルフサービスを可能にし、個々の貢献者の認知的負荷を軽減することです。 Gartner は、インフラストラクチャ プラットフォーム エンジニアリングを「IT インフラストラクチャをユーザーや他のプラットフォームに利用しやすい方法で公開する社内ソフトウェア製品 (IDP) を構築する分野」と定義しています。
したがって、プラットフォーム エンジニアリング プログラムを成功させるには、プラットフォーム チームと既存のインフラストラクチャ チームの間に明確なコミュニケーション ラインを確立することが重要です。プラットフォーム エンジニアリングは単なる DevEx ではなく、インフラストラクチャ側もアプリケーション側や開発者インターフェイスと同じくらい重要です。インフラストラクチャ プラットフォーム エンジニアは、プラットフォーム チームで重要な役割を果たします。
プラットフォーム エンジニアリング チームには、クラウド プロバイダー、インフラストラクチャ チーム、またはその両方からのリソースに関係なく、開発者が使用したいリソースに関係なく、開発者向けに統一されたエクスペリエンスを作成する大きな機会がここにあります。エンタープライズ グレードの IDP では、そのようなリソースの消費が自然に標準化されるため、効率が向上し、セキュリティが向上し、内部または外部のプロバイダーへのコンプライアンスが強化されます。
これは開発者だけでなく、インフラストラクチャ チームにとっても大きな可能性をもたらします。 Platform Orchestrator で構築された IDP は、インフラストラクチャ チームとしての生活をより楽しくするレベルの標準化と自動化を導入します。
たとえば、Postgres を Vx から Vx+1 にアップグレードする必要があり、これをアプリケーション開発チーム全体で行う必要があるとします。 IDP がなければ、各チームに行き、どのインスタンスで実行されているかを調べて、すべてをマッピングする必要があります。その後、戻ってアップグレードする必要があります。通常は個別のチームで、各インスタンスに固有の作業を行います。
適切に構築された IDP (バックエンドとして Platform Orchestrator ) を使用すると、ファイル (リソース定義) を更新するだけで、次回チームがワークロードをデプロイするときに、新しいリソース バージョンが自動的に使用されます。
これは、チケットアクションから完全に離れながら、すべてのチームとワークフローにわたって設計によって標準化されているため、最高の仕事を行うことができます。
結論は
プラットフォーム エンジニアリングとプラットフォーム オーケストレーターは、エンジニアリング組織に、運用方法と開発者がインフラストラクチャと対話する方法を改善する独自の機会を提供し、その結果、効率が向上し、市場投入までの時間 (TTM) が短縮されます。
ただし、プラットフォーム エンジニアリングの取り組みは、既存のインフラストラクチャ チームとの緊密な連携なしには大きく前進することはできません。これにより、既存のインフラストラクチャ チームは、標準化と自動化の推進から大きな恩恵を受け、チケット操作の必要性を排除できます。
インフラストラクチャ プラットフォーム エンジニアは、IDP の展開と広範な組織パフォーマンスにおいてますます重要な役割を果たすようになるでしょう。さらに詳しく知りたい場合は、
1990 年代生まれのプログラマーがビデオ移植ソフトウェアを開発し、1 年足らずで 700 万以上の利益を上げました。結末は非常に懲罰的でした。 高校生が成人式にオープンソースプログラミング言語を自作―ネチズンの鋭いコメント： 詐欺横行でRustDesk依存、国内サービスの タオバオ（taobao.com）は国内サービスを一時停止、ウェブ版の最適化作業を再開 Java最も一般的に使用されている Java LTS バージョンは 17 、Windows 11 は減少し続ける Open Source Daily | Google がオープンソースの Rabbit R1 を支持、Microsoft の不安と野心; Electricがオープンプラットフォームを閉鎖 AppleがM4チップをリリース GoogleがAndroidユニバーサルカーネル(ACK)を削除 RISC-Vアーキテクチャのサポート Yunfengがアリババを辞任し、将来的にはWindowsプラットフォーム用の独立したゲームを制作する予定この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。