先日行われたDevoxx BEカンファレンスで，InfoQは，Red HatデベロッパアドボケートのMarkus Eisele氏に会って，大規模な企業組織内でのマイクロサービスアーキテクチャ採用についての考えを聞くことができた。氏は先頃，マイクロサービスアーキテクチャとツーリング，ベンダ，人々の関係を深く探求する，“Modern Java EE Design Patterns: Building Scalable Architecture for Sustainable Enterprise Development”というミニブックをO’Reillyからリリースしたばかりだ。
InfoQ: こんにちはMarkus, InfoQのために時間を取ってくれてありがとう。まずは自己紹介と，先日 O'Reillyから出版したミニブックについて，簡単に説明してもらえますか？
Eisele: 私はMarkus Eisele，Red Hatでデベロッパアドボケートとして活動しています。15年以上前からJava EEサーバに関係してきて，Java EE専門家グループの一員にもなりました。それ以外では，Javaコミュニティ拡大のために常にアクティブであることを心掛けていて，昨年はJava Championにもなりました。
Red Hatに参加するまで，さまざまな大企業のコンサルタントとして働き，Javaテクノロジを基本とした個々のソリューション案件を支援してきました。この仕事はとても難しいのですが，人生の中でやりがいを感じる時間でもあります。講演やセッションでは，企業IT環境での開発を話題とすることが今でも多いのですが，このような経験を集約して，最近のバズワード(マイクロサービス，クラウド，コンテナ，DevOpsなど)を大局的に把握するように，開発者を支援する活動もしています。
最近では，ESBがもし今日作られるとすればどのようなものになるのか，ということに注目しながら，持続可能なエンタープライズアーキテクチャ全般について話をしています。ソートリーダシップ(Thought-leadership)は素晴らしいと思いますし，新たな方法論やテクノロジの興隆期に時間を費やす人たちの存在は必要不可欠ではあります。しかしながら，大多数の開発者やいわゆるアーキテクトにとっては，それらのアイデアと企業で広く採用されるプラクティスとのギャップを埋める，という作業が課題として存在します。
ミニブックというアイデアはそこから来たものです。現代的なエンタープライズアーキテクチャのアウトラインを示すことで，明日のアーキテクチャの実現に寄与すると同時に，現在入手可能なベストプラクティスの採用も促進しています。Java EEは今日でも，企業で最もよく使われているプラットフォームですから，それらの環境でDevOpsやマイクロサービス，コンテナ，クラウドを採用する場合のギャップと機会には特に注目しています。
Java EEの開発において念頭に置かれていたのが分散アプリケーションのアプローチではなく，単一のモノシリックサーバランタイム，あるいは数多くのさまざまなアプリケーションをホストするクラスタであったことは，秘密でも何でもありませんが，もしあなたがエンタープライズ開発チームの一員で，チームがJava EEでのマイクロサービスの運用を検討しているのでしたら，考えるべき要素はいくつかあります。ミニブックはここで，あなたに一歩先を行かせてくれるのです。
InfoQ: 従来の‘エンタープライズ’企業にマイクロサービスが受け入れられる(あるいは拒絶される)のには，どれ位の時間が必要なのでしょう？
Eisele: 一般的な面で，マイクロサービスは，最近のソフトウェアプロジェクトのすべてにとってのワンストップソリューションにはなり得ないと思います。マイクロサービスが解決するのは，高度に分散化されたフォールトトレラントシステムという，特定の問題空間だからです。100%マイクロサービスというアーキテクチャがどうしても必要なアプリケーションは，全体の20%程度に過ぎないのではないでしょうか。残る80%では，確立されたプラットフォームとランタイムを使った方がよい結果を得られるはずです。しかしながら，モノシリックアプリケーションの保守性に関する基本的なソフトウェア設計原理が，マイクロサービスにも適用されるようになってきたため，そのラインは日を追って不明確になっていくでしょう。
違いがあるのは外部アーキテクチャと通信パターンです。IT産業が例のSOA(service-oriented-architecture)の騒ぎから何かを学んだとすれば，今後５年程度で，マイクロサービスの最善かつ適切な部分は，企業によって完全に受け入れられるでしょう。それまでは引き続き，多くの企業ニーズを解決しなくてはなりません – 中でも重要なのが，ホストシステムとのトランザクションやインタラクションです。開発者の立場からは，これらはマイクロサービスアーキテクチャでは必要ないものだ，と言うかも知れませんが，現実には企業が最も望む部分なのです。
InfoQ: マイクロサービスに移行すると，従来のエンタープライズベンダや製品はどうなると思いますか？
Eisele: 実際のところ，短期間のハイプサイクルに乗せられたプロダクトマネジメントから，“マイクロサービスの洗礼を受けた”最初の製品が生まれるのです。それはESBに特別の機能が追加されるか，既存の機能の名称が変更されるか，どちらかです。将来的にはどちらもそれほど有望ではないばかりか，まったくの誤解を生じさせます。信頼できるベンダならば，既存のプロダクトラインに関連する製品ないし機能を追加することでしょう。そしてもちろん，マイクロサービスへの移行で大きな部分をいつも占めるのが，アーキテクチャのマスタやコンサルティングといったものだと，私は考えています。
私自身は，マイクロサービスプラットフォームをあまり意識しない方がよいのではないか，と思っています。完全な問題空間への技術的ソリューションというものが，あたかも存在するように思われてしまうのではないか，と考えるからです。この点については，明確に否定したいと思います。逆に私は，現代的なエンタープライズ開発(イメージを以下に示す)のピラミッドのすべて対処するベンダや企業を支持したいと思います。これには方法論の変化やベストプラクティスに基づく持続可能なソフトウェアアーキテクチャ，コンテナの分散と協調が可能なインフラストラクチャ，といったものが含まれています。
図１. 現在のエンタープライズ開発ピラミッド
InfoQ: Java EEテクノロジは，例えばSpring BootやRatpackに比較して，Javaベースのマイクロサービスに適していると思いますか？
Eisele: 簡単に言ってしまうと，もっとよい選択肢があります。Java EEはそもそも，開発された要件がまったく違います。使えない訳ではありませんが，このプラットフォームでマイクロサービスを首尾よく完成させるためには，より多くの努力と注意が必要になります。
他にも選択肢はありますし，いくつかはアイデアとしてもかなり有望です。例えばWildFly Swarmを使えば，Java EEアプリケーションをfat-jar，つまり実行可能なアプリケーションにパッケージすることができます。既存のアプリケーションや企業の‘ノウハウ’と，まったく異質のプラットフォームの採用のバランスを取るのは，ほとんどの企業にとって困難な作業です。あるいは(技術的な)新顔の方がフィットするかも知れませんが，移行に必要な努力と資金はますます多くなります。
80/20の観点からそれを見直してみて，私は，JavaとJava EEベースのソリューションがマイクロサービステクノロジを使った既存のアプリケーションを補完するようになるのではないか，と思っています。
InfoQ: ドメイン駆動設計(DDD/Domain-driven Design)運動から派生した概念が，普及にこれほど時間を要しているのはなぜだと思いますか？
Eisele: いくつかのシステムの設計やアーキテクチャを担当してみて，私としては，この業界のプロジェクトの管理方法に問題があると思っています。あるチームがソフトウェアの一部を最初に開発して，メンテナンスや拡張を行うのは別のチーム，という具合です。もちろんここでは，運用については考慮していません。
ビジネスドメインを十分に考慮してDDDの概念を適用するという行為が，まだ広く実践されるスキルでないことは明白ですが，その理由は，プロジェクトチームが解散する時に，集積されたシステムの知識やパターンも解体されてしまうからなのです。それでもプロジェクト自体は成功を収めます。正確には，必要なレベルで，ですが。ソフトウェア設計の見事な作品にお金を払おうという企業はまずありません。企業が求めるのは，合理的な価格で使えるソフトウェアなのです。このような状況であれば，設計ミスを言い逃れるのも難しくはありません。
さらには，すべての企業がスタートアップのように，チームを常に最新の改善やトレンドで更新することを目指している訳ではありませんし，そのような余裕もありません。これはIT産業独特のものなのです。個人が自分自身に継続教育を実施しなければ，代わりにやってくれる人は誰もいません。システム全体の責任を負うDevOpsおよびフルスタックの開発者の出現によって，この部分は大きく変化し，よい方向の影響を受けています。
ウォーターフォールや開発計画に代わって，私たちは今，より多くの信頼を個々のチームに預けるようになりました。エンタープライズマーケットは現在も固定価格の契約やプロジェクト管理に関する古い考え方に苦労してはいますが，彼らにとっての競争上の優位性や完全なサプライチェーンは明確になり始めています。
InfoQ: マイクロサービスを実装する人々やプロセス部分は，どのような点で重要なのでしょうか？
Eisele: 自ら起こした設計ミスすべてに対価を払わねばならず，さらにチームやインフラストラクチャ，方法論が迅速なアジャイル開発をしないのであれば，“エンタープライズ”は“重い，動かせない”の同義語になってしまいます。新しいマイクロサービスアーキテクチャと重い旧式の方法論やプロセスと組み合わせても，うまく行きません。変更の迅速なデプロイも，プロセスを適切に自動化することもできませんし，結局はまともに動作しないソフトウェアで終わるのです。
同期的に開発される個々のサービスや，不適切な部分を稼働するパーツに速やかに交換する改善要求によって，DevOpsプラクティスへの要求はさらに高まります。ですがこれは，パズルの１ピースに過ぎません。エンタープライズ環境では，外部からの技術導入に関する契約から，外部ベンダが運用環境に変更をプッシュするための具体的な方法まで，多くの人々によるサポートが必要なのです。
さまざまなインフラストラクチャが個別にスケールアップできなくてはなりませんし，プロジェクトではセルフサービスモデルが主役となります。これを実現するには，PaaS(Platform as a Service)を利用する以外に方法がないのです。
Eisele氏によるO’Reillyのミニブックである“Modern Java EE Design Patterns: Building Scalable Architecture for Sustainable Enterprise Development”は，Red Hat Developer Blogから入手可能だ。