web-dev-qa-db-ja.com

Azure Service FabricはDockerと同じことを行いますか?

私の考えでは、人々はDockerを使用してローカル環境が本番と同じであることを確認し、アプリが物理的に実行されている場所について考えるのをやめ、その瞬間に最適な場所にアプリを割り当てる必要があります。

私は100%Webベースであり、データベースと一緒にクラウドに移行します。移動できないものはシームレスにブリッジされるため、企業のものとクラウドは1つのサブネットワークになります。

それで、おそらくService FabricはDockerと同じことを既に行っており、アドレス変換サービス(fabric://はファブリックスペースのプロセスのDNSのように機能します)に加えて(一部にとって重要)オンデマンドワーカー割り当て-巨大なスケーラビリティ特典。

  1. Service FabricはDockerを正常に置き換えることができますか?
  2. 視聴者を獲得し、受け入れられていますか?そうでなければ、最高の発明でさえ失敗する可能性があるからです。
27
doker

Docker(会社)はすべてのクラウドにクレームを賭けようとしているため、混乱を招きます。

  • Docker Engine(ほとんどの人が「Docker」と呼ぶ)はコンテナ化技術です。それはあなたに与えることができます
    • プロセス分離
    • ネットワーク分離
    • 一貫したアプリケーション環境
  • Docker Hubは画像レジストリです。 Dockerイメージが保存されるため、展開の一部としてダウンロードできます。
  • Docker CloudはDockerのオーケストレーションシステムです。それはあなたに与えることができます
    • アプリケーションを拡大および縮小する
    • アプリケーションを相互に接続します
    • Docker Hubと統合されたCIテスト(これはオーケストレーションの一部ではなく、別の機能です)

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コンテナーを実行できます。)

54

Service FabricとDockerコンテナー化の主な類似点:

  1. DockersとSFはどちらも、LinuxとWindowsの両方のプラットフォームで、マイクロサービスの実装から不変のイメージを作成できます。
  2. DockersとSFはどちらも、VMのクラスター内でコンテナー化されたアプリケーションを調整できます。これらのVMは、パブリッククラウド、プライベートクラウド、または独自のデータセンターのどこにでも配置できます。どちらもクラウドプラットフォームに依存しないため、どのクラウドサービスにも強い親和性はありません。したがって、マイクロサービス内でクラウド固有の機能を使用していない限り、これで問題ありません。
  3. DockersとSFはどちらも、オーケストレーションプラットフォームの重要な機能を発揮できます。サービスディスカバリー、サービスレベルの負荷分散、サービス間のネットワークレベルの分離、フェールオーバー処理、レプリケーション制御などです。

Service FabricとDockerコンテナー化の主な違い:

  1. Dockerコンテナは、基本的に展開/パッケージングの構成要素です。とは言っても、Dockerは、サービス実装の一部としてコンテナー内で何をパッケージングするかを決定するものではありません。 サービスの種類を実装するためのプログラミング構造も提供しません。一方、Service Fabricは、特定のサービスの種類宣言-ステートフルサービス、ステートレスサービス、仮想アクターからサービス実装を開始できるベースタイプ/インターフェイスの形式でプログラミング構造を提供します。
  2. Dockerの世界では、すべてがコンテナーです。つまり、最小展開/オーケストレーションユニットはコンテナーです。したがって、個々のプロセスを認識またはサポートしません。一方、SFには、ステートレス/ステートフルサービスから派生したマイクロサービスをプロセスとして調整および管理できる規定があります。ただし、SFはDockerと同じようにコンテナオーケストレーションもサポートしています。また、SFの最新バージョンでは、コンテナ内にステートフル/ステートレスサービスをパッケージ化できます。

上記の事実を念頭に置いて、SFはどのクラウドプロバイダーにも強い親和性を持たないことに注意してください。目的のプラットフォームでVMを作成できる限り、パブリッククラウド(Azure、AWS、GCP)で同様に実行できます。

2

それはまったく比較できません。サービスファブリックを使用すると、ヘルスモニタリング、ファブリックとのコード統合、ロギング、モニタリング、ロードバランシング、その他のインテリジェント機能を利用できます。アプリケーションはシャットダウンコードを実行することもできます。 Service FabricはMicrosoftテクノロジー専用ではなく、DockerもSF内に常駐できます。rktまたはUnix OSも同様です。セキュリティとネットワーク機能(Webアプリとインライン)はもう1つのプラスです。信頼できるコレクションは素晴らしいです。そして、より良いアプリケーションの構築とパフォーマンスへのロードマップは、それを採用している企業に保証されています(歴史はそう言っています)。

この質問は、「最大の発明」Dockerを強く支持しています。この比較はDockerマーケティングには役立ちますが、SFをDockerに置き換えるものはありません。 Dockerはほんの小さなOSコピーです(サービス、アプリケーション、またはインテリジェンスとは関係ありません)。 Dockerはアプリケーション開発とは関係ありません。それは意図ではありません。ただ、人々は孤立と共有の必要性を見つけ始めました。そして、それがDockerのすべてです。

1
Blue Clouds