開発者にも浸透し始めたKubernetes、成り立ちに見る難しさの原因
普段アプリケーションを開発しているエンジニアにとってコンテナは少し遠いインフラの世界の話題に感じられるのではないだろうか。しかし現実は、アプリケーション開発者にとってコンテナは身近に迫ってきている。Java開発者を対象にした調査（2022 Java Developer Productivity Report）では、使用しているプラットフォームは上位からDocker（41％）、Kubernetes（26％）、VMware（16％）。上位2つがコンテナで、半数以上を占めている。
さらにVMwareの調査（State of Spring 2021）によると、Kubernetes上でコンテナ化したSpringアプリケーションを稼働している組織は前年の44％から57％へと上昇した。インフラエンジニアだけではなくアプリケーション開発者にとっても、もはやKubernetesは無視できない存在になりつつある。
とはいえアプリケーション開発者にとってコンテナは敬遠したいところではないだろうか。基盤がコンテナで運用されることでスケーラブルになったり、環境を素早く柔軟に構築できたりするのはいいが、コンテナ、特にKubernetesに関与せざるをえないとなると腰が引ける。「インフラエンジニアに任せて、アプリケーション開発に専念したい」のが本音ではないだろうか。アプリケーション開発者の内心にKubernetesへの壁や苦手意識らしきものが潜んでいるかのようだ。
その謎をVMware デベロッパーアドボケイト 柳原伸弥氏がするりと解く。なお柳原氏はもともとアプリケーション開発者でJavaやSpringに詳しい。トラディショナルな開発とクラウドネイティブ開発の両方を経験し、アプリケーションのモダナイゼーションの専門家でもある。
まずはコンテナとKubernetesを分けて考えること。柳原氏は「例えばSpringにはフレームワークにコンテナを作り込む機能があります。開発者はコンテナを意識しなくて良いため、コンテナ自体はそう難しくないと感じるのでは」と話す。
「一方でKubernetesに難しさの根源があります」と柳原氏。もともとKubernetesはGoogleの基盤に源流がある。周知の通り、Googleは24時間365日止まることなく、世界中にGmailやGoogle マップなどのサービスを提供している。もはや社会インフラだ。そのサービスを支えるインフラストラクチャとしてGoogleが開発したものがBorgと呼ばれるクラスタマネージャーである。
このBorgを誰でも使えるようにオープンソース化したのがCloud Foundry BOSHとKubernetes。どちらも源流はGoogleのBorgであり、巨大サービス基盤を想定しているため「Google（の基盤）を自分たちで作ろうとするようなものだから、難しくて当然なのです」と柳原氏は断言する。
Kubernetesを通じてダイナミックなインフラを作りあげていくところに醍醐味はあるものの、Googleに匹敵する巨大インフラを必要とする企業はそう多くはない。大規模サービスに関わるインフラエンジニアやSREエンジニアなら話は別だが、アプリケーション開発者がKubernetesを敬遠してしまいがちなのも無理もないというわけだ。
開発プラットフォームを基盤ではなくプロダクトとして捉えてみる
とはいえ、いまや多くのコンテナやKubernetesは身近な存在になりつつある。アプリケーション開発者はどのようにコンテナとモダンな環境を捉えていけばいいだろうか。
柳原氏は「これからはクラウドネイティブの概念は避けて通れません」と言う。クラウドネイティブなアプリケーションだけではなく、クラウドネイティブなオペレーション然り、クラウドネイティブなプラットフォームも然り。もはやクラウドネイティブは頭文字や枕詞のようについてまわる。
ここで改めて「クラウドネイティブ」を確認しておこう。CNCF（Cloud Native Computing Foundation）の定義から一部引用すると「クラウドネイティブ技術は（各種クラウドの）近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらす」とある。「昔のような重厚長大でモノリシックなアプリケーションではなく、24時間365日止まらないようなスケーラブルなアプリケーションを作っていかなければならない、そんなパラダイムシフトが起きているのです」と柳原氏は説く。
そうしたパラダイムシフトにおける1つのキーワードとしてVMwareが打ち出しているコンセプトが「Platform as a Product（製品としてのプラットフォーム。以下、PaaP）」。インフラエンジニア向けの新しい概念のように見えるが、実はアプリケーション開発者に浸透しているアジャイル開発やDevOpsにも通じる概念だ。これはアジャイル開発が得意なPivotalを統合したVMwareらしいところでもある。
思い出してほしい。アジャイル開発では開発者（エンジニア）、デザイナー、プロダクトマネジャーの3つのロールがチームを組んでアプリケーションを作りあげていく。このアプローチをインフラに適用したもの、アジャイル開発におけるプロダクトをインフラ構築にも適用するのがPaaPになる。そう考えると少し親近感がわくのではないだろうか。
柳原氏は「大事なのがお客様、つまりユーザーの存在です」と強調する。アプリケーション開発でユーザーを意識することが重要であるのと同じように、プラットフォームにおいてもユーザーを意識することが重要になる。プラットフォームにおけるユーザーとなるのはアプリケーション開発をしている「開発者」である。
アジャイル開発における開発者は、PaaPではプラットフォームを作りあげていくインフラエンジニアにあたる。柳原氏は「SREの上位互換にあたると考えている」と話す。
繰り返しになるが、アジャイル開発におけるマインドセットをプラットフォームの世界に適用したのがPaaPとなる。長らくインフラを支えてきたVMwareに、アジャイル開発を各組織に浸透させてきたPivotalが1つになったからこそ実現できる世界だ。
なお「プラットフォーム」は「基盤」と同等と捉えられるものの、柳原氏はこの2つの用語を使い分けているという。「基盤」はかつてのように「構築したら、あとはそのまま使い続けるインフラ」というイメージで捉えている。一方「プラットフォーム」は「チームを作り、愛着を持ち、組織や企業とともに育てていくインフラ」としている。
開発の生産性と楽しさを向上させるDevOpsの実行手段として
もう少しPaaPを深掘りしていこう。柳原氏は興味深い視点で話を進める。「先ほどPaaPのエンジニアはSREの上位互換かもしれないという話をしました。SREを提唱したGoogleでは、DevOpsの実装版がSREであると述べていますよね」（柳原氏）。
Javaアプリケーションのように見てみよう。DevOpsというインターフェースがあり、そこで仕様が決まっていたとする。そのDevOpsという仕様を実装したものがSREやPaaPになるという考え方だ。
Googleは巨大なサービスを安定稼働させるためにBorgを構築していくなかで、SREを育ててきたと柳原氏は見ている。ただしBorgとPaaPは位置づけが異なっている。GoogleのBorgは全世界のユーザーが対象となり、各社で運用するPaaPは自社ユーザーが対象となる。
多少違いはあるものの、アプリケーション開発者がプロダクトに向かうのと似たようなマインドセットでインフラエンジニアやSREがプラットフォームと対峙していると考えることができる。
DevOpsと似ているゆえに、罠や解決策も共通しているところがありそうだ。DevOpsを実現しようとして「DevOpsエンジニア」を掲げて募集し、うまくいかずに頓挫してしまうパターンがあると柳原氏は指摘する。「もともとDevOpsは開発者（Dev）と運用者（Ops）が仲良く幸せな世界を作りあげていこうとするものなのに、（DevとOpsの両方できる人を求めてしまうと）難しくなってしまいます。本来のDevOpsのマインドセットに基づき、チームやポストを作って進めていかないと成功しないと思います」（柳原氏）
同様に、SREも高い素養が求められがちだ。もちろんSREは運用のオペレーターではなく、自ら（インフラのための）ツールをどんどん開発していきつつ、インフラ運用の効率化を図っていかなくてはならない。先に挙げた「DevOpsエンジニア」のように重責になってしまいかねない。
ただしVMwareのPaaPにおいては、アジャイル開発のようにチームを組んで実装していくので（GoogleやKubernetesの世界における）SREほどの高い素養やプレッシャーは少なくなりそうだ。
なぜか。VMwareの考え方を知ると理解できてくる。VMwareは「Abstract things and make things simple（あらゆるものを抽象化し、シンプルに）」というメッセージを掲げている。これはかつてVMwareがインフラ領域で仮想化技術を推し進めてきたなかで、達成した成果とも言える。数多くのサーバーのハードウェアがあるなかで、VMwareはソフトウェアを用いて仮想化を実現してきた。これは抽象化とも言い換えられる。いまVMwareはこのアプローチをそのままアプリケーションの世界に適用していこうとしている。
またVMwareはKubernetesにも目を向けている。柳原氏は「インフラをずっとやってきたエンジニアならネットワーク、ストレージ、コンピュータリソースの扱いは長けています。インフラエンジニアなら、ですよ。これをアプリケーション開発者に求めてはいけません。そのためにはシンプルにしていく必要があります。だからVMwareはKubernetesをシンプルにしていこうとしているのです」と力を込める。
具体的にはVMware Tanzuのポートフォリオの1つ、「VMware Tanzu Application Platform（以下、TAP）」を通じて実現していく。TAPはKubernetesが稼働するプラットフォームではあるものの、アプリケーション開発者からするとKubernetesを意識する必要がない。もちろんYAMLで悩むこともない。
「やはりアプリケーション開発者というのは、企業が本来注力すべきサービスの中身を作りあげるのが本来の仕事です。TAPはそこにフォーカスできるようにするためのプラットフォームです。またKubernetesしかない世界では、アプリケーション開発者とインフラ（プラットフォーム）エンジニアの境界線が曖昧になりますが、TAPがあることにより責任分解点が明確になり、両者はWin-Winの関係になれるのです」（柳原氏）
これまでVMware Tanzu製品を導入した企業では、Tanzu製品をプロダクトとして接している。ユーザーとなるアプリケーション開発者たちに対して、プラットフォームを使いこなせるようにトレーニングも行うこともある。またプラットフォームは「Tanzu」や「コンテナ基盤」などと呼ばず、組織独自の名前（例えば、BeeHive）をつけて、ロゴやノベルティを作りブランディングのための社内マーケティング活動も実施する。こうした活動を通じてプラットフォームは組織内で愛でられ、育てられていく。
どうだろう。アプリケーション開発者が使う開発プラットフォームがKubernetesの恩恵を享受しつつも、難しさは排除できて、なおかつ組織内で成長していく存在だとしたら。開発生産性だけではなく、開発の楽しさも向上するのではないだろうか。
関連情報
ヴイエムウェアは3月3日に、Tanzu Application Platformについてのセミナーを開催しました。デベロッパーとオペレーター、それぞれの視点から解説されています。アーカイブ動画はこちらから！
