ModernJavaEEDesignPatterns / Additional Technologies and Team Considerations

Additional Technologies and Team Considerations †

内容 †

これまでに書いてきたように、ソフトウェアアーキテクチャの構築はがちがちのプロセスに守られているわけではない。 変化する要件に対応するには、チームワーク、創造性、柔軟性が伴わないといけない。 それは、システムや個々のサービスの設計だけでなく、チームの行動や選択するツールにも関係している。 マイクロサービスなシステムは、伝統的なJavaEEアプリケーションのように初めからアプリケーションサーバーが決まっているわけではないので、チームごとにいろいろな見方から決めないといけない。

この付録では、伝統的なJavaEEのエコシステムには入らないマイクロサービスのソリューションを紹介する。 チームでよりスケール可能なアーキテクチャを目指すために新しい視点が切り開かれるだろう。

* Architecture != Implementation †

アーキテクチャレベルの設計をするときは、具体的な方法論や実現方法は考えないものだ。 マイクロサービスでも同じことが言える。 マイクロサービスアーキテクチャにおけるサービス契約によって、実現方法についてはわりと柔軟に考えることができる。 一つのプラットフォームや言語にこだわることもない。

Java EE の経験があるなら、マイクロサービスをやる上でのおすすめやプラットフォームに固有の事項などをご存知だろう。 ここで紹介している一覧を作るにあたって基準にしたのは、エンプラではJava が最も標準的なプログラミング言語であるということだ。 そのことを念頭に置いた上で、Java EE アプリケーションサーバーがなくても実現できるマイクロサービスのためのソフトウェアスタックがあるということを理解しよう。

* Vert.x †

非同期、ノンブロッキングなフレームワーク。 Webアプリケーション界隈では話題になっている感じ。

伝統的なフレームワークと違って、マイクロサービスアーキテクチャやスケーラブルなシステムに合うように設計されている。 OSスレッドに依存せず、完全にノンブロッキングだ。 この特性はマイクロサービスなアプリケーションにとって極めて重要。 メッセージやイベントを並行処理するには必須と言ってもよい。 また、JavaScript? Ruby Groovy などの複数の言語に対応している。

この特徴は、コンテナでなくても実現できている。 Spring などを使用しているアプリケーションの内部でも使用することができる。 ノンブロッキング、リアクティブプログラミングモデルにより、マイクロサービスの設計原則に順応するのも早い。 既存のアプリケーションの再開発にも使えるかも。

* WildFly? Swarm †

WildFly? のサブプロジェクト。 WildFly? を自分用にカスタマイズできる、と考えてよい。 実行可能Jarを実行できる。

Java EE アプリケーションといえば EAR や WAR を作ってデプロイするものだった。 必要な依存ライブラリは全てアプリケーションサーバー側で準備している感じ。 トランザクションやセキュリティに関連する機能はアプリケーションサーバーが提供している。 同じサーバーインスタンスでマルチモジュールアプリケーションをデプロイすることができる。

Swarm だと、自分で使いたいものを選択することができる。 自分で fat JAR を作る感じ。

By designing applications constructed out of many “fat JAR” instances, you can independently upgrade, replace, or scale the individual service instances. This reduces the available amount of specifications and containers for the application to the needed minimum. It also improves the footprint, rollout, and scaling in the final infrastructure while still utilizing the Java EE programing model.

Netflix OSS の Ribbon と Hystrix をサポートしている。 サービスを公開したり、負荷分散したりするのに便利っぽい。 デフォルトでは Ribonn が Eureka を使うようになっている。 標準でついてくるクラスタリングの仕組みはそれに対応していて、エンドポイントの管理ができるようになっている。

* Spring Boot with Spring Cloud †

Spring エコシステム強い。 マイクロサービスのために生まれてきたと言っても過言ではない。 Springフレームワークによって構築されているので、マイクロサービスの開発に必要な機能はだいたい備わっている。

開発のし易さに重きが置かれている。フレームワークも、マイクロサービスを作りやすいようになっている。 すなわち、あらゆるサービスがRESTfulなエンドポイントを備えつつ、Webアプリケーションの実行環境を組み込みで備えているということだ。 Springの思想があらゆるところに埋め込まれている。 実行可能なjarを小さい単位でデプロイすることが、リーンなアプローチに向いている。

Spring Boot で一番イケてるのは Spring Cloud だ。 これもまた Netflix OSS 関係。 アプリケーションと Netflix OSS を、ほとんど設定を自動化して統合できる。

* Dropwizard †

運用に優しい、高性能な RESTful サービスを開発するためのフレームワーク。 Java エコシステムにおいてよく知られている安定したライブラリ（Jetty Jersey Jackson）を組み合わせた fat Jar を作るようになっている。 設定ファイル、メトリクス、ロギング、運用ツールなどがすぐに使える状態で提供されている。 いろいろなインターフェイスやアノテーションで、個々のテクノロジーをつなぎ合わせるようになっている。 個々のテクノロジーについて知らなくても利用できてしまう。 学習カーブが緩やかになってよい。

* Roll Your Own †

Tomcat などを使って Java EE もどきを自作してもよい。 コストに見合うなら選択肢としてありじゃないかな。

Thoughts About Teams and Cultures †

Netflix 社のようなアーリーアダプターが、効率よりもスピードを重視するチームをどうやって作り上げてきたのか読んだことがあるだろう。 エンタープライズなソフトウェア開発チームでそうするためのアプローチがある。 何よりも、関心を失わないことだ。 チームはビジネスの規模や責務を理解すること。 そうすれば、ビジネス側からの関心を保証できるし、新しいサービスを同じビジネスドメインに落とし込むときに再利用できる。 それはそれとして、チーム内にビジネスコンサルタント的な人がいることは重要だ。

エンタープライズな開発において、チームは自己完結的であって欲しいし、要件をまとめるところから実装するところまでを1人だけに任せないようにして欲しい。 ビジネス担当者への質問に時間と体力を消費するのは、常にビジネスコンサルタントだけであるべきだ。 アーリーアダプターな組織でそういうチームは珍しくない。「両面ピザチーム」と呼ばれたりしている。

最大でも4人の人間がビジネスケイパビリティに責任を負うようにせよと述べている。 プロジェクトで必要な数に応じて、「両面ピザチーム」を増やしていけばよい。 個々のチームは「自由と義務」をわきまえること。 ほぼ全てのエンタープライズプロジェクトでは、進捗状況を報告する責任がある。 これはマイクロサービスアーキテクチャにとって最適な、協力的であることを目指すチーム文化とはうまく合わない。 プロジェクトを管理したいという要求と、チームの独立性の間でバランスを取ることが唯一の解決策となる。

誰もが納得できる素敵な方法がある。Scrum あるいはアジャイルなプロジェクトマネジメントプラクティスを導入することだ。 アジャイルなやり方で「両面ピザチーム」を運営するのはまったく新しいことではない。 報告する数字を考えることや、その数字を全体的なプロジェクト計画にマッピングするほうが難しいだろう。 プロジェクト計画において広範囲にわたる話題についてのみ、反復的なアプローチをとるようにすれば、柔軟に対応できるだろうし、うまくやっていけるだろう。

fig-a-1.png?dl=0

典型的なエンタープライズ開発においては、チームの準備が整っていて、報告する内容についてOKが出ているとしても、他のサイロ（化されたシステム）や組織のことを考慮しなければならない。 妄想のアーリーアダプターにおいて活動しているようなチームを作るには、重厚長大なプロセスや古すぎるテクノロジーについて考慮しなければならない。 最新のテクノロジーを扱うからといって、チームメンバー全員がフルスタックエンジニアでなければならない、なんてことはない。 それでも、チーム内だけではなく、技術的な境界を超えて他のチームの人とも協力してことに当たる、という振る舞いは欠かせない。

担当者のつぶやき †

みんなの突っ込み †