RE:INVENT「.NET オープンソースには資金が著しく不足していることがわかりました」と、AWS ソフトウェア開発マネージャーの Saikat Banerjee 氏は今週の re:Invent セッションで語った。
「.NETオープンソースの残念な点は、いまだにサードパーティオープンソースと呼んでいることです。そうあるべきではありません。」
このセッションで、AWS は、プロジェクトへの資金提供と AWS クレジット、Windows 専用 .NET Framework からのツールの移植、Windows Communication Foundation (WCF) フレームワークをクロスプラットフォーム .NET に移植するためのコード貢献、Linux コンテナから Active Directory 接続を可能にするコードなど、オープンソース .NET のサポートについて説明しました。
なぜこのクラウド界の巨人は、Microsoftの技術にこだわるのだろうか？AWSシニアプロダクトマネージャーのマユール・デワイカー氏は、「過去2年間、お客様がWindowsやSQL Serverのライセンスから解放され、Linuxやクラウドネイティブ技術を利用できるよう、.NET Frameworkから.NET Coreへの移行に多くの時間を費やしてきました」と語る。
AWS が .NET を好む理由を説明する re:Invent のスライド (クリックして拡大)
.NET Core（現在は正式には.NET）は、オープンソースのクロスプラットフォーム版で、2016年に初めてリリースされました。アプリケーションの移植は必ずしも簡単ではありません。COMやその他のネイティブWindows APIを呼び出すアプリケーションはLinuxでは動作しません。また、ASP.NET Web FormsやWindows Communication Foundation (WCF)の大部分など、.NET Frameworkの一部は.NET Coreに含まれていません。
AWSがMicrosoftの開発プラットフォームの一部に投資することで、顧客の他の部分からの移行を支援するというのは、奇妙な状況です。Microsoftが設立した.NET Foundationは「.NETプラットフォームを中心とした革新的で商業的にも友好的なオープンソース・エコシステムを支援するために設立された独立した非営利団体」と謳っていることを考えると、.NETオープンソースへの資金不足という主張も意外に思えるかもしれません。AWSは、わずか10社の企業スポンサーのうちの1社としてリストされています。
しかし、オープンソース .NET の道のりは平坦ではありませんでした。昨年は、ある取締役が「プロジェクト管理者の信頼を裏切った」と認めるなど、一連の事件が発生しました。Microsoft が Visual Studio の利益のためにオープンソース .NET から削除した .NET 機能をめぐる論争（その後、謝罪して機能を復活させた）は、.NET のオープンソース性に対する同社の曖昧な態度を改めて浮き彫りにしました。
とはいえ、Microsoftの.NETチームはこのプラットフォームに多大なエネルギーを注いでおり、技術レベルではAWSを含む外部コントリビューターの取り組みを歓迎しています。注目すべき例の一つがWCFへの取り組みです。「Core WCFプロジェクトは、MicrosoftのWCFチームの開発者によって開始されました」とBanerjee氏は述べています。「私たちは開発の非常に早い段階でその開発者とつながり、それ以来ずっと協力して取り組んでいます。このプロジェクトでは、Microsoftと足並みを揃えています。」
- マイクロソフトがSurface以外のPCを出荷：開発者向けの安価なArmボックス
- Microsoft 志向の Linux 開発者の皆様へ: .NET 6 は Ubuntu 22.04 に搭載されています
- .NETの20年: Microsoftの非Javaを振り返る
- GNOME、Mono、Xamarin の創設者 Miguel de Icaza 氏が Microsoft を退職
Banerjee氏によると、AWSは「WCFの限界をそのままにしておくのではなく、改善」しようとしているとのことだ。その取り組みには、HTTPバインディングのフェデレーションIDサポートや、Microsoft Message Queue（MSMQ）に加えてRabbitMQやAmazon SQS（Simple Queuing Service）といった「他のメッセージブローカーも含める」ためにWFCメッセージキューのサポートを拡張する取り組みも含まれる。
「私たちは、そのメッセージング フレームワーク用のレイヤーを提供する設計に貢献しました。そのため、使用したいメッセージング フレームワークの実装を提供できます。」
もう一つの重要な分野はActive Directory（AD）です。「今年取り組んでいるプロジェクトの一つは、LinuxコンテナからのAD接続です」とBanerjee氏は述べています。「お客様がモダナイゼーションを始めると、ADが組織全体を繋いでいるため、ADから離れるのは難しいとおっしゃいます。」
Windows ADでは、グループ管理サービスアカウント（gMSA）がアプリケーションサービスのアカウントとしてよく使用されます。「これはLinuxに移植可能な優れたアーキテクチャです」とBanerjee氏は述べています。AWSは、認証情報フェッチャーと呼ばれるコンポーネントを開発しました。「これはLinuxインスタンス上に存在するデーモンです」と彼は言います。これにより、LinuxコンテナでgMSAを使用できるようになります。
一部の.NETアプリケーションがWindowsに依存し続ける3つ目の要因は、ASP.NET Webフォームアプリケーションです。「顧客がWebフォームアプリケーションを.NET Coreに移植する方法はありません」とBanerjee氏は述べています。
AWSはLinux向けのWebフォーム実装は行っていないものの、.NET向けPorting AssistantにWebフォームからBlazorへの機能を追加しています。Blazorは.NET Coreで動作するWebアプリケーション技術です。「これはまだ完成には程遠いため、コミュニティの皆様のご協力をお願いしています」とBanerjee氏は述べています。チームはまた、WebフォームアプリケーションをAngularJSまたはReactJSに移植するオプションも検討しています。
サーバーレス.NET、特にLambda関数は、もう一つの厄介な問題を抱えています。「お客様から、.NETでLambda関数を起動すると、コールドスタートの問題が頻繁に発生するという話を聞きました。問題は、関数を実行するたびに.NETランタイムをロードする必要があるだけでなく、JIT（ジャストインタイム）コンパイラが毎回起動して.NET中間コードをネイティブコードにコンパイルするため、これもまた時間がかかることです。」
最近の.NET 7リリースにおける解決策は、AOT（Ahead of Time）コンパイルです。AWSはこれを受けて、Lambda関数にネイティブAOTコンパイル機能を追加する.NET向けLambdaツールの開発に取り組んできました。新たに発表されたLambda向けのSnapStartテクノロジーも、この課題の解決に役立つ可能性がありますが、現時点ではJavaのみのサポートとなります。
コミュニティ側では、AWS は最大 10 件のコミュニティ プロジェクトに対してそれぞれ最大 5,000 ドルと AWS クレジットを提供しています。
「現在、AWS でのアプリ開発において、.NET は Python と Java に次いで 3 番目に人気のあるプラットフォームです」と Dewaikar 氏は言います。
MicrosoftのAzureクラウドが.NETアプリケーションに適しているとしても、AWSを標準化している企業は、.NETコードを他のクラウド環境と並行して実行したいと考えるかもしれません。しかし、Windowsを.NETから排除するこうした取り組みは、Azureユーザーにもメリットをもたらします。なぜなら、Azureでも同様な議論が数多く当てはまるからです。Linux VMやアプリサービスはコスト効率が高く、Linuxコンテナの使用はKubernetesの導入に役立ちます。これがオープンソースの本質であり、AWSからの投資はMicrosoftの顧客にとっても有益です。®
