キーポイント
- New software architecture trends to watch include micro frontends, Data Mesh, AsyncAPI, and Policy as Code. The variety of purposes shows that innovation is occurring in many different areas in the architectural landscape.
- As microservices are becoming more common, there is more resistance to starting with a microservices architecture. More companies are looking at the fundamentals of correctly built distributed systems or creating modern, modular monoliths, with the idea that they may need to be broken into microservices at a later date.
- GraphQL has clearly crossed the chasm, with the only debate being how widely it is adopted. There is still innovation regarding scaling GraphQL and making it ubiquitous and general-purpose for large enterprises.
- There has been increased interest in low-code/no-code platforms, which can empower non-developers to customize a system.
- Several architectural concepts that are tracked are only applicable to certain situations. Therefore, they do not have a natural progression across the adoption curve. Examples include functional programming and event-driven architecture.
優れたソフトウェアアーキテクチャの目標は、複雑なシステムの管理を容易にすることです。分散システム、イベント駆動アーキテクチャ、ビッグデータに応えるための、ソフトウェアアーキテクチャにおける最新のイノベーションには、新たに登場したベストプラクティスを活用すると同時に、一般的なピットフォールを避ける支援となることが望まれています。
"InfoQ Software Architecture and Design Topic Graph"では、主要なソフトウェアアーキテクチャのコンセプトと、業界における現在の採用状況を取り上げています。InfoQとQConはどちらもチャートの左側に注目して、イノベータ(Innovator)やアーリアダプタ(Early Adopter)のソフトウェアトレンドを取り上げています。それと同時に、最終的に"キャズムを越えて(cross the chasm)"、多くの企業に採用されるであろうアイデアにも注目しています。
"Software Architecture and Design (A&D)"を担当するInfoQの編集者たちは、このトピックグラフについて定期的に議論し、取り上げるべき新たなトレンドを選び出すと同時に、すでにグラフ上にある項目の採用状況に関する大きな変化にも注目しています。この記事では、内部での議論からのハイライトに加えて、トピックグラフにある単純なテキストの理解に必要な解説を提供したいと思っています。
今回の議論に参加したのは、以下の人たちです。
- Charles Humble、InfoQチーフエディタ
- Daniel Bryant、InfoQニュースマネージャ
- Thomas Betts、InfoQ Architectue & Design 主任エディタ
- Jan Stenberg、InfoQ Architecture & Design エディタ
過去数年間、私たちはA&Dの分野において、注目すべきアイデアをいくつも目の当たりにしてきました。それぞれが異なるソフトウェアのトレンドに対応するものです。例えば、マイクロサービスが広く採用されるようになり、多くのメリットとデメリットが見つけられたことで、成果を確実なものにするパターンが明らかになり、次世代マイクロサービスの成功への期待が高まっています。
イノベータ
イノベータの間での新たなトレンドは、マイクロフロントエンド(Micro Frontend)、AsyncAPI、データメッシュ(Data Mesh)、ポリシ・アズ・コード(Policy as Code)の４つです。
マイクロフロントエンド
マイクロフロントエンドは、マイクロサービスと同じメリットをUIレイヤにも持ち込もうというものです。複雑なシステムをもっと小さく、管理の容易な部品に分解することによって、新たな機能を迅速にリリースできるようになります。
InfoQ Podcastで紹介した後、私たちは、"Building Micro Frontends"の著者であるLuca Mezzalira氏に連絡を取り、今後1,2年に何が起こるのか、氏の考えを聞いてみました。
Luca Mezzalira: マイクロフロントエンドは新たなトレンドではありませんが、2019年に弾みが付いたのは事実です。
これからも数多くのベストプラクティスが見つかるでしょう。コミュニティは活気に満ちています。この8～10ヶ月間、マイクロフロントエンドをもっと開発者にとって取っ付きやすいものにするために、新しいフレームワークやテクニック、ドキュメントを作成していました。
マイクロフロントエンドがフロントエンド開発の万能策だとは言いませんが、シングルページアプリケーションやサーバサイドレンダリングアーキテクチャとは相性がよいと思っています。
マイクロフロントエンドが効力を発揮するのは、数十人が参加する大規模ドメインのプロジェクトにおいてです。複数のサブドメインに分割することで複雑性を低減すると同時に、チーム間のコミュニケーションの作成や調整のオーバーヘッドが不要になり、アプリケーションの個々の部分を独立的にデプロイすることが可能になります。
いくつかの企業ではすでに取り入れ始めていますが、2020年には、このパラダイムをどのように取り入れたか、どのような利点や欠点に出くわしたか、もっと多くのケーススタディを見ることができると期待しています。
2020年にはマイクロフロントエンドがアーキテクチャとして確立して、フロントエンドコミュニティの理解を得られるものになると思っています。すべてのフロントエンドプロジェクトで採用されることを望んではいませんが、このアーキテクチャパラダイムからメリットを得られる企業はたくさんあるはずです。
AsyncAPI
AsyncAPIは、Restful APIとイベント駆動アーキテクチャ、そしてイベントソーシングの間の不一致に対処しようというものです。マイクロサービスの採用の増加に伴ってEDAを実装する企業が増え、その結果としてEDAに関連する技術が進歩しました。しかしこれらの進化には、それまでの同期的なリクエスト/レスポンスAPIから、非同期コミュニケーションを意識したAPIへの移行が必須になります。
InfoQのDaniel Bryantは、"ユーザと会話する中で、この件がよく話題になりました。Swagger/OpenAPIの採用に熱心なユーザは、例外なくAsyncAPIのようなものを欲しがっています"、と語っています。
データメッシュ
データメッシュの概念が最初に論じられたのは、ThoughtWorksのZhamak Dehghani氏の記事でした。この示唆に富んだ概念は、従来のデータウェアハウスやモノリシックなデータレイクの落とし穴は、ドメイン指向のデータオーナシップを取り入れることで回避可能である、というものです。
InfoQのThomas Bettsは、"これまでデータアーキテクチャを追ったことはありませんでしたが、モノリスをマイクロサービスに分割することで大規模データシステムのアジリティ向上を図る、というトレンドに沿っているという意味で、これには関心を持っています"、と述べています。
Dehghani氏にも、データメッシュの現在と今後についての意見を聞いています。
Zhamak Dehghani: ディジタル経済、ディジタル社会、ディジタル組織の進展においては、Connected Decentralization(共同型分権)が基本的トレンドのひとつです。過去10年間、クラウドやマイクロサービス、API、コンテナ化、ドメイン駆動設計といったテクノロジは、運用世界の分散を可能にして来ました。しかし残念なことに、データの世界については、時代錯誤の集中化が幅を利かせたままだったのです。データメッシュは、解析的なデータ管理障害モードへの直接的な回答であり、企業を一足飛びにデータ駆動かつ共同型分権のトレンドにしようというものです。
今後1、2年の間に、データメッシュはさらに採用ベースを広げて、もっと多くの実装ケーススタディを共有できるようになるでしょう。たくさんの初期実装が独自のエンジニアリングツールやテクノロジを生み出して、データメッシュの技術的ニーズにマッチするオープンソースツールやクラウドプロバイダのプロダクトが広く行き渡ることを期待しています。
業界の"データメッシュとは何か"という疑問が、今年になって"データメッシュはどうやればよいのか"に変わってきていると思います。今後普及が進めば、次の疑問は当然、"データメッシュをどう正しく実現すればよいか"になるでしょう。
データメッシュはデータのオーナシップやガバナンスに関わる組織的変更を必要とするので、本当の意味でこのパラダイムを実現できるのは、経営者や指導者による強いサポートのある技術指向の会社です。
ポリシ・アズ・コード
ソフトウェア開発ライフサイクルの管理に関しても、イノベーションがありました。ポリシ・アズ・コードは注目すべきもののひとつで、望ましいシステム状態の構築を支援します。インフラストラクチャ・アズ・コードの考え方を基盤として、アーキテクチャレベルで同じようなメリットを提供するものです。InfoQのDaniel Bryantは、KubeConでの講演やクラウドベンダから、ポリシ・アズ・コードの話題を耳にしています。
アーリーアダプタ
サーバレス
常に建設的な議論の的になる話題のひとつがサーバレスです。InfoQのエディタたちは、サーバレスがキャズムを越えたとは考えていません。このアイデアにはまだ反対意見もあるからです。これはマイクロサービスに対する抵抗とも関係しています。サーバレスやマイクロサービスによるアーキテクチャがすべての問題に対する適切なソリューションではない、ということに気付く開発チームが増えているのです。
この認識は、正しい分散システムの構築やモジュラモノリス(modular monolith)に関する有意義な議論につながっています。
InfoQのJan Setnbergが、先日のDDD Europeカンファレンスでのサーバレスや分散システムに関する議論について伝えています。
Stenberg: 私が面白いと思ったのは、Gojko Adzic氏のサーバレスに関する講演です。強く支持する一方で、非常に単純な"Hello World"アプリケーションでさえ高度に分散化されている点を指摘したのです。このためには高い技術を持った開発者が必要になります。これはサーバレスの費用対効果に影響するのではないでしょうか？
Vladik Khononov氏は、マイクロサービスに関心のあるすべての人に対して、Glenford J. Myers氏が1970年代に著した"Composite/Structured Designを読むように勧めていました。その本にはマイクロサービスという単語は出てきませんが、議論の基盤となっている設計思想はマイクロサービスのものと同じです。
Stenbergはさらに、モジュラモノリスもアーリーアダプタに加えるべきだ、と主張しています。
Stenberg: Kamil Grzybek氏、Randy Shoup氏といった人たち、さらに2015年にはStefan Tilkov氏も、モジュラモノリスの構築は非常に困難なので、それが必要ならばマイクロサービスへ移行した方がよいと主張しています。
ですが、これは妙な話です。アーリーアダプタがどうして、十分に設計されたモジュラアプリケーションを開発できるのでしょうか？"新世代"アーリーアダプタのようなものがあるのでしょうか？
Humble: サーブレスについては、まだキャズムを越えたとは思えませんし、反証となるような事例も実際にいくつか目にしています。これが結果的に、もっと広範な、マイクロサービス全体に対する反対意見になっているのだと思います(あるいは、より正確に言えば、マイクロサービスがすべての問題への回答ではないことに人々が気付いた、ということです) — これについては、QCon Londonでの講演があります。ニッチなアプローチのひとつに留まる可能性も否定できません。モノリスへの回帰についても、追跡や議論が必要ではないでしょうか？
Bryant: 当初は"サーバレス"がキャズムを越えたとも考えましたが、現在はそうは思っていません。この分野でのチャンスが非常に大きくなったことを示すレポート(その一例です)はたくさんありますが、その内容からは、いまだアーリーアダプタの段階ではないかとも思わせられるのです。
Betts: 1年前は完全にサーバレスなシステム構築を語る人がたくさんいましたが、そのようなハイプは影を潜めています。AWS LambdaやAzure Functionのように、個々のサーバレス機能はキャズムを越えたかも知れませんが、完全なサーバレスアーキテクチャはそうでないばかりか、広範な採用を達成したとも言えないようなレベルだと思われます。
ローコード(Low-Code)とノーコード(No-Code)
ローコードとノーコードソリューションは、より多くの機能をエンドユーザの手に渡すことを実現して、開発者の関与を不要にするものです。業界のベテランたちにはベンダの単なる宣伝文句に思えるかも知れませんが、これらのプラットフォームを経験した開発者の数は間違いなく増えています。
Humble: ローコードプラットフォームにはどちらかというと懐疑的です — 以前にもあったような、ベンダの宣伝文句という印象を強く持っています。とは言っても、MicrosoftがPowerAppsやFlow、Power BI、Power Platformといったプロダクトで新たなプッシュをしているので、ローコードプラットフォームを経験する開発者はこれから増えるのではないかと思います。GoogleがAppSheetを買収した件も興味深いですね。これらのプラットフォームはビッグビジネスになりつつあるので、今後も注目すべきトレンドではあると思います。
Betts: (ライトウェイト)ワークフローや意思決定自動化(decision automation)プラットフォームは、まだアーリーアダプタの段階でしょう。これはローコード/ノーコードプラットフォームと強い相関性を持っていますが、話題性という点ではそれらより上かも知れません。これらのプラットフォームは非開発者をターゲットにしているので、スペクトルとしては構築よりも購入という面が強いものです。課題としては、ひとつのプラットフォーム上に大規模なシステムを構築するというよりも、統合に関する部分になります。
Stenberg: ローコードは職場の後輩を思い起こさせます。90年代の大学では、OOは時代遅れだという理由で4GLしか教えてくれませんでした。
最新のワークフローエンジン(Zebeeなど)は、ローコードではないと思います(ただし"ワークフローと意思決定自動化プラットフォーム"ではあるかも知れません)。これらはコアビジネスがスムーズに運営されていることは知っておきたいが、問題発生を監視したくはないようなドメインにおいて、コアビジネスワークフローを処理してくれるものです。
GraphQL
GraphQLは明らかにキャズムを越えていますが、アーリーマジョリティ(Early Majority)かレイトマジョリティ(Late Majority)なのかについては、InfoQエディタの間でも意見が分かれています。テクノロジとしてのGraphQLの使用はレイトマジョリティに達しているかも知れませんが、GraphQLがスケーラビリティに関するアーキテクチャ判断に影響を与えていることや、システム全般に通用する言語を生み出しているという事実からは、いまだイノベーションの段階にあるとも思われるのです。
Humble: GraphQLは間違いなくキャズムを越えたと思います。Dylanは最新のWebトレンドレポートでレートマジョリティに分類しています。
Betts: GraphQLはキャズムを越えたと思います。採用のレベルは、単にAPIで何かを実装してみたというレベルを脱して、システム設計の中心的な位置に達しています。これはTypeScriptの採用状況にとても近いのではないかと思います。TypeScriptでは、システム全体を通じて強く型付けされた構造のメリットを、チームが理解しているのです。
ソフトウェアアーキテクチャにおける倫理
倫理についても取り上げるべきではないか、とBryantが疑問を呈しました。"SACONやQConで、倫理に関するセッションやトラックを目にすることが多くなっています。" 最終的には、今回のトピックグラフでは倫理については取り上げないことにしました。Software Culture & Method Topic Graphの方が適していると思われたからです。
Humbleは過去数年間、QConとInfoQで倫理に関する議論が行われてきたことを指摘しています。
Humble: 倫理は文化的なトピックとして扱われることが多いのですが、複数のキューにまたがるものです。これに関して今後も追跡し、報告する必要があることは間違いありません。私たちがQCon Londonの倫理トラックやそのeMagでこの話題をいち早く取り上げたのは、誇るべきことだと思っています。ソフトウェアがすべての人たちの生活に広く関わっていることを考えれば、今後もこの話題を論じ続けることは非常に重要だと思います。
Bettsは倫理を、技術的リーダとしてのアーキテクトの側面だと捉えています。
Betts: 倫理にまつわる意識の向上や議論の活発化は素晴らしいと思いますが、A&Bトピックグラフで取り上げる必要については確信が持てません。それでも、技術リーダが考慮すべき倫理的な側面はたくさんあると思うので、A&Dでの倫理的考慮について、InfoQの記事で取り上げてほしいと願っています。私は常々、この領域で指導的立場につくべきなのは、本当の意味でそれを理解した実践者たちだと思っています。実践的なリーダシップがなければ、結局は受け身になって、GDPRやCCPAのような必須の政治的規則に従うことを強いられるようになるでしょう。
その他の話題
チャートの他の部分は、ほぼ変わっていません。Reactiveプログラミング、HTTP/2、gRPCはキャズムを越えましたが、その他すべてに動きはありません。プログラミング言語のトレンドと比較して、A&Dの分野では優れたアイデアの成熟に時間を要する上に、その寿命も長い傾向があるので、これは予想の範囲内でしょう。
参考までに、2019年のトピックグラフを紹介します。2020年版はこの記事の先頭にあります。
著者について
Thomas BettsはInfoQのArchitecture & Designを担当する主任エディタで、現在はInforma Techの一部となったIHS Markit Technologyのプリンシパル・ソフトウェアエンジニアです。氏は20年以上にわたって、ユーザを満足させるソフトウェアソリューションの提供に心血を注ぎ続けています。氏は小売業や金融、医療、国防、旅行業など、さまざまな業界での業務を経験しています。妻と息子とともにデンバーに住み、ハイキングを愛し、美しいコロラド州を探索しています。
Charles Humbleは2014年3月からInfoQ.comでチーフエディタの役職にあり、ニュースやアーティクル、書籍、ビデオプレゼンテーション、インタビューといったコンテンツ作成を指揮しています。InfoQの業務にフルタイムで参加する前は、2012年7月にPwCに買収された報酬調査会社PRPi ConsultingのCTOの職にあって、InfoQのJava関連記事を指導していました。PRPiでは、社内で使用されていたすべてのカスタムソフトウェアについて、開発に関する全体的な責任を担っていました。開発者、アーキテクト、開発マネージャとして、20年近くエンタープライズソフトウェアに関わっています。余暇はロンドンを拠点とするアンビエントテクノグループTwofishのメンバとして曲を書いています。14年にわたって高価なおもちゃで遊んだ後、2014年2月にデビューアルバムを発表しました。それ以外は、できる限りの時間を妻や子供たちと過ごしています。
Daniel BryantはDatawireのプロダクトアーキテクトです。InfoQではニュースマネージャであり、QCon Londonでは議長を務めました。現在の専門技術は、"DevOps"ツーリング、クラウド/コンテナプラットフォーム、マイクロサービス実装などが中心です。London Java Community(LJC)のリーダとして、オープンソースプロジェクトへのコントリビューション、InfoQやO'Reily、DZoneなど著名な技術Webサイトで記事の執筆を行う他、QConやJavaOne、Devoxxなど国際的なカンファレンスでも常に講演しています。
Jan Stenbergは北スエーデンで25年以上にわたってITコンサルタントとして活動し、.Net/C#、JVM/Java両プラットフォームでのシステム構築を経験しています。氏の経験分野は、サービスベースの大規模分散システムからWebベースのリッチクライアントアプリケーション、さらにはハードウェア関連のソフトウェアにまで広がっています。