私の考えでは、人々はDockerを使用してローカル環境が本番と同じであることを確認し、アプリが物理的に実行されている場所について考えるのをやめ、その瞬間に最適な場所にアプリを割り当てる必要があります。
私は100%Webベースであり、データベースと一緒にクラウドに移行します。移動できないものはシームレスにブリッジされるため、企業のものとクラウドは1つのサブネットワークになります。
それで、おそらくService FabricはDockerと同じことを既に行っており、アドレス変換サービス(fabric://はファブリックスペースのプロセスのDNSのように機能します)に加えて(一部にとって重要)オンデマンドワーカー割り当て-巨大なスケーラビリティ特典。
Docker(会社)はすべてのクラウドにクレームを賭けようとしているため、混乱を招きます。
Service Fabricはオーケストレーションシステムです。 Dockerコンテナーを調整できますが、Fabric専用にビルドする場合は、サービスとより緊密に統合することもできます。 (Dockerは、コンテナー内で実行されるものについて完全に非依存です。)
そのため、Service FabricはDocker Cloudに匹敵するmostlyですが、完全に一致するわけではありません。他にもDockerベースのオーケストレーションソリューションがいくつかあり(おそらくKubernetesが最大です)、クラウドベースのマイクロサービスソリューションは他にもあります(おそらく、Herokuが最も有名です)。
Service Fabricの主な欠点は、Microsoftテクノロジーであるため、Dockerを実行している場合よりも、Azureに強く結び付けられることです。もう1つは、スタックを構築するためのDockerの選択肢が幅広いことです。上記の3つのDockerのすべてに、少なくとも1つのオープンソースの選択肢があります(これも大きな欠点ですDockerの場合、誰も単一のベストプラクティスのドキュメントを配置していないため)。
マイクロソフトが大好きで、システムを一緒にまとめることが重要でない場合は、Service FabricがDockerエコシステムの優れた代替品になるはずです。 (そして、その下でDockerコンテナーを実行できます。)
Service FabricとDockerコンテナー化の主な類似点:
Service FabricとDockerコンテナー化の主な違い:
上記の事実を念頭に置いて、SFはどのクラウドプロバイダーにも強い親和性を持たないことに注意してください。目的のプラットフォームでVMを作成できる限り、パブリッククラウド(Azure、AWS、GCP)で同様に実行できます。
それはまったく比較できません。サービスファブリックを使用すると、ヘルスモニタリング、ファブリックとのコード統合、ロギング、モニタリング、ロードバランシング、その他のインテリジェント機能を利用できます。アプリケーションはシャットダウンコードを実行することもできます。 Service FabricはMicrosoftテクノロジー専用ではなく、DockerもSF内に常駐できます。rktまたはUnix OSも同様です。セキュリティとネットワーク機能(Webアプリとインライン)はもう1つのプラスです。信頼できるコレクションは素晴らしいです。そして、より良いアプリケーションの構築とパフォーマンスへのロードマップは、それを採用している企業に保証されています(歴史はそう言っています)。
この質問は、「最大の発明」Dockerを強く支持しています。この比較はDockerマーケティングには役立ちますが、SFをDockerに置き換えるものはありません。 Dockerはほんの小さなOSコピーです(サービス、アプリケーション、またはインテリジェンスとは関係ありません)。 Dockerはアプリケーション開発とは関係ありません。それは意図ではありません。ただ、人々は孤立と共有の必要性を見つけ始めました。そして、それがDockerのすべてです。