冪等性についての話
冪等性（べき等性）とは、「同じ動作を何回行っても、常に同じ結果になる」という性質を表す、数学由来の語です。昨今の開発・運用最前線における重要概念であるにもかかわらず、恥ずかしながら、今までこの語を知りませんでした。
亀田氏は、「人間にやらせるとバグります」「定常的に作業を行うものは、API経由でスクリプト化してくださいね」という趣旨のことをおっしゃっていました。私としては、「冪等性の実現は、メカニズムを以て行われなければならない。人間というのは、間違えるのが本質であるから。」という趣旨であると認識しました。
物事をよくしたいという意思が、 常に物事を改善させるとは限りません。 何かを成し遂げるには、 仕組み（メカニズム）が必要です。
上記は、Amazonの創業者にして現在のCEO、2019年時点で世界一の資産家でもあるジェフ・ベゾス氏の発言をAWS Japanが翻訳したものです。確かに、自己改善が風習として根付いているような組織であれば、自己改善の目的意識や方法論といったものも仕組み化されていますよね。
ベンダーロックインについて
基幹系ではないサービス系のシステムについて、亀田氏は「そもそもベンダーロックインは問題にならない」という趣旨の発言をされていました。というのも、「昨今のユーザーエンゲージメントは、非常に足が速い。ベンダーロックインされるされない以前の時点でサービスが陳腐化するものと考えるべきである。」とのことだそうです。逆に、そうそう陳腐化しないサービスというのは、多くの場合は社会の根底に関わるサービスであり、そっちはそっちで「社会的影響の大きさから、失敗が許されないので、現場が精神的に疲弊する」といった問題があってつらいです。
モノリシックアーキテクチャ
大きな単一の機能により、一つの処理を実現するアーキテクチャのことをモノリシックアーキテクチャといいます。恥ずかしながら、今までこの言葉の意味は知りませんでした。
モノリシックアーキテクチャは、スタートアップ期においてはメンテナンス性に優れる利点の恩恵が大きいモデルです。しかしながら、サービスが大規模化してくると、一人の手には負えないほど爆発的に問題が肥大化・複雑化していくのが大きな欠点です。亀田氏の話によれば、AWSも「モノリシックアーキテクチャの壁にぶつかり、マイクロサービスアーキテクチャに移行した」という歴史を経たのだそうです。
マイクロサービス
マイクロサービスの開発モデル
亀田氏の話を聞いた限りにおいては、アジャイル開発モデルというよりは、むしろスパイラルモデルやインクリメンタルモデルのような繰り返し開発型のモデルに類似している、という認識です。伝統的な繰り返し開発型モデルに比べて、各モジュールがより疎結合であるというのが大きな違いでしょうか。
単一責任とドキュメンテーション
亀田氏の話を聞いた限りにおいては、サービス実装においても、単一責任の原則は重要であるようです。その帰結として導かれるのが、マイクロサービスにおいて、ドキュメンテーションは極めて重要であるという原則です。アジャイル開発モデルとは一線を画する話ですね。以下で自分なりに説明してみます。
各マイクロサービスにおいて、外部との唯一の接点はAPIです。APIの仕様は、外部から完全にわかるものでなければなりません。単一責任の原則により、APIの仕様変更を伴わないマイクロサービスの仕様変更はありえません。ゆえに、マイクロサービスにおいて、ドキュメンテーションは極めて重要である、ということになります。
こんな感じでしょうか。
マイクロサービスとステートレス
マイクロサービスにおいて、ステートレスは必要条件である、とのことでした。私としては、各マイクロサービスが内部状態を持ってしまうと、サービス全体として冪等性が破綻する、ということが問題だという認識です。
