クラウドネイティブへのパス
最初に、子音の名前（Cloud Native Computing Foundation）を持つファンドで「クラウドネイティブ」と呼ばれるものを把握しましょう。 CNCFを理解する上で、これらはアプリケーション（および関連するインフラストラクチャ）であり、次の特性を備えています。
- 搾取の可能性 、すなわち 外部ツールを使用したアプリケーション/システムのライフサイクル管理。
- 観察の可能性 、すなわち 現在の状態とパフォーマンスを取得するメカニズムの存在。
- 弾力性 。利用可能なリソース内で、変化する負荷に応じてサイズを増減できます。
- フォールトトレランス 、転倒時の高速自動回復を保証。
- 迅速な展開（展開）、反復、構成の変更を含むダイナミズム 。
アプリケーションがこれらの要件を満たすのに役立つ多種多様な既存の製品を紹介するのが、クラウドネイティブに向けた主なステップの以下の説明です（翻訳については翻訳を参照してください） 。
したがって、CNCF Trail Map（クラウドインフラストラクチャをマスターするプロセス）で推奨されるのは次のとおりです。
- コンテナ化 通常、Dockerを使用して実装されます。 アプリケーションを任意のサイズのコンテナーとその依存関係にパックできます（PDP-11のコードでさえ、エミュレーターで実行）。 時間が経つにつれて、既存の機能をパーツに分割し、新しい機能をマイクロサービスとして実装することをお勧めします。
- CI / CD 継続的な統合と配信（継続的統合/継続的配信）を設定して、ソースコードの変更が自動的に組み立てられ、ステージング、最終的には本番環境でテストおよびデプロイされるコンテナーになるようにします。 自動化されたロールアウト、ロールバック、およびテストを構成します。
- オーケストレーション 。 オーケストレーション用のソリューションを選択します。 Kubernetesはマーケットリーダーと呼ばれ、 認定ディストリビューションがディストリビューションとして推奨されています。
- 観察と分析 。 監視、ログ、トレースのソリューションを選択してください。 CNCFプロジェクトには、Prometheus（監視）、Fluentd（ロギング）、Jaeger（トレース）があります。
- サービスメッシュ 。 これらの製品は、サービスの検出、ステータスの確認、ルーティング、負荷分散など、サービスと外部（インターネットから）からの可用性との相互作用の問題を解決します。 CNCFは、Envoy、 Linkerd 、およびCoreDNSを提供しています（最近、 Conduitについても書いていますが、[これまでに？] CNCFプロジェクトのリストに載っていません） 。
- ネットワーク 。 より柔軟なネットワーク機能は、Calico、 Flannel 、Weave NetなどのCNI互換ソリューションの提供に役立ちます。
- 分散データベース 。 1つのDBMSだけでは不十分な場合、大規模なMySQLの起動にはVitessプロジェクトが推奨されます。
- メッセージング JSON-RESTより優れたパフォーマンスを達成するために、CNCFはgRPCを試すことを提案しています。
- コンテナランタイム 代替のOCI互換コンテナ起動環境は、 containerd 、rktおよびCRI-Oです。
- ソフトウェア配布 。 収集したソフトウェアを安全に配布するには、Notaryを使用できます（ この記事の最後で説明しました ） 。
最初の3つのポイントは基本的なもので、残りは状況に応じてオプションです。
クラウドネイティブランドスケープ
「ランドスケープ」自体は、CNCFプロジェクトや無料ライセンスに限定されない製品のかなり広範なカタログです（ただし、それらのほとんどはオープンソースに関連しています）。 便宜上、これらはカテゴリに分類されます。
- アプリケーション開発 ：データベースとデータウェアハウス（Vitess、CockroachDB ...）、キュー（RabbitMQ、Kafka ...）、ソースコード管理（GitLab、GitHub ...）、アプリケーションモデリング/定義（Docker Compose、Bitnami ...）、継続的な統合と配信（ GitLab Runner、Jenkins ...）;
- オーケストレーションと管理 ：計画/オーケストレーション（Kubernetes、Mesos ...）、サービスの相互作用と発見（CoreDNS、Consul ...）、サービス管理（gRPC、Linkerd ...）;
- 実行環境 ：クラウドストレージ（ Rook 、Ceph ...）、コンテナーのランタイム（containerd、rkt ...）、クラウドネットワークソリューション（CNI、open vSwitch ...）;
- プロビジョニング ：ホストのツールと管理（Ansible、Chef ...）、インフラストラクチャ自動化（Helm、Terraform ...）、コンテナレジストリ（Docker Registry、Quay ...）、イメージセキュリティ（Notary、Clair ...）、キー管理（Vault、Spire ...） ;
- プラットフォーム ：Kubernetes認定ディストリビューション（OpenShift、Tectonic ...）、Kubernetes認定プラットフォーム（Google Kubernetes Engine、Azure Container Service ...）、認定されていないKubernetes実装（Amazon EKS、ContainerShip ...）、PaaSおよびコンテナサービス（Heroku、Hyper.sh ...）;
- 観察と分析 ：モニタリング（Prometheus、Datadog ...）、ロギング（fluentd、Graylog ...）、トレース（Jaeger、Zipkin ...）、サーバーレス（多くのサブカテゴリが個別のテーブルにリストされています ）;
- クラウド ：パブリック（AWS、Googleクラウド...）およびプライベート（OpenStack、MAAS ...）;
- Kubernetes認定サービスプロバイダー （Heptio、 Huaweiなど）。
このコレクション全体がグラフィカルに表示されます。
（ GitHubの完全な画像 。）
（ 注：この表では、 Kubernetesが卒業ステータス、つまり「卒業」を達成した最初のCNCFプロジェクトであったこともわかります。これは最近3月6日に発表されました。開始。）
インタラクティブな風景
さらに、クラウドネイティブランドスケープの2番目のバージョンでは、CNCFは、 landscape.cncf.io （サーバーレス-s.cncf.ioの場合 ）として利用可能なカタログのインタラクティブなWebバージョンを起動しました。
風景のコンテンツ
Cloud Native Landscapeカタログは、外部サービス（GitHubのプロジェクト情報、CrunchbaseとYahoo Financeの財務指標）から情報が追加される特別なYAMLから取得したデータに基づいて生成され、 新しいYAMLとJSONアプリケーションがデータを出力するために使用します。
CNCFは、新しいプロジェクトの追加を歓迎します。これは、前述のlandscape.ymlへのプルリクエストを通じて行われます。 プロジェクトには、GitHubに少なくとも250個の星がなければならず、利用可能なカテゴリのいずれかに対応している必要があります（要件の詳細については、 こちらを参照してください ）。
メインのCloud Native Landscapeテーブル、およびそのサーバーレスの対応物、および前述のTrail Mapは、 さまざまな形式で利用できます 。 すべてのプロジェクトデータは、グラフィックファイルとYAML（Creative Commons Attribution 4.0の下でライセンスされています）、Crunchbaseからの情報、およびプロジェクト/製品ロゴを除き、無料のApache License 2.0の下で配布されます。
PS
ブログもご覧ください。