PaaS(CloudFoundry) と IaaS+(Kubernetes) との関係性に思うこと

近年2年近く、IBM Cloud (旧Bluemix ）上でCloud Foundry でアプリケーション開発を行い実際にシステム構築を行い、ここ半年くらいIBM CloudやGoogle Cloud Platform でk8s上でマイクロサービスやなんやCI/CDを利用したコンテナ開発を検証していく中で感じたこと吐き出してみます。

なぜこの文章を書くか

IBM と Pivotal （そしてCloudFoundry）は、それぞでこれまでの CFのサポートから同時期に k8s のサポートをはじめました。私の周りにも CFとk8sはどういう関係？ CFは k8sになるの？みたいなことや IBM は CFはやめて k8sになるの？（これは商売の話なので私はわからないですが）という声を聞きます。また逆にPivotalさん使っているとも聞くようになりました。なので私の立場からみる CF / k8sを書いてみたいと思います（とはいえプロダクト開発に関わっているわけでもありませんし本来の思惑ともだいぶ違うところがあるかもしれませんのでこの界隈のエンジニアの感想と思っていて興味があればお読みください）

まとめ

• いまVM+運用で構築している標準化された基盤はPaaS(CF)で置き換えれる
• いま運用で例外として構築する基盤はk8sで置き換えられるし管理もできる
• CFはk8sの上に構築できるようになる
• データストアや外部システムとの連携を今どきの方式を採用すると、クラウドネイティブな環境をクラウドでもオンプレでも作れるよ（とはいえ簡単ではないが）
• 抽象化を上げるとことで、どのクラウドにも行くことができるよ。とはいえクラウドネイティブはどこかでロックインされるのでロックインのメリットを享受して進めよう

企業内インフラが目指すものとは

現在、多くの企業いおて導入されているVMWware(ESX)を利用したVM環境も突き詰めればアプリケーションエンジニアにとってはPaaSと同様の環境です。それも不自由なPaaSかもしれません。いわゆるエンタープライズの企業においてはカスタマイズされガバナンスが適応されされたVMテンプレートが用意されていることでしょう。特定の指定されたアプリケーシションサーバや監視プロダクトが導入済みとなったVMの上にアプリケーションを構築していくことになります。そしてその環境は運用担当者によりメンテナンスされ利用するための払い出しが手動（または半自動）で行われていることが多いです。そしてそのVMが利用できない、また規定のネットワークやストレージが利用できないとなると例外的なシステムが構築されていきます。こういった標準化されたものと非標準のものが混在し ていくのが一般的な企業内でのインフラではないでしょうか。

こういったことから「現時点の選択肢として今後企業インフラの目指す先はPaaSであるべきでしょう。」と記載しても特に違和感はないのではないでしょうか（言い過ぎ？）。ここでのPaaSは先程述べた「カスタマイズされたVM+適切な運用業務」をシステム的に保証してくれる仕組みです。こういったことを実際に企業が利用できるレベルで実装している（例えば、サポート体制や将来性など企業が考えるべき検討項目は多岐にわたりますが）代表的なプロダクトの一つが、Cloud Foundry（以下CF) です（CFが代表的なPaaSを実装するOpenSourcecであり多くの企業から賛同を得ていることは疑いのないことでしょう）。 アプリケーション実行環境としてはCFが最適だと思いますが、この辺は全体最適としてk8sを選択している場合にはOpenShift (OpenShiftは、RedHat社の提供するPaaSで内部にk8sが利用されている）などがバランス良いソリューションだと思います。結局VMにしてもその利用方法を色々と規約やテンプレートなどを駆使して統制していることがPaaSではシステマチックに解決していくことになります。

PaaS+SaaSという世界

CFはアプリケーション実行環境と記載しました。企業内では多くのサービスやシステムが混在して相互に絡み合い大きなシステムを形成しています。正規化されたデータも、ファイルサーバに積み上がる非構造化データも様々な種類があります。 IBM Cloudでは、PaaS+SaaS(IBM社やサードパーティ製のものを含めると140以上のサービスが利用可能）を簡単に利用できる仕組みがあります。これは今後のPaaSの世界を垣間見ることができます。企業内のあらゆるリソースを「サービス」として「オーダー」しアカウント管理・利用管理を透過的に行いアプリケーションからは「バインド」という処理でAPI経由での利用が可能になります。例えば勤怠システムの情報から社員の動向を傾向分析するシステムを作りたいと思った場合、そのアプリケーションをコーディングし勤怠システムをバインドして即座に利用可能になることが想像できると思います。（少しおじさんであれば、Webアプリケーションの層構造的なことが当てはまりますね。Web+DBです。Webの部分がアプリケーションでDBの部分がサービスです）

こうったアプリケーションから見た外部の世界とのやり取りを標準かさせる動きも出てきています。CFとk8sではともに Open Service Brokerという仕組みを共有しようとしています。この標準的な仕組みにより CF/k8s — Serivce Broker — サービスをつなぐことができます。これは、企業内における今後のシステム構築の一つの道標になりそうです。この仕組がうまく実装できれば、企業内のDWHを利用したいひいうアプリケーションに動的にリソースを払い出すいことが可能になっていきます。CFやk8s（少し前ではOpenStackなど）の普及によりアプリケーションの実行部分は自動化が進みましたがデータストアや他リソースを利用するという点ではまだまだ自動化が進んでいません。企業内におけるPaaSを考えるときに、データストア（RDS、Hadoopやオブジェクトストレージ、DWHなど）とアプリケーションの連携そしてデータストアとデータストアを密結合したエンジン（例えばSpark）との関係性は整理しておく必要があるでしょう。（なんか最近のマイクロサービス的な文脈でも出そうな記載になりつつあるのでこの辺にしておきます）

実際に、IBM Cloudでは、CF（Bluemix）からも IKE (k8s)からも140種類程度のサービスを呼び出すことが可能になっています。素晴らしいです。同じように GKEでも簡単にBigQueryなどを利用することが可能です。でもまだ相互にBrokerは動いていないです（Brokerが相互に動いてこそマルチクラウドです）このように一定の手続きでリソースが利用できるようなると開発は楽になってきますね。試験環境のDBから本番に切り替えるのもとても簡単になりCI/CDがより現実的に企業内で行えるでしょう。

俺のPaaSを組み立てる

単にPaaS+SaaSが利用したい、そしてルールは柔軟に従えるという場合にはIBM Cloud（ここでは旧SoftLayer IaaSではないBluemixのPaaSを指しています） やHerokuを活用してみるのがもっともコストが安くいいアプローチであると思いますが、ここでは自身の環境に即したPaaSを作ることを考えて行きます。そもそもここ十年くらいのソフトウェアとしてのPaaSの道のりは険しいです。DockerだってOpenStackだってそもそもはPaaSを目指していたはずです。一度PaaSとして作られてしまうとどうしてもカスタマイズ性が弱くなるのは仕方ないです。（結局それが普及に至らなかったからでしょうか。IBM Cloudを触った際に結局はPaaSは裏側のサービスの多さだなと思いました）それに対してk8sはとても柔軟に基盤を作ることができます。とはいえアプリケーションエンジニアからすると抽象度が弱すぎるきがします（インフラ基盤すぎる）。CFはとても抽象化されており容易ですが逆にカスタマイズ性は薄いです。今後の企業にとって先に述べたようなサービスブローカーの仕組みで企業内の各種の機能へをリソースとして利用し、ガバナンスが適切に反映されアプリケーションエンジンが自由に利用できるとなればだいぶ様相は変わりそうです。

CFとk8sのガバナンスを聞かせることをカスタマイズとして考えるとCFのBuildpackやk8s(docker)のContaienrのベーステンプレートの存在は重要です。どちらも同じ役目を持ちますが、よりBuildpackのほうが（アプリケーションエンジニアでは変更しづらい）カスタマイズされた環境が提供され企業ユースでは喜ばれるかもしれません。企業において一定のセキュリティ要件やバージョンの要件を固定したい場合、その後自由に変更できる範囲が少ないほうが管理監査上は良いことが多いでしょう。とはいえ現在Buildpackのカスタマイズは難解に思われます。Dockerfileとk8sのyamlはとても柔軟で簡単です。このあたりのバランスをとりながら企業内にPaaSを作る事ができる必要があります。すでに書きましたが実際のところ大手の企業のESX+VMにおいても「運用」上で同じことが行われています。メンテナンスされたVMイメージの展開、運用チームによる環境の払い出しとルール・制約の適応、結局インフラは管理され程度の差こそあれその企業内で似たようなものを作ることになります。この標準的なイメージに沿わないたぐいのものは非公式や規定外として動作させることになりますがそれも一つのやり方であり正しいとか間違っているとか言うことではないです。これをこれまでの中で言えば、標準化されたシステム＝CF、非標準なシステム＝k8sと捉えると良いかもしれません。どちらのケースにおいてもアプリケーションライフサイクルを見直し、昨今のDevOpsで利用されるプラクティスを取り込みながらシステムを自動ビルド・デプロイできる環境までを鑑みてCFやk8sを選択して行く必要があります。その際に多くの工程をシステム的に含有しているCFの魅力が出てくるでしょう(素のk8s上にPaaS（運用ルールによる規定）を組み立てるのは大変です）

昨今CFとk8sはお互いに補完関係にあると宣言しています。それぞれは見据えている対象が違い、前者はアプリケーションライフサクルを、後者はインフラライフサクルをそれぞれ再定義します。k8sがここまで伸びてきたからこそ、本当に必要な基盤が何であるかを再度考えて採用していく必要があるかと思います。

結局

何が書きたかったのかとダラダラ書いていますが、k8sはとても柔軟に基盤を再定義しており昨今の機運から非常に期待が高まっていますが、企業内で利用するには柔軟すぎ、結局は現行のVM環境での運用と同じことを運用担当・インフラ担当に課すことになります。（k8sを否定しているわけではないです。k8sの柔軟なインフラ環境を作る機能はとても好きです）それに対してPaaSを企業内に作ることを目指す場合には選択肢が少し変わってきます。例えばCFを選択した場合適切に運用すれば運用・インフラ担当の日々のコストに差が出てきます。そしてアプリケーション開発においてもアジリティが向上する効果が見えるはずです。トータルに比較することはとても難しいですがこれからの企業内のインフラ基盤においては重要な事になってくると感じていますので k8s ORCFではなく k8s AND CF を検討してみることがおすすめでです。

おまけ

で、実際に Cloud Foundry 自分で運用したいかと言われると、 k8s ですらちょっと遠慮したいくらい難しくなってきていますね。ESXは単純だ（最近は難しいけど）やっぱ時代はマネージドサービスの利用だよ、と書いてしまうとここまで読んでくれた人に怒られそうだ。いまインフラに向き合っている人はほんとに大変だと思う。。

参考

• Google Cloud Platfrom : https://cloud.google.com/kubernetes-engine/docs/concepts/add-on/service-broker
• Google、「Kubernetes Service Catalog」と「Service Broker」を発表 (http://www.atmarkit.co.jp/ait/articles/1805/01/news021.html)
• CFの便利機能を他の環境でも。Open Service Broker — SlideShare (https://www.slideshare.net/jacopen/cfopen-service-broker )
• IBM Cloud : https://console.bluemix.net/docs/containers/cs_integrations.html#integrations
• Open Service Broker https://www.openservicebrokerapi.org/
• Pivotal Cloud Foundryがコンテナサービス統合を含む大型アップデート、アプリケーション開発は”Kubernetesファースト”な時代に(https://it.impressbm.co.jp/articles/-/15803)
• IBM、Cloud FoundryをKubernetes上で動かすサービスを試験提供開始 (http://www.atmarkit.co.jp/ait/articles/1804/19/news093.html)