こんにちは。R&D本部の小林です。
私はプラットフォームチームで基盤設計・開発のアーキテクトをしています。
今日はecbeing labs３回目のエントリーです。
ちょっと煽り気味なタイトルで書いてみましたが、やばいのか・やばくないのか、考えるきっかけになれば幸いです。
当社では、社名となっているEC構築パッケージ「ecbeing（イーシービーイング）」をはじめ様々なWebアプリケーションを .NET Framework で開発しています。当社のビジネスにとって.NET Frameworkは重要な位置づけでした。
そんな .NET Framework に大きな変革の波が押し寄せてきています。
それが「.NET Core」です。今日は .NET Core の紹介と、当社がどのように取り組もうと考えているかを紹介したいと思います。
まず .NET Core について、以下の３つの大きな特徴を簡単に紹介します。
- クロスプラットフォーム
- オープンソース
- Microsoft によるサポート
クロスプラットフォーム
.NET Core で開発したプログラムは、Windows、Linux、macOSで実行可能です。
これまで .NET Framework で積み上げてきたソフトウェア資産の多くが、クロスプラットフォームで再利用できるようになりました。
クロスプラットフォームだけでしたら「Javaでいいじゃん」というツッコミが来てしまうのですが、さらに .NET には C# や VB.NET という開発言語の選択肢の幅も持ち合わせています。これによってクロスプラットフォーム＆単一言語であるJavaよりも多くのエンジニアを受け入れる器があるのです。
クロスプラットフォームの実現には .NET Standard という「実装と仕様の切り離し」が鍵を握っています。
.NET Standard は、.NET Framework が備えていた「名前空間、クラス、プロパティ、メソッド」といったインターフェースをAPI仕様として定めたものです。
そして .NET Standard の実装が .NET Framework であり、.NET Core であり、Xamarinといった具合に派生されています。これらを .NET 実装と呼びます。
.NET Standard と .NET 実装をクラス図にすると以下のような関係になります。
.NETには、Javaに対するJVM（Java Virtual Machine）と同じように実行エンジンがあります。
これをCLR（Common Language Runtime）と呼んでいます。CLRを前の図に追加すると以下のようになります。（Xamarinはよくわからないことになっているので省略）
.NETのアプリケーションの開発では .NET Standard というAPI仕様、すなわち抽象に依存したクラスライブラリを作ることができます。オブジェクト指向について学んだことのある方なら「抽象に依存する」というキーワードにピンと来るところがあると思います。
.NET Standard という抽象に依存したクラスライブラリを作成することで、.NET Core、.NET Framework、Xamarin で動作するソフトウェアコンポーネントを開発することができるのです。
簡単なルールに沿って開発するだけで超巨大なエコシステムの部品をつくることができる。これはすごいですね！
※.NET Standardにもバージョンがあります。.NET Standardのバージョンと、.NET実装の対応関係はしっかり把握しておきましょう。
※.NET エコシステムを支える柱の一つにNuGet（ぬげっと）というパッケージマネージャーがあります。NuGetについては後日このブログで紹介していきたいと思います。
オープンソース
オープンソースの利点として、その実装の透明さがあります。バグに遭遇しても自分で原因を発見し、修正することができます。
オープンソースにリスクが無いとは言えませんが、圧倒的大多数の善意のエンジニアによる監視の目が行き届いている限りには安全です。
オープンソースは学習者にとって素晴らしいリソースになります。.NETのソースコードを眺めるだけでも多くの学びがあります。
なお、日本語圏には独自の問題が付き物です。.NET Frameworkでは過去にSMTPのメール送信まわりの仕様に悩まされた時代がありました。
グローバルな視点で物事を考えて進める企業にとっては、日本語圏の独自の問題は後回しにならざるを得ません。でも、オープンソース化のおかげでそのようなリスクを恐れる必要がなくなりました。
Microsoft によるサポート
オープンソースのコミュニティは非常に重要です。
グローバルな大企業が後ろ盾のオープンソースなら、簡単には放棄されることはありません。
Google、Amazon、Facebook、Microsoft、Appleなどの大企業がコミュニティを支えていれば安心です。
当社は大手の企業様にも導入いただいているECサイト構築パッケージを開発しています。
そして、Microsoftのサーバー製品を利用し、開発製品を導入し、クラウドを利用しています。
当然ながらMicrosoftからビジネス向けサポートを得ています。Microsoftのサポートは当社のお客様への責任を果たすうえで重要な役割を担っています。
もちろん .NET Framwork と同様に .NET Core もサポートを受けることができます。
.NET Frameworkはどうなるの？
.NET Core をすぐにでも全面的に採用したいところではありますが、.NET Core には .NET Framework に含まれていた以下のような .NET テクノロジをまだ利用できません。
- Windows Form
- Windows Presentation Framework
- Windows Workflow Foundation
- Windows Communication Foundation (サーバー実装)
- ASP.NET WEB Form
現在 .NET Framework で作られたコードには、.NET Core に移植できないコードがあるということです。.NET Framework のコードを .NET Core に移植するのは、今やるべきことではありません。
Microsoftは、.NET Framework を引き続きサポートしつづけると明言しています。もう少し様子を見た方が良いでしょう。
.NET Core は「クロスプラットフォームの.NET実装」であったのに、.NET Core 3.0（2019年3月時点ではPreview）から以下のような、Windowsプラットフォーム限定の .NET テクノロジにも拡張をはじめました。
- Windows Form
- Windows Presentation Framework
これは .NET Framework のサポート終了に向けた布石ではないかと感じています。
.NET Core がWindowsプラットフォーム前提の領域に拡張を続けるのであれば、.NET Framework のコードはもっと .NET Core に移植しやすくなっていくことでしょう。
新しいアプリケーションは.NET Frameworkでも良いだろうか？
もし新しいアプリケーションを作成するのだとしたら、.NET Core を強く推薦したいと思います。
.NET Core で書いたアプリケーションは、あらゆるプラットフォームで動作可能で、どのクラウド事業者でも実行可能で、Microsoft による強力なバックアップ体制のもと、世界中のエンジニアが .NET Core の発展に貢献しています。
.NET Framework はOSの一部分として巨大化し、歩みが遅くなってしまいましたが、.NET Core は猛烈なスピードで進化しています。.NET Core は非常にコンパクトであり、必要なものだけを追加可能であり、Dockerに簡単に乗せることができます。
今日はDockerの話はしませんでしたが、当社では .NET Core をDockerで動かす新しいアプリケーションの開発を進めている最中です。次回は .NET Core とDockerへの取り組みについてご紹介したいと思います。
まとめ
いまどき .NET Core を使っていなくても...やばくないです。
ただ、.NET Core への移行に向けて、新しいクラスライブラリは .NET Standard でつくっておくと良いでしょう。
新しいアプリケーションは .NET Core を選びましょう。
それでは、今日はここまで。
小林
～私たちと一緒にプロダクトを開発する仲間を募集中です！！～
