マズローの自動化欲求階層説
現在、コンテナよりもホットなものがあるとすれば、それはおそらくサーバーレスのようなコンテナをベースにしたものでしょう。 これは、現在「クール」な存在であることに加えて、自動化とオーケストレーション* が現代のアプリケーションにとっていかに重要であるかを示す焦点でもあります。
ほぼ毎日、コンテナ アーキテクチャに何らかの新しいコンポーネントが追加され、それに伴い適切なレベルの自動化も実現されます。 コンテナの世界で自動化できるものがあれば、自動化されます。 豊富な API と構成/テンプレートベースの成果物への依存により、コンテナベースの環境内での自動化はほぼ継続的に進化しています。 API エコノミーがビジネスのデジタル変革にとって重要であるならば、もう 1 つの API エコノミーは IT のデジタル変革にとって不可欠です。
コンテナ環境も例外ではなく、コンテナ環境が本番環境に導入され続けるにつれて、アップストリーム (N-S) サービスが、これらの非常に不安定な環境内から拡張および提供されるアプリを提供できるだけでなく、自動化およびオーケストレーション レイヤーでそれらのアプリと統合できることがますます重要になります。
これは、このテクノロジーの「スタック」の一部の層が他の層よりも不安定であるためです。 たとえば、コンテナの作成と破棄は、クラスター全体が作成および破棄されるよりもはるかに定期的に発生します。 実際、 Data Dog HQ の Docker 採用レポートには、「2017 年 3 月時点で、Docker を実行している Datadog の顧客の約 40% が、 Kubernetes 、Mesos、 Amazon ECS 、Google Container Engine、またはその他のオーケストレーターも実行している」と記載されています。 自動化/オーケストレーションは、特にその中核部分において、コンテナの成功にとって非常に重要です。 つまり、私たちが前進するにつれて、自動化のニーズが他のすべてのものの基盤となるため、自動化のニーズをできるだけ早く（そして徹底的に）満たすことが不可欠になります。
これはクラウド環境にも当てはまります。 自動化とオーケストレーションの必要性を生むのは、不安定さだけではありません。結局のところ、俊敏性も必要です。 クラウド コンピューティングに関連する複雑な「セルフサービス」モデルでは、ユーティリティ コンピューティング モデル内でクラウド コンピューティングの弾力性のあるオンデマンド アーキテクチャの概念をサポートするために自動化が必要です。 クラウドとコンテナの両方に共通する一連の自動化ニーズが特定されており、これがビジネスにとっての価値を理解するための基礎となります。
マズローの欲求階層説と同様に、自動化欲求階層説は、成長を可能にする高次の欲求に向かって上向きに進むためには満たされなければならない「欠乏」欲求があるという前提に基づいています。
より高いレベルの成長ニーズを満たす前に、より低いレベルの赤字ニーズを満たす必要があります。 不足している欲求が満たされると、その欲求は消え去り、私たちの活動は、まだ満たされていない次の欲求を満たすことに習慣的に向けられるようになります。 これらは私たちの顕著なニーズになります。 しかし、成長のニーズは引き続き感じられ、いったん関与するとさらに強くなる可能性があります。 これらの成長ニーズが適度に満たされると、自己実現と呼ばれる最高レベルに到達できる可能性があります。-- https://www.simplypsychology.org/maslow.html
本質的に、この特定の自動化ニーズ階層は、アプリケーションとその複合サービスのスケーリングに関する基本的なニーズに重点を置いています。 このコンセプトを最初に発表した非常に優秀な F5 エンジニアは次のように説明しています。 「下部の自動化は最も頻繁に発生し、アプリケーションがオンライン状態を維持するために不可欠であるため、最も価値があります。 最上位の自動化は、頻度が低く（おそらく「1 回だけ」）、多くの人がすでに手動で作業を行っているときに同時に行われるため、最も価値がありません。」
これらは、コンテナ/仮想マシンおよびアプリの作成/破棄を自動化するための「基本的な」ニーズであり、スケールだけでなくスケールの有効性にとっても重要です。 その有効性は、コストを抑制し、従来は（コストのかかる）手動操作に課せられていた規模の負担を軽減するために重要です。 今日このようなイベントが発生する量と頻度を考えると、自動化は必須であり、あればよいというものではありません。 これは欠乏の欲求であり、つまり、それが満たされない場合、より高次の、あまり頻繁に発生しない自動化について心配する必要はほとんどないことを意味します。
これは特にコンテナに当てはまり、Data Dog が「コンテナの平均寿命は 2.5 日であるのに対し、すべての企業では、従来の VM とクラウドベースの VM の平均寿命は 23 日である」と指摘していることからも、このことが裏付けられているようです。 これは自動化の影響を受けているようです。 「オーケストレーターを使用して Docker を実行している組織では、コンテナの一般的な有効期間は 1 日未満です。 オーケストレーションなしでDocker を実行する組織では、コンテナは平均 5.5 日間存在します。」
コンテナとそれに続くアプリの作成/破棄を自動化する機能は、組織が従来の環境とクラウドベースの環境の両方でコンテナの利点を享受するために必要な、規模のスピードと俊敏性を実現するために不可欠です。
高次の自動化のニーズは、ルーティングのニーズとほぼ同じであり、成長のニーズに該当します。 基本的な（欠乏）ニーズが満たされると、成長のニーズが追求されます。 クラスターの作成/破棄とルーティングの変更は頻繁には発生せず、アプリが導入されてスケーリングできるようになった場合にのみ価値が高まります。 環境が開発/テスト環境から本番環境に移行し、アプリケーションを提供することでビジネス価値を提供する必要があるときには、これが必須になります。 結局のところ、応答できないアプリにルーティングするのは、飢えた人に抱擁を与えるようなものです。 温かくて心地よい感覚は、食料に対する基本的な欲求を満たすものではありません。 2016 年に Mesosphere がユーザーを対象に実施した調査では、62% のユーザーがすでに本番環境でコンテナーを使用していることがわかりました。 コンテナに焦点を当てたカンファレンス DockerCon での 2017 年の Portworx の調査では、回答者の 67.2% が本番環境でコンテナを使用していることがわかりました。 つまり、少なくともコンテナを採用している組織にとっては、ルーティングのニーズが急速に重要になってきています。
ビジネスの自己実現の究極の目標である成長は、階層全体が満たされるまで、つまり「スタック」全体が自動化され、調整されるまで達成できません。 したがって、NS データ プレーンを主に使用しているユーザーが、まず環境のスケーリング ニーズに対応し、NS から EW トラフィックへの移行が行われるルーティング ニーズまで対応しながら、ボトムアップでオーケストレーションを行うことは当然のことです。 これは、Kubernetes などのコンテナ オーケストレーター自体を中心とした、より緊密に結合されたエコシステムの継続的な開発からも明らかです。 最近の開発の 1 つは、「ルーティング」のニーズに重点が置かれており、レイヤー 7 (URI/API) でルーティングするイングレス コントローラーを組み込んで、NS から EW サービスへの移行がシームレスに行われるようにしています。 そのコンポーネントも、ルーティングのニーズを満たし、組織を階層の上へと押し上げて成長を実現するために、最終的には統合（自動化）される必要があります。
これをコンテナ固有の構造に変換することで、コンテナ環境の自動化のニーズを、成長を実現するための拡張のニーズをサポートするネットワーク内のサービスにマッピングできるようになります。 コンテナとネットワーク/アプリケーション サービス構造の両方に自動化が必要です。 配信中にコンテナを管理するサービスを同時に自動化せずに、アプリを拡張するために 100 個のコンテナを作成すると、ニーズが満たされません。 これらのネットワーク構造は、ネイティブ コンテナー構造として存在することも、コンテナー環境にネイティブに適合するように調整された既存のアプリ サービスとして存在することもできます。 実装の詳細はアーキテクチャと運用要件によって異なりますが、成功を実現するには、基本（スケール）と成長（ルーティング）のニーズを満たすために、両方の構成要素セットの存在が必要です。
いずれの場合も、コンテナとクラウドの成功はエコシステムに大きく依存しており、デジタル変革イニシアチブを通じてビジネスの成長に不可欠な自動化とオーケストレーションを実現するために、その他の API エコノミーに依存することを意味します。
* コンテナの世界では、自動化とオーケストレーションの概念が混同され、一方が他方と並置されているように見えるのは、イライラします。 しかし、今のところはそれを無視して、衒学者を本来あるべき場所に留めておくことにします。 私の頭の中。 叫ぶ。 必死に。