三位一体: クラウドネイティブ、DevOps、プラットフォームエンジニアリング

クラウド ネイティブ、DevOps、プラットフォーム エンジニアリングはいずれも非常に複雑な概念であり、その境界は常に拡大しており、重複する部分も多くあります。 3 つの出発点は同じではありませんが、有機的な全体を形成できます。

クラウドネイティブ

Cloud Native Foundation はクラウド ネイティブを次のように定義しています。

クラウド ネイティブ テクノロジーにより、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。

これらの技術により、フォールト トレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブ テクノロジーにより、エンジニアはシステムに頻繁かつ予測可能な重大な変更を加えることが容易になります。

クラウド ネイティブの目的は、「フォールト トレラントで、管理しやすく、監視しやすい疎結合システムを構築する」ことであり、採用されている手法としては、「コンテナ、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API」などがあることがわかります。ただし、これらには前提条件もあり、「パブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの新しい動的環境」に存在する必要があります。

これは定義というよりは、どんな「正しい」アプローチにも当てはまると思われる「万能」なボックスのように思えます。しかし、この定義は実際の状況と一致しません。開発や運用・保守には多くの問題があり、それらを解決する唯一の方法はありません。実際には、あるツールが非常に便利であることに気付き、その背後にあるアイデアが成功の鍵であることが徐々にわかることがあります。このアイデアはその後発掘されて方法論となり、さらに多くのツールが派生します。良い例としては、Kubernetes の宣言型 API とその実装方法 Operator が挙げられます。多くのツールがこのアイデアを借用し、独自のオペレーターを実装して、疎結合された複雑なシステムを形成しています。これらの方法は最終的にクラウドネイティブなアプローチになりました。

「クラウド ネイティブ」は、単にそれを実行する良い方法があることを伝えているだけだということがわかります。ツールプロバイダーはこのアプローチを使用してツールを開発でき、エンドユーザーはクラウドネイティブ ツールを使用する必要があります。しかし、このコンセプトに基づいたツールが多すぎて、どのように選択し、組み合わせるかが大きな問題になっています。そのため、Cloud Native Foundation は次の図を示しています。

写真

これはひどいことです。クラウド ネイティブをうまく行うための重要な問題は、適切なツールを選択する方法です。そのためには、CTO とアーキテクトがクラウド ネイティブ ソリューションに引き続き注意を払い、同僚とのコミュニケーションを増やす必要があります。そのため、当社の公式アカウント「Yunyunzhongshengs」では、引き続き皆様にツールをご紹介しております。

しかし、何かをうまくやるには、技術だけの問題ではありません。多くのクラウド ネイティブ実践者、特に従来のエンタープライズ実践に携わる実践者は、この点について深く理解している必要があります。クラウドネイティブはテクノロジーに重点を置いており、あまりイデオロギー的な要素はありませんが、テクノロジーは知らないうちに人々の協力関係を変えており、これによって引き起こされる問題は他の方法で解決する必要があります。

デブオプス

クラウド ネイティブと比較すると、DevOps にはさまざまな定義があります。 Atlassian の定義を見てみましょう。

DevOps は、ソフトウェア開発チームと IT チーム間のプロセスを自動化および統合する一連のプラクティス、ツール、および文化的哲学です。チームの権限委譲、チーム間のコミュニケーションとコラボレーション、テクノロジーの自動化を重視します。

DevOps 運動は、ソフトウェア開発および IT 運用コミュニティが従来のソフトウェア開発モデルに懸念を抱き始めた 2007 年頃に始まりました。このモデルでは、コードを作成する開発者は、コードを展開してサポートする運用スタッフとは独立して作業します。 DevOps という用語は、「開発」と「運用」という言葉を組み合わせたもので、これらの領域を 1 つの継続的なプロセスに統合するプロセスを反映しています。

手法やツールに重点を置くクラウドネイティブと比較すると、DevOps には「実践、ツール、文化的概念」という 3 つの側面が含まれていることがわかりますが、その優れた価値はその起源にまで遡ることができます。 Atlassian は DevOps の歴史の中で次のように書いています。

アジャイル開発手法の台頭にもかかわらず、開発チームと運用チームは何年もサイロ化されたままでした。 DevOps は、より優れたソフトウェアをより早くリリースするための共同ツールとプラクティスのさらなる開発です。

Martin Fowler の Bliki では、DevOps の起源について次のように説明しています。

アジャイル ソフトウェア開発により、要件分析、テスト、開発間のサイロの一部が解消されました。展開、運用、保守も、ソフトウェア開発プロセスの残りの部分から同様に分離されているアクティビティです。 DevOps 運動は、これらのサイロを排除し、開発と運用の間のコラボレーションを促進することを目的としています。

この記事によると、DevOps が解決する問題は、運用組織と開発組織間のコミュニケーションと調整の問題だけではなく、「アジャイル開発」におけるさまざまな役割のサイロ化の問題でもあるそうです。また、「アジャイル開発」という言葉は、DevOps の前提がアジャイル開発であることをも意味しています。そうでない場合でも、ThoughtWorks の Web サイトに記載されている次の要素を考慮する必要がある場合があります。

また、DevOps はすべての組織にすぐに適するわけではなく、組織は何らかの変更を加える必要がある場合があります。常にコンウェイの法則を念頭に置いてください。これは、組織によって設計されたシステムは、組織自体のコミュニケーション構造を反映するという格言です。つまり、ビジネスクリティカルなアプリケーションの大部分を大規模なモノリシック アプリケーションを使用して実行している場合、DevOps は組織に適していない可能性があります。 DevOps は、作業をチームが所有できる個別のチャンクに分割できる組織に最適です。

すべての組織が DevOps を実装できるわけではないのは事実です。組織内の部門間の壁が高くなるほど、DevOps の実装は難しくなります。

組織によって DevOps の定義はさまざまですが、前述の説明から、DevOps はアジャイル開発の延長であることもわかります。 DevOps を早期に導入する組織は部門間の壁が低く、開発者のビジョンと能力が優れているため、運用と保守における高度なベストプラクティスを迅速に吸収でき、DevOps の実践によってより良い結果を達成できます。

しかし、ほとんどの組織には、そのような熱意のある開発者はおらず、「Dev」担当者が推進する「Ops」はプロフェッショナルではない可能性があります。部門間の壁が高いことも相まって、DevOps を推進することに対する抵抗は非常に大きいです。

従来の企業における DevOps の非互換性に直面して、多くのメーカーも DevOps コンセプトの改良版を立ち上げています。あるいは、DevOps の旗印の下で多くの DevOps 製品が発売されています。これらの製品は、DevOps の「面倒な」部分を回避し、ツールに重点を置いています。彼らは、特に開発チームにおいて、多かれ少なかれ何らかの役割を果たしてきましたが、運用や保守の段階まで能力を拡張できていないことがよくあります。

DevOps ツールとプラクティスの開発を担当する専用の「DevOps チーム」を設立している組織も数多くあります。これは可能ですが、開発チームが自らの業務を管理するという原則から多少逸脱します。

エンタープライズレベルの研究開発の現状に直面して、DevOps の問題を解決するための新しい指導アプローチが必要です。

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

DevOps 運動は 15 年ほど前から行われていますが、ほとんどの企業では、DevOps の完全な実装とそのメリットはまだ実現されていません。この自律的な DevOps チームは、組織の配信レベルを向上させるのではなく、多くのセキュリティ問題を生み出しました。

一方、クラウドネイティブ技術の発展により、「プラットフォーム」を構築することはもはや難しい作業ではなくなりました。プラットフォームを中心とした社会的技術管理の実践、つまりプラットフォーム エンジニアリングが登場しました。

CNCF プラットフォーム エンジニアリングのホワイトペーパー (翻訳) によると:

分散コンピューティングにおけるプラットフォームは、複数の目的に対して共通のサポート機能とサービスを提供するレイヤーです。このプラットフォームは、Web ポータルやページ、シナリオ固有のコード テンプレート、自動化可能な API、コマンド ライン ツールなど、これらの機能やサービスを取得、使用、管理するための一貫したユーザー エクスペリエンスを提供します。

写真を見るともっと分かりやすいかもしれません:

写真

ここで言及されているプラ​​ットフォームは、一般的に内部開発者プラットフォーム (IDP) として認識されています。

このプラットフォームは、プラットフォーム チームとアプリケーション チーム間の新しい分業インターフェイスになります。チーム間のコラボレーションは、次の構造に調整されます。

写真

運用保守チームの専門家は、プラットフォームに機能を統合することを主な責任とする有効化チームになります。プラットフォームには多くの手動の運用および保守タスクが実装されていることが判明しており、関係者はプラットフォームの研究開発チームに参加して、運用および保守作業をプラットフォームに抽象化する責任を負う必要がある場合があります。もちろん、プラットフォームの方向性をコントロールするためにプラットフォーム プロダクト マネージャーも必要になる場合がありますが、これは元の運用マネージャーの役​​割である可能性があります。

このプラットフォームは、Kubernetes を含むインフラストラクチャの複雑さを隠し、ベストプラクティスをカプセル化しているため、R&D チームは、セキュリティ規制に違反したり、ベストプラクティスに従わなかったりすることを心配することなく、ビジネスニーズに応じて独自のインフラストラクチャ環境をより簡単に構築できます。 R&D チームは、プラットフォームが提供するセルフサービスを通じてほとんどのタスクを完了でき、独自のアプリケーションに対して「責任」を持つことができます。これは、DevOps の原則と一致しています。

では、プラットフォーム エンジニアリングの「プラットフォーム」と以前のプラットフォームの違いは何でしょうか?いくつかの側面があると思います。

• プラットフォームのユーザーは異なります。従来のプラットフォームのユーザーは運用保守チームである可能性がありますが、社内開発プラットフォームのユーザーは開発者、つまりアプリケーション チームです。
• 2 つのプラットフォームの構築者は異なります。従来のプラットフォームは、独立した研究開発チームによって開発されることが多く、このチームの最も強力な能力は開発です。このモデルが採用された理由の 1 つは、以前のツールが比較的原始的で、実行には高度な抽象化が必要であり、研究開発に高い要求が課せられていたことです。このモデルの問題点の 1 つは、運用と保守の知識がプラットフォームから分離されていることです。プラットフォームのユーザーとしての彼らの知識は、プラットフォームにうまく統合できません。社内開発プラットフォームは、運用・保守プラットフォームチームの構築に重点を置いています。さまざまな運用および保守の専門家が日常業務をより意識し、運用と保守の専門知識をより適切に組み合わせることができます。
• プラットフォーム構築の考え方が異なります。従来のプラットフォームでは、多くの場合、機能のパッケージ化、つまり、さまざまな以前の運用および保守タスクの簡素化に重点が置かれています。社内開発者プラットフォームは、実際の研究開発プロセスと、開発者が目標を迅速に達成できるように支援することに重点を置いています。

DevOps がアジャイル開発から運用と保守への拡張であるならば、プラットフォーム エンジニアリングは DevOps に対する経営陣の対応です。これまでのITILと同様に、DevOpsのように改革を後戻りさせることなく、組織構造の観点から設計を開始できるようになりました。

トリニティの未来

それでは、なぜそれが三位一体なのかを見てみましょう。

• クラウド ネイティブ テクノロジーは、プラットフォームを構築するための機能を提供します。クラウドネイティブ関連テクノロジーが登場する前は、ほとんどの組織にとって独自のプラットフォームを構築することは非常に困難でしたが、現在ではクラウドネイティブによって多くの組織に同様の機能が提供されています。
• DevOps はコラボレーションのための文化的基盤を提供します。開発と運用の従来の分業では、効率的な製品提供につながらないことが証明される事例が増えています。コミュニケーションとコラボレーションを促進する DevOps 文化は、最新のアプリケーション配信の基礎となっています。プラットフォームがあっても、異なるチームが同様の文化を維持する必要があります。
• プラットフォーム エンジニアリングは、組織レベルでガイドラインを提供します。プラットフォーム エンジニアリングの概念の導入により、同様の考えを持つ多くの人々に共通の用語が提供され、この目標に向けて協力し、業界全体の変化を実現できるようになりました。

前述のように、これら 3 つの概念にはさまざまな解釈がありますが、この記事では、それぞれの重要なポイントを理解し、業界にとっての 3 つの重要性を理解していただければ幸いです。

プラットフォーム エンジニアリングは私たちが望む状態であり、クラウド ネイティブはこの状態を実現するために使用するツールです。この状態を達成するには、私たち参加者一人ひとりが常に DevOps の協調精神を維持する必要があります。これが三位一体です。