現在弊社ではマイクロサービスへの取り組みを進めております。
いまさらマイクロサービスとは云々という話がしたいのではありません。
ただ何故いまこのテーマに取り組んでいるのか、というところ少し話してみます。

古くは前職在籍時、システムリニューアルに取り組んでいた時、SOA（サービス指向アーキテクチャ）と
いうものを知りました。
2008-09年くらいの話です。
当時システム設計を進めていく時に何度も考えさせられた課題への一つの答えがこのSOAにあると考え、それを実現するにはどういう取り組みにより叶うのか、ということを学びました。
ところが、既に開発は進んでいて、ある程度の方向性が見えたときには時すでに遅し、取り込むことは叶いませんでした。
その後もこの課題に何度も直面し、そのたびにこの時の葛藤を思い出しました。
それから数年が過ぎたときマイクロサービスという概念が脚光を浴び始めました。
なるほど、これはSOAの一つの形だな、と当時感慨深い想いを感じたものです。
またこのマイクロサービスは独立したシステムであり、疎結合により多様なシステムと連携を果たしそれぞれは限られた範囲のスモールシステムであるという姿を持っていました。
あらま素晴らしい、と思っていた時（既に現職で起業済み）、マイクロサービスを構築するという案件に加わることができました。
その案件は結果的にカットオーバーを見ることなく、途中でチームは解散する失敗プロジェクトとなりました。
そこにはマイクロサービスならではの技術課題が山積し、主体となって進めていたチームが結果的にはギブアップし、客先が案件をクローズすると判断しました。
私は機能仕様側のチームにいたため、技術課題への取り組みには参加できていませんでした。
ただそこで何が起きていたのかをいろんな関係者にインタビューしてある程度は把握できていました。
当然問題は一つではなく、外から見ても足りていないことが少なくありませんでした。
数多くの技術課題の一つにトランザクション管理の難しさがありました。
Sagaのオーケストレーションで行うとしていたものが、不完全な設計で機能しなかったのです。

その後私どもの社内で自社サービスの開発を行うことにしました。
その際に採用するアーキテクチャーとして、今後のWEBサービスとしての拡張性を確保するためにマイクロサービスを選択しました。
ただ言わばリベンジのノリが無かったかというとウソになるほど、この技術にこだわっている自分がいました。
そしてこの開発チームの編成にはかつて失敗案件となった際の基盤構築を担当したチームのメンバーと組むことにしたのです。
彼らには失敗という経験値が備わっていることが最大の理由であることは言うまでもありません。
ちょうど同時期にこの基盤の導入に積極的な顧客の支えもあり、いくつかのトラウマを乗り越え、この度マイクロサービスのJavaアプリ基盤として完成することができました。
今後この基盤をベースに自社サービスの拡充および様々な案件への適用を進めていきたい思っております。

そして何故ここにこだわるのか。
それはやはり様々な可能性を感じているからです。
巷で言われるマイクロサービスのメリット／デメリットはほぼ語られているとおりに存在します。
それでもメリットを享受することに大きな価値を見出せるシステム・組織・機能を持っている企業にとってやはり魅力的なソリューションであると思います。
でもこれはあまり簡単な道ではないことも事実です。
だから面白い、そう感じているのです。
この度完成した基盤は、これから実際のアプリに展開されていく過程で様々な未熟さを露呈し、その対応に追われることとなるでしょう。
いずれこの基盤が「マイクロサービスの」と言わずとも様々なシステムに適用され、新たな価値を作ることに役立つ日を願いつつ、これからこれを育てていきます。