ここで書いていないこと(はじめの前に)
タイトルから、VMWare/Hyper-V/KVMやクラウドの仮想マシンと、コンテナーの比較の記事に見えるかもしれないが、ここで書く仮想マシンはJava仮想マシン、.Net仮想マシン(CLR)を扱う。
はじめに
現在はコンテナーのブームであることはご存知だと思う。それはコンテナー・オーケストレーションであるKubernetesの登場で決定的になった。
コンテナーが目指していたことは、他の仮想マシンでも目指していた思想と一致する部分がある。
本記事ではそういうコンテナーで実現できたものと、過去の仮想マシンとの比較を記事にする。
コンテナーの目指しているもの
コンテナーはImmutable Infrastructureという考え方のもと、ポータビリティーのあるイメージを配布する仕組みをもつ。
このポータビリティーはコンテナが好まれる性質のひとつである。
過去の仮想マシンでもこのポータビリティーは大きな目標であったが、コンテナーほど大きなムーブメントにはならなかったように思う。
本記事ではそのあたりの歴史から、コンテナー・ブームを紐解く。
Java仮想マシン (第一章) - 最初に商用的に成功した仮想マシン
90年代半ばにインターネットのブームの中で、Sun MicrosystemsはJava言語を発表する。
その次代は、オブジェクト指向言語のブームの真っ只中で、Java言語はオブジェクト指向言語を、しかも、当時は珍しく無料で配布を配布を始めた。
JavaはどのOSでも動くという意味合いで、Write Once, run anywhere という標語も使った。Javaでコンパイルされた中間言語は、Java仮想マシンが動作するOSであれば、どれでも稼働した。
初期(第一章)のJava仮想マシンの成功に向けた推進には、後にJavaの衰退の起因のひとつが含んでいた。それはあくまでJava言語のみでコンパイルできることに拘ったことだ。
.Net
当時Microsoftは自社の技術に非常に拘っていて、Java言語の普及に対して、自社のソリューションを提供したいと考えていた。
そこで登場をしたのが.Netである。
.NetはCLR(Common Language Runtime)と呼ばれる仮想マシンのもとで稼働する意味では、Java仮想マシンと似ていた。
ところが、それ以外の戦略はJava仮想マシンとは別の方向を目指した。
- 言語は、Visual Basic .Net、C#、JScript .Net、F#など複数言語に対応させた。
- (当初は)実行環境はWindowsに限定した。
この言語の面で、ニュートラルな性質からPythonやRuby等多言語に対する.Netコンパイラも開発された。(IronPython、IronRuby)
多言語に対応する仮想マシンという意味合いでは、Java仮想マシンは、遅れている印象を与えた。
Java仮想マシン (第二章) - 多言語への対応
Javaは.Netの登場で、多言語化に向けて舵を切る。
特に2000年代半ばから、Webの開発にRuby on Railsのブームが始まり、軽量プログラミング言語 (LL) が大きくフォーカスされた。
必要に応じて、Java仮想マシンのスペックも拡張した。
PythonやRubyに対してはJythonやJRubyが登場した。
また、Java仮想マシン独自の言語もGroovy、Scala、Kotlin、Clojure等、現れた。
Kotlinは後にスマートフォンであるAndroidの推奨開発言語になるなど、一定の成功は収めたと思われる。
Java仮想マシン/.Net仮想マシンの現在
Java仮想マシンも.Net仮想マシンも、現在でも広く使われている。
現在のステータスとしては以下であると思われる。
- Java仮想マシンはいまだエンタープライズ・エリアやAndroideで多く使われている。
- .Net仮想マシンもWindowsでの開発ではいまだ多く使用されている。MicrosoftのCEOがナデラになって以降、Linuxへの対応にも注力しているが、十分に成功しているとは言えない。
- RubyやPython等のOSSの言語への対応に関してはいずれも開発が止まる/停滞する状態で、Java/.Netとも失敗したと言ってよい。これはRubyやPythonの言語の方向性と、こういった仮想化技術とが相容れなかったのだろうと推測する。
コンテナーの現在
その中、コンテナーが現れた。コンテナー技術を、上記の仮想化技術と比べてみる。
- コンテナーはLinuxで動く言語であれば、言語を問わない。
- コンテナーで作成したイメージは(Linuxで、かつ、CPUが同一であれば)どの環境でも動く。
- コンテナーを仮想化技術ということもあるが、仮想マシンとは異なり、中間言語を変換しながら仮想させるのではなく、ネイティブ・バイナリーが稼働する。
- コンテナーはLinuxの技術のため、あらゆる環境(OS)で稼働する技術ではない。(Windowsコンテナーという技術もあるが、あまり使用されてないので、本記事では無視する)
最後のLiunxでのみ稼働という点は、コンテナー技術の大きな弱点のひとつではある。WindowsやMac でのコンテナー稼働も、Hypervisorでの別環境でLinuxを動かして、実現している。
また、コンテナーのイメージはネイティブで稼働する性質上、CPUを選ぶ。これまではx86-64が主流だったが、MacBookのM1等、ARMもあり、実際は、複数CPUへの対応は難しい問題でもあると思われる。
上記のような弱点もあるが、Javaや.Netが中間言語への変換を考えることを比べると、Linuxで動く言語であれば、何でも稼働することは非常な利点がある。
このようにJavaや.Netで目指していたあらゆる言語での実行環境のポータビリティーはようやくコンテナーの登場で実現したと言える。
今後のことも考えると、コンテナーにフォーカスすることは正しい選択であるだろう。
・