Lightbendは、2,100のJVM(JavaおよびScala)開発者を対象に調査を行った。
- 開発動向とITインフラの動向との間の相関関係
- 組織がアプリケーションを近代化している手法
- 実運用環境において新興技術が使用されている状況の内訳
「エンタープライズ開発動向2016:2100 JVM開発者のクラウド、コンテナ、およびマイクロサービスの分析」というタイトルのレポートは、重量のあるJ2EEサーバーを使用したアプリケーション構築からマイクロサービスと軽量コンテナへの移行の主な要因を調査した。
以下に示すように、調査に参加した開発者は多種多様な企業を代表していた。
この調査によると、
- マイクロサービスと高速データが、主要なアプリケーションの近代化を推進している。
- 軽量コンテナは、インフラストラクチャを民主化し、Java EEアプリケーションサーバーに対抗している。
- 移植性と柔軟性における利点が、「クラウドネイティブ」アジェンダを推進している。
前例のない大量のアクセスやデータのために設計された今日の分散サービスは、柔軟性が高く、疎結合され、スケーラブルなリアクティブシステムに依存している。
このリアクティブシステムへの移行については、Reactive Manifestoで説明されている。
これらの変革が起きている理由は、近年、アプリケーションの要件が大幅に変更されたためである。ほんの数年前、大規模なアプリケーションは、数十のサーバー、秒単位の応答時間、オフライン保守の時間、およびギガバイト単位のデータを持っていた。今日のアプリケーションは、モバイルデバイスから数千のマルチコアプロセッサを実行するクラウドベースのクラスタに至るまで、あらゆるものに採用されている。利用者はミリ秒の応答時間と100%の稼働時間を期待している。データはペタバイト単位の量である。昨日のソフトウェア・アーキテクチャーでは、今日の要求はもう満たすことができない。
継続的なデータの要求を維持するためには、頻繁なリリースサイクルが重要である。当レポートには次のように記載されている。
12-18ヶ月ごとにソフトウェアをリリースするのは、Waterfallモデルに戻っているも同然だ。
マイクロサービスと高速データ
今日のエンタープライズアプリケーションは、リアルタイムのデータとストリーミングに重点を置いて設計されている。アプリケーション開発における比較的新しいトレンドであるマイクロサービスは、サービス指向アーキテクチャーから進化したものだ。当レポートには次のように記されている。
10年前、サービス指向アーキテクチャー(SOA)はマイクロサービスと同じ原則の多くを実現し、インターフェースの設計とアプリケーションの分解に大きな可能性を秘めていた。しかし、SOAが失敗した理由は、インフラストラクチャーに重点が置かれていなかったためだ。今日、マイクロサービスが広く採用されている理由は、サービス分離に加えて、SOAによって決して適切に処理されなかったデプロイとライフサイクルの関心事を体現しているためである。
C2B2の主任コンサルタントであるMatt Brasier氏は、昨年末、マイクロサービスとSOAの間の議論について投稿した。
SOAとマイクロサービスはどちらも同じ原則集であるが、異なる組織層に適用される。
マイクロサービスの存在そのものが、SOA原則の成功から来たものである。
SOA対マイクロサービスの実際の答えは、どちらも異なるソリューションに適しているということだが、エンタープライズアーキテクチャよりも多くのアプリケーションが作成されているのであれば、ESBよりもマイクロサービスフレームワークがプロジェクトに適している可能性がある。
PayaraとC2B2の創設者兼ディレクター、Steve Millidgeは次のように述べている。
マイクロサービスとSOAには違いはない。それは依然としてSOAでもある。
それにもかかわらず、調査結果は、以下に示すようにマイクロサービスに移行する組織の増加傾向を示している。
昨年末、マイクロサービスのこのような増加傾向が予測され、InfoQは今年初めに、「2016年はJava EEマイクロサービスの年となるだろう」と述べた。
調査結果によると、連続型データの要求を満たすように設計されたApache Spark、Apache Kafka、Akkaなどのフレームワークが、以下のようにより一般的な選択肢となっていた。
マイクロサービスの増加傾向は確実視されているが、Lightbendのレポートにあるマイクロサービスの主な留意点の1つは、次の通りである。
マイクロサービスは操作が簡単だと思われがちだが、それは本当か? — 実際にマイクロサービスを運用している企業では、操作ツールの未熟さが34%の懸念事項となった。(全調査回答を対象とすると、22%がマイクロサービスの課題として操作ツールの未熟さを挙げていた。)
InfoQは、マイクロサービスの7つのアンチパターンから学んだ教訓について議論した。 OpenCredoのChief ScientistであるDaniel Bryantは、マイクロサービスの7つの大罪とそれらを避ける方法について説明した。Bashoのこのブログでは、Sean Kellyが、マイクロサービスへ移行する実現可能性を判断するためのガイドとして、マイクロサービスの誤謬をいくつか取り上げた。そしてAlex Zhitnitskyは、OverOpsこのブログで、「実際にマイクロサービスを実装し、マイクロサービスが一体何であるかを知るための、各フレームワークの徹底解説」を書いている。議論されたフレームワークは、Java EE、LightbendのLagom、Pivo=talのSpring Boot、Dropwizard、SpotifyのApolloだった。
軽量コンテナ
軽量コンテナの勢いが増している。それは、「インフラストラクチャの移植性を長い間追い求めてきた開発者が、コンテナを大きな希望として見ている」からである。以下に示すように、回答者の30%がコンテナを試しており、22%がコンテナを運用環境に使用しており、別の22%がコンテナでパイロット開発をしている。
調査結果によると、Docker / Docker SWARM、Kubernetes、Marathon(MesosとDC / OSのコンテナオーケストレーションプラットフォーム)などのコンテナが、以下に示すように人気のある選択肢だった。
Dockerには、ADP、PayPal、Uber、Lyft、Merckを含む50以上の顧客がいる。KubernetesにはSAP、Ancestry、eBayを含む約20の顧客がいる。
Lightbendレポートにおける、コンテナに関する留意点の1つは以下である。
開発者はコンテナがJVM界隈を混乱させる巨大な潜在力を持っていると考えている — 回答者の57%がコンテナがJVM界隈を混乱させるだろうとし、32%はまだ確かではないと回答したが、コンテナはほとんど誇大広告だと思ったのはわずか11%だった。
InformationWeekの大規模・クラウド担当編集者Charles Babcockは、コンテナについて知っておくべき9つの基本事項について説明している。
結論
Lightbendのレポートに書かれたその他の留意点は次の通り。
- Scalaの開発者は、マイクロサービスや軽量コンテナの採用においてJava開発者より先行している。
- マイクロサービスは、Scala開発者の42%が運用環境で使用している。Java開発者は28%だった。
- コンテナは、Scala開発者の31%が運用環境で使用している。Java開発者は21%だった。
- 中小企業(1-200名)の開発者は、大企業の開発者よりもテクノロジーの意思決定に大きな影響を与える。
- コンテナは、IoTアプリケーションを書くための、より良い選択肢である。