microservice
monolithicとの対比
実際には間はいっぱいある
巨大なひとつのバイナリが関係ないいろんなAPIをたくさん提供している
これはこれで設定とかデプロイが共通化できるのでメリットが有る
複数のレイヤーをexposeしている
microserviceが絶対必要なケース
実は無い
compelling use-cases
API 1とAPI 2で相対QPSが時系列変化する場合
API 1 / API 2のリソースを別にprovisioningできたら安くなるんでは?
実際には一個のバイナリがAPI 1+API 2をexposeすれば勝手にbalanceされる
ので、microserviceやる利点はこの場合個別のquotaをenforceすることにある
なので、quota systemがなければ無意味
外向け / 内向け
セキュリティ境界・異なる認証システム
移行時のproxy
リリースサイクルが異なる
実際には巨大バイナリのプラグインホットリロードのほうがいい場合がある
プラグイン
組織境界
サービス設計にもSOLID原則当てはめるべき?
そうでもない
特にSRPとかはどうでもいい
サービスの重さは他の部分にある
自分が重要と思ってること
別実装可能性
これができないと、実装詳細が漏れてきて密結合になる
高度なことをしているサービスはこれが多い
MLとか、特殊なDBとか
高度なencapsulation
内部実装は当然
運用・デプロイ・開発・設計プロセスまで含めてencapsulateされていること
実質的に、独立したマネージャー(or TL)がいる別のチームで、APIの変更議論は最小限ですむこと
TBD: リソースの管理は誰がどうやる?
#アーキテクチャ