多くの組織は、マイクロサービス（粒度の小さい、再利用可能な機能のユニット）を、一枚岩の反応の遅いシステムを分割して、より敏捷性の高いものに変えるための希望の光のように考えている。しかし、ビジネスで用いられるほかのテクノロジと同じで、マイクロサービスは万能薬ではないし、一つ間違えば事態は簡単に悪化する。要件や変更の要求が積み上がるにつれ、ソフトウェアの提供が滞り、スケジュールが期待されていた範囲から外れる可能性は十分にある。特に、多くのことが手動で進められている開発組織ではそうなりがちだ。
最近投稿された2つの記事は、安易にマイクロサービスの開発と導入に手を染めることを戒めている。1つ目の記事は、Asurionのエンタープライズアーキテクチャおよび戦略担当主席アーキテクトであるVijay Alagarasan氏のもので、もう1つの記事はIT戦略コンサルタントのTony Bradley氏のものだ。
マイクロサービスとは何だろうか。Alagarasan氏によれば、マイクロサービスとは「分散した、機能ドメインとして整理されている業務上の機能をサポートする、粒度の細かいサービスを構築することにより、サービス指向アーキテクチャ（SOA）を提供するアプローチ」だ。要するに、これはよりスケーラブルなSOAだと言える。Bradley氏は、マイクロサービスとDevOpsの関係性を指摘し、これらを「DevOpsとコンテナを包含し、アプリケーションを小さな個別のコンポーネントに分割する、ソフトウェア開発と導入の革命」だと呼んでいる。
これらのことを念頭に、この記事では、マイクロサービスを基礎としたプロジェクトの計画と実施に役立つガイドラインを紹介する。経験を積んだIT業界人なら、過去のテクノロジで言われていたこととの共通点を見いだすかも知れない。万有引力の法則のように、ずっと残り続ける真実というものはあるのだ。
1．IT部門だけでなく、事業部門にも価値を提供する。前述の通り、これは正しいことが実証されているルールだ。このルールは長年の間に登場した多くのテクノロジでその正しさが証明されており、マイクロサービスのプロジェクトが正当化できるものかどうかを検討するのにも有効だ。「マイクロサービスに対するアプローチは、組織に恩恵をもたらすものでなければならない。価値をもたらし、業務上の目的とよく噛み合うものでなくてはならず、ただマイクロサービスの流行に乗るためのものであってはならない」とBradley氏は述べている。
2．現在と将来のマネージャーと開発者に指針を示す。サイズが「マイクロ」であっても、これらのサービスはほかの大型ソフトウェアプロジェクトと同水準のマニュアルとサポートを必要とする。
3．ガバナンスの体制を整備する。テクノロジを基盤としたほかの取り組みと同じで、しっかりしたガバナンスがなければ、マイクロサービスの取り組みは簡単に軌道を外れてしまう。Alagarasan氏は、「これを予防するには、サービスに関連のないビジネス機能が追加されないよう、ガバナンスを行う必要がある。サービスとビジネス機能は明確に対応していなくてはならず、その境界線から外れたものを追加すべきではない」と述べている。さもなければ、サービスは「緊密に結合したアーキテクチャになってしまい、提供時のエントロピーは増大し、結合の強さが混乱を生み出すことになる」と同氏は警告している。
