先週の (Emit) カンファレンスでは、卓越した講演の数々、興味の尽きないパネルディスカッションが行われ、サーバレスコミュニティの優秀な仲間たちに出会って貴重な意見交換をする機会がたくさんありました。

そこでは誰もが一様に、コストこそがサーバレス適用の推進の鍵だとみなしていました。オンデマンド実行と生来の弾力性は、稼働率を最適化しつつ、稼動時間と信頼性もさらに高い状態に保ちます。従量課金制はコストを直接的に定量化できるものに変えました。場合によっては 桁外れの 節約 になる可能性があります。パネルディスカッションで、Gartnerのアナリストの Anne Thomas は、企業クライアントは”コスト”が有利という理由からサーバレスに興味を持つ、と話しました。

しかし、クローズドなシステムにフリーランチはありません。メリットを得るには何かを犠牲にしなければならないのです。テクノロジーにおいては、そのメリットと引き換えに支払う最も一般的な通貨は”複雑さ”です。

大規模な負荷の下で確実にスケールできるよう、モノリスがマイクロサービスに置き換えられた時、 それはフリーランチではありませんでした 。結果整合性の対応、非同期性、レイテンシとフォールトトレランスの処理、APIとメッセージスキーマの管理、ロードバランシング、ローリングアップグレードの実行などなど、利便性と引き換えに、膨大な量の割り増しの 複雑さを代価として 払っています。

どこが複雑になるのでしょうか。そしてそれを管理するにはどうすればよいのでしょう？

（図の注釈：モノリス、マイクロサービスからサーバレスへ、メリットを得ると複雑さが増す）

上の図を見てください。オレンジ色のブロックはコードを表します。マイクロサービスからサーバレスに移行するにつれ、1つ1つのコードのブロックは小さく、シンプルになる一方で、全体の複雑さは増します。この割り増しの複雑さの中身はほとんど”ワイヤリング”によるものです。つまり、設定、デプロイのスクリプト、DevOpsツーリングアーティファクト（テンプレート、レシピ、プレイブック、Dockerファイル…）など、ソリューションをクラウドに持ち上げ、保持するために用いられるあらゆるもの、オレンジ色のブロックの間を埋めるグレーの部分がそれです。これを見ると古いロシアのジョークを思い出さずにはいられません。

空気は何でできているの？

えっと、分子だよ！

じゃ、分子の間には何があるの？

えっと、もちろん空気だよ！

このコード間のワイヤリングという代物、コードだったらどれだけよいか！　そしてこれこそが、”コードとしてのインフラ”だと唱えるDevOpsのあり方なのです。DevOpsは（別の定義を与えるとすれば）、マイクロサービスによってもたらされた余分なワイヤリングの複雑さを抑えるフレームワークとツール集であると言えます。

サーバレスがマイクロサービスに取って代わる時も、フリーランチではないでしょう。巨額のコスト節約と引き換えに、さらなる複雑さという代償を払うことになります。

サーバレスシステムには、マイクロサービスよりもシンプルになる部分もあります。仮想マシン、ネットワーキング、ストレージ、オペレーションシステムを扱わないので、インフラのプロビジョニング、設定、監視、修復といった大きなオペレーションの負荷から解放されます。関数はシンプルなプログラミングモデルで、主にビジネスロジックに焦点を当てています。実行環境は緊密であり、”連続するX-Ray”の下でコントロールされます。 @AzureFunctions のプロダクトマネジャーである Chris Anderson は、関数の実行によって問題の特定がいかに簡単にできるようになったかを強調しました。

しかし、やはりエネルギー保存の法則に例外はないので、関数がシンプルになると、放出された複雑さはどこか別の場所に移動します。複雑はどこへ行ったのでしょうか。そしてそれを管理するにはどうすればよいのでしょう？

複雑さの一部はクラウドPaaSサービス（JPaaSとでも呼びましょう）に委ねられています。Amazon API Gateway、S3、Kinesis、SNS、 DynamoDB、StepFunctions、あるいはそれらのAzureとGCPの仲間は、あらゆるサーバレスソリューションで力を発揮します。すぐに使うことができ、完全に管理され、豊富な機能を持ち、”無限大の”スケールが可能で、従量課金制です。これらのメリットを得るために、私たちは喜んでコントロール（もう1つのテクノロジー上よくある通貨）を諦め、インフラとボイラープレートの懸念から解放される方を選びます。マイクロサービスの “スマートなエンドポイントと処理能力のないパイプ” が、”処理能力のないエンドポイントとスマートなパイプ”に戻ったらどうなるか、そのワークフローはどうなるか考えてみましょう。少しだけ時間をかけて、この振れ幅について検討してください。

時に、コントロールを放棄したのが裏目に出て、かつてはシンプルだったところで複雑さが急上昇することもあります。CloudFormationテンプレート経由でAWS API Gatewayにバイナリヘッダを設定していると、マイクロサービスのコード内で行っていた操作の明快さが恋しくなることでしょう。機能の充実したJPaaSサービスを使うには、相当の専門知識が必要です。そして、その知識は普通のプログラミングやCSとは異なり、プラットフォーム間で変換できません。DymanoDBを知っていても、それはBigTableを学ぶ際にはほとんど役立たないのです。

とはいえ、JPaaSへの委託は最終的にはプラスであり、複雑さのかなりの部分をカバーします。しかし全てではありません。繰り返しになりますが、複雑さの別の部分は”ワイヤリング”にあります。

関数は小さくなりますが、理解すべき関係性、管理すべき依存関係はより多くなります。関数はシンプルになりますが、理論的なフローを含みません。ロジックとエンドツーエンドのソリューションはイベント駆動です。もはやコーディングアーティファクトには属さず、推論が非常に困難になります。

この側の複雑さは今日、どのように対処されているのでしょうか。あまり良い答えはありません。それを管理下に置くにはスーパー技術者（たち）が欠かせません。処理方法とルーツは未だ追いついていません。サーバレスフレームワークは雨後のタケノコのように出現していますが、ほとんどはFaaSで往生し、解決済みの同じ問題のバリエーションに過ぎないようです。最も進んだ「サーバレス」のフレームワークでさえ、そしてサーバレスがFaaSを超えていると認識し、その他のサービスにプラグインとネイティブリソースを提供している人にとってさえ、「サーバレス」は、サーバレスソリューションのエンドツーエンドワイヤリングの複雑さをカバーしていないのです。正規の HelloRetail サーバレス プロジェクトコード を例に取り、どれだけの複雑さが放置されているのかを調べてみましょう。”プロジェクト”、サーバ相互とJPaas上の依存関係、デプロイの命令、イベントタイプとスキーマ、それ以上に多くの事項がフレームワークにカバーされていません。それらについては部分的にスクリプトがあり、部分的にドキュメントに記載されていますが、主に”スーパーエンジニア”の頭の中にあるか、トライバルナレッジ（言語化されていない暗黙知）のままのようです。（これはソフトウェアにおいては”トラブルナレッジ”とも呼ばれます）

DevOpsはどうでしょう。役に立ちそうでは？　答えはノーです。少なくとも、完全なソリューションでありません。1つに、DevOpsの関係者は、サーバレスよりもkubernetesに群がっています。なぜでしょうか？　いわゆるメイカー志向のDevOps的な友人たちはサーバレスを研究できるようなインフラのノブとレバーを持っていないのでしょうか。あるいはもっと根源的な理由かもしれません。つまり、DevOpsは別の問題空間、マイクロサービスに対する応答なのであり、多くのマイクロサービスの仮定がもはや成り立たないため、サーバレスに完全に適用できないのです。”SSHでのクラウドボックス接続”を取り除くだけで、DevOpsツールセットの半分は使えなくなります。Terraformなどは、クラウドインフラを体系化するために構築されましたが、それでも、マイクロサービスのDevOpsで使われているほどには、サーバレスコミュニティでは好まれていません。

結果として、今日のサーバレスは確立されたオペレーションフレームワーク、パターン、その複雑さを抑えるツーリングを欠いたままです。スーパーエンジニアなくしては、エンドツーエンドのソリューションの発明、複雑さの抑制はできません。これらのスーパーエンジニアは、既存の道を燃やして成功への過程を示し、パターンが現れるのを助ける人でなければなりません。しかし、GartnerのAnneが(Emit)カンファレンスのパネルディスカッションで指摘したように、フレームワークとツーリングが追いつかない限り、サーバレスの適用が広まることはないでしょう。

過去の数々の事例が示すように、困難はチャンスです、DevOpsはマイクロサービスの複雑さを抑えるために登場し、クラウドアプリを”可能”にしました。きっと、サーバレスの複雑さを抑える何かが現れ、クラウドアプリを”経済的”に変えるでしょう。いずれにしてもそれは大きな転機になります。お金の話となれば、経済的な力は完璧に機能します。

サーバレスのコスト節約のメリットは非常に明確で実体のあるものです。主要なクラウドベンダーからサーバレスへの移行の後押しは非常に強くなるので、複雑さが克服され、サーバレスのアプリケーションが主流になるまでに長くはかからないはずです。