2018年の陰謀論？ Docker Inc とマイクロサービスの終焉!

今月初め、「Docker, Inc. は死んだ」という記事で、Docker, Inc. は 2018 年中に消滅すると予測されました。この見解に対して、「Docker Inc. は死なない」という記事がすぐに登場し、この見解に反論しました。

[[218908]]

Docker, Inc. は死んだ!

[[218909]]

Chris Short 氏は「Docker, Inc. is Dead」の中で、2017 年は Docker, Inc. にとって困難な年だったと述べるのは控えめな表現であると述べています。

実際、Uber を除けば、誇大宣伝に囲まれたシリコンバレーのスタートアップ企業で、Docker ほどひどい年を過ごした企業を思い浮かべるのは難しい。

将来の人々が Docker を振り返るとき、2017 年は、この重要なソフトウェア会社が悪質なビジネス慣行によって破壊され、最終的に地獄に落ちた年だったと見るでしょう。

Dockerは優れたソフトウェアです

明確に言えば、Docker はソフトウェア開発におけるこのイノベーションの波において重要な役割を果たしてきました。 cgroup、名前空間、プロセス分離などの Linux プリミティブを同じツールに組み込むことができるのは、間違いなく素晴らしい成果です。

Docker の登場により、開発環境は最終的にバージョン管理機能を備えたシンプルな Dockerfile へと変化しました。

そのツールチェーンは、Packer、Vagrant、VirtualBox、およびその他のインフラストラクチャを Docker 陣営に移行します。 Docker UI は実に素晴らしいです!

Docker: シリコンバレーの新たな寵児

Docker は初期の成功により、その製品を中心に大規模なコミュニティを急速に構築することができました。さらに、急速な発展は極めてスムーズな資本の流れももたらしました。

Goldman Sachs、Greylock Ventures、Sequoia Capital、Insight Venture Partners は Docker に多額の資金を提供してきました。現在までに、Docker の資金調達総額は 2 億 4,200 万～ 2 億 5,000 万ドルに達しています。

製品の品質自体は賞賛に値するが、同社は人事面で一連の失策に見舞われた。残念なことに、これはシリコンバレーの人気企業の多くに存在する問題であり、明らかに変化が必要です。

KubernetesはDockerに影響を与える

Kubernetes の台頭により、Docker の破滅は加速しました。 Docker は、オープンソース コミュニティのコンテナ オーケストレーションの新たな寵児である Kubernetes に対処するための適切な方法を見つけることができていません。

Docker が所有する Docker Swarm は、同社が所有する唯一のコンテナ オーケストレーション ツールです。 Kubernetes は Docker コンテナへの好意を示すことに先鞭をつけましたが、Docker は依然として独自の競合ソリューションを生み出しました。

記録によると、Docker は 2017 年初頭に記事、カンファレンス、さらにはその他の大規模なイベントを通じて Kubernetes に対する不満を表明しました。

しかし、オースティンで開催された DockerCon 17 カンファレンスから判断すると、Docker は突然 Kubernetes を全面的にサポートすることを決定しました。

この突然の変化は、Kubernetes の台頭が止められないことを明確に認めたものです。 Docker は 2017 年の KubeCon + CloudNativeCon North America カンファレンスでこの決定を繰り返し、間違いなくこの結論をさらに強調しました。

モビー？

昨年 4 月の DockerCon 17 で Docker が Moby を発表した理由は誰も知りませんでした。

Moby は Docker プロジェクトの新しいアップストリームと言われていますが、事前の警告がなかったことを考慮すると、Solomon Hykes が DockerCon 17 カンファレンスで発表したときには大きな衝撃と論争が巻き起こりました。

この対立を解決するために、GitHub のスタッフが直接介入することさえ選択しました。 Moby デプロイメントの取り扱いは初心者にとってはまだわかりにくく、その結果 Docker ブランドが損なわれる可能性があります。

Kubernetes の冷淡な受け入れ

Docker Inc. が遅ればせながら、そしてぎこちなく土壇場で Kubernetes を採用したことは、同社の差し迫った崩壊を意味していた。問題は、Docker Swarm がまだ成熟していないことです。

実際、Docker Swarm 製品チームとその少数のオープンソース貢献者は、Kubernetes コミュニティの急速な開発ペースに追いつくことができませんでした。

Docker UI と同様に、Kubernetes UI も優れています。現時点では、Docker 自体がコンテナ分野の非主流コンサルティング会社になり始めているようです。

陰謀論: Docker 社は破滅する運命にあることを知っていた。技術者たちは、Moby を大規模にリリースし、Kubernetes を突然採用することを決定しました。これらはすべて、自分たちに息抜きの余裕を与えるためでした。 #Docker #DevOps

— クリス・ショート (@ChrisShort) 2017年12月29日

クリス・ショートは最終的に、Docker Inc. の本当の問題は継続的なリーダーシップの欠如にあると結論付けました。同社では、各リーダーが独自の戦略的重点設定を持っています。

この世代間の断絶は会社の中核からどんどん遠ざかっていますが、それでもまだ存在しています。 Docker が自らを破壊していることは明らかです。

Docker の「生と死」の物語: この船はどこまで行けるのでしょうか?

[[218910]]

Dylan Chris 氏は「Docker Inc. は死なない」の中で次のように書いています: Chris Short 氏の指摘の一部は正しいものの、Docker がすぐに舞台を去ることはないだろう。

Dockerは確かに優れたソフトウェアです

Docker は、cgroup、名前空間、プロセス分離などの Linux プリミティブを同じツールに組み込んだ素晴らしいソフトウェアです。

Docker のシンプルなインターフェースにより、管理者以外のユーザーにとっての参入障壁が低くなり、開発者コミュニティが簡単にワークフローに追加できるようになります。

Docker は EE/UCP をリリースし、いくつかの大企業も参加しました。これにより、Docker は開発者、中小企業、大企業にとって優れたソフトウェアとなり、Docker によって開発が遅れることはありません。

Dockerには友達がいる

Brendan Burns 氏 (Microsoft Kubernetes シニア エンジニア): 「Solomon と Docker を Kubernetes コミュニティに迎えることができてうれしく思います。」多くの人が Docker について語るときにこの発言を引用し、それが Docker にとって大きな打撃であると考えています。

しかし、これについて話す本当の目的は、企業間のコラボレーションについて話すことであり、「誰が誰のコミュニティに参加するか」にこだわることではありません。

子供を育てるには村全体の協力が必要です。そして、その村は世界最大の企業の最も優秀なエンジニアで構成されており、全員が Docker をより良くするために懸命に働いています。 Docker と Kubernetes の連携は、Kubernetes と UCP の両方にとって非常に有意義です。

Dockerにはビジネスがある

Docker Inc. は買収されたり閉鎖される予定はありません。 Docker には十分なリーダーシップ、十分な資金、優れたマーケティングがあり、すべての兆候が同社が急速に成長し、エンタープライズ市場に参入することを示しています。しかし、成長するのは簡単ではありません。 「エンタープライズ アプリケーションの近代化」という彼らのスローガンは素晴らしいです。

これは OSS ベースの会社であり、市場には多くのチャンスがあります。 Iron の製品の 1 つは Docker をベースにしていますが、OSS 企業のさまざまなソフトウェアも積極的に活用しており、OSS ソフトウェアに対してより高いレベルのサポートと機能を提供できます。

他のプロジェクトでは、メンテナーや小規模な開発チームを支援するために、Open Collective を通じて寄付することがよくあります。 Docker による containerd の寄贈は素晴らしい動きであり、CNCF 憲章に完全に準拠したプロジェクトです。

Docker は「上流階級」へと向かっていますが、真のユーザーである開発者を見捨てたわけではありません。全体として、Docker Inc. には成長の余地が大きく、2018 年も成長を続けるでしょう。

そして最近、「2018 年のマイクロサービスの終焉」というタイトルの陰謀論記事が登場し、次のような内容が書かれていました。

2018年: マイクロサービス狂の終焉

マイクロサービスの話題は最近非常に人気があり、時には「クレイジー」と表現されることもあります。

Netflix は DevOps をうまく活用しており、マイクロサービスも使用しています。つまり、マイクロサービスも使用すれば、DevOps でもうまく機能できるということです。

多くの場合、私たちは目の前の問題を解決するためにマイクロサービス モデルを導入しようと多大な努力を払っていますが、そのコストとメリットについては明確ではありません。

次に、マイクロサービスとは何か、このパターンがなぜ魅力的なのか、そしてそれが直面する主な課題について詳しく説明します。

マイクロサービスが適切なモデルであるかどうかを検討している場合は、この記事の冒頭で一連の簡単な質問を通じて選択を支援します。

マイクロサービスがなぜ人気があるのでしょうか?

マイクロサービスとは何ですか? なぜそれほど人気が​​あるのですか?まずは基本から始めましょう。次の図は、左側に従来のモノリシック アーキテクチャ (単一の巨大なユニット)、右側にマイクロサービスがある仮想ビデオ共有プラットフォームの実装を示しています。

2 つのモデルの違いは、最初のモデルは 1 つの大きなユニットのみを備えたモノリシック アーキテクチャであることです。 2 番目のタイプは、それぞれが独立したサービスである複数の小さなユニットで構成されます。上記の図は十分に詳細なので、マイクロサービス モデルの魅力が簡単にわかります。

マイクロサービス アーキテクチャの具体的な利点は次のとおりです。

• 独立した開発: 小さな独立したコンポーネントは、小さな独立したチームによって構築できます。チームは「アップロード」サービスの開発を担当し、他のサービスについて心配する必要がなくなります。各コンポーネントの機能がシンプルになるため、開発者がコンポーネントを理解するために費やす時間が大幅に短縮され、新しい機能の開発が容易になります。
• 独立した展開: 個々のコンポーネントを個別に展開できます。これにより、新機能をより迅速かつ低リスクでリリースできるようになります。 「ストリーミング」コンポーネントのバグが修正されたり、新しい機能が追加されたりしても、デプロイメントは他のコンポーネントに影響を与えません。
• 独立したスケーラビリティ: 各コンポーネントは独立して拡張できます。新しい番組がリリースされる忙しい期間中、ダウンロード コンポーネントを拡張して、すべてのコンポーネントを拡張することなく、増加した負荷をサポートできるため、拡張の回復力が高まり、コストが削減されます。
• 再利用性: 各コンポーネントは小さな特定の機能を実装します。つまり、他のシステム、サービス、製品に簡単に適応できるということです。 「トランスコード」コンポーネントは他のビジネス ユニットで使用でき、他のグループにトランスコーディング サービスを提供する新しいビジネスに書き換えることもできます。

上記の詳細から、モノリシック アーキテクチャよりもマイクロサービス モデルの方が優れていることは明らかです。もしこれが事実なら、なぜこのモデルは最近になって人気が出始めたのでしょうか?

なぜマイクロサービスはもっと早く普及しなかったのでしょうか?

マイクロサービスには多くの利点があるのに、なぜもっと早く普及しなかったのでしょうか?理由は2つあります。

• それにより当社の技術力が向上します。
• 最近の技術の進歩により、私たちはそれを次のレベルに引き上げることができました。

この質問の回答を書き始めたとき、1、2文では明確に説明できないことに気づいたので、別の投稿に分割して後で公開しました。

したがって、この記事では、ESB とサービス指向アーキテクチャ、コンポーネント設計、境界付けられたコンテキストを無視して、単一のプログラムから複数のプログラムに移行するプロセスを省略します。

私たちはすでにさまざまな方法でマイクロサービスを使い始めており、コンテナ技術（特にDocker）やクラスター技術（Kubernetes、Mesos、Consulなど）の最近の人気により、技術的な観点からマイクロサービスモデルがより実現可能になりました。

マイクロサービスを実装する場合は、始める前によく考える必要があります。理論的な観点からその利点を見てきましたが、欠点はあるのでしょうか?

マイクロサービスの何が問題なのでしょうか?

マイクロサービス モデルには多くの利点がありますが、欠点は何でしょうか?私の知る限り、主に以下の問題があります。

開発の複雑さの増大

開発者にとって状況はさらに困難になるでしょう。開発者が新しい機能を開発する場合、その機能が他のサービスに依存しているときは、開発者は自分のマシン上ですべてのサービスを実行するか、それらのサービスに接続する必要があります。これは、単一のプログラムを単純に実行するよりも複雑になることがよくあります。

この問題はいくつかのツールで部分的に緩和できますが、システムを構成するサービスの数が増えるにつれて、開発者がシステム全体を実行する際に直面する課題も増えます。

運用の複雑さの増大

根本的な複雑さは、サービスを維持するチームにとって大きな課題となります。彼らは、少数のサービスではなく、数十、数百、さらには数千の実行中のサービスを管理します。サービスの数が増えると、通信リンクの数が増え、エラーが発生する可能性が高くなります。

DevOpsの複雑化

上記2点は開発と運用が別々に行われていることを示しています。 DevOps の人気が高まっていますが (私は DevOps の大ファンです)、DevOps はこの問題を軽減できるでしょうか?

現在でも多くの組織が独立した開発および運用チームに依存していますが、マイクロサービスの導入を好む組織もあります。

すでに DevOps を導入している組織にとって、これは依然として難しい場合があります。開発者とオペレーターの両方を務めることは十分に困難ですが (優れたソフトウェアを構築するには不可欠です)、クラスター化されたコンテナー システム、特に急速に進化しているシステムのニュアンスを理解する必要があるのはさらに困難です。

上級専門家が必要です

開発チームのメンバーが全員専門家であれば、結果は良いものになるかもしれません。しかし、スムーズに動作しない単一のモノリシック システムを使用すると想像してみてください。システムの数が増えると、操作の複雑さが増します。

これは、効果的な自動化、監視、クラスタリングを通じて実現できます。しかし、ボトルネックとなるのはテクノロジー自体ではなく、それを効果的に使用できる人材を見つけることです。これらのスキルは現在非常に需要が高く、見つけるのが難しいかもしれません。

現実世界のシステムには境界が曖昧なことが多い

マイクロサービスの利点を説明するとき、独立したコンポーネントについてよく話します。しかし、多くの場合、コンポーネントは独立していません。論文では、特定の領域が制限されているように見えるかもしれませんが、詳細を調べてみると、予想以上に難しいことがわかります。

事態は非常に複雑になってきています。境界が明確に定義されていない場合、理論的にはサービスを個別にデプロイできる場合でも、相互依存性があるためにサービスのクラスターをデプロイする必要があることに気付く場合があります。

つまり、連携して動作する一連の管理対象サービス バージョンが必要であり、これらのサービス バージョン間の連携を検証およびテストする必要があり、独立して展開可能なシステムは実際には存在せず、新しい機能を展開するには、多くのサービスを慎重にオーケストレーションして同時に展開する必要があります。

国家の複雑さは見落とされがちである

前の例では、機能の展開では複数のサービスの複数のバージョンを同時に展開する必要がある場合があることを説明しました。

ブルー/グリーンデプロイメント（ほとんどのサービスオーケストレーションプラットフォームで簡単に処理できます）や、複数のバージョンのサービスの並列実行、使用するバージョンを決定するチャネルなど、適切なデプロイメント手法によってこの問題を軽減できると想定します。

サービスがステートレスである場合、これらの手法によって多くの課題を軽減できます。しかし、ステートレス サービスは扱いが非常に簡単です。実際、ステートレス サービスがある場合は、マイクロサービスをスキップして、代わりにサーバーレス モデルを検討することになるでしょう。

実際には、ほとんどのサービスには状態が必要です。たとえば、ビデオ共有プラットフォームのサブスクリプション サービスを例に挙げてみましょう。サブスクリプション サービスの新しいバージョンでは、サブスクリプション データベースに新しい形式でデータを保存できます。

2 つのサービスを並行して実行すると、システムの 2 つのモードが同時に実行されることになります。ブルーグリーン デプロイメントを実行し、他のサービスが新しいデータに依存している場合は、それらのサービスを同時に更新する必要があり、サブスクリプション サービスのデプロイメントが失敗してロールバックする場合は、階層のロールバックが必要になります。

NoSQL データベースにはこれらの問題は存在しないと思われるかもしれませんが、そうではありません。スキーマを適用しないデータベースは、スキーマレス システムであることを意味するものではありません。

これは単に、スキーマがデータベース レベルではなくアプリケーション レベルで管理されることを意味します。データの形状とその進化の仕方を理解するという課題は依然として残っています。

コミュニケーションの複雑さは見落とされがちである

相互依存するサービスの大規模なネットワークを構築すると、サービス間で多くの通信が発生し、課題が発生する可能性があります。

まず、潜在的な失敗はどこにでもあります。サービスが別のサービスの呼び出しに失敗した場合、ネットワーク呼び出しが失敗したと想定して、少なくとも数回再試行する必要があります。サービス間の呼び出し関係が増えるほど、状況は複雑になります。

ユーザーが共有サービスにビデオをアップロードするとします。次に、アップロード サービスを実行し、データをトランスコーディング サービスに渡し、サブスクリプション サービスと推奨サービスを更新する必要があります。これらの呼び出しはすべて、ある程度の調整を必要とし、失敗した場合は再試行する必要があります。

また、再試行ロジックの管理は困難になる可能性があります。同期操作は多くの場合あまり安定しておらず、失敗しがちです。この場合、より信頼性の高い解決策は、非同期パターンを使用して通信を処理することです。

ここでの課題は、非同期パターンによってシステムがステートフルになることです。前述したように、分散型およびステートフル システムの扱いは困難です。

マイクロサービス システムがサービス内通信にメッセージ キューを使用する場合、基本的にこれらのサービスを結び付ける大きなデータベース (メッセージ キューまたはブローカー) が存在します。最初は問題ないように見えるかもしれませんが、パターンには常に隠れた危険が潜んでいます。

新しいバージョンのサービスでは、新しい形式でメッセージが書き込まれる場合があります。送信側サービスが送信メッセージの詳細を変更すると、そのメッセージに依存するサービスも更新する必要がある場合があります。

もちろん、異なる形式の複数のメッセージ処理サービスを用意することもできますが、その数が増えると管理が難しくなります。サービスの新バージョンをデプロイする場合、送信元サービスの異なるバージョンからメッセージが送信されたにもかかわらず、サービスの 2 つの異なるバージョンが同じキューからのメッセージを処理する可能性があり、複雑なエッジ ケースが発生する可能性があります。

これらのエッジケースを回避するための最善の方法は、特定のバージョンからのメッセージのみを許可することです。つまり、以前のバージョンからのメッセージが適切に除外されるように、サービス バージョンのセット全体をデプロイする必要があります。

これも、詳細に掘り下げてみると、独立したデプロイメントの考え方が期待どおりではない可能性があることを示しています。

バージョン管理が難しくなる

前述の問題を軽減するには、バージョンを慎重に管理する必要があります。 Semver のような標準に従うとこの問題は解決するでしょうか?答えはノーです。

Semver は強力なツールですが、連携して動作するサービスと API のバージョンを追跡する必要があります。

これは難しいことであり、どのバージョンのサービスが適切に連携するかについて混乱する可能性もあります。

ソフトウェア システム内の依存関係を管理することは、Node モジュール、Java モジュール、C ライブラリなど、どのようなものであっても非常に困難です。独立したコンポーネントと単一の全体との間の矛盾は処理が困難です。

依存関係が静的であり、パッチ適用、更新、編集が可能な場合、課題は避けられません。しかし、依存関係自体がライブ サービスである場合は、単に更新するだけでは不十分な可能性があります。システム全体が修正されるまで、多くのバージョンを実行する必要がある場合があります。

分散トランザクション

マイクロサービスは、操作全体にわたってトランザクションの整合性が求められる状況では非常に困難になる可能性があります。分散状態は扱いが難しく、多数の小さなユニットに障害が発生すると、クラスターの操作が困難になる可能性があります。

この問題は、多くの場合機能するべき等性、再試行メカニズムなどを実装することで回避できます。

しかし、場合によっては、操作のトランザクション性を、失敗と成功の間の状態ではなく、成功または失敗のいずれかに保証する必要があります。この問題を解決したり、マイクロサービス モデルでトランザクションを実装したりすることは非常に困難です。

マイクロサービスはモノリシックなモデルを偽装している可能性がある

個々のサービスとコンポーネントは個別にデプロイできますが、ほとんどの場合、Kubernetes などの何らかのクラスタリング プラットフォームを実行する必要があります。

Google の GKE や Amazon の EKS などのマネージド サービスを使用すると、クラスター管理の複雑さが自動で処理されます。

ただし、クラスターを自分で管理する場合は、大規模で複雑なシステムに直面します。単一のサービスには上記のような多くの利点がありますが、それでも細心の注意を払う必要があります。このシステムの展開、更新、フェイルオーバーなどの操作はそれほど簡単ではありません。

ほとんどの場合、利点は実現できますが、それでも大規模で複雑なシステムを管理することの難しさを過小評価したり、過小評価したりしないでください。マネージド サービスは役立つかもしれませんが、これらのサービスのほとんどは比較的新しいものです (たとえば、Amazon の EKS は 2017 年後半にリリースされたばかりです)。

マイクロサービスへの熱狂は冷め始める

マイクロサービス流行に乗らないように慎重に検討してください。これを手助けするために、自分自身に問いかけたい質問をいくつか挙げ、その答えをリストアップしました。

• PDF バージョンをダウンロードするには、ここをクリックしてください: microservice-questions.pdf (https://github.com/dwmkerr/blog/raw/master/2018/microservice-madness/images/microservice-questions.pdf)

マイクロサービスとアーキテクチャを混同しないでください

マイクロサービス アーキテクチャというものは存在しません。マイクロサービスは、コンポーネントの別のパターンまたは実装にすぎません。システムでマイクロサービスが使用されているかどうかは、アーキテクチャとは無関係です。

マイクロサービスは、多くの点でパッケージ化と運用の技術的なプロセスに関するものであり、システム設計に関するものではありません。コンポーネント境界は、エンジニアリング システムにおける最も重要な課題の 1 つです。

サービスの規模がどれだけ大きくても、Docker コンテナ内にあるかどうかに関係なく、システムをどのように組み立てるかを慎重に検討する必要があります。ここでは標準的な答えはなく、もう 1 つの選択肢があるだけです。