コンテナは型にはめられることにうんざりしています
感謝祭と…七面鳥。 クリスマスと…ツリー。 コンテナとマイクロサービス。
それぞれの言葉に対して最初に思い浮かんだ言葉が私の予想と一致したなら、あなたは今日のテクノロジー市場における過剰な連想の餌食になっていることになります。 どちらか一方に焦点を当てた議論では、コンテナとともにマイクロサービスについてもすぐに言及される傾向があります。 その理由の 1 つは、applicationsを集中的で機敏なサービスに分解するアーキテクチャ アプローチであるマイクロサービスが、コンテナ ベースのデプロイメント モデルの機敏な性質とよく適合するためです。 しかし、コンテナ自体がテクノロジーであることを忘れないでください。 これらは、マイクロサービスがアーキテクチャ上の目玉となるずっと前から存在しており、マイクロサービス ベースのアプリのデプロイメントにのみ有益であるわけではありません。
Lightbend (自称、世界をリードするリアクティブapplication開発プラットフォームの誇りあるプロバイダー) が 2100 人の JVM 開発者を対象に実施した調査「Enterprise Development Trends 2016 」から、クラウド、コンテナー、マイクロサービスに関する多くの洞察を得ました。 興味深いことに、大多数 (59%) がまったく新しいapplicationsをコンテナ化することを検討している一方で、41% が「既存のapplications」をコンテナ化の対象としています。
これはまったく異常ではありません。 Mesosphereが2016 年 8 月に 500 人の Mesos ユーザーを対象に実施した調査を見ると、51% が Mesos 上でモノリシックapplicationsとレガシー アプリケーションを実行していることがわかりました。 85% は、おそらく予想どおり、マイクロサービス アーキテクチャを実行しています。
コンテナは明らかに新しいアプリのためだけのものではなく、移植性、迅速な拡張性、DevOps 主導の運用との適合性など、コンテナの多くの利点をレガシー アプリケーションやモノリシックapplicationsで活用できるようにする手段として活用されています。 結局のところ、スムーズな移植性が約束されていたのに、各パブリッククラウド プロバイダが異なるイメージング形式を標準化したため、再イメージングに長い時間がかかりました。 複数のゴールド イメージ (環境ごとに 1 つ、マイナー ブランチごとに 1 つ、メジャー ブランチごとに 1 つ... など) を維持することは、運用上の悪夢となりました。 コンテナは、ハニーバジャーのように、気にしません。 OS から OS へ、仮想マシンから仮想マシンへ、クラウドからクラウドへと移行します。 これらは、瞬く間に (数えてみると約 400 ミリ秒です) コストベースのシームレスなクラウド移行の理想を実現するものとして、これまでに提案された最良の方法の 1 つです。
それでも、コンテナを「クラウド」テクノロジーとして分類するのはやめましょう。 確かに、これは、長らく宣伝されながらもほとんど実現されていないクラウド プロバイダー間の移植性の多くを実現しますが、クラウドやクラウドのような環境に限定されるものではありません。 Sumo Logic の最近のレポートで指摘されているように、コンテナは確かに「クラウド」で使用されています。このレポートでは、調査したアプリの 15% で Docker が本番環境で使用されていることがわかっています。 しかし、これはオンプレミスなど他の場所でコンテナが使用されていないことを意味するものではありません。 実際、前述の Mesosphere レポートでは、ユーザーのほぼ半数 (45%) が「オンプレミスのみ」であり、大多数が「ハイブリッド」と「クラウドのみ」に分かれていると指摘されています。 興味深いことに、「大企業（従業員 500 人以上）の方がオンプレミスで運用する可能性が高い」ことも判明しました。
コンテナは興味深いデプロイメント オプションであり、コンテナ オーケストレーション ソリューション (Docker、Docker swarm、Mesos および Marathon、Kubernetes など) によってサポートされている場合、applicationsを自動的にデプロイおよびスケールアップおよびスケールダウンできる非常にアジャイルな環境が提供されます。 これはマイクロクラウド、または少なくともクラウドのような環境であり、パブリック クラウド、プライベート クラウド、または「クラウド」をまったく使用せずに展開できます。 コンテナは、モノリシック アプリ、最新アプリ、マイクロサービス ベースのアプリ、API のデプロイとスケーリングに使用できます。 アプリが環境に密接に結合されないようにオペレーティング システム層を標準化することに重点を置いているため、柔軟性が非常に高くなります。
コンテナは、簡単に言えば、アプリがハニーバジャーになり、低レベルの詳細を「気にしない」ことを可能にする抽象化レイヤーです。 コンテナ オーケストレーション ソリューションによって監視および管理されると、その抽象化によって、アプリケーション インフラストラクチャ全体のリソース効率を向上させる方法で、スケールアップ、スケールダウン、スケールイン、スケールアウトが自動的に可能になります。
コンテナ、マイクロサービス、クラウドは BFF かもしれませんが、それぞれが独立した存在でもあります。 それぞれが補完的なメリットを提供し、時にはあえて言えば、他のメリットと相乗効果をもたらすこともあります。 しかし、コンテナを「マイクロサービス専用」や「クラウド専用」という非常に狭い型にはめ込まないようにしましょう。
コンテナは型にはめられることにうんざりしています。 彼らにアーキテクチャ内のさまざまな役割を試してみれば、それぞれの分野で主導的な役割を果たす能力が十分にあることがわかるかもしれません。