Cloud Foundry vs Kubernetes

PaaS をどう使い分けるのか?

最近、Cloud Foundry(CF) と Kubernetes(k8s) に注目しており、PaaS や CaaS などと言われたりして、実際、何が異なるのかを整理する必要があると感じました。
正直、エンジニアとしては名称などどうでもよくて、これらのツールをどう使い分けたら機能するのかというところに興味があるわけです。

そんな中、CF,k8s の両方のコミッターだった KarlKFI さんがStack Over Flow で答えていた内容が参考になったため、翻訳と自分なりの整理を試みたいと思います。

*そもそも CF, k8s がわからんぞという方は、
CF: jakopenさんのスライド

k8s: コンテナ管理システム「Kubernetes」について調べてみました

を参考にされてみてください。

Cloud Foundry vs Kubernetes

CF では Application PaaS, k8s は Container PaaS (あるいは CaaS) と呼べるでしょう。
CF では内部的にコンテナが使いますが、それをユーザには意識させません。そして、アプリケーション開発に主眼を置いているため、ビルドパックやOrg, Spaceによるユーザごとのアプリケーション管理が可能です。

一方で、k8s はアプリごとコンテナ数やDockerファイルから直接コンテナを作る機能などのように、k8s上のコンテナに直接影響を与えるような設定をユーザが設定できるようにしています。

しかし、これらの境目は技術的な流行りによって変わりつつあるところで、
* CF が Docker Image を実行できるようになる(かも) Lattice accepts Docker images
* Kubernetes が Docker Image を生成できる機能を追加する(かも) Open Shift
また、k8s を生み出した Google も CFのgold sponserになる など、これからの動向は予想できません。

細かい箇所で異なる点では、
k8s:
1. コンテナの集合であるPod(仮想NICを共有する)自体をスケールすることができる
2. コンテナのイメージを直接デプロイできる
3. OSSのコミュニティが CF より大きく活発 (訳注:これは指標がわかりません。githubのコミッターは CF の方が多いです CF k8s
4. 拡張性が高く、3rdパーティーのプラグインなどを追加できる
5. Web GUI もある

CF:
1. 認証機能が成熟しており、ユーザのグループ分けなどがサポートされている(Org, Space, Role などを設定)
2. 開発したアプリ(php, node.js, python,… のフレームワークを使ったものなど) をデプロイできる
3. ロードバランシングの機構が含まれている(k8sも実装が進んでいる)
4. bosh で k8s と同じようにコンテナのオーケストレーション(デプロイやライフサイクルの監視)が行われている
5. ログやメトリクス(グラフ描画するためのデータ)の集積が行いやすい
6. Web GUI は エンタープライズから提供されることが多い

CF bosh vs k8s

CF と k8s を比較すると上のような話になりますが、実は CF には bosh と呼ばれるオーケストレーションツール上で動作させるため、この bosh と k8s を比較したほうが技術的には妥当な感じがします。

bosh は CF の App だけではなく、様々なコンポーネントの面倒も見ています。また、多種類のIaaS(例:OpenStack, VMWareやvSphereなどなど)上で動作できます。
ただし、boshのコミッターである KarlKFI も「悪夢のように使い方が難しい」 ツールとなっているようです。

一方で、k8s 自体をデプロイする際の抽象化はまだまだ甘いところがありますが、改善はされているようです。
例えば、k8s をDC/OS 上にワン・コマンドで展開する機能が実装されたりしているようです。

結局、どう使い分けるの?

プラットフォームを構築する側からすれば、技術的に似た(コンテナのオーケストレーション)ことを行うため、構築する難しさは乗せるIaaS層やネットワーク、社内の事情によって変化するでしょう。
そのため、目を向けるべきは 誰がPaaSを使うのか? ということです。例えば、簡単なアプリを新規に作ってサクッと公開したいという場合に、Docker Image を用意して、コンテナの設定を行って、…という k8s より CF の方が向いているでしょうし、反対に複雑で大規模な構成のシステムや昔作った秘伝のタレ的なDocker Imageをリリースして、コンテナの調整をしてしまいたいという場合には、k8s の方が向いているでしょう。

もちろん、いつどのような機能がそれぞれのプラットフォームに追加されるのかがわからないため、常に動向を調べる必要がありますが、PaaSを使う人の目線で考えるというのは欠かせない点かなと思いました。

デスマーチはなぜなくならないのか – IT化時代の社会問題として考える

一文で表すと…?

現在の文脈において、なぜデスマーチが起きてしまうのかを3名のソフトウェアエンジニアへのインタビューを基に社会学のアプローチを用いて考察した書籍。

ソフトウェア開発はデスマーチが起こりやすい性質がある

IT業界ではよくある話としてのデスマーチですが、その原因についてあまり考えてこなかったということもあり、読んでみました。
本の中では主に著者がソフトウェアエンジニアに対して行ったインタビュー内容とその考察が記されているのですが、インタビュー内容はうなずきながら読むことができ、また著者が社会学の博士課程を通じて専門としていることもあり、そのインタビュー結果を解釈するプロセスが勉強になりました。

僕が特に面白いと感じたのは、ソフトウェア開発はデスマーチが起こりやすい性質があるという著者の視点です。
本の中でも述べられているように、エンジニアはそもそも「ソフトウェア開発」はどういったプロセスなのかを考えることはあまりありません。確かに僕もただ作りたいと思っているものをコードとして書き出すということをしているわけですが、この作業は抽象的な要求を具体的なものとして落とし込むプロセスだと著者は考え、その性質がデスマーチを起きやすくしていると考察しました。

確かに業務を考えてみると、仕様書や口頭でソフトウェアに関する要求を理解し、実際はそれを微妙にコードで調整しながら、お互いの認識に合う落とし所にプログラムを作成していきます。
つまり、ソフトウェアが完成するまで具体的な仕様は決定せず、時間やコストの見積もりはかなり困難であることになります。例えば、あるライブラリの機能を使ってソフトウェアを作る際に、そのライブラリの仕様が変わる、ドキュメントと実際のコードに差異があったということを経験した方は少なくないでしょう。
その結果、開発に見積もり以上の工数がかかるのは現場のエンジニアの能力以前に、ソフトウェア開発の性質となります。

そのために、製造業的な見積もりを行い、限られた納期を伸ばすという想定がなされないまま仕事が依頼され、エンジニアは死の行進へと向かいます。

遊び感覚のソフトウェア開発もいつまでも遊びではいられない

インタビューを通じて、さらにわかったのはデスマーチに陥る理由はエンジニア側にも存在するとしています。特に若い頃から遊び感覚でプログラミングを行ってきたエンジニアは、仕事は遊びの延長であり、長時間ソフトウェアを書くことを苦にしないという方が多くいます。
しかし、そうしたエンジニアも次第に年齢を重ねるに従って、自身の健康や家族との時間を過ごしたり、両親の看病を行うなど様々な外的要因によって徐々に開発や勉強にかけられる時間が減るという問題が出てきます。

そのようなプレッシャーの中で先の見通しにくいソフトウェア開発は肉体的にも精神的にもエンジニアを追い詰め、最終的に燃え尽きてしまうということが起こってしまうのです。

この本は単純にデスマーチは人・時間が足りないから起こるという結論で済まされがちなところを、上記のようなソフトウェア開発の性質やそこに携わる人や組織の観点からより深く分析をしており、またその分析手法も社会学の方法を取り入れて出来るだけ客観的に試みているところが面白く感じました。

関連書籍

ソフトウェア開発では人数を増やしても仕事は早く終わらない、むしろ長期化する恐れがあるということを世に主張した言わずと知れた著作です。
20世紀中頃まで一般的に行われていた産業では仕事を細分化して、大勢の人に割り当てれば仕事も早くこなすことができていました。しかし、近年、ソフトウェアに代表されるように作るものが複雑化するに従って、人数が増えてもプロダクトの説明や教育に時間がかかり、また仕事を細分化するのが難しいなかで、プロダクトマネージャーはどうしたらよいのかを知ることができます。

個人的には、ソフトウェア開発は手術みたいなもので、プロジェクトマネージャとしての正しい方針はまずプロジェクトの性質を見極め、設計1/3、実装1/6、テスト1/4、統合・実地テスト1/4という割合で時間を配分し、手術と同様、執刀医、副執刀医を決めて、その二人を補助するように他のプログラマを配置すると良いという発想が斬新でした。