Kubernetes。クーバネティスともクーバーネイティスとも呼ばれる、日本人にはちょっと読みにくいこのプラットフォームは、知名度だけはとてもある。ただ、全ての現場に広く届けられたかと言えば、そうは言えないだろう。将来はKubernetesになると言われても、じゃあ今の資産をそのまま移せるものではない。次のリリースで検討すると言いながらも、単にコンテナ化してもシステムが変わるわけではないので、ユーザー側ではメリットがつかみにくい。かえって新しいアーキテクチャーを採用することで、余計な苦労をするかもしれない。チャレンジは技術者には楽しいかもしれないが、ユーザー側は別にシステムが動けばいいのだ。これまで通りの実績ある設計で、堅実に作って欲しい。そうやってKubernetesへのチャレンジができていない現場はたくさんあるだろう。
そもそも、まだKubernetesはまだまだ進化途上だ。定期的にバージョンアップしていくが実装も速く、3年経ったら絶対に陳腐化している。例えばWindows Serverがリリースから10年はサポートするように、Kubernetesもそろそろ安定化を期待されるだろう。つまりLTS版（長期サポート）の登場だ。今はまだ存在しない。
バージョンがどんどん上がっていくのはいいが、その上のアプリケーションやシステムを毎回メンテナンスしなければいけないとしたらコストに跳ね返ってしまう。そもそも開発者の持つ開発環境をコンテナに閉じ込めておいて、コンテナエンジンでそのまま動かせるのが売りだったのに、Kubernetesの機能に依存することによりバージョンアップに対して脆弱になってしまう。
ところで、IBMからこんなサービスが出た。
日本IBMは6月29日、IBM Cloudで提供するフルマネージド型のランタイムサービス「IBM Cloud Code Engine」について、報道機関向けのオンライン説明会を開催した。
（中略）
昨今、クラウドネイティブなアプリケーションでは、コンテナー／Kubernetesの利用が一般的になっている。その点について、同氏はKubernetesの活用について「ハードルがかなり高い」ことを指摘した上で、「開発者はアプリを動かしたいのであって、インフラを構築／運用したいわけではない」「開発者はアプリ開発に注力すべき」ということから、IBM Cloud Code Engineを「複雑なスキルやインフラの管理／運用を必要としない、アプリを瞬時にデプロイできる環境」だと位置付けた。
そう、Kubernetesがクラウドに露わになっている時点で、抽象化が足りないと思っていた。
大昔に、私が小学生中学年のころだったか。コンピューターで簡単なプログラムを実行するならBASICでもいいが、本格的な活用には「機械語」が必要だ。そんな記事をパソコン雑誌で読んだことがあった。
何せ小学生なので何の教養もなかったが、機械語、というネーミングはとてもファンタジックだった。人間の言葉じゃない言葉が存在するというのだ。それも16進数で、0123456789ABCDEFという、16個の組み合わせが織りなす雰囲気がとても魔法的だったのを覚えている。
ただ、機械語を理解するのはとても難しいので、次はアセンブリ言語というちょっとだけ人間にわかりやすい言語ができた。情報処理技術者試験でもまだCASLという単元が残っている。アセンブリ言語は機械語と一対一なので、まだ人間にはわかりにくいが機械語そのものよりはまだわかりやすかった。
それでももっと人間がわかりやすい言語を、ということでCやFORTRAN、COBOLなどの高級言語と、それを機械語に翻訳するコンパイラが生まれた。
最近は、もっと人間が開発しやすい言語を、ということでJava、Pythonなど、技術の進化は止まらない。
この流れの中で最も大事なのは、もうほとんどの開発者は機械語など全く知らないということだ。言語を作る人ですら、機械語まではたどり着けない。これが抽象化のパワーであると考える。翻訳ソフトのおかげでもう英語圏の人と話すのに英語を勉強する必要がない、というのと同じだ。
開発者がシステム開発を行い、インターネット上でサービスをするまでに、Kubernetesを意識しなければいけないのであれば、それは余計な努力が必要だということになる。抽象化することにより、全くインフラを感じないで作ったアプリケーションを簡単に動かせることが重要だ。
そうすると、今のKubernetesは、存在感があり過ぎる。
各パブリックベンダーは、Kubernetesを活かして抽象化したインフラ基盤を作り、冒頭のIBMのようにアプリケーション開発者に使ってもらおうという画策を行っている。しかし、Kubernetes側をバージョンアップしようものならアプリケーション側で対応しなければいけないパターンも捨てきれない。
では、Kubernetesの抽象化が進みインフラ基盤に溶け込んでくると、開発者だけいればいい時代が来るのか。
私はそうはならないのではないか、と見ている。なぜなら、開発者がアプリ開発者に注力するならば、そこから下の層（Kubernetesから下のレイヤー）はやはり誰かが責任を持って管理しなければいけないからだ。
抽象化が進めば進むほど、その実装がどうなっているかに精通し、何か不具合が起こったときに動ける技術者はやっぱり必要になる。パブリッククラウドの中では、このような技術を持ったたくさんの技術者が正常動作のために働いている。
いずれKubernetesが安定化した後。どう開発者に届けるかを画策するインフラエンジニアの姿が見える。どんどん抽象化が深くなり、開発者にはKubernetesすら感じなくなったときにむしろ具体的に、インフラエンジニアの役割はクローズアップされてくると思う。
