マイクロサービスを大規模システム開発に適用できる可能性と課題

devops教科書もそうだけれど、クックパッドがどのようにMicroservicesしてきたか/How Cookpad shifts to Microservices // Speaker Deckも読んでみると、今までのオンプレでやってきたことの一部をクラウドに置き換えているだけで、やっていること自体に変わりはない、と理解しているのだけれどあっているかな＞アーキテクトな人

例えば、クックパッドの事例は、当初のアーキテクチャで維持管理が破綻しかけてきたから、最新のアーキテクチャにお引越ししたプロジェクト、でしかない。でしかないと表現したけれど、実際にやるためには手間と時間と試行錯誤があるだろうことは想像できるので、その辺りはお疲れです、と。

採用したマイクロサービスも、乱暴に言えば、ライブラリやAPIを使った実現仕様への置き換えだ。ものすごく乱暴な表現だけれど。

そして、こうしたアーキテクチャって、従来あった下表の概念の派生というか、元をたどれば同じ思想なのではないか、と直感的に思うし、PaaSでつくるマイクロサービスを当てはめるとこうなるかと。

１	個別業務システム	業務ロジック
２	共通業務機能	API
３	制御プログラム	インフラ周りAPI
４	ミドルウェア	クラウドサイドの中
５	OS	クラウドのOS

正しいかどうかはわからないけれど、たぶん、そうじゃなかな、くらい。でも、そうイメージできるんだよなぁ。

上表の制御プログラムの列の設計思想は、大規模システムを開発するときの設計思想で、これをまったくプロジェクトをバラして、お互いの都合でリリースしあっているところに業務ロジックというWebサービスやアプリを作っているのが今の時代のやり方なんだろう、と。

クックパッドのマイクロサービス化でのよかったことにあるシステム境界が明確になるなんて、上表のレイヤーであればそりゃ当然だ、と思うもの。

ただ、これもクックパッドの例のテストのサイクルが長いとリンケージする相手のリリースアップがあるとエラーが起きてしまうのも、非同期開発なら当然わかることで、大規模開発ではそれをずれないようにしていたから大変だし、お金も時間もかかるわけで。

そうすると、現在の公共系の大規模プロジェクトはマイクロサービス化を前提としたシステム開発で行けるのではないか、と頭をよぎったり。

そうすると、それぞれ担当するレイヤーや業務に専念することができる、と。

ただ、インタフェースを持つ先方へのリクエストができないから、それで苦しむかもしれない。