チームに来社して戴きました。近藤和彦君など元同じチームの人や、弊社担当営業の方も来られてていました。私は別件のテレカンに入っていたのですが、途中から参加したので、サマリー等を写真とともに紹介したいと思います。チームのお二人、そして私、という記念写真です。成本さんは、私がマイクロソフト入社3年目で公共営業部門のアーキテクトをしていた頃に、エバンジェリストとして異動を勧めてくれた人で、それ以降、私はデベロッパーマーケティングチームに所属し、テクニカルエバンジェリストとして10年以上在籍しました。現職の社長とも、彼のチーム在籍2年目に、イベントや案件で知り合っており、その意味では、大変縁が深い人と言えます。まわりまわって今ここにいるのも、彼のおかげというわけですね。2010年頃に米国本社に移籍して以来、今年で10年目、日本人エンジニアとしてのサバイバルの秘訣なども、今度来社されたときに弊社社員に語って貰うのも良いかもしれないですね。記念撮影セッション内容について弊社の案件絡みのコンフィデンシャルな内容の質問等も多かったので、そのあたりは触れられませんが、一般論としてもいろいろ説明して戴いたので、そのあたりの内容を写真とともにご紹介したいと思います。参照アーキテクチャについてマイクロサービスの4要件マイクロサービスの4要件についてのお話です。このあたりは私もいろいろなセミナーや勉強会でのセッション登壇でお話しすることが多いところですが、特にこの4つをコアの要件として説明して戴きました。独立して故障から修復できる上の3つは良く語られているところですが、4つ目の“障害についても独立している”というのは、結構重要なことで、当たり前なのですが、あまり書いてある文献がないですので、押さえておいて戴きたいところです。要は、サービスごとに開発がしたいためにマイクロサービスが生まれたという背景があるわけです。政府の調達の話でも、デジタル手続法案成立後の現在、本格的にクラウドファーストの方針の下で、調達を進めていくことになっており、私は特に国レベルのマイクロサービス基盤の整備、というところをデータ連携の観点から纏めていくチームに入っています。このあたりはまた別の機会にご紹介できればと思っています。成果物もどんどん出していきます。政府CIOポータル失敗しがちなパターンさて次に、失敗しがちなパターンについて、説明して貰いました。リポジトリが統一されててサービスごとのデプロイができないこれらはよくやりがちな失敗として挙げられますよね。最初の設計時に、そもそもこのあたりを意識してやって行かないと、なかなか難しい課題に、途中で直面する、ということになるわけです。4つ目の内容は、もはやデータを共有しているわけでサービスとして独立性を維持していない状況になっています。連載でも詳細を書く予定ですが(すみません、ちょっと遅れています)、要は分散システムとして、メリット・デメリットを意識して、マイクロサービス基盤の設計をしていかなければならないです。エンタープライズにおける分散システムの設計そのものに立ち返って、検討していかないと適切な設計はできないので、そのあたりも注意が必要ですよね。一つのサービスのダウンが他のサービスに影響しない上手くいく例を上げて戴いています。モデリング等は、最初からこうできれば問題ないに決まっています。問題はどうやってそこを見極めていくかで、一朝一夕には答えは出ません。データベースの分離は、これはやっておかないといけないですよね。最低限ここから検討して、永続化できる単位で、取り組んでいきたいところです。Nugetの活用は重要です。同じような仕組みにしたいですね。あとは、障害の分離のところでも書いた通りです。ガバナンスの問題マイクロサービスの特長マイクロサービスには他にもいろいろ課題があります。特長と言われているところの裏腹にあたるのが課題だと思って戴ければ間違いないと思います。難しいか難しくないかと言えば、サービスの粒度切り出しにしても、全体の設計としても、難しいとは思います。向いてないシステムもあります。必要のないシステムも多いです。それを無理やり偉い人の意向や営業的な理由などで、実装してしまうとそこから大変だったりします。CD42セッションでもお話ししました通り、このあたりは、分散システムの基本にもう一度立ち返って考えて戴くと同時に、どこまで投資対効果が見つけられるか、マイクロサービスを採用して今後5年10年進化する個別のサービスとして育てていく必要&価値があるか、を基本に、採用の可否を検討すべきと思っています。DT52セッションでも予告しました通り、継続的にオンライン・オフラインで、皆様と一緒にディスカッションの機会が持てたらいいなと思っている次第です。今後ともよろしくお願いします。Days%d人のブロガーが「いいね」をつけました。