マルチクラウドやらないと！ってことで、Anthosを調べました。
GCP担当しているので。
まだソースを元に、少し考察をしたレベルですがこちらにまとめます。
No1
Anthos を発表 : マルチクラウド環境に対応した全く新しいアプリケーション管理プラットフォーム | Google Cloud Blog
・公式でGoogleが発表したので、ここがスタートだと思います。
・簡単、柔軟、安全に実行できる Google Cloud の新しいオープン プラットフォーム
・GCPではGKEを使い、他のクラウド、オンプレではGKE On-Premを使う。
・Anthos Migrate：
仮想マシン（VM）をオンプレミスや他のクラウドから GKE のコンテナに最小限の労力で直接かつ自動的に移行することができる。
・Anthos Config Management：ロール ベースのアクセス制御とリソースのクォータを設定、強制して名前空間を作るマルチクラスタ ポリシーを作成できる。
考察
・コンテナ上で動かすからプラットフォームを選ばずどこでもなんでも実行できるメリットがある。
・でも、コンテナネイティブ、クラウドネイティブで構築しないといけない前提があるのはデメリット。そういう客こそAzureにはいなさそう。
・コンテナネイティブでやっておけば、OSに縛られないから本当に便利。
・どこでもやり取りしやすくなるのはセキュリティが不安はある
No2
(1) Anthos in a minute - YouTube
2020/08/03
https://www.youtube.com/watch?v=xfwlbt3QZrM
point
・Anthosはハイブリッド、マルチクラウドのプラットフォーム
・アプリを変更しないで済む
・コンテナ化されたマイクロサービスを展開する
・ゼロトラストセキュリティモデルも提供する→IAPConnectorが関係する
・ベンダーロックインしない
考察
・Antosの問題点もチェックの必要がある
・客のめんどくさい部分を解決できるならいいができない時は導入しずらい
・Anthosを考えるとモダナイゼーションにもつながるし、CI CDにもつながる
No3
(1) Google Cloud Anthos - Explained in 4 Minutes - YouTube
https://www.youtube.com/watch?v=HMWIt9pI3ps
2019/06/19
point
・Antosは、アプリケーション管理のツール
・Anthosだけで、オンプレ、クラウドのアプリをスケール、管理することができる
・GKE、GKE-onpremの上にISTIOをたてる。その上にAnthos config managementがたつ。その上にGCP Marketplaceがある
・GCP Marketplaceがあると、例えば、WordPressをインストールしてMarketPlaceにアクセスすると、複数のコマンドを実行せずに同じ環境を得ることができる。
・ISTIOはVPNやInterconnectでつながる。
考察
・MarketPlaceの活用方法も見えてきた
・Anthosはアーキテクチャとしての考え方が非常に大事
No4
Anthos の技術概要 | Google Cloud
https://cloud.google.com/anthos/docs/concepts/overview?hl=ja
2021/1/27
point
・メインはAnthos on Google Cloud、Anthos オンプレミス、Anthos on AWS
・サンプルもあるが、ほかのクラウドやオンプレでコンテナを使ってないと、メリットはわからないと思う
考察
・ここが全貌なのは間違いない。
・できることはなんとなくわかるが、文章だけなのでイメージしずらい。管理のしやすさはわかるが、それだけで使うメリットが見いだせない気がする。
・そんなに難しいことではない気がしてきた
No5
(1) D2-3-S01: Anthos が変えるハイブリッド クラウドの形 - YouTube
https://www.youtube.com/watch?v=hpSbjIwgij8
2019/08/09
point
・DXにより、エンジニアに求められるスキル、開発環境などが変わっている
・フルマネージド、オープンテクノロジー
・マルチクラウド：クラウドに置けないデータはオンプレに。オンプレ環境を有効活用。コストも有効にみれる。
・Knative→cloud run
・Istio、K8sの専業管理者をたてるのは難しいので、今後進歩に貢献していきそうな技術はフルマネージドにする
・なぜGoolgeがコンテナを使うのか？
→新機能をどんどん、グローバルにリリースしたい。リソースを有効活用したい。開発者は開発に集中したい。ライブラリとアプリがまとまっているのは、すごくやりやすい。アプリエンジニアだけで解決できるのはいい。
コンテナだけでは足りず、コンテナオーケストレーションが火うようだった。
自分のローカルで動く→Goolgeで動かしたいとき、5000万だいのリソースで動かすには、コンテナのスケジューリングが適している。
サーバが落ちたとき、サービスが止まってしまうとき、自動的にコンテナを違うところで動かしてくれる。負荷にも対応できる。
・ポリシー、サービス、クラスタ管理をしている。
・マイクロサービスでは、お客様情報の管理も別。そうすれば、セキュリティも細かく管理できる。ISTIOはそのマイクロサービスの接続を管理できて、どことどこが繋いている必要があるかと考えられる。＝サービスメッシュ
・Migration for anthos:仮想マシンで動いているものをできるだけ簡単にコンテナにして、クラウドに持っていける。GKEにもっていける。
・4つのきもとなる機能がある。：Migration for anthos、Anthos config management,GKE(on-prem),istio
・エッジロケーションにも使える
考察
・マルチ、ハイブリッドだけでなく、エッジまで考えられる
・実際に使える人がいるかどうかというところがネックになる
No6
(1) D2-4-S04: Google Cloud の全貌と正しいはじめかた - YouTube
point
・ハードウェアが自由なので、ソフトウェアベースで考える
No8
(1) [Cloud OnAir]Config Connector の特徴と、Anthos Config Management を組み合わせた、構成管理の自動化について[2020年2月27日放送] - YouTube
https://www.youtube.com/watch?v=6p5IqnqHiAE&t=2980s
2020/02/27
point
・クラスタ管理がGKEHub。Anthos ConfigManagemtntでporishi-kanをする
・VMの話もでる ライセンス不要
・config syncの詳しい話も
・ポリシー管理もコードで行う
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Anthosを一言でいうと：アプリケーション管理のツール。Anthosだけで、オンプレ、クラウドのアプリをスケール、管理することができる。
成り立ち：GCPのいろんな機能を組み合わせてAnthosとして展開してる
メリット
簡単、柔軟、安全に実行できる
コンテナ上で動かすからプラットフォームを選ばずどこでもなんでも実行できる
マイクロサービスを展開できる
クラウドに置けないデータはオンプレに。オンプレ環境を有効活用。コストも有効にみれる。
ベンダーロックインの問題：コンテナで連携するので、ベンダーロックインしなくなる
ゼロトラストセキュリティモデルも提供する IAPConnectorはコンテナをベースにしているので、ゼロトラストモデルも利用可能
技術者は必要か
できる限り必要内容にはしている。
Istio、K8sの専業管理者をたてるのは難しいので、今後進歩に貢献していきそうな技術はフルマネージドにするのがGoogleの方針。
オンプレミス側、他クラウドでやること GKE on-prem でコンテナを考慮した実装が必要
Migration for anthosを使うことでコンテナネイティブに変更できる
主な機能：Migration for anthos、Anthos config management,GKE(on-prem),istio
Anthos config managementの役割：ロール ベースのアクセス制御とリソースのクォータを設定、強制して名前空間を作るマルチクラスタ ポリシーを作成できる。
Migration for anthosの役割：仮想マシン（VM）をオンプレミスや他のクラウドから GKE のコンテナに最小限の労力で直接かつ自動的に移行することができる
GKE(on-prem)の役割
istioの役割
Marketplaceを利用する：GKE、GKE-onpremの上にISTIOをたてる。その上にAnthos config managementがたつ。その上にGCP Marketplaceがある
・GCP Marketplaceがあると、例えば、WordPressをインストールしてMarketPlaceにアクセスすると、複数のコマンドを実行せずに同じ環境を得ることができる。
ネットワークはオンプレ側とどうつながるか：ISTIOをVPNやInterconnectでつなげる
AWSが近い理由：Anthos on AWSという機能があり、AWSを考慮した内容が公式ドキュメントにも記載されている
Goolgeがコンテナを使う理由：
新機能をどんどん、グローバルにリリースしたい。リソースを有効活用したい。開発者は開発に集中したい。ライブラリとアプリがまとまっているのは、すごくやりやすい。アプリエンジニアだけで解決できるのはいい。
コンテナだけでは足りず、コンテナオーケストレーションが火うようだった。
自分のローカルで動く→Goolgeで動かしたいとき、5000万だいのリソースで動かすには、コンテナのスケジューリングが適している。
サーバが落ちたとき、サービスが止まってしまうとき、自動的にコンテナを違うところで動かしてくれる。負荷にも対応できる。
エッジロケーションにAnthosを使う：
ポリシー管理もコードで行う