※この記事は、自分の意見や View をまとめるための駄文です・・・
最近、PaaS の代名詞でもあった Pivotal社 が 2019年末に VMware に買収されていた事を知りました。元々 VMware から独立したので出戻りになります。
VMware の Kubernetes (k8S) 製品群のブランドである Tanzu の一部として組み込まれる事になったようです。
Pivotal が独立した当時は、世界は IaaS から PaaS の世界に向かっていく。と言うビジョンがあったと思いますが、PaaSの世界の一本だけでやはり厳しかったのかもしれません。
デファクトスタンダードになるには、Open Source である必用があり、なので VMware から飛び出した。というような見方をしていました。
でも、その後、インフラの世界はいろいろな概念が出てきてシンプルな進化は遂げませんでした。
例えば、数年前だと AWSのラムダが流行らせたサーバーレスや FaaS (Function As a Serivce) という概念があります。
世間的に細かい定義はあるのかもしれないのですが、私的にはこれは PaaSに含めてしまっていいかなと思っていたりします。
ただ、FaaS が受けたのは、システムがパブリッククラウドに取り込まれるにしたがって、パブリック・クラウドのサービス間の隙間を埋める「ちょっとした」機能が欲しかった。というのが私の印象です。
AWS Lambda で使ったコードを、GCP の Cloud Function で使えるかというそういう移植性は基本的にないので、FaaSというのは移植性の無い(弱い) PaaS という側面もあると思います。
でも一番 FaaS の本質を表せるのは、特定のパブリック・クラウドの疎結合なサービス間を埋めるためだったり、サービスの機能を拡張するために生まれた PaaS (時々 SaaSレベル) という言い方が本質を表しているかな。と思います。(SaaS レベルと感じるのは、例えば「S3にあるファイルがおかれたときに、ＸＸな処理をする」みたいな、完全に S3を前提にしていたりすると「SaaS」感を感じるからです）
FaaSは、何かと聞かれた時に・・・
- 使われているテクノロジー面での切り口 → PaaS / SaaS である。
- 実現したかった事の切り口 → 特定のパブリック・クラウドの疎結合なサービス間を埋める/ サービスの機能を拡張する
(と、この文章を書きながら仮結論にしてみました。こういうのはいろんな見方があり、その人の触れる事のできる情報によって変わるのであくまで私の個人ビューという事で・・・）
PaaS で歴史が長いと言えば、GAE (Google App Engine) があります。これを 早すぎた FaaS とみる向きもありますが、コードだけ作って後はお任せします。という発想は、大半のエンジニアは生理的に受け付けにくく、流行らないかなと思っていました。コードさえ書けばスケールを気にせず実行してくれる。というアイディアは素晴らしいのですが、なんでも深く知りたるエンジニアの気質としては、すこし居心地が悪い感じを受けたのも事実です。
エンジニアの生理的な感覚で自分の作ったものは、どこの環境でも動くようにしておきたい。という感覚があるはずで、それが特定の PaaSプラットフォームに依存した形になり、そこのレベルはブラックボックスというのは、気持ちが悪いような・・・この呪縛から解き放たれるには時間がかかるかなと思っていました。
とは言え、昨年、金融関係のシステムの案件で「GAEを使って設計してるんですよ」というエンジニア（というかＣＴＯというか・・・）出会いました。そのシステムはいろいろなビジネス環境の変化で無くなったのだが、GAE 自体は浸透しているのかもしれません。
PaaSは今後も無くなりはせず、適材適所で使われるものである。というのが継続していくのかな。と思っています。
Docker と Kubernetes の登場
現在もそうかもしれませんが、エンジニアは、Virtual Box や VMware を使ってアプリを動かす環境を自分の開発マシンの上に作りがちだと思います。
但し当時一般的だった、仮想マシンは起動が重たく、ディスク容量も食べるため、みんなディスク容量を気にしながら運用していました。私はUSBの外付け HDDに昔の仮想マシンを次々と追い出していく。というような運用をしていました。
そんな中、Docker が登場しました。
「Dockerはいつリリースしたんだっけ？」と思って Wikiを調べて見ると 2013年3月13日が初版の正式リリースになっています。
当時は「Dockerには sshでログインできない」みたいな記事がたくさんあったのを覚えています。今なら「そんなの辺り前じゃん」と思われる事ですが、仮想マシンに慣れきった開発環境を自前でもっている人に取ってはVMの代わりとしては、意外な事で Docker は「使いにくい」と思っていました。
いちいち Dockerfile なるスクリプトじみた物をかかないといけないのも面倒くさく、仮想マシンであれば環境を作ってしまえば、スナップショットでそのまま保存でき、再利用できました。基本、何も覚える必用がなくオペレーションができました。。ただ「ディスクスペースとメモリが・・・」という問題は引き続きありました。
また、エンタープライズ屋さんの間では、「コンテナ？大昔から Solaris Containers があるじゃん。いまさら？」みたいな、割と冷静な反応が多かったのを覚えています。IBMのAIXに詳しい人なら「WPAR (Workload PARtition) 」がコンテナと似たような概念でアプリの筐体間移動までサポートしているものまでありました。
当時、部門内で Docker の起動の速さだったり、使いかってをデモした記憶があるのですが、「ポテンシャルは感じるけど、企業がビジネスに使う所には出てこないだろうな」というのが当時の雑感でした。なので「こんなの流行ってますよ」程度の心持でデモをしていました。
ただ、(私の)予想に反して Docker は、流行りました。
Solaris Container 等の当時すでにあった技術は Solaris を持っている人だけのものでしてが、Docker Container は Linux を持っている全ての人が使えるものでした。敷居の低さが、決定的な違いになったのだと思います。
Docker にポテンシャルがあるのは良いとして、大きな問題は Docker で作ったサービスの可用性をどう保つかが、Docker が趣味の領域を超えられるか次なら課題だったと思います。
コンテナが何かの障害で倒れた時に、物理的にも独立したノードで同じコンテナを再起動させ、データの整合性まで引き継ぐ事ができなければ、本番環境でコンテナは使えません。開発環境だけで使うのでは少し残念な感じになってしまいます。
「可用性を保ったシステムにできないので本番環境には使えないだろうな」と思っていた中 Kubernetes (k8s) が誕生しました。
K8S の登場も Wiki を参照すると 2014年6月7日だったそうです。当時は、2014年後半に入っても「Kubernetes はどうやって読むんだ？」というディスカッションがあり、一生懸命 Youtube を繰り返し発音をつかんだ記憶があります。
ただ、私はそれでも「Open Source で、可用性を実現するソフトウェアは開発が上手くいかない」と思っていました。
当時の実験環境で主流だったVMWare は、既に HA や、FT構成さえも組めてしまい、DR (Disaster Recovery) の切り替えの複雑なプロセスをマネージするための SRM (Site Recovery Manager) や、DRS (Distributed Resource Sharing) まで考えられた製品群が用意されていました。
当時は本当に VMware 一強で、KVMは仮想マシンを使う事が精一杯で、本番構成で冗長性を保つためには、Lifekeeper や ClusterPerfect の Third Vendor のクラスタソフトを使っていました。
特にHWをまたいだ可用性のためのクラスタリングを行うソフトウェアは、1）開発者がその環境を持っている必用があり、大規模な環境になってしまうため、大半の技術者にとっては開発環境を持つ、維持する事が難しい。2）開発者の中でも可用性を保つためのソフトウェアを開発しよう。というモチベーションを持つ人が少ない。せいだと思っていました。なので「K8Sも開発が上手くいかない」と予想していました。
が、ここは予想に反して企業連合が大量の資金を投資し、K8S を立派なソフトウェアに仕上げていきました。これはOSSの中では、結構、珍しい事ではないかと思います。
大規模な開発環境が前提となる、基盤系の Open Source ソフトウェアの開発がなかなか普及レベルまで到達しないというのは OpenStack の例もあります。
インフラ系のOSSは、マニアック過ぎて、このエリアに興味や仕事で関われる数が圧倒的に少ないため、基盤系の OSS の開発というのはなかなか進まない。と予想していたのですが、K8Sに関しては思いっきり予想が外れました。
統計を見ると、Google の貢献度が大きく、次に個人、RedHatで、75%を締めており、その次は"その他"となっています。
私は、Google が OSS の領域に巨額な資金を投資して参加した事と RedHat と一緒に参加した事が、K8S が形になってきた一番の原因かなと。思いました。
ただ、単純な OSS では、Googleは、バグがあっても直してくれるわけもなく、K8S の上にビジネスアプリを載せるには実運用で不安が残ります。
オンプレユーザーの視点では、OSS ながらもサポート費用を払えば RedHat が OpenShift として何らかの改善をしてくるという安心感が、全体の後押しをしているのだと思っています。そしてそれはクラウド上の K8S サービスにも反映されていきます。
少し意外だったのは、AWS や Microsoft、IBM と言ったクラウド上で K8S のサービスを提供している会社がそれほど、コントリビューターとして高い位置を占めていない事です。
一方で Docker が Swarm や K8S 周りのエンタープライズ事業を売却した事から、少なくてもこのエリアは OSS になった事で、オンプレでは単純に儲かるエリアでは無い事が示唆されています。
2019年4月に発表されたGoogle Anthos や、2019年11月に発表されたMicrosoft の Arc は、オンプレ K8S に乗り出しています。自社のパブリック･クラウド上の K8S とのハイブリットクラウドを目指した相乗効果を考えてのものだと思いますが、今は体力ありきの施策だと想像されます。
2019年のK8S
予想に反して K8S は進化を続け、私のような素人がパット見た感じ、かなりできあがった感じになってきたように見えます。
ただ、一方で 2019年になっても K8Sの自前運用からはてなが撤退した事が「Kubernetes Meetup Tokyo #22」で語られている通りに、誰でも簡単に。という洗練度でソフトウェアが完成されてないようにも見えます。
私は minikube や、クラウド上の K8Sサービスを使っているおちゃらけレベルなので、運用ができないような状況に直面するわけも無いのですが、まだまだ改善の余地があるのだと思います。
忘れてしまいがちですが、ビジネスで使うための技術は運用までのサイクルを考えてまでの技術だと思います。運用が特定人物に依存しないといけない/学習ハードルが高いうちは、リソースの余裕がある会社しか投資できません。
K8S自体が、一般にマネージドな有料サービスとして公開し規模を稼ぐ事で、人をお金を投入しても回収できるクラウド事業者だけが構築･運用できるサービスというのが実態なのだと思っています。仕事で100%コミットできる恵まれた環境にある人以外は、構築にはまだ手を出さない方が良い状況なのかなというのが現在の印象です（まだ、Buggy なリリース時に手を出すと、仕事の時間が削られるのと、覚えた事もすぐに古くなりそうな・・・）
また、ネット上では流行っているように見られるK8Sですが、2020年の1月にK8Sの勉強会に行った時に、参加していたエンジニアに聞いてみましたが、誰も実案件は聞かない。というのが反応でした。
ネットではすごく流行っているように見えるけど・・・というのがまだ実態ではないのかなと思っています。（狭い観測範囲なので、主観以外の何物でもないですが・・・）
PaaS からCaaS (Container as Service) へ
長々とこの話を書いたのは、Pivotal のページを見ていて「PKS」というサービスがあるのを知ったためです。
これは K8S のサービスで、いつのまにか PaaS 一本のビジネスからピボットしていました。記事を検索すると2018年3月に発表がされていました。
Google Anthos では、仮想マシンからコンテナへの移行ツールについての言及がありました。
まだ、Anthos がどれほどのものか研究出来てないものの、簡単に既存の VMをコンテナに移行できるのであれば、コンテナ化をしたくなってきます。（コンテナ化のデメリットもあるにはあると思いますが）
全てがコンテナになり K8Sの環境さえあれば、クラウドベンダー、オンプレ環境、自マシンなど場所をとわず、マニフェストファイルに、指定したリソースと可用性でシステムが稼働してくれる。そんな未来がやがてやってくるのかな。と思うとワクワクします。
ただ、5年前のK8S の誕生時は、こんな未来が来るとは予測してなかったですし、コンテナはあくまでマイナーな存在であり続け仮想マシンに人はこだわり続けるだろうと思っていました。
5年後に何がインフラ技術の辺り前になっているかだれも予想ができないものだなとつくづく感じます。
2019年には、一般的な Webサービスならコードを書かないで作ってしまう NoCode が流行でした。ひょっとしたらインフラ自体が忘れ去られて「NoCodeがデフォルトだよね」と言う未来になっているのかもしれなません（という事はなく、適材適所になる。というのが私の予想だけども）
#この記事は個人の主観に基づく感想で、全く違う視点で技術動向を眺めている人もいると思います。感想の違いについては、いろいろご容赦下さい。。。