Javaエンジニアは何を考え、どう行動すべきか？ 急速に変化するエンタープライズJavaの世界：Red Hatのリッチ・シャープルズ氏に聞いた

Java EEの開発、Oracle JDKの提供方針変更など、Javaの世界は大きく変化している。一方で、マイクロサービスアーキテクチャへの移行が提唱されている。Java開発者が今、本当にやるべきことは何か。長年Javaの開発に携わり、開発者への的確なアドバイスで知られるRed Hatのプロダクトマネジメント担当シニアディレクター、リッチ・シャープルズ氏に、率直に聞いた。

[PR／＠IT]

PR

　Java開発者の周囲では今、さまざまに新たな動きが起こっている。OracleがJava EEのコミュニティー化、Oracle JDKの方針変更など、Javaに関するこれまでのやり方を変えたことがユーザーの混乱につながっている。一方、Java EEの世界では「アプリケーションのマイクロサービス化」がますます声高に叫ばれるようになっている。エンタープライズJava開発者の中には、これに戸惑いを覚え、あるいは疑念を持つ人たちも多い。

　今、Java開発者は何を考え、今後どのように行動すべきか。長年Javaの開発に携わってきており、開発者への的確なアドバイスで知られるRed Hatのプロダクトマネジメント担当シニアディレクター、リッチ・シャープルズ氏に、率直に聞いた。

――Oracleが2017年10月に、Oracle JDKのバグフィックスやセキュリティアップデートに関する方針を変えました。これに大きな懸念を抱いている組織は多いと思いますが、どう考えますか？

　Oracleはいくつかのことをしています。

　まず、OracleはJDKのリリースサイクルを早めようとしています。これについては、良いことだと思います。数年ごとでなく、6カ月あるいは9カ月ごとに新機能がリリースされるのは、開発者にとっていいことです。

　大規模なユーザー企業が困っているのは、Oracle JDKを使うのが難しくなったという点です。Sun Microsystemsの後を引き継いだOracleはこれまで、無償のOracle JDKを3年のライフサイクルで提供し、パッチも提供してきました。人々はパッチが継続的に提供されるものと信頼して、無償バージョンを使ってきました。

　Oracleが発表したのは、「無償バージョンのOracle JDKで、アップデートやセキュリティパッチの恩恵を得たければ、新バージョンにアップデートしなければならない」ということです。すなわち、アップデートを事実上、強制されることになります。

　これにはもちろん、良い面もあります。できるだけ最新バージョンを使うということは、一般的には良いことですし、セキュリティの面でもお勧めできます。しかし、強制されたくないというのは人の常です。

　企業の選択肢は、Oracleとの有償契約により、JDKを長いライフサイクルで提供してもらうこと、またはRed HatやIBMといったベンダーに商用サポートを頼むことです。

　また、Java SE 9がリリースされます。これはおそらく、最も大きな改変が施されたJava SEになるでしょう。従来のアプリケーションを再検証する必要が出てきますし、コードを一部変更しなければならないかもしれません。Java SEは長年にわたって互換性が確保され、私たちはこれに慣れていますから、影響は大きいと思います。

　Red Hatはミドルウェアのベンダーとして、JDKの隠れたAPIや高度な機能を使ってきました。このため、どの部分でアプリケーションに問題が起こるのかを理解しています。そこで私たちは、ガイダンスおよび移行ツールを顧客に提供し、新バージョンへの移行を支援しようとしています。

　古いバージョンのパッチストリームは、2018年の10、11月にはなくなるので、どこかの商用バージョンを使わない限り、非常に厳しい状況になると思います。私としては、JDK 9をダウンロードし、アプリケーションをテストすることをお勧めします。

――一方、マイクロサービス化など開発アーキテクチャの変更が話題に上ることが増えていますが、これに疑念を持つJava開発者も少なくないと思います。本当に全てのJava開発者が、マイクロサービスに取り組む必要はあるのでしょうか？

　どんな新技術に対しても、健全な疑念を抱くのは良いことだと思います。

　しかし、マイクロサービスアーキテクチャに移行することには大きなメリットがあります。既存のアプリケーションを改善するにしても、新しいアプリケーションを構築するにしても、小さなコンポーネントの集合体としてアプリケーションを開発することで、その後のアプリケーションへの変更を、より独立した形で、段階的に開発できるようになります。

　これに対し、大規模でモノリシックな、例えば30人の開発者が関わっているようなJava EEアプリケーションや.NETアプリケーションに改変を加えようとすると、アプリケーションの一部を変えるだけで、再構築、再テスト、再パッケージ、再デプロイを、アプリケーション全体について実行しなければなりません。チーム全体が連携して、数週間、あるいは数カ月も作業を行う必要が出てきます。

　北米では、IT部門に対する、「アプリケーションを迅速に提供せよ」というプレッシャーが高まっています。あらゆる産業でディスラプションが起こっており、どんな組織も機敏に動かなければなりません。こうした中で、NetflixやGoogle、Amazonなどが採用してきたマイクロサービスアーキテクチャに基づくアプリケーション開発手法は、模範として考えられています。ただし、あらゆる企業が、NetflixやGoogle、Amazonのような問題を抱えているわけでもありません。

　私は開発者に、マイクロサービスについて実用的な考え方をしてほしいと思っています。そのため、全てのアプリケーションで有効だとは思っていませんし、全ての企業に適しているとも思いません。CI/CDを実現するようなモダンなソフトウェア開発テクニックを採用していない限り、マイクロサービスで成功するのは非常に困難です。Red Hatは、他のベンダーと異なり、「全てをマイクロサービスに移行させよう」などとは考えていません。

　とはいえ、大部分のJava開発者は、マイクロサービスを恐れることはありません。ソフトウェアの開発について、過去10年ほどの間に蓄積された経験や知識がそのまま活用できます。

――Java開発者は、マイクロサービスという新たな世界についても有利なスタートが切れているということですね。

　もちろんです。Java EEは、優れた設計に基づくプラットフォームです。モジュラリティが特徴で、アプリケーションとUIなど、ロジックが分離されています。Java EEアプリケーションは、一般的に良い設計が構築されていることが多いと思います。

　では、まずどこから始めるべきでしょうか。私のアドバイスは次の通りです。

　最初に新しい事業の一部である新たなアプリケーションを対象に選ぶと、おそらく苦労するでしょう。新たな分野を理解しなければならないですし、ソフトウェア開発の新たな手法も同時に学ばなければならないので、リスクが大きすぎる可能性があります。それよりも、あなたが理解しているアプリケーション分野で、いずれかの既存Java EEアプリケーションを、より小さな単位に分割することから始めるのがいいと思います。

――そうした開発者が使うツールやアプリケーションプラットフォームは、これまでのJavaアプリケーションと新しいマイクロアーキテクチャによるアプリケーションのどちらにも対応できるようなものであることが望ましいですよね？

　そうですね。大部分の企業には、さまざまなスタイルのアプリケーションが混在しています。サービス指向、モノリシック、メインフレームのバックエンドなどです。新しいデザイン手法のアプリケーションは非常に少数です。このため、あらゆる種類のアプリケーションを実行できる環境が必要です。

　Red Hat OpenShift Container Platformは、こうした点で非常に良い環境です。OpenShiftはクラウドネイティブでステートレスアプリケーションのためのプラットフォームではありますが、既存のモノリシックなJava EEアプリケーションをそのまま、「リフト・アンド・シフト」で実行することも可能です。また、コンテナを活用することで、自動化や開発者のセルフサービスなどの開発から本番運用までの一貫性を保つ基盤を提供できます。

　OpenShiftは、既存アプリケーションとマイクロサービスアプリケーション双方のための、素晴らしいハイブリッド環境です。よく見られるのは、第1ステップとして、典型的なWebSphere／WebLogicのモノリシックなJava EEアプリケーションを、OpenShift上でJBoss EAPに移行することです。第2ステップは、そのアプリケーションを分割したいと考えたなら、軽量JavaランタイムのWildFly Swarmを活用できます。WildFly Swarmでは、Java EE APIをそのまま活用しながら、無理なくマイクロサービス化を進められます。

――レッドハットのマイクロサービス戦略で新たに発表した「Red Hat OpenShift Application Runtimes」は、どのようなメリットがありますか？

　Red Hatでは、さまざまなアプリケーションをサポートし、これまでの世界とマイクロサービスの橋渡しをしたいと考えました。移行を助けるために、いくつかのランタイムを選び、製品化したのがOpenShift Application Runtimesです。

　先ほど説明したWildFly Swarmは、JavaEE MicroProfileのRed Hatによる実装です。Java EEアプリケーションのマイクロサービスへの移行を支援します。また、SpringのAPIに親しんでいる開発者のためには、Spring BootをRed Hatがサポートします。リアクティブなアプリケーションについては、イベントドリブンな非同期アプリケーションで人気のあるVertexを、さらに、JavaScriptバックエンドの構築・運用に向けては、Node.jsを用意しています。

　今後は、golangやPythonなどのランタイムも追加していくつもりです。Pythonはアナリティクスや機械学習で再び注目されています。今後2、3年で、マイクロサービスアーキテクチャ、データストリーミング、機械学習／AIが融合し、イベントドリブンなインテリジェントアプリケーションが急速に台頭するでしょう。

――あらためて、OpenShift Container PlatformとOpenShift Application Runtimesを使うと、エンタープライズJava開発者は何ができるでしょうか？

　OpenShift Application Runtimesの一部として、開発者をガイドするツールを用意しており、これらがマイクロサービスアプリケーションの構築を容易にします。

　マイクロサービスでは2つの複雑さがあります。１つ目は分散アーキテクチャであるがためのコーディングの複雑さ、２つ目はGitHub、Maven、Jenkinsなど、従来とは異なるツール群を習得しなければならないことです。

　開発者向けガイドツールでは、これらの複雑さの大部分を隠蔽できます。例えばあるデータベースに接続する、REST APIを使ったマイクロサービスアプリケーションを開発したいと思ったら、これらの設定は、全てウィザードを通じ、クリックで行えます。これに基づき、ジェネレーターがランタイムアーティファクトを構築します。バルクヘッドパターンへの対応も、ユーザーに代わって行います。

　これにより、開発者はアプリケーションロジックに集中できます。全体として、マイクロサービスアプリケーションの開発は非常に容易になり、マイクロサービスアーキテクチャの習得もしやすくなります。

　また、マイクロサービスを学習できるサイト「OpenShift Interactive Learning Portal」を提供しています。開発者は何もインストールせずに、分単位で、コードを書き始めることができます。

――近い将来はどのような進化を、開発者は期待できますか？

　1つはサービスメッシュです。サービスメッシュはKubernetesやエンタープライズKubernetesのOpenShiftの上で、アプリケーションとインフラのロジックを分離します。デザインパターンのベストプラクティスが組み込まれており、バルクヘッド、A/Bテスト、ローリングアップグレードなどに関わるインフラ関連のコーディングから、開発者を解放します。

　Red HatはIstioというプロジェクトを後押ししており、その実装を、2018年春には少なくともテクノロジープレビューとして提供予定です。

　もう1つの重要な動きはサーバレスコンピューティングです。この1年半くらいの間に、開発者の間で大きな関心を集めるようになりました。

　アプリケーションをマイクロサービス化する際、迅速さと引き換えに、分散アプリケーションの構築と運用における、複雑さを受け入れなければなりません。しかし、サーバレスでは、複雑さから解放されます。サーバレスは全てのアプリケーションに適用できるものではありませんが、特定のアプリケーションには非常に適しています。

　Red HatはApache OpenWhiskを支援しており、こちらについても2018年春に、テクノロジープレビューで提供予定です。

――そして、これらの技術を、適材適所で組み合わせて使うこともできるようになるということですよね。

　はい。Red Hatの顧客は、メインフレームバックエンドから、SOA、メッセージブローカー、ミニサービス、マイクロサービス、サーバレスまで、さまざまな世代の技術を使ったアプリケーションを動かし、そして、これらを相互に連携する必要があります。

　そのような環境に対応するには、多様なワークロードを扱えるOpenShiftのような基盤が、ますます求められることになります。

――エンタープライズJava開発者の皆さんへのメッセージをお願いします。

　健全な疑念を持ちながらも、一度マイクロサービスのことを考え、どんなメリットが得られるのかを考えてみてください。そして、あなたの組織にとって有益だという判断に至ったなら、あなたの確かな目で適切な対象を見つけ、パイロットプロジェクトを進めてください。既存アプリケーションの分割を行うなら、どの程度分割するか、それに合わせて開発チームをどう分けるかを考えてください。

　最も重要なポイントは、ビジネスに影響をもたらすアプリケーションを開発するのに集中できる環境であるかどうかです。その上で「あなたがどんな問題を解決したいか」を明確化することです。性能の向上なのか、品質の向上なのか、より迅速なデリバリなのか。そして、数値目標を設定し計測してください。

　あなたがプロトタイプを実施し、設定した目標を達成したことを組織内で伝えれば、その取り組みに賛同してくれる人が増えるでしょう。