クラウドネイティブが盛り上がっているので、概要と、関連団体と、サービスメッシュと、サーバーレスと、ハイブリッド/マルチクラウドについて調べてみた

この記事は [ラクス Advent Calendar 2019](https://qiita.com/advent-calendar/2019/rakus) の18日目の記事です！

先日は @Y-Kanoh さんのAIBOの記事でした！
AIBOもいろんなAPIが公開されているのを初めて知りました！
（高額なのに購入されてて、すごいです…。） 

# はじめに
はじめまして！
株式会社ラクスパートナーズのさとうと申します。

Qiitaはいつも読者側で投稿したことがなかったので、今回が初投稿です。

社内の肩書はクラウドエンジニアで、普段はAWS上でのインフラ管理・構築・検証を主に行っています。

最近クラウド界隈ではクラウドネイティブ技術が盛り上がっており、私も多分に漏れず今年は情報収集に明け暮れました。
クラウドネイティブ技術やその周辺情報については様々なメディアで取り上げられており、Qiitaにも多くの投稿がありますが、
今回は自身の今年1年のまとめとして、「クラウドネイティブの概要」「関連団体」「サービスメッシュ」「サーバーレス」「ハイブリッド/マルチクラウド」についてまとめてみました！

# クラウドネイティブ概要

最初に、クラウドネイティブの定義や技術の変遷についてざっくりまとめてみたいと思います。

## 定義
クラウドネイティブ技術のプロジェクトを多数ホストしている団体、[Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/)が定義している内容が、同団体の[Githubリポジトリ](https://github.com/cncf/toc/blob/master/DEFINITION.md)に公開されています。
> クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
>これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

また、atmarkITの記事で、青山真也さんと草間一人さんの対談でも分かりやすくまとめられています。
[草間一人×青山真也 クラウドネイティブ対談](https://www.atmarkit.co.jp/ait/series/16443/)

## 変遷
いろいろな情報を参考にしたのですが、ソースを忘れてしまいました・・・。
ざっくりとした個人的なまとめとしては、

1. 情報技術の発達とともに、サービス・アプリケーションが複雑/肥大化してきたり、ビジネス展開・開発と運用の迅速化が必要になってきて、今までのやり方（オンプレミスでの管理、モノリシックアーキテクチャ、仮想マシン上でのアプリケーション展開、人の介在する割合が多い運用など）ではキツくなってきた
2. そのため、アプリケーションをマイクロサービスアーキテクチャにしてアプリケーション1つ1つの容量を小さくしたり、迅速性と再現性が高くマイクロサービスと相性が良いコンテナ技術を採用した。また拡張性・柔軟性があり、インフラ管理が少ないパブリッククラウドサービスを利用するようになってきた
3. そしたらコンテナが多すぎて管理がキツくなってきたので、コンテナオーケストレーションで管理を自動化しつつ、宣言的なAPIやインフラコード化を実現した
4. そしたらネットワークが複雑になりすぎたのでサービスメッシュができた
5. また、インフラ管理をほとんど意識しないサーバーレス技術もできた
6. んで、こういった技術を総称して、クラウドネイティブ技術って呼ぼうぜ！！！

みたいな感じでしょうか？
すっごい見辛いまとめで申し訳ありません・・・。
2～3あたりは並行で進んできた部分もあると思うので、完全に順番分けはできないかもしれません。
また、間違っている部分も大いにあると思うので、ご指摘あればよろしくお願い致します！



# 関連団体
次に、クラウドネイティブ技術に関わる団体についてまとめたいと思います。
団体と一口に言うと範囲が広すぎますので、今回は上述のCNCFおよび、そのCNCFをホストしている[The Linux Foundation (LF)](https://www.linuxfoundation.jp/)にフォーカスを当てたいと思います。

## The Linux Foundation (LF)
![lf](https://www.linuxfoundation.org/wp-content/uploads/2018/08/logo_lf-300x184.png)
画像出典：https://www.linuxfoundation.jp/

LFは、Linuxを始めとした、多数のオープンソースプロジェクトをホストしている非営利団体です。
本当に多数のプロジェクトをホストしていますが、例えば以下のようなプロジェクトがあります。

 - いわずもがなの[Linux](https://www.linuxfoundation.jp/projects/linux/)
 - 自動運転やコネクテッドカーの技術を開発している[Automotive Grade Linux](https://www.automotivelinux.org/)
 - Jenkinsなどの継続的デリバリーツールのプロジェクトをホストしている[Continuous Delivery Foundation (CDF) ](https://cd.foundation/)
 - AI、機械学習のプロジェクトをホストする[The LF AI Foundation](https://lfai.foundation/)
 - フロントエンドのデータクエリ言語GraphQL関連のプロジェクトをホストする[The GraphQL Foundation](https://foundation.graphql.org/)
 - ブロックチェーン関連のプロジェクトをホストする[Hyperledger](https://www.hyperledger.org/)
 - JavaScript関連のプロジェクトをホストする[The OpenJS Foundation](https://openjsf.org/)（2019年3月にJS FoundationとNode.js Foundationが統合されて誕生）
 - エッジコンピューティングのプロジェクトをホストする[LF Edge](https://www.lfedge.org/)
 - オープンソースのCPU命令セットであるRISC-Vの仕様策定や、エコシステム開発を行っている[RISC-V Foundation](https://riscv.org/)

現在のIT業界で話題になっている技術のほとんどが網羅されている印象です。
ホストしているプロジェクトの推定開発コストは**16B USD(約1.7兆円)** 、関連イベントに参加するエンジニアは**年間35,000人**とのことです。ヤバいですね。
そしてCNCFも、このLF傘下のプロジェクトのひとつです。


## Cloud Native Computing Foundation (CNCF)
![cncf](https://media.licdn.com/dms/image/C4D0BAQFCywAAEfoSzQ/company-logo_200_200/0?e=2159024400&v=beta&t=J5d9R2y3bkIJ3aiQLoIJYpKKWpUxTLZ5A2cCuizaq5s)
画像出典：https://jp.linkedin.com/company/cloud-native-computing-foundation

CNCFは、上述の通り、オープンソースのクラウドネイティブ技術のプロジェクトをホストするLF傘下の団体です。

### 組織体制
Github上に[憲章](https://github.com/cncf/foundation/blob/master/charter.md)がまとめられており、以下のようなことが記載されています。

> 1．使命　
財団の使命は、クラウドネイティブコンピューティングをユビキタスにすることです。
Cloud Native Computing Foundationは、オープンソースのベンダー中立プロジェクトのエコシステムを促進および維持することにより、このパラダイムの採用を促進しようとしています。最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。

> 5．理事会　(Governing Board)
CNCF理事会は、CNCFのマーケティングおよびその他のビジネスの監督と予算決定を担当します。

> 6．技術監視委員会　(Technical Oversight Committee (“TOC”))
TOCは、CNCFの技術ビジョンを定義および維持します。理事会が設定したCNCFの範囲内で新しいプロジェクトを承認し、プロジェクトの概念アーキテクチャを作成します。プロジェクトの調整、プロジェクトの削除またはアーカイブを実施します。

TOCは、毎月第1火曜日の午前8時に会議を行い、毎月第3火曜日にプロジェクトのプレゼンテーションを行っているようです。（ https://github.com/cncf/toc ）
ここにはまとめきれませんが、とてもしっかりとした組織体制で運営されているようです。
非営利団体の組織運営というものを知りませんでしたが、ここまでしっかりとやっていてすげぇなーと思いました。（小並感）

### プロジェクト
現在ホストしているプロジェクトは多数ありますが（[プロジェクト一覧](https://www.cncf.io/projects/)）、2019年11月現在Graduatedレベルとなったプロジェクトには、下記があります。
（プロジェクトのレベルについては後述します。）

 - [Kubernetes](http://kubernetes.io/)：Googleで開発された、コンテナーオーケストレーションツール
 - [Prometheus](https://prometheus.io/)：SoundCloudで開発された、システムモニタリングツール
 - [Envoy](https://www.envoyproxy.io/)：Lyftで開発された、レイヤー7プロキシツール
 - [CoreDNS](https://coredns.io/)：Kubernetesクラスタ内でPodの名前解決やサービスディスカバリに利用される、軽量かつ高速なDNSサーバー
 - [containerd](https://containerd.io/)：Docker®の一部として開発された、ハイレベルコンテナランタイム
 - [Fluentd](https://www.fluentd.org/)：Treasure Dataで開発された、ロギングツール
 - [Jaeger](https://www.jaegertracing.io)：Uberで開発された、分散トレースシステム
 - [Vitess](https://vitess.io)：YouTubeで開発された、MySQLインスタンスのクラスター展開・スケーリング・管理ツール

![k8s](https://www.cncf.io/wp-content/uploads/2018/08/kubernetes.svg) ![pro](https://www.cncf.io/wp-content/uploads/2018/08/prometheus-1.svg) ![envoy](https://www.cncf.io/wp-content/uploads/2018/08/envoy-1.svg) ![cdns](https://www.cncf.io/wp-content/uploads/2018/08/coredns.svg) ![cd](https://www.cncf.io/wp-content/uploads/2018/08/containerd-1.svg) ![fl](https://www.cncf.io/wp-content/uploads/2018/08/fluentd-1.svg) ![jg](https://www.cncf.io/wp-content/uploads/2018/08/jaeger-1.svg) ![vt](https://www.cncf.io/wp-content/uploads/2018/12/vitess-1.svg) 
画像出典：https://www.cncf.io/projects/

#### Journey Report
いくつかのプロジェクトは、変遷をJourney Reportとしてまとめて公開しています。
コントリビューター数やコミット数、国や企業別の貢献度など、様々な視点でまとめられていて、面白かったです。

- [Kubernetes Project Journey Report](https://www.cncf.io/cncf-kubernetes-project-journey/)
- [Envoy Project Journey Report](https://www.cncf.io/cncf-envoy-project-journey/)
- [Prometheus Project Journey Report](https://www.cncf.io/cncf-prometheus-project-journey/)


#### TrailMap, LandScape
CNCFは、現在のクラウドネイティブ技術を[LandScape](https://landscape.cncf.io/)としてまとめています。
また、クラウドネイティブ技術を取り入れる方法として[TrailMap](https://github.com/cncf/landscape/blob/master/README.md#trail-map
)を紹介しています。
画像が大きいので記事には貼りませんが、気になる方はリンクや他記事を参考にしていただければと思います。

しかし、TrailMapについては、上述の青山真也さんと草間一人さんの[記事](https://www.atmarkit.co.jp/ait/series/16443/)でいろいろと突っ込まれていました・・・。


#### プロジェクトのレベル
CNCFでは、ホストしているプロジェクトのレベルを明確に定めています。
![plevel](https://www.cncf.io/wp-content/uploads/2018/12/graphic-chasm-3-02.svg) 
画像出典：https://www.cncf.io/projects/

レベル | 要件
--- | ---
Sandbox  | CNCFのTOC（Technical Oversight Committee: 技術監視委員会）から最低2人のスポンサー
Incubating | 最低3つの独立したエンドユーザーが本番環境で正常に使用、健全な数のコミッター、明確なバージョン管理、公式リファレンス実装etc
Graduation | 少なくとも2つの組織のコミッター、コアインフラストラクチャイニシアチブベストプラクティスバッジを達成および維持、CNCF行動規範を採用、プロジェクトのガバナンスとコミッターのプロセスを明確に定義etc

他にもしっかりとした要件があるようなので、ご興味があれば[こちら](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)を参照してください。


### メンバーシップ
現在CNCFに加入している企業は[こちら](https://www.cncf.io/about/members/)で確認することができます。
メガパブリッククラウドはもちろんのこと、Apple、AlibabaやHuaweiなどの中国企業など、そうそうたる企業が名を連ねています。
国内企業では主に、Fujitsuがプラチナメンバーとして、NECがゴールドメンバーとして加入しています。

#### 会員費用や特典

CNCFのメンバーには、下記のクラスと特典があるようです。

クラス | 費用 | 特典
--- | --- | ---
プラチナ | $370,000 | 理事会に1人の代表者任命、理事会の小委員会または投票メンバーに1人の代表者指名、Webや資料の目立つ場所にロゴ配置、エンドユーザーでもある場合その全権限
ゴールド | $120,000 | ゴールドメンバー5人ごとに理事会に1人の代表者を任命、最大3人のゴールド代表者を任命、エンドユーザーでもある場合その全権限
シルバー | 企業規模別、最大$50,000 | シルバーメンバー10人ごとに理事会に1人の代表者を任命、最大3人のシルバー代表者を任命、エンドユーザーでもある場合その全権限
エンドユーザー | 企業規模別、最大$4,500 | エンドユーザーアドバイザリーコミュニティに参加、エンドユーザーテクニカルアドバイザリーボードに1人の代表者を指名
アカデミック | $1,000 | 各種ミーティングへの参加、KubeConなどのスポンサーシップ割引、Webや資料にロゴ表示
非営利 | $500 | アカデミックと同じ？

参考：https://www.cncf.io/about/join/

翻訳が良くできず詳しくわからない部分もありますが、有名企業が高いクラスの会員になっているのは、理事会への代表者任命などの理由があるのかなと思いました。
もちろん、オープンソースの貢献という理由もあると思いますが、トレンドの技術を主導できる立場になることは、特にIT企業としては高い費用を払ってもなる価値があるのかな、と調べていて感じました。


# サービスメッシュ

次に、サービスメッシュについてまとめました。

## 定義
定義ですが、「クラウドネイティブ技術」のように明確な定義を示しているものは見つかりませんでした。
上述のCNCFの[ブログ](https://www.cncf.io/blog/2017/04/26/service-mesh-critical-component-cloud-native-stack/)でサービスメッシュについて述べている記事がありましたので、ここではそれを抜粋します。

> サービスメッシュは、サービス間通信を処理するための専用インフラストラクチャレイヤーです。最新のクラウドネイティブアプリケーションを構成する複雑なサービストポロジを介した信頼性の高いリクエスト配信を担当します。

私としては、「クラウドネイティブ概要」で記したように、コンテナ＋マイクロサービスで通信が複雑になってきたから、通信の可視化と割り振り＋障害連鎖の防止のために利用するもの、という印象です。

## 構成
![servicemesh_architecture](https://www.nginx.com/wp-content/uploads/2019/02/service-mesh-generic-topology.png)
画像出典：https://www.nginx.com/blog/what-is-a-service-mesh/

次に、サービスメッシュのアーキテクチャーです。
管理側のコントロールプレーンと、サービスのサイドカープロキシ（主にEnvoy）のデータプレーンで構成されます。
サービス間通信をサイドカープロキシに仲介させることで、アプリケーションの実装を変更することなく、トラフィック管理やセキュリティ、テレメトリーを実現するようです。

Qiitaでは、@mamomamoさんがとても分かりやすくまとめてくださっていました。
https://qiita.com/mamomamo/items/92085e0e508e18bc8532

## プロジェクト、サービス
次に、プロジェクトやサービスについてです。

CNCFの[LandScape](https://landscape.cncf.io/category=service-mesh&format=card-mode&grouping=category)には、主なサービスメッシュのプロジェクトについてまとまっています。
また、こちらの[サイト](https://servicemesh.es/)では、主要なサービスメッシュの比較がわかりやすくまとまっていました。

ここでは、いくつか抜粋し、簡単な紹介をしたいと思います。

### Istio
![istio.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/448684b4-81d0-9af0-52bb-9d07edde8da0.jpeg)
画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://istio.io/

おそらく、一番有名なサービスメッシュではないかと思います。
現状、最も機能が豊富なようで、サービスメッシュのデファクトスタンダートといえそうな印象です。

開発主体 | バージョン | プロキシ | プラットフォーム | オープンソース
--- | --- | --- | --- | ---
Google、IBM、Lyft | 1.4.2 | Envoy | Kubernetes, Consul & Nomad | 〇

### Linkerd
![linderd.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/9bdbc82c-9ed6-c11f-ce66-d2a48eff0ed9.jpeg)
画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://linkerd.io/

LinkerdはCNCFのIncubatingプロジェクトで、最初に開発されたサービスメッシュのようです。

開発主体 | バージョン | プロキシ | プラットフォーム | オープンソース
--- | --- | --- | --- | ---
Buoyant | 2.6 | Linkerd2 proxy | Kubernetes | 〇

### AWS App Mesh
![appmesh.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/c67c3a3d-20c8-57e5-ed2e-b541008ae10b.png)
公式ウェブサイト：https://aws.amazon.com/jp/app-mesh/

AWS App Meshは、AWSが提供しているマネージドサービスのサービスメッシュです。
App Mesh自体の利用は無料で、コンテナと共にデプロイされたプロキシが使用するEC2インスタンスやFargateのCPU/メモリに対してのみ料金が発生するようです。
AWS内のサービスですが、パートナー企業として、DataDogやHashiCorp、Tetrateなどの企業が名を連ねています。

開発主体 | バージョン | プロキシ | プラットフォーム | オープンソース
--- | --- | --- | --- | ---
AWS | - | Envoy | ECS, Fargate, EKS, EC2 | -

### Consul Connect
![consul.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/60bbce65-e782-b09f-4a59-244fff7f6293.jpeg)
画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://www.hashicorp.com/products/consul/

Consul Connectは、TerraformやVagrantなどで有名なHashiCorpが開発しているサービスメッシュで、オープンソース版とエンタープライズ版があるようです。

開発主体 | バージョン | プロキシ | プラットフォーム | オープンソース
--- | --- | --- | --- | ---
HashiCorp | 1.6 | デフォルトはEnvoyだが変更可 | Consul, Nomad, Kubernetes | 〇

### Kuma
![kuma.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/ab57623b-b669-3cd5-0bb9-9c14ec526b5b.jpeg)
画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://kuma.io/

KumaはKong社が開発しており、2019年9月10日にオープンソースで提供を開始した、新しいサービスメッシュです。
今までのサービスメッシュよりも、使いやすさに念頭を置いているとのことです。
atmarkITにリリース時の[記事](https://www.atmarkit.co.jp/ait/articles/1909/17/news063.html)が掲載されていました。

開発主体 | バージョン | プロキシ | プラットフォーム | オープンソース
--- | --- | --- | --- | ---
Kong | 0.3 | Envoy | Kubernetes, VMs | 〇


# サーバーレス

次に、サーバーレス技術についてまとめました。

## 定義
まず、定義についてです。
上記でいろいろと述べたCNCFですが、サーバーレス技術に関しても[ホワイトペーパー](https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview)をまとめています。
このホワイトペーパーは英語なのですが、嬉しいことにatmarkITに[日本語翻訳版](https://www.atmarkit.co.jp/ait/series/9263/)が載っています。

以下、定義の抜粋です。

> サーバレスコンピューティングとは、「サーバ管理を必要としないアプリケーションの構築と実行の概念」です。 これは、1つまたは複数の関数としてバンドルされたアプリケーションがプラットフォームにアップロードされた後、 その時々のニーズを正確に反映した実行、スケーリング、請求が行われる、よりきめ細かなデプロイメントモデル を表しています。
サーバレスコンピューティングとは、「コードをホストして実行するためにサーバを使用しない」という意味では ありません。運用エンジニアがもはや必要とされないという意味もありません。むしろ、「 サーバレスコンピューティ ングの利用者が、サーバのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティプランニ ングに時間とリソースを費やす必要がなくなった」という考え方を指しています。代わりに、これらのタスクと機能 は全てサーバレスプラットフォームによって処理され、開発者および IT／運用チームから完全に抽象化されます。 

当たり前の話ですが、「サーバーがない」わけではなく、「サーバー管理を必要としない」ということのようです。

また、サーバーレスの変遷や技術については、Microsoftの川崎さんが分かりやすい[資料](https://www.slideshare.net/yokawasa/serverless-v1909-173712712)を公開して下さっています。

## プロジェクト、サービス
次に、プロジェクトやサービスについてです。
またまたCNCFですが、[Landscape](https://landscape.cncf.io/format=serverless)に現在のサーバレスのプロジェクトやサービスがまとめられています。![serverless.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/d6dfb6c1-f8bf-abd7-27c8-486a93b75026.jpeg)
画像出典：https://landscape.cncf.io/format=serverless

AWS LambdaやAzure Functionsなどのマネージドサービスは多数の記事があると思いますので（言い訳）、
今回は、この中からServerless FrameworkとKnativeについて、簡単な紹介をしたいと思います。

### Knative
![knative.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/4ba474d5-307a-7b97-ec35-767513b8c68b.jpeg)
画像出典：https://landscape.cncf.io
公式ウェブサイト：https://knative.dev

Knativeは、Google、IBM、Red Hat、Pivo​​tal、SAPなどが開発している、Kubernetesをベースとしたサーバーレスプラットフォームです。
Kubernetesの各種タスク（コンテナのビルド、構成ファイルの生成、ネットワークルールやロギングの設定など）を隠蔽して管理を簡素化し、Kubernetesでのサーバーレスなワークロードの実行を可能にすることを目的としているようです。

Knativeは「Serve」と「Event」というコンポーネントで成り立っており、Serveはリクエスト受信/ルーティング/スケールを行い、Eventはイベントトリガーのセットアップを行うようです。
元々は「Build」というコードのビルドやパッケージングを行うコンポーネントもあったようなのですが、現在は分離して[Tekton](https://github.com/tektoncd)というGoogleが開発しているCI/CDツールとなったようです。
（参考：https://www.atmarkit.co.jp/ait/articles/1909/20/news068.html ）

### Serverless Framework 
![sls.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/7b4ae3fb-a847-115f-ff0e-649663921795.jpeg)
画像出典：https://landscape.cncf.io
公式ウェブサイト：https://serverless.com

Serverless FrameworkはServerless, Inc.が開発している、サーバーレスアプリケーションの構成管理ツールです。
AWS、Azure、GCP、Alibaba Cloud、Knativeなど様々なプラットフォームに対してデプロイでき、サーバーレス版のTerraformといった印象です。
オープンソースエディションとプロエディションがあり、プロエディションはさらにフリー、チーム、エンタープライズとクラスが分かれています。
Qiitaでは、@horike37さんが使い方を分かりやすくまとめて下さっていました。( https://qiita.com/horike37/items/b295a91908fcfd4033a2 )


# ハイブリッド/マルチクラウド

最後に、ハイブリッド/マルチクラウドについてまとめたいと思います。

2019年に、Googleが[Anthos](https://cloud.google.com/anthos/)、Microsoftが[Azure Arc](https://azure.microsoft.com/ja-jp/services/azure-arc/)というハイブリッド/マルチクラウドプラットフォームを発表しました。
![Anthos.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/0b7f8db2-cd2a-f230-10f4-3672f8168a0a.png)
画像出典：https://cloud-ja.googleblog.com/2019/07/bringing-hybrid-and-multi-cloud-to-our-apac-customers-with-anthos.html
![arc.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/4040b014-1448-8d32-254f-378773d4d7e0.png)
画像出典：https://azure.microsoft.com/ja-jp/services/azure-arc/

どちらも自社クラウド上のリソース、オンプレミス、他社クラウドのリソースを一括管理できるという点では似ていますが、
AnthosはKubernetesクラスターをベースに、Azure ArcはKubernetesクラスターに加えてWindowsとLinuxベースのサーバーも一括管理できるという点が異なっているように見受けられます。

一方、AWSはハイブリッドクラウド環境として、[AWS Direct Connect](https://aws.amazon.com/jp/directconnect/)を提供していたり、今年のre:Inventで[AWS Outposts](https://aws.amazon.com/jp/outposts/)のGAを発表しましたが、マルチクラウドに関してはまだ言及していないように思います。
![dc.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/15803f2c-ace3-f879-da98-9c0ebdb59738.png)　![outpost.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531493/d6d3e77b-e67f-ab70-5452-3e80d4bbf1bd.png)

三社の方針の違いは、TechTargetの[記事](https://techtarget.itmedia.co.jp/tt/news/1912/12/news08.html)でまとめられています。
また、Azure Arcに関しては、@Yoshiyuki03さんがまとめてくださっていました。( https://qiita.com/Yoshiyuki03/items/99a6c42e5f24085da14b )

また、IBMは[Multicloud Manager](https://www.ibm.com/jp-ja/cloud/multicloud-manager)というサービスを展開しており（こちらもKubernetesベース？）、
Oracle Cloudは、Azureとの相互接続を[発表](https://docs.oracle.com/ja/solutions/learn-azure-oci-interconnect/)しています。



この流れの理由として、ベンダーロックインを避けたいユーザーニーズもあると思いますが、パブリッククラウド首位のAWSから顧客を奪いたいという狙いもあるのでしょうか。

# まとめ
情報をまとめていく中で、以下の点を今後意識していきたいなと感じました。

- Kubernetesを軸にしたエコシステムはもの凄い勢いで拡大しているので、Kubernetesへの理解を深めていく
- Kubernetesなどのクラウドネイティブ技術の情報を得るために、LFやCNCFの動きを追っていく
- ハイブリッド/マルチクラウドの流れが進みそうな印象があるので、1つのパブリッククラウドプロバイダーの理解・技術を深めるのも大事だが、各プロバイダーの特色を把握することや、ハイブリッド/マルチクラウドも提案・構築できるようになる

正直、今回は裾野を広げすぎた感がありました・・・。
サービスメッシュ、サーバーレス、ハイブリッド/マルチクラウドに関しては、簡単な情報のまとめだけで「やってみた」まではいけなかったので、今後は実際に触ってみて理解を深めたいと思います。

明日は @west-c さんの投稿になります！お楽しみに！