マイクロサービスを設計するときはエンジニアの発想を捨てる

マイクロサービスとそのAPIの設計をするときは、ユーザにフォーカスしたデザイナーとして考える必要がある。Nic Benders氏はMicroservices Practitioner Summitのプレゼンでそう主張した。まず、APIを設計し、それからサービスを外から内側に向かって開発するのだ。

Benders氏はNew Relicのチーフアーキテクトを務めている。同社は単一の一枚岩のアプリケーションからスタートした。顧客が増えるに従い、機能が増え、そしてサービスが成長した。この成長に伴って、問題が頻繁に発生するようになった。これらの問題を解決する方法を数年にわたって考えた結果、一枚岩のアプリケーションから、マイクロサービスアーキテクチャへ移行することに決めた。

この移行の中で氏が考える最大の失敗は、エンジニアとして発想してしまったということだ。サービスを内側から外へ作ってしまった。データレイヤから始め、ビジネスロジックに進んだ結果、APIは最後になってしまった。ユーザのニーズではなく、ビジネスロジックに適合するAPIを作るのなら、このやり方でいいだろう。設計フェーズで多くの意思決定がなされたが、APIに制約を持ち込み、ユーザの受け入れを妨害する決定もあっただろう。Benders氏は、デザイナーのように発想するべきだったと、振り返る。

システムを設計するときはデザイナーのように考える必要があります。

デザイナーのように発想するなら、ユーザが解決しようとしている課題と共に新しい製品の設計から出発し、その新しい製品がどのようにしてその問題を解決するのか考え、最後に実際のユーザで仮説を検証する。ユーザはとても具体的なタスクを持っており、考えたモデルとは合わないかもしれない。なので、APIファーストで外側から内側へと設計することが重要なのだ。APIを定義したら、開発者はAPIをサポートするサービスを実装する。氏はこのやり方をテスト駆動開発(TDD)と比べている。TDDでもテストは先に書いて開発を駆動する。

Bender氏はAPIを開発するとき、いつも擬似コードを書くことから始め、APIに対するプログラミングをシュミレーションする。APIから変な感じを受けたら、引数やメソッドを変更する。また、先にドキュメントを書いてしまうやり方も有効だ、と氏はいう。APIを使う人との議論がシンプルになるからだ。

また、Benders氏はシステムの設計はそれを使う人の使い方も変えることにも注意を促す。サービス開発をシンプルにするシステムはユーザのサービス構築を促進させ、ログを簡単に出せるようにするシステムならログ入手も簡単だ。設計の意思決定は、存在する問題を解決することだけに関わるのではない。あるタスクを簡単にしたり、別のタスクを難しくしたりして長期的な使い勝手の舵取りをすることでもある。設計を変えることで、命令することなく、ユーザに特定の振る舞いをするように促すことができるのだ。

また、Anders Jensen-Waud氏もThinking Outside-In: How APIs Fulfil the Original Promise of Service-Oriented Architectureと題して、同様の主題の記事を書いている。