ブログ | CTO オフィス

ヘッドレスアーキテクチャが増加中

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2022年12月12日公開

API の爆発的かつ広範な使用は、ヘッドレス アーキテクチャの台頭に貢献し、この新時代のapplicationアーキテクチャにおいて GraphQL に重要な位置を与えています。

20 年以上にわたり、アプリ アーキテクチャにおける大きなパラダイム シフトが、アプリ配信の進化に直接影響を与えてきました。 歴史的に、市場を支配し影響を与える運命にあるapplicationアーキテクチャは 5 年ごとに登場し、市場を形成し始め、その後約 5 年で支配的になり、それが今度はアプリ配信市場の変化を促進します。 

マイクロサービス (クラウド ネイティブ) は 2015 年に市場で注目を集めましたが、サービス メッシュとイングレス制御が台頭し、アプリ配信環境の方向性が決定的になったのは 2020 年になってからでした。 現在、マイクロサービスに代わるアプリ配信の原動力となる新しいアーキテクチャ、ヘッドレスが登場しつつある兆候が見られます。

アプリ配信におけるアプリの影響

過去の傾向に基づくと、ヘッドレス アーキテクチャは 2025 年までに市場の注目を集め、アプリ配信市場に変化をもたらし始めるでしょう。 このサイクルの信頼性と、API およびグラフ テクノロジに関連する市場における活動と関心の高まりが相まって、2030 年までにアプリの配信に大きな影響を与えると予想されます。

ヘッドレス アーキテクチャを推進するトレンド

2 つのテクノロジー トレンドの融合を推進する外部要因がいくつかあり、その結果、アプリ配信に次の大きな変化がもたらされるでしょう。 API ファーストの設計データの民主化

  1. デジタルトランスフォーメーション
  2. ビジネスをデジタル化する動きは、「デジタル企業」が提供する「デジタル サービス」として現れます。 デジタル サービスは、アプリ、アプリ配信、アプリ セキュリティ、データから構成される一時的なビジネス構造であり、API を使用して統合、オーケストレーション、運用されます。 現在、組織の 82% が社内外の消費者にデジタル サービスを提供しています(SOAS 2022 )。

    同時に、主に API を介して通信するマイクロサービスの採用も増加し続けています。 当社独自の調査によると、「現在、パブリック API とプライベート API の数は 2 億に近づいており、2031 年までにその数は数十億に達する可能性がある」と推定しています。

    トレンド: その結果、モバイルとマイクロサービスが 2010 年から 2020 年にかけてアプリ配信市場に混乱をもたらしたのとほぼ同じように、成熟したアプリ配信市場に混乱をもたらすほどの規模で API への移行が起こります。

    • 「API は大いに活用されており、調査回答組織では平均 15,564 個の API が使用されており、2021 年までの成長率は 201% です」( Noname Security )。
    • 私が 2022 年度に追跡した市場活動の 18% は、何らかの形で API に関連していました。 37,000人以上のAPIプロフェッショナルを対象に調査したPostmanの2022年API状況レポートの回答者の89%によると、組織におけるAPIへの投資は今後12か月間で増加するか、同じままになるとのことです。

  3. 分散化
  4. 分散化は、リモートワーク、IoT の大量導入、データ プライバシーに関する懸念から生じる分散型デジタル活動の結果です。 分散化は、特に産業用 IoT に適用される場合、ブロックチェーンやエッジ コンピューティングなどの Web3 テクノロジと結び付けられることが多いです。 しかし、分散化の結果こそが、実は混乱を引き起こす原因なのです。 データとapplicationsの両方が「分散化」されるため、分散システムで予想されるパフォーマンスとセキュリティの課題が発生します。 これには、エッジでデータ処理とデジタル フロントエンド ワークロードを展開することを検討している組織の 77% が含まれます ( SOAS 2022 )。

    傾向: 分散化は、データを分散する機能も組み込むため、分散applicationsを超えた影響を及ぼします。 従来のアプローチでは、データはapplicationsの背後にある保護された層に配置されます。 分散化により、仲介者 (application) を必要とせずに、データが API を通じて直接公開されるという新しいアプローチが強制されています。 この移行により、applicationアーキテクチャに対する階層ベースのアプローチがなくなり、外部パートナー、サードパーティの開発者、および消費者にデータへの直接ルートが提供されます。 applicationアーキテクチャ内でのワークロードの民主化の始まりは、マイクロサービス アーキテクチャに見られます。 また、反転に依存するビジネス モデルでデータを民主化すること、つまり API を通じてデータを解放し、パートナーやサードパーティの開発者に価値を生み出すことには、既存のビジネス価値があると考えています。

    また、反転に依存するビジネス モデルでデータを民主化すること、つまり API を通じてデータを解放し、パートナーやサードパーティの開発者に価値を生み出すことには、既存のビジネス価値があると考えています。

     

  5. ローコード/ノーコード
  6. デジタル化により、市場に存在する以上のエンジニアリング人材の需要が高まっています。 これにより、組織はデジタル ビジネスによって生成される膨大なデータ ストアを活用できなくなります。 存在する才能は過負荷状態にあり、ビジネスの要求に応じて迅速に成長できないことがよくあります。

    この需要と供給のギャップにより、ローコード/ノーコード ソリューションが急増し、より幅広いユーザーがソリューションやサービスを開発できるようになりました。 調査によると、企業の 75% が「ローコード/ノーコードと従来のイノベーションの組み合わせ」を採用するそうです。

    傾向: ローコード/ノーコード ソリューションは、ビジネス ロジックとデータへのアクセスに依存しており、これらは両方とも、データの民主化と API ファースト設計によって広く利用可能になります。 これらのソリューションの必要性は、データと API の両方のトレンドの成熟を促進する役割を果たします。

API に関連する市場で使用される言語 (ルーター、ゲートウェイ、ミドルウェア) は、マイクロサービス、モバイル、アーキテクチャの変更によって市場が以前変化する前に使用されていた言語と似ています。 API 作成の活動、用語、速度を見ると、この変化がアプリ配信とセキュリティ市場に大きな影響を与えることがわかります。

API の可観測性、セキュリティ、脅威インテリジェンス、フェデレーションに特化した製品やサービスの形で、業界ではすでに API ベースの混乱が始まっています。

これらの変化は真空中で起こるわけではありません。 実際、マイクロサービスによるアプリ配信の変化は、Kubernetes の広範な採用と、イングレス コントローラー (L7 ルーティング) などのアプリ配信テクノロジーによって従来提供されていた機能を直接組み込むというアーキテクチャ上の決定によるところが大きいです。

API の移行も同様で、現在の傾向から、この移行により GraphQL が普及することが予想されます。GraphQL は、データとより直接的にやり取りし、REST ベースのソリューションによるパフォーマンスの問題に対処する API 設計アプローチであり、さらに重要な点として、アプリ配信機能をコア機能セットに組み込むことになります。

ヘッドレス アーキテクチャ

API の優位性により、アナリストが「ヘッドレス アーキテクチャ」と呼ぶものが推進されています。つまり、従来のプレゼンテーション レイヤーなしでビジネス機能と機能が API として公開されるのです。 このアーキテクチャは、市場で台頭しつつあるもう 1 つの技術トレンドである「コンポーザブルapplications」の文脈でよく議論されます。

ヘッドレスアーキテクチャ

ヘッドレス アーキテクチャは、API が多大な労力をかけずに簡単にカスタマイズできる構成可能なロジックを提供する実用的な方法であるため、ローコード/ノーコード ソリューションのニーズに対応するのに適しています。 ヘッドレス アーキテクチャは、さまざまなapplications、サービス、システムからデジタル サービスを構成するニーズにも対応しており、主に API 主導の IoT 市場ですでに証明されているように、分散ワークロードを統合する非常に実用的な方法です。

したがって、アプリ配信とセキュリティ技術の次の変化は API によって推進され、ヘッドレス アーキテクチャが主流になるだろうと言うのは妥当なようです。

最も大きな影響は、API 配信とセキュリティ サービスに及ぶでしょう。 市場では長い間、API は単に Web アプリの配信とセキュリティの特殊なユースケースとして扱われてきました。 この変化により、API は従来の手段では対応できない特定の配信およびセキュリティのニーズを持つ別個のエンティティ クラスであるという現実が明らかになります。 これは、API 経由で直接公開されるデータ サービスの影響を調査する場合に特に当てはまります。 歴史の大部分において、データはapplicationsを通じてのみ公開されてきました。 API 経由で直接公開されること自体が大きな変化ですが、API がもはや Web アプリのサブセットではなく、それ自体が独立したアーキテクチャ コンポーネントである理由を示す完璧な例となります。 

ヘッドレス アーキテクチャにおける GraphQL の役割

アプリ アーキテクチャのこの変化は、API アプローチも歴史的に変化してきた時期に起こっており、通常は API の使用方法に応じて変化しています。 すべての API は最終的にはデータを交換するために使用されますが、時間の経過とともに、そのデータのタイプと形式はapplicationアーキテクチャの制約と機能を反映して変化します。 たとえば、より頻繁なデータ交換の必要性とモバイル プラットフォームの計算能力の低下への対応として、モバイルとマイクロサービスへの移行とともに、REST と JSON が普及しました。 SOAP と XML では、広範な解析が必要となり、過剰な帯域幅を消費しました。 REST と JSON は、既存の HTTP 構造を活用してエンドポイントを記述し、JSON のよりシンプルなデータ形式に移行することで負担を軽減しました。

ただし、SOAP/XML と REST/JSON はどちらも従来の開発者スキルを必要とし、開発者スキルをほとんど必要としないローコード/ノーコードへと傾向が進んでいます。 GraphQL は、開発者以外のユーザー向けに設計されたシンプルなクエリ言語であり、シンプルなツールと非常に親和性が高く、より幅広いユーザーが利用できます。 これにより、API がアクセス可能になり、あらゆる種類のデジタル サービスに組み込むことができるようになります。 これにより、アーキテクチャが API のみ (ヘッドレス) に移行するにつれて、REST/JSON の完璧な代替品になります。

GraphQL は、API の拡散の問題と、SOA (サービス指向アーキテクチャ) から REST への移行を促進したのと同じパフォーマンスの問題に対する現在のお気に入りのソリューションです。 GraphQL には仕様の利点もあり、人材不足の課題を軽減するローコード/ノーコード ソリューションの開発を促進するのに役立っています。

最後に、GraphQL は API をクエリし、今日のデータ ストアの大部分は API 対応であるため、GraphQL ベースのソリューションはapplicationの「仲介者」を効果的に排除し、データ ソース自体に直接アクセスできます。 これは、遠隔地のデータに高速かつ直接アクセスする必要がある分散applicationsに特に役立ちます。

これにより、GraphQL は、イングレス コントローラーがマイクロサービス アーキテクチャへの「ゲートウェイ」として機能するようになったのと同じように、ヘッドレス アーキテクチャへの「ゲートウェイ」として機能するのに最適な位置に置かれます。

結論

唯一不変なものは変化であると言われますが、それはテクノロジーにも当てはまります。 誰かがゲームのルールを変えるまで、数年以上何もしないことはめったにありません。 アプリの配信とセキュリティの世界では、これらのルールはapplicationアーキテクチャによって部分的に定義されます。 したがって、アプリケーションの配信とセキュリティも進化させる強制機能として機能しない限り、applicationアーキテクチャに大きな変化は発生しません。

この変化はまだ数年先のことですが、GraphQL や API などのテクノロジーが、インフラストラクチャからエッジ、アプリ配信まで、あらゆるものにすでに大きな影響を与えていることが分かります。

ヘッドレス アーキテクチャが増加しており、GraphQL が重要な役割を果たすようになります。