ヘッドレス アーキテクチャの台頭
APIの爆発的な普及により、ヘッドレス アーキテクチャが台頭し、GraphQLがこのネオモダンなアプリケーション アーキテクチャで注目されています。
20年以上にわたり、アプリケーション アーキテクチャの大きなパラダイム シフトが、アプリケーション デリバリの進化に直接的な影響を与えてきました。これまでアプリケーション アーキテクチャは、そう運命づけられているかのように、市場シェアを支配して影響を与え、5年ごとに市場を形成し、その後約5年間市場を支配し、それがアプリケーション デリバリ市場に変化を促してきました。
マイクロサービス（クラウドネイティブ）は、2015年に市場のマインドシェアを獲得しましたが、それも2020年まででした。その年にサービス メッシュやイングレス制御がアプリケーション デリバリ環境の方向性を牽引するようになったためです。そして現在は、新たなアーキテクチャであるヘッドレスがマイクロサービスに代わってアプリケーション デリバリの原動力になろうとしていることが早くも示唆されています。
これまでの傾向から、ヘッドレス アーキテクチャは、2025年までに市場のマインドシェアを獲得し、アプリケーション デリバリ市場に変化をもたらすでしょう。このサイクルの信頼性が高いことと、APIやグラフィックス技術に関連する市場の活動や関心が高まっていることがあいまって、2030年まではアプリケーション デリバリに大きな影響は見られないでしょう。
ヘッドレス アーキテクチャを推進するトレンド
アプリケーション デリバリの次の大きなシフトをもたらす、APIファーストの設計とデータの民主化の2つの技術トレンドをけん引する外的要因は、いくつかあります。
- デジタル トランスフォーメーション
- 「APIの利用は大幅に進んでおり、調査に回答した組織のAPI平均使用数は15,564個、2021年の成長率は201％です。」（Noname Security）
- 2022年度に私が調べた市場活動の18％は、何らかの形でAPIに関連するものでした。37,000人以上のAPI専門家を調査したPostmanの『2022年版API現状レポート』の回答者の89％は、今後12か月の組織におけるAPIへの投資が増加するか、同程度で維持されると回答しています。
- 分散化
- ローコード/ノーコード
ビジネスのデジタル化の動きは、「デジタル エンタープライズ」が提供する「デジタル サービス」として現れています。デジタル サービスとは、アプリケーション、アプリケーション デリバリ、アプリケーション セキュリティ、データで構成され、APIを使用して統合、オーケストレーション、運用される、一時的なビジネスの構成概念です。現在、組織の82％が社内外のお客様にデジタル サービスを提供しています（SOAS 2022）。
同時に、主にAPIを介して通信するマイクロサービスの利用は増加し続けています。当社は独自の調査に基づき、「パブリックおよびプライベートAPIの数は、現在、2億に近づいており、2031年までにその数は数十億に達する可能性がある」と予測しています。
トレンド：その結果、成熟したアプリケーション デリバリ市場を揺るがす規模でAPIへのシフトが起こります。これは、モバイルとマイクロサービスが2010年から2020年にかけてアプリケーション デリバリ市場を揺るがしたのと同じ状況になるでしょう。
分散化は、リモート ワーク、IoTの大規模導入、データ プライバシーに関する懸念から生じる分散型のデジタル アクティビティの結果です。分散化は、特にインダストリアルIoTに適用されるとき、多くの場合、ブロックチェーンやエッジ コンピューティングなどのWeb3技術と組み合わされます。一方、分散化は実際には結果として変化を引き起こします。データとアプリケーションが「分散化」されることで、あらゆる分散システムにパフォーマンスが期待され、セキュリティの課題が生まれます。これには、データ処理とデジタル フロント エンド ワークロードをエッジに配置することを検討している77％の組織が含まれます（SOAS 2022）。
トレンド：分散化は、データを分散することが可能になるため、分散型アプリケーションを超える結果をもたらしています。従来のアプローチでは、データはアプリケーションの背後にある保護層にしまい込まれていましたが、分散化により、仲介者（アプリケーション）を必要とせずに、APIを介してデータを直接提供するという新しいアプローチが必要とされています。このシフトにより、アプリケーション アーキテクチャへの階層ベースのアプローチが排除され、外部パートナー、サードパーティ開発者、消費者に対してデータへの直接のルートが提供されます。アプリケーション アーキテクチャにおけるワークロードのこうした民主化の始まりは、マイクロサービス アーキテクチャに見ることができます。また、APIを介してデータを解放し、パートナーやサードパーティ開発者に価値をもたらすという逆転の発想に基づいたビジネス モデルにも、データの民主化という現存のビジネス価値を見ることができます。
また、APIを介してデータを解放し、パートナーやサードパーティ開発者に価値をもたらすという逆転の発想に基づいたビジネス モデルにも、データの民主化という現存のビジネス価値を見ることができます。
デジタル化により、エンジニアリング人材の需要が高まっており、その数は市場に存在する人材を上回っています。このため組織は、デジタル ビジネスが生成する膨大なデータ ストアに手を付けられずにいます。また、人材を確保していても過剰な負担がかかり、その多くはビジネス ニーズに応じて迅速に開発を行うことができません。
この需要と供給の隔たりにより、より多くのユーザーがソリューションやサービスを開発できるようにするためのローコード/ノーコード ソリューションが急増しています。調査によると、企業の75％が「ローコード/ノーコードと従来のイノベーションの組み合わせ」の採用を予定しています。
トレンド：ローコード/ノーコード ソリューションは、ビジネス ロジックとデータへのアクセスに依存し、どちらもデータの民主化とAPIファーストの設計により広く利用できるようになったものです。これらのソリューションのニーズが、データとAPIのトレンドの成熟を加速させています。
API関連市場（ルーター、ゲートウェイ、ミドルウェア）で使用される言葉は、マイクロサービスやモバイル、アーキテクチャの変化がもたらした前回の市場のシフトの前に使用されていた言葉と似ています。API作成の活動、用語、速度は、今回のシフトがアプリケーション デリバリとセキュリティの市場に大きな影響を与えるであろうことを示しています。
既に、業界のAPIベースの変化の始まりは、APIの可観測性、セキュリティ、脅威インテリジェンス、フェデレーションを特に重視した製品やサービスという形で現れています。
こうしたシフトは、隔離された状態では起こりません。実際、マイクロサービスが引き起こしたアプリケーション デリバリのシフトは、その大部分が、Kubernetesの普及と、従来はイングレス コントローラ（L7ルーティング）などのアプリケーション デリバリ技術で提供されていた機能を直接組み込むというアーキテクチャ上の決定によるものでした。
APIのシフトも変わりません。現在のトレンドは、このシフトが、データをより直接的にやり取りし、RESTベースのソリューションによりパフォーマンスの懸念に対処するAPIを設計するというアプローチである、GraphQLの台頭を促すこと、そしてさらに重要なこととして、このシフトのコア機能セットにアプリケーション デリバリ機能が組み込まれることを示しています。
ヘッドレス アーキテクチャ
APIの優位は、アナリストが「ヘッドレス アーキテクチャ」と呼ぶものを後押ししています。これは、従来のプレゼンテーション層なしにAPIとして提供されるビジネスの機能です。このアーキテクチャは、市場で台頭している別の技術トレンドである「構成可能なアプリケーション」の文脈でたびたび語られています。
ヘッドレス アーキテクチャは、ローコード/ノーコード ソリューションのニーズに対応するのに適しています。なぜなら、APIは、労力をかけずに簡単にカスタマイズできる構成可能なロジックを提供するための実践的な方法だからです。また、ヘッドレス アーキテクチャは、さまざまなアプリケーション、サービス、システムからデジタル サービスを構成するニーズにも対応し、主にAPI主導のIoT市場で既に実証されているとおり、分散ワークロードを統合するきわめて実践的な方法と言えます。
つまり、アプリケーション デリバリとセキュリティ技術における次のシフトはAPIによって推進され、それはヘッドレス アーキテクチャを主流とすることになると言えるでしょう。
最も重要な影響が及ぶのが、APIデリバリおよびセキュリティ サービスです。市場は長い間、APIを単にWebアプリケーション デリバリおよびセキュリティの特殊なユース ケースとして扱ってきました。今回のシフトにより、APIが、従来の手段では対処できないデリバリとセキュリティの特別なニーズを伴う、個別のクラスのエンティティであるという現実が明らかになるでしょう。これは特に、APIを介して直接提供されるデータ サービスの影響を調べてみるとよくわかります。これまでの歴史の大部分で、データは必ず、アプリケーションを介して提供されてきました。APIを介して直接的に提供されることはそれだけで大きなシフトですが、APIがもはやWebアプリケーションのサブセットではなく、それ自体で独立したアーキテクチャのコンポーネントである理由を完璧に示す例となっています。
ヘッドレス アーキテクチャにおけるGraphQLの役割
また、アプリケーション アーキテクチャの今回のシフトは、APIアプローチも歴史的にシフトする時期に、一般的にはAPIの使われ方に応じて、起こっています。すべてのAPIは最終的に、データの交換に使用されますが、時間とともに、そのデータの種類や形式はアプリケーション アーキテクチャの制約や機能に合わせて変化します。例えば、RESTとJSONは、より頻繁なデータ交換のニーズや、モバイル プラットフォームの計算能力の低下に対応するため、モバイルやマイクロサービスへのシフトとともに普及しました。SOAPとXMLは、膨大な構文解析を必要とし、帯域幅を過度に消費しました。RESTとJSONは、エンドポイントを記述するために既存のHTTP構造を活用し、JSONのよりシンプルなデータ形式にシフトすることで、負荷を削減しています。
SOAP/XMLもREST/JSONも従来の開発者スキルセットを必要としますが、トレンドは、開発者スキルをほとんど想定しないローコード/ノーコードに向かっています。GraphQLは、非開発者を対象としたシンプルなクエリ言語であり、シンプルなツールとの親和性が高く、幅広いユーザーが利用できるようになります。これにより、APIにアクセスしやすくなり、あらゆるデジタル サービスにAPIを組み込めるようになります。このため、アーキテクチャがAPIのみ（ヘッドレス）に向かって移行していく中で、GraphQLはREST/JSONの完璧な後継者となります。
GraphQLは現在、APIのスプロールや、SOA（サービス指向アーキテクチャ）からRESTへの移行を進めたのと同じパフォーマンスの問題に対処するためによく利用されているソリューションです。GraphQLには、仕様上の利点もあり、人材不足がもたらす課題を軽減するローコード/ノーコード ソリューションの開発の推進に役立っています。
最後に、GraphQLはAPIにクエリを実行し、現在のデータ ストアの大部分はAPIに対応しているため、GraphQLベースのソリューションは、アプリケーションという「仲介者」を効果的に排除し、データ ソース自体に直接アクセスできます。これは、リモートに配置されたデータに迅速かつ直接的にアクセスする必要がある分散型アプリケーションにとって特に有益です。
これにより、イングレス コントローラがマイクロサービス アーキテクチャへの「入口」の役割を果たして台頭したのと同じように、GraphQLは、ヘッドレス アーキテクチャへの「入口」という重要なポジションに位置づけられています。
まとめ
唯一、不変なものは変化することであると言いますが、それは技術にも当てはまります。誰かがゲームのルールを変えるまで、数年以上も立ち止まっていることなど、ほとんどありません。アプリケーション デリバリとセキュリティの世界では、このようなルールの一部は、アプリケーション アーキテクチャにより定義されます。したがって、アプリケーション デリバリとセキュリティの機能も進化させる動きがなければ、アプリケーション アーキテクチャで大きな変化は起こりません。
このシフトはまだ数年先ですが、GraphQLやAPIなどの技術がインフラストラクチャからエッジ、そしてアプリケーション デリバリまで、あらゆるものに多大な影響を及ぼしていることが既に明らかです。
ヘッドレス アーキテクチャが台頭し、GraphQLは重要な役割を果たすでしょう。