そうしたアプリケーションアーキテクチャはホリスティック（総体的：holistic）と定義される。すなわち、APIを使ったマイクロサービスの上に構築されて世界全体を見渡し、世界における自分の位置を認識する。

APIゲートウェイの可能性

　NGINX（訳注）によると、開発者がアプリケーションをマイクロサービスのセットとして構築することを選んだ場合、そのアプリケーションのクライアントがマイクロサービスとどう通信するかを決める必要がある。「モノリシックアプリケーションは、（一般的には複製され、負荷分散された）エンドポイントが1セットしかなかった。だがマイクロサービスアーキテクチャでは、各マイクロサービスが一般的にきめの細かい一連のエンドポイントにさらされる」。NGINXのブログでそう解説されている。

訳注：原文は「Nginx」だが、ここはオープンソースのWebサーバ「nginx」のことではなく、「NGINX Plus」の販売やサポートを行っているNGINX inc.を指す。

　そうしたエンドポイントを組み合わせるのは難しい。IDソフトウェア会社Auth0の主席アーキテクト、ビトリオ・バートッチ氏によると、現代のアプリケーションアーキテクチャではソフトウェアは動的に組み合わされ、解体される。従って、認証とアクセスコントロールがソリューションをつなぎ合わせる唯一の接点になることもある。

　「たとえクライアントアプリケーションが動的に浮上して流動化したとしても、常にセキュアかつポリシーを順守したリソースアクセスを徹底させるためには、適切な権限管理が必須だ。開発者が求められる生産性と高速デリバリーを維持しながら分散されたリソースの組み合わせを実現するには、一貫性のある、標準に基づく認証戦略を採るしかない。これはオンプレミスであれクラウドであれ、内部APIであれSaaSアプリであれ、モバイルソリューションからサーバ対サーバに至るまで共通している」（バートッチ氏）

アプリケーションの弾力性への道

　技術設計・工学企業Aricentの技術・イノベーション担当アシスタントバイスプレジデントのシャミック・ミシラ氏は、マイクロサービスとコンテナでホスティングされたアプリケーションの時代において、システムモニターは激変すると語る。同氏によると、Infrastructure as Code（IaC）要素（例えばマイクロサービスをホスティングするコンテナなど）の監視に必要なモニタリングシステムは、オーケストレーションシステムでアラートを捉え、それに従って行動することが求められる。

　「そうしたモニタリングシステムは、アプリケーションの弾力性へとわれわれを導く入力チャネルだ。モニタリングシステムに役割を持たせ、計算の促進やアプリケーションあるいはAPI利用に基づくマイクロサービスの収益化につなげることもできる。効率的なホリスティックアプリケーションの内部では、機械学習がイベントベースのアーキテクチャ（例えばサーバレスなど）とマイクロサービスのリアルタイム処理を実現する鍵を握るツールになる。機械学習はサービスの価格決定、不正検知、マイクロサービスのためのインフラメンテナンス、ソフトウェアのテスト、根本原因分析、データのモニターに基づき自律的に行動する能力の促進につながる」（ミシラ氏）

　DataStax（Cassandraデータベースサービス企業）の開発者関係担当バイスプレジデントのパトリック・マクフェイディン氏は、ホリスティックアプリケーションへの途上において、たどるべき「単一コードの道」は存在しないと話す。ホリスティックアプリケーションのそれぞれの要素はAPIを使ってつなぎ合わされている。これによりアプリケーションの各コンポーネントで需要に応じてリソースを増やすことができ、それがシステムの拡張性を高めている。これを自動化して開発チームの負担を軽減することもできる。そうなれば開発チームはインフラではなくソフトウェアに集中できる。

　「結果として、ホリスティックアプリケーションは顧客サービスを向上させる助けになるはずだ。そうした要素を全て連携させることによって、特定の顧客が望む全ての結果とデータを含む、よりパーソナライズされた体験を提供できる」とマクフェイディン氏は言う。

　「半面、環境ははるかに複雑になる。各要素はそれぞれ独自のサービスを運営して独自のデータを生成し、独自のサービス品質保証契約（SLA）を満たさなければならないノードのクラスタで形成される。この拡張状態は全ての要素がうまく連携し、各サービスからのデータが効率的に管理される状態に依存するので管理が難しい」と同氏は言い添えた。

　求められるのは考え方を変えることだ。マクフェイディン氏によると、各要素は随時変更されたり更新されたりすることから、プロジェクトの「完了」を宣言するのははるかに難しい。サービスの柔軟性は高まるものの、ソフトウェア開発者の役割についての考え方を変える必要がある。アジャイル開発をうまく導入している企業は、この変化に効率的に対応できる態勢にあるはずだ。だが、アジャイルが名ばかりの企業やプロセスが完全に実行されていない企業は苦労するかもしれない。

　ソフトウェア分析企業OverOpsのソリューション工学担当バイスプレジデントのエリック・マイゼル氏によると、組み立て可能でコンテナ化され、コンパートメント化された新しいソフトウェアの世界は、そうした複雑なアプリケーションの安定性を維持するという課題を背負った担当者の頭痛の種になっている。

　「モノリシックアプリケーションの文脈の中でさえ、フレームワークのログを記録してプロダクションコードの機能問題を発見するといった30年前からの技術に依存する状況は、よく言ってもレベルが低い。マイクロサービスやホリスティックアプリケーションの文脈においては価値がないも同然だ。ホリスティックアプリケーションでコールスタックをどう定義するのか。どうすればログファイルの限られた情報から、分散されたコードベースの機能問題に関する十分な情報が得られるというのか」。マイゼル氏はそう問い掛ける。

　「マイクロサービスの個別テストは、配信されたアプリケーションの全般的な品質を判断するのに必要なホリスティックテストから切り離される。機能品質／健全性に関する新しいアプローチが必要だ。モノリシックアプリケーションからより動的なアプローチへと移行する中で、開発およびIT運用チームは、自分たちのコードの状態に関するもっときめ細かい可視性とコンテキストを必要とし、継続的安定性を保証する手段を向上さなければならない」

世界の端のアプリケーション

　コンテナ化され、コンポーネント化され、コンパートメント化されたソフトウェアはアプリケーションアーキテクチャの未来を表す。だがモノリシックアプリケーションやレガシーシステムも依然として存在している。今後に向けた最善のアドバイスは、そうした非コンテナ型のシステムをホリスティックアプリケーションの世界の中に存在する組み立て可能な機能の「大きな塊」として扱うことかもしれない。

　ホリスティックアプリケーションのまとめ

• 認証およびIDベースのアクセスコントロールは、分散システム間で調整を行う貴重なリンクとして機能する
• ホリスティックアプリケーションは、IaCに重点を置いたモニターシステムを必要とし、オーケストレーション機能を使ってアラートを捉え、システムの健全性を保つ
• ホリスティックソフトウェアには複雑な側面もある。それぞれの要素が独自のサービスを運用し、独自のデータを生成し、独自のSLAを満たさなければならないノードのクラスタで構成される
• マイクロサービスの個々のテストは、分散アプリケーション全体の品質を見極めるために必要なホリスティックテストとは切り離される。
• 機械学習は、サーバレスやマイクロサービスなどの技術を使ったイベントベースのホリスティックアーキテクチャのリアルタイム処理を実現する鍵を握るツールになる。これは自己修復と自立型コンポーネントを提供する上で重要な役割を果たす
• ホリスティックアプリケーションは終わることがない。ソフトウェアプロジェクトは随時拡張され、変更され、更新される。これは常時稼働型ソフトウェアの未来だ