ツイートで流れてきて「Post-Microservices(マイクロサービスの次)」というキーワードに興味があったので、原文を読んでみることにした。
原文のタイトルは「マイクロサービスの道」となっていて、Post-Microservicesという雰囲気はしない。Twitterでは盛って書いたのかな。
「step backすることにした」と書いてあるが、要するに創業当時にmonolithだったものを2017年に一念発起してmicroservicesにしたが、ここにきて再びmonolithを考えるということのようだ。
Airbnbは自動化とツール化に投資してきたが、これらを速いサイクルで回すにはマイクロサービスよりモノリスがよいとのこと。
多くのマイクロサービスが相互に接続すると小さな変更ですら相互関係が複雑になるので所有権と可観測性とツールの3つを強化することとした。
そこでMicro+macroservicesという新しいアーキテクチャ。要素としてはUnified APIとCentral data aggregatorとService block facade APIの3つで交際されていて、Central data aggeregatorがglue(糊)の役割を果たし、Unified APIとService block facade APIがマイクロサービスにイテレーションや抽象化をもたらす存在となっている。
ここが話のキモだと思うのだが説明が少なすぎて頭に入ってこない。想像も交えると、step backと言ってるもののマイクロサービスからモノリスに戻そうというわけではなく、Post-Microservicesと言ってるもののMicroserviceそのものを一定のルールの下で推進して所有権とか可観測性を損ねないようにしようといった感じか。
Conwayの法則だとは書いてないが、こういったアーキテクチャにするため組織も似たような構造にしたというので、まさにConwayの法則だ。
さらにMicro+macroservicesを推進させるチームを発足し「モバイルアプリのdeprecation(償却)を12か月にする」「モノリスの負債を可視化する」「頻度の低いエンドポイントはsunset(衰退)させる」「移行を長期的に保有する」「depreciation(償却)をインパクトがあるものと認識する」といった5点をリードしているという。
こちらも、読んでてよくわからなかったのだが、いざアーキテクチャを移行する段階になって読めば、納得できるものもあるかもしれない。