統合型システムの致命的欠点
先ほど「開発言語や技術トレンド、利用する技術システム基盤に大きなこだわりや制限がなければ」と抽象的に記述したのは理由があります。それは、現在のITシステムでは、この制限が致命的になるケースがより顕著化しやすくなってしまったことです。
例えば、図8のように既にJavaを用いて統合型システムがあったとします。そこに新たに「AI」や「動画・音声」のような機能を追加したくても、それらを実現する為のOSや言語などが既存の統合型システム上では実現が難しいというケースがあります。そのため、統合型システム内に機能をどうしても組み込めないという事態が生じます。
これまで多くのエンタープライズ・システムでは、事務型の処理を扱う場合が多かったのでこのような問題に遭遇するケースは少なかったのですが、ニーズが多様化し、そのため実現する技術までもが多様化してしまうと、すべて自前で作成することは現実的ではありません。つまり、業務システムであっても、マイクロサービスの導入も避けられなくなってきているという事です。
アーキテクチャの選択パターン
結局、マイクロサービス型だけでも、統合型システム型だけでも解決は難しいというのがわかったと思います。企業や形態毎にどちらの方がより多くの場合のケースをカバーしているという割合の偏りはあっても、100%どちらかで解決できるというものでもなくなっています。
ここまでの説明を読めば想像できる方もいるかと思いますが、筆者が携わる会社では、図9のようなポリシーでどちらのアーキテクチャを選択するのか決めています。
例えば、主に以下のような場合には、統合型システム型を採用します。
- 機能は同じでも、業態毎に扱うデータやタイミングが異なるケースがある。
- スケジュールやコストが事業計画と密接に関係している。
一方、マイクロサービスを採用する場合には以下の条件を満たすかを基準にしています。
- 業務形態等にかかわらず同じ機能が求められる。例えば、法令で定められている場合等がこのケースに該当する。
- 技術の高さや難易度が求められ、変化への対応よりもノウハウや経験の蓄積のほうが優先される機能である。
- SaaS業者等が提供している機能だけで目的を達成することができる。
- 他のマイクロサービスと業務上で致命的な問題となりえる連携は必要ない。
簡単に言えば、事業側担当とともに決める必要がある機能は統合型システム型で作り、法令や技術部門だけで判断可能な機能はマイクロサービスにしています。
これは積極的にマイクロサービスを技術的に採用することを強みとしている場合でなければ、多くの場合、同じような判断になるのではないかと思います。
最後に
これまでマイクロサービスと統合型システムについてのメリット・デメリットを紹介し、それらを組み合わせないと実際は難しいと述べてきました。しかし、これでは結局、全体としては非常に結びつきが強い統合型システムになってしまうと思う方もいると思います。
今回は統合型システムとマイクロサービス間の連携についてはあえて言及しませんでした。次回は、この連携を行う部分の技術やアーキテクチャについて紹介したいと思います。