さらばスパゲティコード、「マイクロサービス」で分割 :日本経済新聞
なんかおかしいと思いません？
「さらばスパゲティコード、「マイクロサービス」で分割 3大クラウド新技術（4）」
まず、「クラウド」の話は関係ないよねこれ。マイクロサービスを構築する際にDockerみたいなものを使いがち、というのは確かだけど、それは別にクラウドサービスじゃないんだよなあ。
で、マイクロサービス「で」分割ってのがそもそもおかしい。なにをよ？スパゲッティを細かく切り刻めってこと？確かにそれなら絡まないかもしれないけど、繋がってもいないよねｗｗｗｗ
まあ、これだけならタイトルが悪いだけではあります。マイクロサービスはスパゲッティコードとオサラバするための手法ではありませんからねえ。
さて、マイクロサービスという以上は、従来型のモノリシックではない、それなりに機能的に疎結合を目指したコンポーネント群からなるアプリケーションに比べても更に境界線が引かれた「サービス」を組み合わせたシステムを構築せねばなりませんが、そのサービスが有用であれば有用であるほど「しがらみ」ができてしまうのも一つの大きな課題です。単に外部に使ってもらっているサービスならともかく、「自社のビジネス要件を実現するため」のサービスであれば、サービスをいざ変更したくなった場合に旧バージョンとの並行稼働など意味をなさないこともよくありますよね。そうすると、そのサービスって一見独立しているけど使う側の事情に縛られた身動きの取りづらいものになっていることになり、システムは疎結合だけどビジネスは密結合みたいななんだかわからない状態になってしまいますよね。そして、そのサービスは他のサービスの要件に強く依存しており…みたいな。
こうなるとサービス間の関連性がスパゲティーコードよりも更にわけのわからないレベルでこんがらがってきます。ほとんどタコ足配線状態。
マイクロサービスを利用する際はなぜマイクロサービスでならなければならないのか、をちゃんと考える必要があるし、大抵の場合、必然性など無いことがわかります。特に全体のサービスを通して一貫したトランザクションが必要な場合は従来型のアーキテクチャよりも複雑化することが多いし、密結合に近づく場合も多いですよね。将来的な処理の増大に備え、スケーラビリティが必要、というのは多少動機になるかもしれません。モノリシックなシステムのスケーラビリティは柔軟性を持ったものになりづらいのは確かです。でもそれが譲れない要件じゃない限りは、アプリケーションのアーキテクチャそのものの都合ではなくて、開発チームの形態とその継続性によって決めたほうが健全な気もしています。
いずれにしても、スパゲティーコードを書くような開発者がマイクロサービスを設計・開発したらマイクロサービスが本来目指している形にはなり難く、パフォーマンスがそもそも出ないダメシステムになりそうですけどね。
