Everything is a Matter of Degree

Learning logs of the transition from Web to Enterprise

(拙訳).NET Core と .NET Framework のどちらを選ぶべきか

.NET Core の勉強をしようかと、とりあえずダウンロードページに行ってみた際に、.NET Core と .NET Framework どちらを選ぶべきかの説明が日本語化されていなかったので、ざっと訳してみた。

元記事はこちら docs.microsoft.com

要約すると、

  • .NET Core に存在しない機能や NuGet ライブラリに依存してる場合は .NET Framework を使う
  • または、既存のアプリで .NET Framework 使ってるものは無理に移行する必要なし
  • 新しいアプリ作るなら .NET Core で

といった感じ。以下拙訳です。

サーバアプリケーションにおいて .NET Core と .NET Framework のどちらを使用するか

.NETでサーバサイドアプリケーションを開発する際、 .NET Framework と .NET Core という二つのランタイムの選択肢があります。どちらも多くの .NET プラットフォームのコンポーネントを共有しており、書いたコードも両者で共用できます。しかし、両者には根本的な違いがあり、用途によって使いわけることになります。本記事では、どのような場合にどちらを使うべきかを説明します。

以下のようなケースでは、サーバアプリケーションに .NET Core を使うべきです:

  • クロスプラットフォームの必要がある場合
  • マイクロサービス化する場合
  • Docker コンテナを使う場合
  • 高性能でスケーラブルなシステムなシステムの場合
  • アプリケーションによって .NET の複数バージョンが共存する場合

一方、以下のようなケースではサーバアプリケーションに.NET Coreを使うべきです:

  • クロスプラットフォームの必要がある場合
  • マイクロサービス化する場合
  • Dockerコンテナを使う場合
  • 高性能でスケーラブルなシステムなシステムの場合
  • アプリケーションによって.NETの複数バージョンが共存する場合

どのような場合に .NET Core を選ぶべきか

前述した .NET Core を選択する理由について、以下でより詳細に説明します。

クロスプラットフォームの必要性

もし複数のプラットフォーム(Windows, Linux, macOS)で動作するアプリケーションを作るのが目的であれば、明らかに .NET Core を選択すべきです。

.NET Core は上記 OS を開発環境としてもサポートしています。Windows には IDE として Visual Studio が提供されています。また、macOSLinuxWindows では Visual Studio Code を使用することもできます。Visual Studio Code は、IntelliSense とデバッグ機能を含む .NET Core を完全にサポートしています。さらに、オープンソースの Omnisharp プロジェクトを使用して IntelliSense を有効にし、SublimeEmacs、Vi などのサードパーティのエディタを .NET Core 向けにすることもできます。あるいは、コードエディタを一切使用せず、サポートされるプラットフォームすべてで利用可能な .NET Core コマンドラインツールを直接利用することもできます。

マイクロサービスアーキテクチャ

もし独立した、スケーラブルで、ステートフルまはステートレスな複数のマイクロサービスからなるマイクロサービス指向のシステムを採用しているのであれば、.NET Core が一番の候補となります。.NET Core は軽量で、マイクロサービスのスコープに向けた API 面を最小化することができます。また、マイクロサービスアーキテクチャはサービス境界をまたで、複数のテクノロジを混在させることができます。例えば、.NET FrameworkJava, Ruby, その他モノリシックなテクノロジで開発されたマイクロサービスやサービスとの連携して動作する新しいマイクロサービスを追加することで、.NET Core を段階的な採用することが可能になります。

使用できるインフラはたくさんあります。大きく複雑なマイクロサービスシステムにおいては、Azure Service Fabric を使用できます。ステートレスなマイクロサービスでは、Azure App Service 等の他のプロダクトも利用できるでしょう。次に説明するように、Dockerベースのマイクロサービスの代替手段は、どのような種類のマイクロサービスのアプローチにもフィットします。これらのすべてのプラットフォームは .NET Core をサポートしており、マイクロサービスをホスティングするのに最適です。

コンテナ

コンテナはコンテナ化されたあらゆるアーキテクチャの Web アプリケーションやサービスで使用できますが、一般的にはマイクロサービスアーキテクチャのシステムにおいて用いられます。将来的には .NET Framework も Windows コンテナ内で使用できるようになるとはいえ、.NET Coreはその本質たるモジュール性と軽量さから、コンテナにぴったりです。コンテナを作成、デプロイするとき、そのイメージサイズは、.NET Framework より .NET Core のほうがはるかに小さくなります。またクロスプラットフォームなので、サーバアプリケーションを例えば Linux の Docker コンテナにデプロイすることもできます。

Docker コンテナは自前の LinuxWindows インフラでホスティングすることもできますし、あるいはAzure Container Service のような、クラウド上でコンテナアプリケーションを管理、オーケストレーション、スケールすることができるサービスを利用することもできます。

高性能でスケーラブルなシステムの必要性

もしシステムに最高のパフォーマンスとスケーラビリティが必要な場合、.NET Core と ASP.NET Core が最善の選択肢です。ASP.NET Core は ASP.NET の性能を10倍上回り、Java サーブレットや Go 言語、Node.js など、マイクロサービス向きの他の人気のある技術を一歩リードしています。このことは、サービス数が何百にもなりうるマイクロサービスアーキテクチャでは特に重要です。ASP.NET Core を使うことで、システムをはるかに少ない数のサーバ/VM で運用することができ、それが最終的にインフラコストの削減につながります。

アプリケーションごとに異なる .NET バージョンの必要性

もし複数の異なったバージョンのフレームワークへの依存性をもつアプリケーションをインストールできるようにしたい場合、100%共存可能な .NET Core を使う必要があります。一つのマシンに、異なるバージョンの .NET Core をかんたんに共存インストールすることができるので、それぞれ異なるバージョンの .NET Core を使用した複数のサービスを同じサーバで実行することが可能となり、それによってアプリケーションのアップデートや IT 運用におけるリスクを取り除き、コスト削減も削減できます。

どのような場合に.NET Framework を選ぶべきか

.NET Core が新しいアプリケーションやアプリケーションパターンには大きなメリットをもたらすのに対し、.NET Framework は今後も多くの既存シナリオにおいて自然な選択肢であり続けるでしょう。そのため、サーバアプリケーションにおいて、.NET Framework がすべて .NET Core に取って代わられるということにはならないでしょう。

既存の .NET Framework アプリケーション

多くの場合において、既存のアプリケーションを .NET Core にマイグレーションする必要はないでしょう。それよりも、ASP.NET Core で新しいWebサービスを追加するなど、既存のアプリケーションを拡張するときに .NET Core を用いることをおすすめします。

.NET Core で利用できないサードパーティ .NET ライブラリや NuGet パッケージを利用する必要性

多くのライブラリは迅速に .NET 標準への対応を進めており、これにより .NET Core を含むすべての .NET 製品群でコードを共通化できるようになります。さらに、 .NET 標準 2.0 では .NET Core の API が大変充実し、.NET Core のアプリケーションは既存の .NET Framework ライブラリを直接利用できるようになるため、よりかんたんにコードを共通化できるようになります。とはいえ、この移行対応はすぐに完了するわけではないため、方針を決める前に、あなたのアプリケーションで必要となるライブラリの状況を確認することをおすすめします。

.NET Core で利用できない .NET テクノロジの必要性

いくつかの .NET Framework のテクノロジは、.NET Core では利用できません。その中には、今後の .NET Core のリリースで利用できるようになる予定のものもありますが、.NET Core が対象とするアプリケーションパターンには当てはまらないテクノロジは、永久に利用できないかもしれません。NET Core 1.0 で利用できないテクノロジの中で、有名なものを以下に示します:

  • ASP.NET Web Forms のアプリケーション: ASP.NET Web Forms は .NET Frameworkで のみ利用可能で、ASP.NET Core や .NET Core を利用することはできません。今のところ、ASP.NET Web Forms を .NET Core に取り入れる予定はありません。
  • ASP.NET Web Pages のアプリケーション: .NET Coreのロードマップ に示されているとおり、将来的には ASP.NET Web Pages は ASP.NET Core に含まれるようになる予定ですが、ASP.NET Core 1.0 では、まだ取り込まれていません。
  • ASP.NET SignalR のサーバ/クライアント実装: .NET Core ロードマップで説明されているように、将来のリリースには含まれる予定ですが、.NET Core 1.0 のリリースタイムフレーム(2016年6月)では、ASP.NET Core はクライアント、サーバともに ASP.NET SignalR を使用できません。サーバサイドおよびクライアントライブラリGitHubリポジトリで、プレビュー版を利用できます。
  • WCF サービスの実装: .NET Core の WCF サービスを利用するWCF クライアントライブラリがあったとしても、2016年6月時点では WCF のサーバ実装は .NET Framework のみで利用可能です。今のロードマップに含まれてはいませんが、将来に向けて検討されているところです。
  • Workflow 関連のサービス: Windows Workflow Foundation (WF)、Workflow Services (一つのサービス内のWCF + WF)、WCF Data Services (以前は“ADO.NET Data Services”と呼ばれていたもの)は、.NET Framework のみで利用可能です。 .NET Core への移植予定はありません。
  • 言語サポート: 今のところ Visual Basic と F# は .NET Core でサポートされていませんが、Visual Studio 2017 とそれ以降のバージョンではどちらもサポートされる予定です。

正式なロードマップに加えて、.NET Core に移植される他のフレームワークもあります。詳細については、“port-to-core”というマークのついた CoreFX の issue を参照してください。このリストは、Microsoft からこれらのコンポーネント .NET Core に提供すると約束するものではなく、単純にコミュニティの要望を取り込んでいるだけです。もしその中に気になるコンポーネントがあるなら、あなたの意見がわかるように GitHub 上での議論に参加することを検討してください。あるいは、もし何か足りないものがあると思ったら、CoreFX リポジトリに新しい Issue を作成してください。

.NET Core をサポートしないプラットフォームを利用する必要性

マイクロソフトサードパーティのプラットフォームの中には、.NET Core をサポートしないものもあります。例えば、Service Fabric Stateful Reliable Services や、Service Fabric Reliable Actors などのAzureサービスは .NET Framework を必要とします。他のサービスの中には、.NET Core ではまだ使用できない SDK があります。すべての Azure サービスは .NET Core を使用しているため、これは過渡的な状況です。その間、クライアント SDK の代わりに REST API をいつでも使用できます。

さらなるリソース