インタビューVMware は、アプリケーションの配信を簡素化すると主張する Kubernetes パッケージのバンドルである Tanzu Application Platform をプレビューしましたが、既存の Tanzu Application Service を Kubernetes 上で実行する計画は断念されました。
Tanzu Application Platform（TAP）についてまず理解すべきことは、Tanzu Application Service（TAS）とはほとんど共通点がないということです。両者は全く異なるものであり、名前が似ているのは残念なことです。
TASは、オープンソースのアプリケーションプラットフォームであるCloud Foundryテクノロジーを基盤としています。その複雑な起源は2009年のVMwareに遡ります。その後、Pivotal Softwareにスピンアウトし、Pivotal SoftwareはコアソフトウェアをCloud Foundry Foundationに引き継ぎました。その後、TASはVMwareに再買収され、Tanzuの一部となりました。TASとCloud Foundryは、アプリケーションのパッケージ化とデプロイにBOSHを使用しています。
対照的に、今週のバーチャル SpringOne イベントで発表された TAP は、Kubernetes の新しいアドオン セットであり、アプリケーションのデプロイの詳細の多くを抽象化して、開発者が自分のコードに集中できるようにすることを目的としています。
TASはどこにも行きません。正直に言うと
私たちは、Google 在籍時に最初の Kubernetes プロジェクトの共同創設者であり、VMware の R&D 担当副社長である Craig McLuckie 氏に話を聞きました。McLuckie 氏は、これが TAS の終わりの始まりではないことを私たちに納得させようと、多くの時間を費やしました。
「Tanzu Application PlatformはTanzu Application Serviceを自然に補完するものです」と彼は言います。「Tanzu Application ServiceはCloud Foundry上に構築されており、私たちが提携している多くの組織で非常に多くの利用と継続的な成長を遂げています。」
そうは言っても、「多くの組織はすでに Kubernetes の世界に存在しているか、Kubernetes の世界へ急速に移行しています」と彼は付け加え、「開発者の IDE から Kubernetes を使用した本番環境への容易な道を構築するのは、少々大変なことかもしれません」。
「私たちは、シンプルなパスとして Tanzu アプリケーション プラットフォームを導入しました。これは、開発者が最新のアプリケーションを構築するために必要な、完全にキュレートされた依存関係のセットから始まります。コミュニティがそれらの部分の 1 つが悪用されていることを発見した場合、影響を受ける可能性のあるすべてのアプリケーションを更新できるようになります。」
Tanzuアプリケーションプラットフォームは、ソフトウェアサプライチェーンを管理してセキュリティを確保し、導入を簡素化することを目指しています。
TAPは、VMwareがスポンサーとなっているJavaアプリケーションフレームワークであるSpringから、ある意味でインスピレーションを得ています。「Springは、開発者が本番環境に密結合しないものを構築できるようにしました」とマクラッキー氏は述べています。
制御の反転とは、インフラストラクチャ要素がマニフェストを介してコードにバインドされ、わずかに異なる属性を持つ実稼働前環境と実稼働環境の違いについて開発者が心配する必要がなくなることを意味します、と彼は言います。これが、エンタープライズ Java の世界で Spring が優位に立っている理由です。
言葉遣いに気をつけましょう
ただし、すべてのアプリケーションがJavaで書かれているわけではない。McLuckie氏は、Microsoft .NETと.NET Core、そしてPython、Ruby、JavaScript/Node.jsといった他の言語の重要性が依然として高いことに言及している。TAPの目的は、Kubernetesにデプロイされたアプリケーションにランタイムに関係なくSpringのような原則を適用し、「開発者がプラットフォームを意識したアプリケーションを構築する必要がない」ようにすることだ。TAPの中核コンポーネントは、アプリケーションをプラットフォームで実行できるように記述するマニフェストであるworkload.yamlである。
Workload.yaml は Tanzu Application Platform の動作の鍵となります
TAP自体はどのようにインストールするのでしょうか？「TAPは単なるパッケージの集合体です」とMcLuckie氏は言います。「Linuxにパッケージがあるように、Kubernetes用のパッケージングシステムを導入しました。便利な機能をパッケージとしてまとめ、Kubenetesにデプロイできるようにしています。KubernetesであるTanzu Kubernetes Grid（TKG）にデプロイできます。TKGはvSphereに統合されていますが、OpenShift、GKE、AKS、EKSでも実行できます。」
「当社が提供するパッケージを Kubernetes クラスターにドロップするだけで、巧みに作成された Kubernetes コンテナを作成できるビルド システムが完成します。」
- VMwareは、Tanzuコンテナの信条を広めるためのツールを最良の同盟国に提供した。
- VMwareは、その主力製品をクラウドサブスクリプションに移行するための狭い一方通行の道を構築
- IBMがHCIに再び挑戦、アナリストはコンテナ中心のソフトウェア定義ストレージのアプローチが状況を一変させる可能性があると指摘
- VMware は Tanzu の 1 年目を Advanced Edition の一般提供で締めくくり、アプリのモダナイゼーションを実現する魔法のツールを発表
TAPテクノロジーは、オープンソースのKubernetesプロジェクト、そして関連するオープンソースプロジェクトとどのように関連しているのでしょうか？「TAPは、可能な限りKubernetesの完璧な拡張機能です。Kubernetesに重大な欠陥が見つかった場合、私たちはコミュニティを通じてその欠陥を解決できるよう尽力します。TAPはKubernetesプリミティブ内、その上、そしてその周囲に組み込まれています。TAPはKubernetesリソース定義であり、カスタムオペレーターであり、Kubernetesエコシステムに、より本質的なアプリ認識をもたらします。」
McLuckie氏によると、VMwareはkpack、Carvel、Harborといったオープンソース技術を通じてKubernetesに大きく貢献してきたという。「私たちはオープンソースを通して活動する、このオープンエンゲージメントモデルの採用に尽力してきました。Spring自体も好例です。…その構成要素を詳しく見てみると、ほとんどが私たちが貢献したオープンソース技術なのです。」
「誰かがそれらをパッケージ化し、誰かがそれを支え、顧客が問題に遭遇した場合に確実に対処できるようにする必要があります。私たちは、オープンソースコミュニティで育成している多くの技術を管理し、それらを使いやすいフォームファクターにまとめることで、Kubernetesに関して顧客が抱える最大の課題の一つ、つまり選択肢や統合ポイントが多すぎて混乱してしまうという課題に対処する役割を担っていると考えています。」
ライセンスはどのように機能しますか？「Tanzu スイートの他の部分と同様に、使用しているリソースのコア数を単純にインデックス化します。これはオンプレミスでもパブリッククラウドでも機能する必要があります。」
Tanzu Application Service と、これも Kubernetes 上で動作するというアイデアについてはどう思われますか？これには長い歴史があります。Cloud Foundry Foundation とそのスポンサー企業（Pivotal/VMware を含む）は、長年にわたり Kubernetes への移行に取り組んできました。
決定的な瞬間
2019年、PivotalのCEO（当時）であるロブ・ミー氏はKubernetesへの移行が必然であると説明したが、同社のテクノロジーが「Kubernetesと互換性がない」という理由で株価は下落した。
しかし、移行は起こり、Cloud Foundry Foundationは現在、このプロジェクトを「Kubernetes向けのクラウドネイティブ開発エクスペリエンス」と表現していますが、古いCFアプリケーションランタイムとBOSHツールは依然として存在しています。TASはTAP上で動作するのでしょうか？
「TASはKubernetes上では動作しません。TASはBOSH上で動作します」とマクラッキー氏は述べた。「私たちはTASをKubernetes上で動作させるために多大な投資を行ってきましたが、TASの真のZen（3R）を実現するには、アプリケーションの再設計や証明書のローテーションなど、完全にオーケストレーションされた環境を構築する必要があり、かなりの作業が必要であることがわかりました。」
同社は、TASをKubernetes向けに最適化した代替プラットフォームとして、TAPを開発することを決定しました。「最終的にはTAS互換のAPIをこの上に提供したいと考えています。すべてを統一されたベースラインに統合することには価値があるからです。しかし、現実には、ほとんどのお客様にとってTASは本来の機能を十分に果たしてくれています。」
TASにおけるWindowsエクスペリエンスは非常に優れており、多くのお客様が高密度のWindowsベースのワークロードを抱えています。このシステムは、Kubernetesエコシステムでは再現が難しい価値を生み出します。だからこそ、それを維持すべきではないでしょうか？そして、組織がいつ、そして移行を行うかどうかは、自ら決定できるようにすべきです。
Kubernetes 上の TAS: ベータ版のお客様と何百回も議論した結果、スケーラビリティ、速度、セキュリティ、安定性の基準を満たせるとは思えませんでした。
この件に関する同社の投稿はさらに率直だ。「ベータ版のお客様と何百回も議論を重ねた結果、Tanzu Application Service for Kubernetesのアプローチでは、Kubernetesとそのエコシステムを強力にする主要な宣言型プリミティブを活用・公開できないと判断しました。また、スケーラビリティ、スピード、セキュリティ、安定性に関する当社の基準を満たすことも、お客様が慣れ親しんできたような開発エクスペリエンスを提供することもできないと判断しました。」
Cloud Foundryプロジェクトにとって、この技術の創始者がKubernetesへの移行を断念するということは何を意味するのでしょうか？財団にコメントを求めましたが、まだ返答はありません。
ここで興味深いのは、TAPとTASの高レベルの目標は似ていないわけではないということです。ただ、一方がKubernetes上で動作し、もう一方がそうでないというだけです。Kubernetesが今後も主流であり続けると仮定すると、VMwareはTASプロジェクトの健全性を維持していると主張していますが、TASの将来は暗いものになりそうです。
反論としては、TAS と BOSH が Kubernetes の複雑さなしにうまく機能するのであれば、変更を主張するのは難しいというものです。®
