[序文]世界初のクラウドネイティブアプリケーション標準の定義とアーキテクチャモデルであるOpen Application Model（OAM）のコアコンセプトは、「アプリケーション中心」です。これは、一連の宣言的で柔軟なR＆Dと運用と保守を重視しています。拡張された上位レベルの抽象化は、複雑であいまいなインフラストラクチャレイヤーAPIを直接使用する代わりに、協調して動作します。最近、AWS ECSチームが公式のGitHubでAmazon ECS for Open Application Modelと呼ばれるオープンソースプロジェクトをリリースし、OAMの実践を模索するメーカーが増えています。複数のクラウドベンダーが団結して受け入れることができるように、OAMの魅力は何ですか？
著者| Zhang Lei、Alibaba Cloud Native Application Platformのシニアテクニカルエキスパート
Deng Hongchao、Alibaba Cloudテクニカルエキスパート
編集長| Tang Xiaoyin
ヘッド図|東ICからCSDNダウンロード
出品 | CSDN（ID：CSDNnews）
サーバーレスという言葉は2012年の記事「ソフトウェアとアプリの未来がサーバーレスである理由」で最初に使用されました。しかし、本当に考古学に行くと、この記事の内容は実際には継続的インテグレーションとコードバージョン管理のソフトウェアエンジニアリングの概念であることがわかります。今日、Serverlessが言及する「ゼロへのスケール」と「支払い」について話しましょう。 FaaS / BaaSのように、これらのことはまったく問題ではありません。
2014年、AWSは「Lambda」という製品をリリースしました。この製品の設計コンセプトは非常にシンプルです。つまり、クラウドコンピューティングは最終的にはアプリケーションにサービスを提供することを目的としているため、ユーザーがアプリケーションをデプロイしたい場合は、独自のプログラムを作成して、特定のタスクを実行するための場所が必要です。このプログラムが実行されるマシンまたは仮想マシン。
「サーバーレス」というパラダイムをまったく新しいレベルに引き上げたのは、ラムダのリリースでした。サーバーレスは、クラウドでアプリケーションをデプロイして実行するためのまったく新しいシステムアーキテクチャを提供します。ユーザーは複雑なサーバー構成を気にする必要はなく、自分のコードと、ホストできるクラウドコンピューティングプラットフォームにコードをパッケージ化する方法だけを気にする必要があることを強調します。運用エンティティ」。AWSは、事前割り当てされたリソースではなく、実際のトラフィックに基づくアプリケーションインスタンスのスケーリングや実際の使用量に基づく課金など、一連の従来の機能を経て、サーバーレスの分野で事実上の標準を徐々に確立してきました。
2017年に、AWSはFargateサービスをリリースしました。これはサーバーレスの概念をコンテナベースの実行可能なエンティティに拡張しました。すぐにこのアイデアは、Google Cloud Runなどにも続き、「次世代」のコンテナベースのサーバーレスランタイムが始まりました。ブーム。
サーバーレス与Open Application Model（OAM）？
では、OAMはAWSとサーバーレスと何をしているのでしょうか？
まず、Open Application Model（OAM）は、Alibaba CloudとMicrosoftが共同で開始し、クラウドネイティブコミュニティが共同で管理する一連のアプリケーション記述仕様（spec）です。OAMのコアコンセプトは次のとおりです。「アプリケーション中心」。R＆Dと運用および保守は、複雑であいまいなインフラストラクチャレイヤーAPIを直接使用するのではなく、宣言的で柔軟で拡張可能な上位レベルの抽象化のセットの周りで連携することを強調します。
たとえば、水平拡張にK8s HPAを使用するコンテナベースのアプリケーションの場合、それはOAM仕様の下で次の2つのYAMLファイルによって定義されます。
# 研发负责编写这个 YAML 文件
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: web-server
spec:
# 待部署的应用详情
workload:
apiVersion: core.oam.dev/v1alpha2
kind: Server
spec:
containers:
- name: frontend
image: frontend:latest
---
# 运维（或者 PaaS 平台）负责编写这个 YAML 文件
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: helloworld
spec:
components:
- name: frontend
# 该应用运行所需的运维能力
traits:
- trait:
apiVersion: autoscaling.k8s.io/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: scale-hello
spec:
minReplicas: 1
maxReplicas: 10このようなYAMLファイルがK8sに送信されると、OAMプラグインによって完全なDeploymentおよびHPAオブジェクトに自動的に変換されて実行されます。OAM仕様では、R＆Dと運用および保守の焦点が完全に分離されていることがわかります。R＆Dは、自分に関連する非常に少数のフィールドを書き込むだけでよく、K8の完全なAPIを学習する必要はありません。アプリケーションの定義とリリース。
OAMは、「アプリケーション」、「運用および保守機能」、「リリース境界」などの一連のクラウドネイティブなアプリケーション配信定義標準を規制しているため、アプリケーション管理プラットフォームの開発者は、この仕様を使用してそれぞれを説明できます。さまざまなアプリケーションと操作および保守戦略、そして最後にOAMプラグインを介して、これらのYAMLファイルをK8の実際のリソース（CRDを含む）にマップします。
言い換えると、OAMは「上位抽象化」を定義するための事実上の標準を提供し、この「上位抽象化」の最も重要な役割は、さまざまなインフラストラクチャの詳細（HPA、入力、コンテナー、ポッド、サービスなど）を防ぐことです。など）R＆Dクラスメートに漏れ、不要な複雑さを引き起こしました。したがって、OAMがリリースされると、K8sアプリケーションプラットフォームを開発するための「武器」と呼ばれます。
しかし、より重要なのは、アプリケーションの説明から「インフラストラクチャレイヤーの詳細を取り除き、開発者に最も親しみやすい上位レベルの抽象化を提供する」というこの考え方は、「インフラストラクチャ解除」のサーバーレスの概念と一致することです。より正確には、OAMは本質的にサーバーレスです。
このため、OAMがリリースされると、サーバーレスの分野で大きな注目を集めました。もちろん、AWSも欠かせません。
究極のエクスペリエンス：AWS ECS for OAM
2020年3月の終わりに、AWS ECSチームは公式のGitHubでAmazon ECS for Open Application Modelと呼ばれるオープンソースプロジェクトをリリースしました。
プロジェクトアドレス：https://github.com/awslabs/amazon-ecs-for-open-application-model
このプロジェクトは、AWSチームがサーバーレスサービスに基づいてOAMをサポートする試みです。このプロジェクトの基盤となるランタイムは、前述のサーバーレスコンテナーサービス、Fargateです。そして、このAWS ECS for OAMプロジェクトが開発者にもたらす経験は非常に興味深いものです。
準備作業には3つのステップがあります。
ユーザーは、AWSアカウントの認証情報をローカルに持っている必要があります。これは、AWS公式クライアントのaws configureコマンドを使用してワンクリックで生成できます。
プロジェクトをコンパイルすると、oam-ecsという実行可能ファイルを取得できます。
oam-ecs envコマンドを実行して、その後の展開のために環境を準備する必要があります。このコマンドが終了すると、AWSはVPCと対応するパブリック/プライベートサブネットを自動的に作成します。
準備が完了したら、OAMアプリケーションのYAMLファイルをローカルで定義するだけです（上記のhelloworldアプリケーションの例など）。次に、次の1行のコマンドを使用して、HPAを含む完全なアプリケーションをFargateに配置できます。これはインターネット上に展開され、パブリックネットワーク上で直接アクセスできます。
oam-ecs app deploy -f helloworld-app.yamlとても簡単ですか？
AWS ECS for OAMプロジェクトの公式ドキュメントでは、より複雑な例が示されています。説明しましょう。
今回デプロイするアプリケーションは、3つのYAMLファイルで構成されています。これらのファイルは、R＆Dと運用と保守の2つの問題に分かれています。
R＆Dは執筆に責任があります：
server-component.yaml
このファイルのコンテンツはアプリケーションの最初のコンポーネントであり、デプロイするアプリケーションコンテナーを記述しています。
worker-component.yaml
このファイルのコンテンツアプリケーションの2番目のコンポーネントは、現在の環境のネットワークに障害がないかどうかを確認するループジョブについて具体的に説明しています。
運用と保守は、書き込みを担当します。
example-app.yaml
このファイルの内容は、完全なアプリケーションコンポーネントトポロジと、各コンポーネントの運用と保守の特性です。具体的には、ワーカーコンポーネントを拡張するために使用される「手動スケーラー」の運用と保守の戦略について説明しています。
したがって、完全なアプリケーション記述である上記のexample-app.yamlは次のとおりです。
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: example-app
spec:
components:
- componentName: worker-v1
instanceName: example-worker
traits:
- name: manual-scaler
properties:
replicaCount: 2
- componentName: server-v1
instanceName: example-server
parameterValues:
- name: WorldValue
value: Everyoneご覧のとおり、2つのコンポーネント（worker-v1とserver-v1）を定義しています。worker-v1コンポーネントには、manual-scalerと呼ばれる手動の拡張戦略があります。
このデモの3つのYAMLファイルはすべて、このディレクトリで表示できます。
https://github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples
ただし、上記の複雑なアプリケーションのデプロイメントは、非常に単純なコマンドです。
oam-ecs app deploy \
-f examples/example-app.yaml \
-f examples/worker-component.yaml \
-f examples/server-component.yaml上記の手順を実行した後（中国の学生は特別なネットワークの問題のために少し忍耐が必要になる場合があります）、oam-ecs app showコマンドを使用してアプリケーションアクセス情報とDNS名を表示できます。ブラウザを開いてアクセス情報を入力すると、以下に示すように、アプリケーションに直接アクセスできます。
イメージの更新やreplicaCountの値の変更など、アプリケーション構成を変更する場合は、上記のYAMLファイルを変更してから再度デプロイするだけで済みます。これは完全に宣言型の管理です。
実際、上記の操作がAWSコンソールを介して行われる場合、さまざまな構成のために少なくとも5つのクラウド製品ページを互いにジャンプする必要があります。または、CloudFormation構文を学び、非常に長いCFを記述する必要があります。ファイル。アプリケーションがFargateインスタンス、LoadBalancer、ネットワーク、DNS構成などを実行するために必要なすべてのリソースを取得します。
ただし、OAM仕様により、上記のアプリケーションプロセスの定義と展開は非常に単純になっただけでなく、クラウドサービスオペレーションの元のプロセスをより簡潔でわかりやすい宣言型YAMLファイルに直接変換しました。ここでOAM仕様を実装するために必要な具体的な作業は、実際には数百行のコードだけです。
さらに重要なことは、AWS FargateのようなサーバーレスサービスをOAMのような開発者に優しいアプリケーション定義と組み合わせると、あなたは本当に感じるでしょう：このシンプルでさわやかで非常に低い精神的負担はサーバーレスであることがわかります開発者にとっての究極の体験。
最後に：アプリケーションモデルがサーバーレスと出会うとき
OAMモデルは、クラウドネイティブアプリケーション配信エコシステムに大きな影響を与えました。現在、Alibaba CloudのEDASサービスは、OAM上に構築された業界初の本番レベルのアプリケーション管理プラットフォームになり、すぐに次世代の「アプリケーション中心」の製品体験を開始します; CNCFコミュニティでは、配信プラットフォームのCrossplaneプロジェクトは、OAM仕様の重要な採用者および保守者にもなっています。
EDAS公式ウェブサイト：https://help.aliyun.com/product/29500.html
クロスプレーン：https：//github.com/crossplane/crossplane
実際、AWS Fargateだけでなく、クラウドコンピューティングエコシステムのすべてのサーバーレスサービスは、OAMを開発者向けのプレゼンテーションレイヤーおよびアプリケーション定義として簡単に使用できるため、元の複雑なインフラストラクチャAPIを簡素化および抽象化し、元の複雑なプロセス操作の「ワンクリック」アップグレードで、Kubernetesスタイルの宣言型アプリケーション管理になりました。
さらに重要なことに、OAMの高いスケーラビリティのおかげで、Fargateにコンテナーアプリケーションをデプロイできるだけでなく、OAMを使用して、関数、仮想マシン、WebAssembly、さらには考えられるあらゆるタイプのワークロードを記述することもできます。これらはサーバーレスサービスに簡単にデプロイでき、異なるクラウドサービス間でシームレスに移行することもできます。これらの「魔法」のように見える能力はすべて、標準化された拡張可能な「アプリケーションモデル」がサーバーレスプラットフォームに出会うときに衝突する可能性のあるイノベーションスパークです。
アプリケーションモデル+サーバーレスは、クラウドネイティブエコロジーで最もホットなトピックの1つになりつつあります。CNCFクラウドネイティブアプリケーションデリバリーグループ（SIGアプリデリバリー）に参加して、クラウドコンピューティングエコシステムを「アプリケーション中心」に促進することができます。前進し続けなさい！
OAMプロジェクトのAWS ECS：https://github.com/awslabs/amazon-ecs-for-open-application-model/
アプリケーションモデルプロジェクトを開く：https://github.com/oam-dev/spec
CNCF SIGアプリ配信：https：//github.com/cncf/sig-app-delivery
著者について：
Zhang Lei、アリババクラウドネイティブアプリケーションプラットフォームのシニアテクニカルエキスパート、CNCF China Ambassador、CNCF Application Delivery Sigの会長。
Alibaba Cloudの技術エキスパートであり、Kubernetesオペレーターメカニズムの最初の作成者の1人であるDeng Hongchaoは、K8sアプリケーション管理システムについてより多くの研究と経験を持っています。
【終わり】
今日のメリット
ルーチーに会う
また、「100万人がAIを学ぶ」の重要な部分として、2020 AIProConデベロッパー1万会議が7月3日から4日までオンラインでライブ放送され、開発者はAIの最先端テクノロジーについてワンストップで学ぶことができます研究、コアテクノロジーとアプリケーション、およびエンタープライズケースの実務経験。また、オンラインでエキサイティングで多様な開発サロンやプログラミングプロジェクトに参加することもできます。将来を見据えた一連のアクティビティとオンラインライブブロードキャストの相互作用に参加すると、何万人もの開発者と通信できるだけでなく、ライブブロードキャストの限定ギフトを獲得したり、テクノロジーの巨人に参加したりすることもできます。
チケットはビッグショー限定です！本日から、クリックして元の登録「2020 AI開発者1万会議」を読み、クーポンコード「AIP211」を使用して、299元相当の無料オンライン会議チケットを入手できます。100枚限定、先着順！是非、指を使って無料でメンバーシップを取得してください！
クリックして元のテキストを読み、会議の公式Webサイトに直接アクセスします。
