ついに誰かがクラウドネイティブをわかりやすく説明してくれた

クラウドコンピューティングも後半に入りました。前半のようにクラウドに行くかどうかで悩むのではなく、クラウドコンピューティングの価値を最大化するためにどのようにクラウドに行くかを議論しているところです。クラウド コンピューティングをさまざまなビジネス シナリオに深く統合するにはどうすればよいでしょうか?テクノロジーを企業にとって真に有効に活用するにはどうすればよいでしょうか?企業の IT 導入コストを節約するにはどうすればよいでしょうか?

「クラウド ネイティブ」が登場するまで、誰もその答えを知りませんでした。

クラウドネイティブとは何ですか?

クラウドネイティブとは何ですか?これについてはさまざまな意見があり、統一された定義はありません。 CNCF の定義を使ってクラウド ネイティブを理解しましょう。

兄？ CNCF?

CNCF の正式名称は Cloud Native Computing Foundation で、中国語では「Cloud Native Computing Foundation」と翻訳されています。 CNCF は、2015 年 12 月 11 日に設立され、Linux Foundation 傘下の財団です。 CNCF は、クラウド ネイティブ テクノロジーを促進するために、ベンダー中立のオープン ソース エコシステムを育成し、維持することに取り組んでいます。 CNCF は、クラウド ネイティブ分野で最も影響力と権威のある組織です。

CNCF の物語は Cgroups (コントロール グループ) から始まり、その歴史は 16 年前に遡ります。

Google は 2004 年にコンテナ テクノロジの使用を開始し、当初 Process Container と呼ばれていた Cgroups を 2006 年にリリースしました。

プロセス コンテナーの目的は非常に単純です。仮想化テクノロジと同様に、プロセスにオペレーティング システム レベルのリソース制限、優先度制御、リソース監査機能、プロセス制御機能を提供することを目的としています。この設計思想に基づき、プロセス コンテナは 2006 年に Google のエンジニアによって正式にリリースされ、翌年には Linux カーネル トランクに組み込まれました。

コンテナという用語は Linux カーネルではさまざまな意味を持つため、混乱を避けるために、コントロール グループ (Cgroup) に名前が変更されました。

2013年にDockerプロジェクトが正式にリリースされ、2014年にはK8sプロジェクトも正式にリリースされました。

その理由は非常に簡単に理解できます。コンテナと Docker を使用する場合、誰もがこれらのコンテナを便利に、迅速かつエレガントに管理できるようにする方法が必要です。これが K8s プロジェクトの本来の意図です。

K8s はクラウド ネイティブの基礎であり、これについては後で詳しく説明します。 Google と Redhat が K8s をリリースした後、プロジェクトは急速に成長しました。

2015 年、Google、Redhat、Microsoft などの大手クラウド コンピューティング ベンダーといくつかのオープン ソース企業が共同で Cloud Native Computing Foundation (CNCF) を設立しました。 CNCF が最初に設立されたとき、創設メンバーは 22 名で、K8s は CNCF がホストする最初のオープンソース プロジェクトとなりました。

それ以来、CNCF は急速に成長しました。 2020年2月現在、公式サイトのデータによると会員数は433名です。

では、CNCF はクラウド ネイティブをどのように定義しているのでしょうか?

中国語に翻訳:

クラウド ネイティブ テクノロジーにより、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。これらの技術により、フォールト トレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブ テクノロジーにより、エンジニアはシステムに頻繁かつ予測可能な重大な変更を加えることが容易になります。 Cloud Native Computing Foundation (CNCF) は、クラウド ネイティブ テクノロジーを促進するために、ベンダー中立のオープン ソース エコシステムを育成および維持することに取り組んでいます。私たちは最先端のモデルを民主化することで、これらのイノベーションを大衆に利用できるようにします。

CNCF によるクラウド ネイティブの定義に加えて、インターネット上で広まっている別のバージョンでは、Pivo​​tal の Matt Stine 氏が 2013 年に初めてクラウド ネイティブの概念を提案したとされています。 2015 年、クラウド ネイティブが推進され始めた頃、Matt Stine 氏は著書「Migration to Cloud Native Architecture」の中で、クラウド ネイティブ アーキテクチャの特徴として、12 の要素、マイクロサービス、自己アジャイル アーキテクチャ、API ベースのコラボレーション、脆弱性に対する回復力などを定義しました。

2017 年、Matt Stine 氏は論調を変え、クラウド ネイティブ アーキテクチャをモジュール性、可観測性、展開可能性、テスト可能性、置き換え可能性、処理可能性という 6 つの特性にまとめました。一方、Pivo​​tal の公式 Web サイトでは、クラウド ネイティブを DevOps + 継続的デリバリー + マイクロサービス + コンテナという 4 つの主要ポイントにまとめています。

MattStine 氏は、クラウド ネイティブは DevOps、継続的デリバリー、マイクロサービス、アジャイル インフラストラクチャ、コンウェイの法則などを含むアイデアの集合体であると考えています。

クラウド ネイティブには、テクノロジー (マイクロサービス、アジャイル インフラストラクチャ) と管理 (DevOps、継続的デリバリー、コンウェイの法則、再編成など) の両方が含まれます。クラウドネイティブは、クラウドテクノロジーとエンタープライズ管理方法の集合体とも言えます。

CNCF の公式定義に基づいて理解を深めていきましょう。代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。では、これらのテクノロジーとは何でしょうか?それらはどのように関連しているのでしょうか?

クラウドネイティブの代表的なテクノロジー

容器

一般的に言えば、「コンテナ」(LinuxContainer、LXC) はすべて「Linux コンテナ」です (もちろん Microsoft もコンテナに取り組んでいますが、Linux ほど成熟していません)。オープンソース ソリューション プロバイダーである Red Hat の公式 Web サイトに記載されているコンテナーの定義:

Linux® コンテナは、システムの他の部分から分離されたプロセスの集合です。これらのプロセスを実行するために必要なすべてのファイルは別のイメージによって提供されるため、Linux コンテナーは移植可能であり、開発からテスト、本番環境まで一貫しています。その結果、コンテナは、従来のテスト環境の複製に依存する開発パイプラインよりもはるかに高速に実行できます。コンテナはより一般的になり、使いやすくなり、IT セキュリティの重要な部分となっています。

コンテナーはプロセス レベルの分離を提供し、オペレーティング システムによって管理されるリソースを相互に分離されたグループに分割し、相互に分離されたグループ間のリソース使用の競合を解決できます。たとえば、アプリケーション (Application、APP) APP1 は Centos オペレーティング システムでのみ実行でき、APP2 は Ubuntu オペレーティング システムでのみ実行できます。 APP1 と APP2 が同じオペレーティング システム上で同時に実行されると、競合が発生します。コンテナ技術はこのような問題を解決できます。現在主流のコンテナ技術には、Docker、LXD、RKT などがあります。

ドッカー

コンテナに関して言えば、Docker について話さなければなりません。

2010年、数人のひげを生やした若者が米国サンフランシスコで「dotCloud」という会社を設立しました。同社は主にPaaSベースのクラウドコンピューティング技術サービスを提供しています。具体的には、LXC に関連するコンテナ技術です。 LXCはLinuxコンテナ仮想化技術（Linuxコンテナ）の略です。

その後、dotCloud はコンテナ テクノロジーを簡素化および標準化し、Docker と名付けました。

Docker プロジェクトがリリースされたとき、それは LXC の単なるユーザーにすぎませんでした。アプリケーション コンテナの作成と使用に関するロジックは、Warden などの競合製品のロジックと基本的に変わりませんでした。しかし、PaaS プロジェクトを本当に困らせるのは、Docker プロジェクトの最も強力なキラー機能であるコンテナ イメージであることが今ではわかっています。

Docker プロジェクトは、コンテナ イメージを使用して、アプリケーションの実行に必要な完全な環境、つまりオペレーティング システム全体のファイル システムを直接パッケージ化します。このアプローチは、長い間 PaaS ユーザーを悩ませてきた一貫性の問題に対する解決策と見なすことができます。 「一度リリースすればどこでも実行できる」Docker イメージを作成することの重要性は、開発環境とテスト環境を統合することすらできない Buildpack を作成することよりもはるかに高いです。

Docker プロジェクトにより、コンテナ テクノロジの使用のハードルが大幅に下がりました。軽量、ポータブル、仮想化されており、言語に依存しません。プログラムを書いてイメージ化すると、どこにでも展開して実行できるようになります。開発・テスト・本番環境が完全に統合されており、リソース管理や仮想化も行えます。

オープンソースのアプリケーション コンテナ エンジンである Docker は、開発者やシステム管理者が分散アプリケーションを構築、リリース、実行できるように設計されたプラットフォームです。一般的な Docker プラットフォームには、Kubernetes、Openshift V3、Flynn、Deis などがあります。

Docker を使用すると、開発者はさまざまなアプリケーションと依存パッケージをポータブル Docker コンテナにパッケージ化し、Docker コンテナをリソースのセグメンテーションとスケジューリングの基本単位として使用し、ソフトウェア ランタイム環境全体をカプセル化して、Linux マシンに公開することができます。

Docker の設計原理は上図に示されています。 Docker の設計によれば、アプリケーション ソフトウェアの配信プロセスは海上輸送のようなもので、オペレーティング システム OS は貨物船のようなもので、OS に基づく各ソフトウェアはコンテナのようなものになります。ユーザーは標準化された手段を通じて動作環境を自由に組み立てることができます。同時に、コンテナの内容は、ユーザーまたは専門家 (開発者またはシステム管理者) によってカスタマイズできます。このように、アプリケーション ソフトウェア製品を提供することは、標準化されたコンポーネントのコレクションを提供することと同等です。

Docker を一文で説明してください。

コンテナがなければグローバル化はあり得ません。そして、Docker は IT の世界におけるコンテナです。

コンテナを使用する場合は、コンテナのライフサイクルを調整および管理する必要があり、Kubernetes を理解する必要があります。

クベネフィット

Kubernetesについてお話しましょう。 Kubernetes はかつてクラウド ネイティブの基礎と呼ばれていました。

K8s、正式名称はKubernetesです。この単語はギリシャ語に由来し、操舵手またはパイロットを意味します。 K8s はその略称であり、「ubernete」の 8 つの文字を数字の「8」に置き換えたものです。

K8s はまったく新しい発明ではありません。これは、Google が社内で使用している Borg をベースに改良した汎用コンテナ オーケストレーション スケジューラです。 2014年6月にオープンソース化され、同年7月にはMicrosoft、Red Hat、IBM、Dockerなどが相次いでK8sに加わった。 2015年にGoogleはLinux Foundation傘下のCloud Native Computing Foundation（CNCF）に寄贈し、K8sはCNCFの最初のプロジェクトとなった。

K8s のアーキテクチャは少し複雑です。簡単に見てみましょう。

K8s システムは通常、K8s クラスターと呼ばれます。このクラスターは、主にマスター ノード (マスター ノード) とノード ノード (コンピューティング ノード) のグループの 2 つの部分で構成されます。

以下に、特殊な用語について説明します。

• マスター: K8s ノードを制御し、ジョブ タスクが作成されるマシン。
• ノード: これらのマシンは、K8s マスター ノードの制御下で割り当てられたタスクを実行します。
• ポッド: 1 つ以上のコンテナのコレクションで、全体として 1 つのノードにデプロイされます。同じポッド内のコンテナは、IP アドレス、プロセス間通信 (IPC)、ホスト名、およびその他のリソースを共有します。 Pod は、基盤となるコンテナのネットワークとストレージを抽象化し、クラスター内でのコンテナの移行をより便利にします。
• Replicationcontroller: クラスター上で実行されているポッドのインスタンスの数を制御します。
• サービス: 特定のポッドからサービス コンテンツを分離します。 Kubernetes サービス プロキシは、ポッドがクラスター内のどこに移動されたか、または置き換えられたかどうかに関係なく、サービス要求を適切なポッドに自動的に配布する役割を担います。
• Kubelet: このデーモンは各ワーカーノードで実行され、宣言されたコンテナが適切に起動され実行されていることを確認するためにコンテナのリストを取得する役割を担います。
• kubectl: これは Kubernetes のコマンドライン構成ツールです。

K8s の専門用語をいくつか理解すると、K8s の一般的な理解が得られます。

クラウドは安定した、すぐに利用できるインフラストラクチャを提供できますが、ビジネスをクラウドに移行することは難しい問題となっています。 K8s の登場は、初期のコンテナ オーケストレーション ソリューションから始まるのではなく、アプリケーションをクラウドに移行する問題 (つまり、クラウド ネイティブ アプリケーション) を解決することに重点が置かれています。

CNCF でホストされている一連のプロジェクトは、クラウド ネイティブ アプリケーションのライフサイクル全体の管理に特化しており、デプロイメント プラットフォーム、ログ収集、サービス メッシュ、サービス検出、分散トレース、監視、セキュリティなど、さまざまな分野でオープン ソース ソフトウェアを通じて完全なソリューション セットを提供します。

Google は、Kubernetes の Pod、Deployment、Job、StatefulSet などのさまざまな概念オブジェクトを抽象化および簡素化することで、クラウド ネイティブ アプリケーション向けのユニバーサルでポータブルなモデルを形成しました。クラウド アプリケーションのデプロイメント標準として、Kubernetes はビジネス アプリケーションに直接向けられており、クラウド アプリケーションの移植性が大幅に向上し、クラウド ベンダー ロックインの問題が解決され、クラウド アプリケーションをクラウド間でシームレスに移行したり、ハイブリッド クラウドの管理に使用したりできるため、エンタープライズ IT クラウド プラットフォームの新しい標準となっています。

マイクロサービス

マイクロサービスを導入する際には、まずマイクロサービスとは何かを理解する必要があります。名前が示すように、マイクロサービスは、「マイクロ」とは何か、そして「サービス」とは何かという 2 つの側面から理解する必要があります。狭義のマイクロとは、サイズが小さいことを意味します。有名な「2枚のピザチーム」は良い説明です（2枚のピザチームはAmazonのCEOであるベゾスが最初に提案したもので、1つのサービスの設計には、設計、開発、テスト、運用、保守のすべての参加者が2枚のピザを一緒に用意するだけでよいことを意味します）。

いわゆるサービスはシステムと区別する必要があります。これは、ユーザーが認識できる機能の最小セットである、比較的小規模で独立した機能単位の 1 つまたはグループにサービスを提供します。

従来のモノリシック アーキテクチャはシステム全体として展開されますが、マイクロサービスは独立した各コンポーネント (ユーザー サービス、製品サービスなど) として展開されます。単一のアプリケーションでは、特定の業務の要求量が非常に大きいことがわかった場合、その業務のみを拡大することはできません。クラスターを実装するには、単一のアプリケーション全体をコピーし、別の環境をデプロイすることしかできません。マイクロサービスは、まさにモノリシック アプリケーションの欠陥のために誕生しました。

マイクロサービスとモノリシック アプリケーションの違いは、Martin Fowler の次の図で説明できます。

それはどういう意味ですか？たとえば、各サービスのスループットに応じて、支払いサービスでは 20 台のマシンを展開する必要があり、ユーザー サービスでは 30 台のマシンを展開する必要があり、製品サービスでは 10 台のマシンのみを展開する必要があります。このような柔軟な展開は、マイクロサービス アーキテクチャでのみ可能になります。

近年人気が高まっている Docker は、マイクロサービス アーキテクチャに効果的なコンテナを提供します。

サービスメッシュ

サービス メッシュとは、サービス間の通信を処理するために使用されるインフラストラクチャ層を指します。これは、最初に Buoyant (Service Mesh プロジェクト Linkerd を開発した会社) によって提案され、社内で使用されました。同社は2016年9月29日に初めてこの用語を公に使用した。

サービス メッシュは通常、マイクロサービス アプリケーションの構成可能なインフラストラクチャ層で使用されます。 Istio (Google、IBM、Lyft がサポート) は、最もよく知られているサービス メッシュ アーキテクチャです。

Kubernetes（元々は Google によって設計され、オープンソース化されました）は現在、Istio でサポートされている唯一のコンテナ組織フレームワークです。

サービスメッシュがなぜ人気があるのでしょうか?多くの企業にとって、Docker や Kubernetes などのツールは「デプロイメントの問題を解決」したか、ほぼ解決しました。しかし、ランタイムの問題はまだ解決されていません。ここでサービス メッシュが登場します。

展開の問題は何が解決されますか? Docker や Kubernetes などの機能を使用すると、デプロイメントの増分的な運用上の負担を大幅に軽減できます。これらのツールを使用すると、100 個のアプリケーションまたはサービスを展開する作業は、単一のアプリケーションを展開する作業の 100 倍の労力ではなくなります。これは大きな前進であり、多くの企業にとってマイクロサービスの導入コストの大幅な削減につながりました。これは、Docker と Kubernetes が提供する強力な抽象化だけでなく、組織全体でパッケージ化とデプロイメント モデルのプロセスを標準化するためでもあります。

Service Mesh の登場により、マイクロサービスの接続、管理、監視における Kubernetes の欠点が補われ、Kubernetes のアプリケーションとサービスの管理が改善されました。そのため、Service Meshの代表格であるIstioが登場すると、Kubernetesと連携して動作する強力なマイクロサービス管理ツールとして業界から高く評価されました。

不変のインフラストラクチャ

従来の可変サーバー インフラストラクチャでは、サーバーは継続的に更新および変更されます。このタイプのインフラストラクチャを使用するエンジニアと管理者は、SSH 経由でサーバーに接続し、パッケージを手動でアップグレードまたはダウングレードしたり、サーバーごとに構成ファイルを調整したり、新しいコードを既存のサーバーに直接展開したりできます。つまり、これらのサーバーは変更可能です。作成後に変更することもできます。

変更可能なインフラストラクチャは、多くの場合、次のような問題を引き起こします。

• 災害が発生するとサービスを再構築することが困難になります。継続的な過度の手作業と記録の不足により、標準で初期化されたサーバーから同等のサービスを再構築することが困難になります。
• サービス操作中にサーバーを継続的に変更すると、プログラム内の可変変数の値が変更されることになり、一貫性のない状態の同時実行のリスクが発生します。サーバーにこれらの変更を加えると中間状態も導入され、予期しない問題が発生する可能性があります。

不変インフラストラクチャは、サーバーがデプロイされた後に変更されない別のインフラストラクチャ パラダイムです。プログラミングにおける不変変数は、値が割り当てられた後は変更できず、新しい変数を作成して古い変数全体を置き換えることしかできません。この特性により、この変数は並行環境で安全に使用できます。インフラストラクチャの最も基本的な不変性は、サービスを実行するサーバーがデプロイ後に変更されないことを意味します。

不変インフラストラクチャの利点には、インフラストラクチャの一貫性と信頼性の向上、およびよりシンプルで予測可能な展開プロセスなどがあります。

構成ドリフトやスノーフレーク サーバーなど、変更可能なインフラストラクチャでよく見られる問題を軽減または完全に防止できます。ただし、これを効果的に使用するには、包括的な展開の自動化、クラウド コンピューティング環境での迅速なサーバー プロビジョニング、ログなどのステートフル データや一時データを処理するソリューションが必要になることがよくあります。

宣言型API

エンジニアは宣言型プログラミングを命令型プログラミングと常に比較してきましたが、これらはまったく異なるプログラミング手法です。

私たちが接する最も一般的なプログラミング スタイルは、実際には命令型プログラミングです。命令型プログラミングでは、特定の効果や目標を達成するために実行する必要がある命令を記述する必要があります。一般的なプログラミング言語である Go、Ruby、C++ は、実際には開発者に命令型プログラミング手法を提供します。

宣言型と命令型は、まったく異なるプログラミング スタイルです。

• 命令型 API では、「コンテナの実行」、「コンテナの停止」など、サーバーが実行するコマンドを直接発行できます。
• 宣言型 API では、システムが何を実行すべきかを宣言し、システムは継続的にその状態に向かって進みます。

平たく言えば、命令型プログラミングとは一人称で、自分が何をしたいのか、そしてそれをどのように行うのかを考えることです。オペレーティング システムは、このプログラミング パラダイムを最も好みます。オペレーティング システムはほとんど「考える」必要がなく、コードを 1 つずつ命令に変換するだけで済みます。宣言型プログラミングは、あなたがやりたいことの「二人称」に似ています。 「プロダクトマネージャー」と「開発」の間にはちょっとした関係があります。 「製品マネージャー」は要件を提案する責任のみを負い、「開発」がそれをどのように実装するかについては気にしません。

上で述べたテクニックとツールをまとめてみましょう。

K8s はクラウド ネイティブ全体の基礎であり、クラウド ネイティブ エコシステム全体は K8s 上に構築されています。コンテナは k8s の基盤となるエンジンです。 Docker は最も広く使用されているコンテナ ツールです。マイクロサービスは Docker の優れたパートナーです。サービス グリッドはマイクロサービスの補助であり、k8s 上に構築されたリクエストの拡張機能です。不変のインフラストラクチャは、現代の運用と保守の基礎です。宣言型 API は k8s のコーディング方法です。

クラウドネイティブアプリケーションの価値

スペースの制約により、クラウド ネイティブ アプリケーションの値を 3 つだけ挙げることにします。

1) 迅速な反復

クラウドネイティブ アプリケーション開発を活用するということは、Kubernetes に代表されるコンテナなどのアジャイルでスケーラブルなコンポーネントを使用して、マルチクラウドなどの技術的な境界を越えても、明確に記述された方法で統合された個別の再利用可能な機能を提供することを意味します。これにより、デリバリー チームは反復的な自動化とオーケストレーションを使用して迅速に反復処理を行うことができます。

2) 自動展開

クラウド ネイティブ アプローチは、ソフトウェア配信プロセスで開発環境やその他のさまざまな環境を構築するために多大な労力を必要とする従来の仮想化指向のビジネス プロセスよりもはるかに優れています。クラウド ネイティブ アーキテクチャは、自動化と構成の機能を備え、信頼性が高く、実証済みで、監査済みの既知の適切なプロセスを基盤としているため、繰り返しの手動介入を必要とせずに俊敏な結果を実現します。

3) 独立性と効率性

クラウド ネイティブはマイクロサービス アーキテクチャをもたらします。マイクロサービスとは、基本的に独立してリリースできるアプリケーション サービスです。したがって、大規模なアプリケーション全体への影響が少なく、アップグレードしたり、グレー表示したり、独立したコンポーネントとして再利用したりできます。各サービスは専用の組織によって個別に完了することができ、依存側は入力ポートと出力ポートを決定するだけで完全に開発できます。チーム全体の組織構造もより合理化されるため、コミュニケーションコストが低くなり、効率が高くなります。

クラウド ネイティブについて話すときは、クラウド コンピューティングについて話す必要があります。それをクラウドコンピューティングと比較しないのは愚かなことです。クラウド コンピューティングの最初の波は、特にクラウド コンピューティング インフラストラクチャが安価になったことで、コスト削減とビジネスの俊敏性が重視されました。

多くの企業は、アプリケーションの開発にマイクロサービス アーキテクチャを使用する傾向があります。マイクロサービスは開発が速く、責任が単一で、顧客による導入も迅速です。同時に、これらのアプリケーションは迅速な反復を通じて進化し、顧客の認知を獲得することができます。クラウド ネイティブは、マイクロサービスの開発、テスト、展開、リリースのプロセス全体をオープンにすることができます。

クラウド プロバイダーは、市場のニーズに応えるために、位置情報を提供する Google マップやソーシャル コラボレーションを実現する認証プラットフォームなど、さまざまなシナリオに対応する API を提供しています。これらすべての API をエンタープライズ ビジネスの機能と組み合わせることで、顧客向けの独自のシナリオを構築できます。この統合はすべて API レベルで行われます。つまり、モバイル アプリケーションと従来のデスクトップ アプリケーションの両方をシームレスに統合できます。したがって、クラウド ネイティブを使用して開発されたアプリケーションは、非常にスケーラブルです。

ソフトウェアには不具合がないはずがありません。従来のエンタープライズ レベルの開発方法では、エンタープライズ アプリケーションを監視および保守するための専任の担当者が必要です。クラウドネイティブ アーキテクチャでは、基盤となるサービスまたは API がクラウドにデプロイされます。これは、負担の大きい運用および保守作業をクラウド プラットフォーム プロバイダーに移管することと同じです。つまり、顧客のアプリケーションはより専門的なケアを受けられると同時に、運用および保守コストも節約できます。

結論

9 年前、Netscape の創設者である Marc Andreessen は、「ソフトウェアが世界を飲み込んでいる」と述べました。 6 年前、OpenStack Foundation の創設者 Jonathan Bryce 氏は次のように付け加えました。「世界中のあらゆるものはオープンソースから生まれています。」その後、業界では「クラウド コンピューティングは空の色を変えた」という意見が一般的になってきました。しかし、過去 2 年間でクラウド コンピューティングの概念は明確に細分化され、「クラウド ネイティブ」が最大のテーマとなっています。

「大きな魚」がやって来ます。私たちにできることは、古いやり方に固執するのではなく、「大きな魚」を受け入れることです。時代はクラウド ネイティブを求めていますが、クラウド ネイティブは一夜にして実現できるものではなく、段階的なプロセスです。クラウド ネイティブを拒否し、クラウド ネイティブを理解し、クラウド ネイティブを受け入れ、クラウド ネイティブに従います。