それはさらに「Microsoftのプラットフォームに何が起きているのか」という核心に及んだ。Azureのデータが示している通り、「Microsoft loves Linux」というスローガンは単なる中身のない言葉ではない。

　クライアントサイドでは、Microsoftは「Windows Phone」を捨てて「iOS」と「Android」向けに独自のアプリケーションを開発する方を選んだ。「Microsoft Word for Android」は5億回以上ダウンロードされている。

Windows Subsystem for Linux

　もう一つの特筆すべき展開として、「Windows Subsystem for Linux」（WSL）と呼ばれるWindows 10の機能がある。これはLinuxバイナリコード（ネイティブELF64）をWindowsで実行できる素晴らしい技術だ。LinuxシステムコールはWindows APIに変換される。

　これでLinuxディストリビューション（「Ubuntu」「openSUSE」「SUSE Linux Enterprise Server」「Debian GNU/Linux」「Kali Linux」）をMicrosoft Storeからインストールできるようになった。この機能は誰でも利用できるとはいえ、対象は一般ユーザーではなくWindowsでLinuxツールチェーンや無数にあるコマンドラインユーティリティーを使う開発者だ。そして公式にサポートされたLinux GUI（グラフィカルユーザーインタフェース）はない。ただしハックすることはできる。

　Linux VMではなくWSLを使うことは、同じファイルシステムへのアクセスを含む密接な統合を意味する。WindowsからLinux実行ファイルを起動したり、WSLからWindows実行ファイルを起動したりすることもできる。

　WSLの狙いは、UNIX系のプラットフォームをターゲットとする開発者にとっての摩擦をなくすことにある。開発者はWindows 10を設定して、WSLでコンパイルと運用を行いながら、Windows側でコードエディタ（「Visual Studio Code」を含む）を実行できる。

　Microsoftは徐々にWSLの改善を図っており、最新バージョン（2018年4月のWindows 10更新プログラムに含まれるビルド1803）には多数の機能強化が盛り込まれた。その中には、ディレクトリごとに大文字と小文字が識別できるファイル名のWindows側およびLinuxでのサポート、UNIXドメインソケット、バックグラウンドタスク、WindowsとWSLの間でパスの名称を変換できるユーティリティーなどが含まれる。

　Visual Studio Codeを「Node.js」と併用している開発者は、設定ファイルで「useWSL」の属性をtrueに設定するだけでWSLをターゲットにできる。

クロスプラットフォームの.NETと、Visual StudioでのLinux向け開発

　Microsoftは「Visual Studio」でLinuxやクロスプラットフォームプロジェクトをターゲットにできるようにするために、複数の取り組みを進めてきた。必ずしもWSLを有効にする必要はない。2014年末に同社が発表した「.NET Core」は「.NET Framework」から分岐したオープンソース製品で、Windows、Linux、Macで実行できる。現行版のバージョン2.1ではArmベースの「Raspberry Pi」がサポート対象に加わった。

　実際に、.NET Coreは「ASP.NET Core」「Entity Framework Core」などのフレームワークでもサポートされている。いずれも現行バージョンは2.1だ。

新たな投資

　Microsoftは今もWindowsオンリーの.NET Frameworkをサポートしているが、新たな投資は.NET Frameworkではなく.NET Coreにすると同社は言明している。

　BuildでMicrosoftは、今後登場予定の「.NET Core 3.0」ではWindowsデスクトップアプリケーションをサポートすると発表した。これは.NET Frameworkをレガシーサポートの役割へと追いやる方向に向けた重要な一歩といえる。

　ただし.NET Coreは.NET Frameworkの機能の一部しかサポートしていない。「ASP.NET Web Forms」「Windows Communication Foundation」（WCF）、「Windows Workflow Foundation」のサポートが省略されていることには注意する必要がある。

　.NET Coreには「C#」への偏りもある。「Visual Basic」や「F#」もサポートされてはいるが、全種類のプロジェクトには対応していない。

　.NET Coreを使うべき有力な理由もある。一般的にはパフォーマンスが優れている方がよい。.NET Coreはマイクロサービスを念頭に設計されていて、LinuxとWindowsの両方のコンテナで快適に動作する。

　Visual StudioにおいてASP.NET CoreでLinuxコンテナをターゲットとするためには「Docker for Windows」をインストールするだけで済む。Docker for Windowsは「Hyper-V」の仮想化機能を使っており、右クリックメニューでDocker Linuxのサポートを同アプリケーションに追加する。MicrosoftはLinux向けの「SQL Server」も提供するようになった。

クロスプラットフォームモバイル

　現代では、開発者はPCではなくスマートフォンや「iPad」「Chromebook」のためのコードを書かなければならないことがある。

　このエンドツーエンドスタックをターゲットとするために、Microsoftはクロスプラットフォームモバイル開発ツールが必要になり、2016年初めにiOSとAndroid向けのC#コンパイラを入手する目的でXamarinを買収した。

　Xamarinコンパイラは、.NET Frameworkの初期のオープンソースインプリメンテーションである「Mono」をベースとしている。Microsoftは現在、Xamarinと.NET Coreとの間でできるだけ多くのコードを共有しようと努めている。

　開発者はXamarinを使い、共有型の非ビジュアルコードを開発してそれを各プラットフォーム向けのネイティブGUIと組み合わせるか、あるいはXamarin Formsと呼ばれるアブストラクションを使ってGUIコードも共有することができる。いずれもネイティブプラットフォームGUIコントロールを使うアプローチであり、カスタム描画でそれをエミュレーションするアプローチではない。

　Buildカンファレンスでは、Xamarinチームが「Android Emulator」をHyper-Vでサポートするプレビューを披露した。これで開発者にとっての悩みの種が解決される。これまではAndroid Emulatorを使うためにIntelのHAXMを有効にする必要があったが、HAXMとHyper-Vは共存できないため、Hyper-Vを無効化しなければならなかった。

　XamarinはMacデスクトップもターゲットにできる。ただしVisual Studioからではない。macOSのターゲティングは、例えば「Visual Studio for Mac」を使うなど、Mac上で行わなければならない。

モバイル開発用のオプション

　Visual Studioを使ったモバイル開発には他のオプションもある。Microsoftは「JavaScript」（あるいはJavaScriptのスーパーセットである「TypeScript」）とHTMLで開発されたアプリ用に、「Apache Cordova」向けのツールを提供している。

　開発者は「C++」でコードを書いて、iOSやAndroid向けにコンパイルすることもできる。

マイクロサービス

　MicrosoftのLinuxサポートは、マイクロサービスやDevOpsの展開の要でもある。

　同社がクラウドネイティブアプリケーションのことを語る場合、それはアプリケーションをマイクロサービスに分解して簡単に拡張できることを意味する。

　マイクロサービスは一般的にコンテナも示唆するが、「Azure Functions」というサーバレスプラットフォームもある。データベースサーバをホスティングする代わりに「Azure SQL Database」や「Azure Cosmos DB」（MicrosoftのNoSQLデータベース管理ツール）のような管理型サービスを活用すればメンテナンスの負担を軽減でき、開発者はそうしたAzureサービスに内蔵された拡張性を活用できる。

MicrosoftのLinux戦略

　Windows開発はニッチな行為になり、Microsoftのプラットフォーム上でさえもLinuxが主流になるのだろうか。

　同社にはまだ、「Active Directory」や「Exchange」「Dynamics」、SQL Serverなど他のサーバ製品と密接に統合された「Windows Server」を推進する強いインセンティブがある、というのがその答えだ。

　これはむしろ、パブリックWebアプリケーションは既にLinuxに独占されているものの、もし顧客がAzureで運用しているのであれば、推奨されるOSに関係なく同社が繁栄できるということをMicrosoftが認識していることを物語る。

　Microsoftにとっての利点は、「Java」や「PHP」、Node.js、あるいは他の技術を使っている開発者に、Windows上で運用する摩擦を感じさせずにクラウドサービスを提供できる点にある。

　もっともMicrosoftのコンテナ事情は、恐らく混乱を招くほどに多様だ。開発者は以下に示すようなさまざまな方法でコンテナを運用できる。

「Azure Container Instance」（ACI）

　このサービスは2018年4月にプレビュー版を脱した。ユーザーはVMやクラスタ（サーバレスモデル）を作成せずに、WindowsまたはLinuxコンテナを自動拡張機能付きで作成できる。料金はCPUとメモリ利用に対して秒単位で課金される。

　「顧客からは常に、ACIはバーストワークロードの処理に適しているという声が寄せられる。ACIは、迅速でクリーンにパッケージされたバーストコンピューティングをサポートしており、クラスタマシンを管理する間接費が取り除かれる」。サンダース氏はブログにそう記している。

「Web App for Containers」

　Web App for Containersは、「Web App Service」と同じモデルでコンテナをデプロイできる。

　設定や拡張、負荷分散は容易だが、真のサーバレスではない。料金は利用しているかどうかを問わず、稼働しているものに対して支払う。ただし自動スケーリングのためのルールを設定することはできる。単一のWeb App for Containersで複数のコンテナを運用することも可能になった。

「Azure Kubernetes Service」

　ホスティング型の「Kubernetes」サービスによって調整されたLinuxコンテナで、ユーザーはコマンドラインを使用するか、Azureポータル経由でクラスタをデプロイする。Kubernetesには自己修復の設定、拡張、負荷分散、自動ロールバック（必要があれば）、ストレージ管理などのメリットがある。

「Azure Service Fabric」

　Azure Service Fabricはマイクロサービス管理のためのランタイムで、WindowsとLinuxコンテナの両方に対応している。

　Kubernetesが業界全体で広く使われているのに対し、Azure Service FabricはMicrosoft独自のサービスだが、Azureだけではなくオンプレミスでも運用できる。

　Azure Service Fabricはデプロイ、モニター、アップグレード、拡張などを管理できる。ステートフルサービス用に「Reliable Actors」というアプリケーションフレームワークをサポートしている。

　Buildで発表されたAzure Service Fabric Meshのプレビュー版は、サーバレスアプローチを支持してクラスタ管理の必要性をなくしている。

「Azure Batch」

　ユーザーはLinuxまたはWindowsを使ってバッチコンピューティングでコンテナを運用できる。

　デバイスの選択を合理的にする助けになっているのが「Azure Container Registry」（ACR）だ。

　このサービスはDocker Registryと互換性のあるAPIを使っており、開発者はコンテナイメージを管理して、それを上記の全サービスにデプロイできる。

　これでコンテナをACRにプッシュし、ACRデプロイからプロダクションへとプッシュする継続的インテグレーションと継続的デリバリー（CI/CD）のプロセスをセットアップすることが可能になった。