クラウドネイティブとスモールスタートのミスマッチ
「コンテナをベースに各サービスを分割した、クラウドネイティブを意識した構成でシステムを開発しました。これを稼働させてサービス開始したいのですが、小規模な利用者数から始める（スモールスタート）ときは、クラウド上で稼働させると小さなコストから始められる（スモールスタート）のですよね？ 例えば……月額〇万円ぐらいで……？」
そう聞かれて、答えに口ごもる。そう期待するのは、すごくよく分かる。でも期待したようにはいかないことも多い。月額数万円、それも後半になることもある。そうすると、年間では100万円に届く。
「クラウドって従量課金なんですよね。使った分だけお支払いなんですよね。だから利用者数が少ない時は費用も小さくなりますよね？」
クラウドサービスの基本的な考え方はそう。でもクラウドネイティブは、ちょっと違う。これを定義しているCloud Native Computing Foundation、略称CNCFは、こう始まった。
2014年。Googleは、コンテナのオーケストレーションに使用していたBorgという内部プロジェクトをオープンソース化した。プロジェクトを着地する場所がなかったため、GoogleはThe Linux Foundationと提携してCloud Native Computing Foundation（CNCF）を世に送り出した。これにより、Kubernetesやその他のCloud Native Solutionの開発と、コラボレーションが促進された。Borgの実装はGoで書き直され、Kubernetesに名前が変更され、はじまりのプロジェクトとしてCNCFに寄贈された。
クラウドネイティブの始まりは、Googleがその巨大サービスを安定的に稼働させるための仕組みやノウハウを共有したところから始まった。そのコアであるコンテナ・オーケストレーションは、すばらしい拡張性（スケールアップ）と自律性（オートヒーリングとオートスケーリング）を提供してくれる。それは、常にちょうどよい規模で動作し、ちょうどよい費用を実現してくれるということでもある。
でも最低限、オーケストレーターとホストは常時稼働させておく。最小構成がちょっと大きめ。だから縮小性（スケールイン）に関しては、そこまで小さくならない。上ででてくるKubernetesで言えば、こういうことになる。
1つのマスターノードと1つのワーカーノードがクラスタの最小構成です。
冗長性を考慮するとMasterは最低3台のサーバーが必要です。また、Workerの方も普通に考えて最低2台サーバー構成になるはずです（1台でも構築できますが、１台でいいのならそもそもKubernetesを使う必要性がうすいです）。つまり、現実的な構成だとサーバーが最低でも5台必要になります。
Masterというのがオーケストレーター。Workerというのがホスト。動かしてみるだけでも合わせて2台、現実的な構成では合わせて5台が常時稼働する。「使った分だけお支払いなんですよね」という話で言うと、この2台または5台はずっと使いっぱなしなので、フルタイム課金されてしまう。あまりスモールにならない。
「じゃあコンテナを使うなというんですか？」
そうでもない。オーケストレーターやホストといった「サーバーを持たない」、つまり「サーバーレス」という選択肢がある。
コンテナを動かし続けたいなら、ホスト部分がサーバーレスになる、AWS FargateやAzure Container Instancesといった選択肢がある。もう一歩踏み込んで、コンテナを動かし続けるのをやめる選択肢もある。外からの呼出しを受けてから自動起動し、処理を終えたら自動終了すると、動かす時間と費用が最小化になる。AWS Lambda、Azure Functsions、Google CloudのCloud RunといったFaaS（Functions as a Service）に分類されるサービスが、この数年でコンテナ実行に対応していて、これを実現してくれる。
ただ、クラウドネイティブっぽくはなくなる。まずKubernetesではない。次に、もしFaaSやサーバーレスのコンテナホストではなく、もう一歩譲ってクラウドベンダーの用意する「マネージドKubernetes」を使った場合すら、次のようなことになる。
マネージドKubernetesを使う＝結局ベンダー依存になる。ということで、特定の企業に依存しない（ベンダーロックがない）というKubernetesのメリットが薄れてしまいます。そうすると、場合によってはAWS独自のコンテナマネジメントサービス「Amazon Elastic Container Service（Amazon ECS）」など、専用のサービスの方がKubernetesよりも扱いやすい可能性があります。
ましてやFaaSやサーバーレスともなれば、使い方もそれぞれ違うから利用者のスキル的にもベンダー依存になる。ベンダーロックインがないことは、Kubernetesのメリットというだけではなく、クラウドネイティブの提案価値にも挙げられているけど、そこからはだいぶ遠くなる。
クラウドネイティブやコンテナに問題があるわけじゃなく、目的が合わないもの同士を組合わせようとすると相性に苦労しがちだという話だ。スモールスタートは、利用拡大に応じて費用が膨らむのは許せるけど、利用規模が小さい時の最低費用＝固定費は許せない。クラウドネイティブは逆に利用拡大に応じて膨らむ費用を最適化することは譲れないけど、最低費用＝固定費は許容する。目的の違いのために、価値観が違う。譲れるところと譲れないところが真逆なのだ。
よく技術選定というと、機能や費用の〇×表を作って比較するシーンを見かける。でも近年、IT製品やクラウドサービスの数と変化が膨大になってそんな比較が追いつかなくなっている。
その中で、まず考えるべきなのはその技術の目的じゃないかな、と思ったりする。いわゆる、パーパス・ビルド・テクノロジーの時代として。僕がクラウドコンピューティングやWeb2.0やアジャイルなどの歴史や起源をたどりたがるのは、正確な定義とか正当性を問題にしたいのではなく、パーパスを確かめておきたいということなのだ。それが気持ちよくテクノロジーと付き合うコツだと思う。