著者：OAMプロジェクトリーダー
REVIEW：2019年10月17日、アリババのパートナーは、アリクラウドインテリジェントな基礎製品事業部ゼネラルマネージャー江Jiangwei（愛称：シャオ謝が）重いがのQCon上海で発表された、アリの雲とマイクロソフトが共同でオープンなアプリケーションモデルを開きアプリケーションモデルを発売しました（OAM）のオープンソースプロジェクト。ネイティブアプリケーションの管理と配信をクラウドにアプリケーション開発者、運用、保守担当者、アプリケーションインフラストラクチャを伝えると接続するための標準化された方法でのOAMのビジョンは、より簡単、効率的、かつ制御可能となっています。
なぜOAMの懸念？
- 懸念の分離：開発者は、アプリケーション自体に焦点を当て、運用、保守要員がモジュラー運用および保守機能を懸念し、より簡単にアプリケーション管理が可能で、アプリケーションの配信は、より制御可能になります。
- プラットフォームに依存しないと非常にスケーラブル：アプリケーションとプラットフォーム層は、定義を分離、説明が拡大し、クロスを達成するために、任意のアプリケーション環境をサポート
- 操作とモジュラーアプリケーションのメンテナンスが備わっています：あなたが自由に機能や運用・保守支援モジュラー実装の記述を組み合わせることができます
コンテナの配置の分野でデファクトスタンダードとしてKubernetesプロジェクトは、成功した、このようなアリクラウドKubernetes（ACK）および他のネイティブのクラウドサービスとして急速な成長を促進しました。しかし、我々はまた、サービス、展開など、実際には、コアAPIアプリケーションリソースのちょうど別の部分Kubernetesとして、懸念している、そしてアプリケーションのすべてを表現することはできません。多分、我々はヘルムチャートような方法で展開することができるアプリケーションを介して表現しようとすることができますが、一度実際に実行中のアプリケーションを配備するが、それでもアプリケーション中心のモデルの制約を欠いています。これらの問題は、アプリケーションのAPIに、Kubernetesとネイティブのクラウド技術スタックを反映しているAPIのリソースは、アプリケーション自体の完全な実行を表すことができ、アプリケーション管理に焦点を提供するために、リソースセンターを必要とし、標準、非常に一貫性のあるモデルで、だけでなく、今日のアリの雲であるテンプレートやアプリケーションのいくつかのコンポーネントを使用してMicrosoftは共同での発売を発表しましたオープンなアプリケーション・モデルのオープンアプリケーションモデル（OAM）の理由のために。
プロジェクト住所：https://openappmodel.io
OAMの仕様と実装プロジェクトは、現在、2つの部分から構成され
オープンアプリケーションモデルとは何ですか？
OAMは、基準の適用の説明に焦点を当てています。本明細書で、アプリケーション記述は、アプリケーションを展開および管理するためのインフラストラクチャの詳細から完全に分離することができます。この関心事の分離（Conernsの別離）設計上の利点は非常に明白です。Kubernetesが異なるクラスタに変わるように、例えば、実際の生産環境では、それは入力、CNI、またはサービスメッシュであるか、これらの一見一貫した操作および保守概念を説明することができます。運用・保守機能とアプリケーション定義のクラスタを分離することにより、我々は、アプリケーション開発者は、むしろ、そのような細部の運用・保守「でどのようなアプリケーションの展開」より、ポイント自体の価値に集中できるようにすることができます。また、懸念プラットフォームアーキテクトの分離が容易に迅速かつ容易にアプリケーション開発者は、これらのコンポーネントの操作およびメンテナンスに集中することができ、プラットフォームコンポーネントの動作および保守機能は再利用可能なように包装することができる作り、コードを統合することができ信頼性の高いアプリケーションを構築します。オープンアプリケーションモデルの目標は、簡単なアプリケーションの管理を容易にするために、複雑なアプリケーションの配信がより制御可能になりようにすることです。
まず、アプリケーションアセンブリ（コンポーネント）
OAMにおいて、「アプリケーション」とは、一般的な概念の複数の組み合わせです。最初のコンセプトは：アプリケーション全体の重要な部分であるアプリケーションコンポーネント（コンポーネント）。したがって、アプリケーションコンポーネントは、両方のアプリケーションの実行を含むことができるサービスに依存：例えばMySQLデータベースとして、ならびにアプリケーションサービス自体：例えば、PHPサーバの複数のコピーを持っています。開発者は、単一のアプリケーションコンポーネントに「パッケージ化」におけるそれらのコードを記述し、そして次いで成分と他のサービスとの間の関係を記述するためにコンフィギュレーションファイルを書き込むことができます。プラットフォームのアプリケーションアーキテクトは多重化することができる一つのモジュールに分解するように、コンセプトのアプリケーションコンポーネントは、そのようなモジュール式のアプリケーションでは、パッケージの一部は、セキュアで拡張性の高いアプリケーションを構築するベストプラクティスを表し思いました：それは、説明および実装を達成するために、アプリケーション・コンポーネントを分離、完全分散型アーキテクチャモデルを介してです。
第二に、アプリケーション・デプロイメント構成ファイル（アプリケーションの設定）
実際のアプリケーション稼働してなり、これらのアプリケーション・コンポーネントを記述するためには、運用、保守担当者は、専用介して適用されますが、それはすべてのアプリケーションコンポーネントが実行されるアプリケーションのインスタンスを作成するプロファイル情報を展開含まれています。OAM構成ファイル自体は、開発者またはプラットフォームによって提出されたアプリケーションに応じてアプリケーション動作および保守要員を説明することができる可能に稼働して、対応する実際のアプリケーションをインスタンス化するために、APIの宣言的仕様です。
第三に、アプリケーションの操作およびメンテナンス特性（形質）
最後に、コンセプトは、アプリケーションの操作やメンテナンス性など水平展開戦略と進入ルールの適用など、特定のデプロイメント環境内のディメンションの輸送用途の特性を記述（形質）、のセットがあり、これらの特性は、アプリケーションの運用・保守のために非常に重要であり、しかし、彼らは実際にはさまざまな展開環境で異なる実装を持っている傾向があります。簡単な例として、入口同じ、完全に異なっていてもよく、ローカルパブリック・クラウド・データ・センター内に実装されている。前者は、専用ハードウェアであってもよい、一般に、SLBのクラウドサービスです。これは、これら2つの環境の進入操作や保守作業のために、大きな違いがあることを意味します。同時に、どのような環境では関係なく、アプリケーション開発者のための、この進入ルール、それは正確に同じであってもよいです。アプリケーションの設計機能、可能性の懸念のように、この分離：限り、アプリケーション環境の両方がOAMイングレスモデルでは、この機能の運用および保守の実装を提供して、そのアプリケーションが非差別的ルールの進入の統一された記述を使用することができますアップと両方の場所で実行されています。同時に、2つの環境インフラ・プロバイダは、個々の操作やメンテナンス要件（例えばを満たすために、これらのアプリケーションの機能を設定し続けることができます：異なる環境のイングレスは、会議のコンプライアンスとセキュリティで達成します違い）
OAM：プラットフォームに依存しない、非常にスケーラブルなアプリケーション機能の説明
PaaSのアプリケーションモデルと比較すると、OAMは、多くのユニークな特徴を持っている、最も重要なことは、次のとおりです。プラットフォームに依存しません。我々はOAMリリース（rudr）Kubernetes基づいていますが、オープンアプリケーションモデルとKubernetesを実現しますが、強く結合されていません。確かに、OAMはもちろんの事の場面を計算するエッジを含む任意のプラットフォームまたはオペレーティング環境上で実現することができます。また、Kubernetesは、多くの操作環境で最良の選択肢ではないかもしれない同意する、またはユーザーなどサーバレスなインフラストラクチャの動作環境の複雑さを心配する必要はありません。これらのシナリオでは、OAMは、まったく同じアプリケーション管理の経験を提供することができます。
第二の重要な特徴は、自然なデザインの仕様（OAM仕様）がスケーラブルで、OAMです。OAMなどのPaaSは、（上記Kubernetes「キャップ帽子」、例えば）下層のプラットフォーム専用アプリケーション管理環境のいくつかの特徴によってマスクされない、閉鎖系を形成しません。代わりに、OAMプラットフォーム層特性との違いは、アプリケーション機能プラットフォームシステム（形質システム）によって具現化することができるようになっています。換言すれば、限り、異なるプラットフォームがアプリケーション（形質）を提供するために必要な特定の機能を使用することができるように、開発者が容易にクロスプラットフォームアプリケーションを開発することができます。システム・プラットフォームの特徴を適用することによって具現化することができる。同様に、も、最も基本となるハードウェアプロバイダ、。OAM全体的なデザインは、「最小公分母」は、多くの場合、ロック・プラットフォームの移植性の問題が発生しないようにすることです。代わりに、OAM機能は移植性を提供するだけでなく、それはまた、各プラットフォームは、独自の特性と用途を明らかにする能力を持っていることを保証します。OAMは、開発者が、異なるプラットフォームのための移植性と差別化機能のバランスを取るために自由に標準的な方法することができます。
オープンコミュニティと今後
さて、アプリケーションモデルを開き、対応するKubernetesは、初期の結果を達成している、我々は非常に興奮しています。OAMの仕様は、開発のためのオープンウェブ財団協定に基づいています。最初から私たちの目標は、オープンなアプリケーションモデルを開きアプリケーションモデルプロジェクトがオープンガバナンスと広範な協力を達成するために、中立財団なったようにすることです。：あなたはより多くの情報をご希望の場合は、開いているアプリケーションのモデルプロジェクトGitHubのリポジトリに行くOAM仕様、および標準ベースOAM Kubernetesの達成 Rudr。
今日はちょうど小さなステップOAMプロジェクトを発表しました。私たちはあなたのフィードバックを楽しみに、そしてKubernetesのための任意のクラウド環境と使用される単純な、ポータブル、再利用可能なアプリケーションモデルを作成することと密接に協力すること。
：元の直接OAMのホーム読むにはこちらをクリックしてhttps://openappmodel.ioを
「アリババクラウドネイティブマイクロチャネルパブリック番号（ID：Alicloudnative）フォーカスマイクロサービスで、サーバレス、コンテナ、サービスメッシュ及び他の技術分野、クラウドネイティブで人気の技術動向を中心に、クラウドネイティブの大規模な着陸の練習は、ほとんどがクラウドネイティブ開発を理解してください技術公衆番号。」