イノベーションへの入り口はネットワークにあります
ミズーリ州セントルイス。 フランス、オルレアン。 ホットゲート、ギリシャ。
歴史を通じて、特定の場所は「_____への入り口」という言葉で称えられてきました。 これらの場所は、王国の防衛（フランス、スパルタ）または新しい土地への入植に向けた大規模な取り組みの始まり（セントルイス）として戦略的に重要であることで有名です。 ゲートウェイは、通常は重要な場所など、別の場所につながる場所です。 それをコントロールすれば、誰が、または何が入るか（または出ていくか）をコントロールできます。 アクセスを制御するだけでなく、侵入や攻撃に対するより効率的な保護ポイントも提供します。 現代世界では、国際空港で「税関」を通過する必要があるときや、入国するために恐ろしい「セキュリティ」を通過しなければならないときに、世界中の空港でこれらのゲートウェイを目にします。
したがって、テクノロジーの歴史の中で、戦略的に重要であると考えられ、総称して「ゲートウェイ」と呼ばれる一連のデバイスが登場したことは驚くことではありません。
アプリケーションの場合、これらのデバイス (アーキテクチャの戦略的なポイントを占める) は、新しいテクノロジのセキュリティ、スケール、および多くの場合相互運用性を実現します。
大まかに言えば、ネットワーク ファイアウォールは、ネットワーク内のアプリ中心のゲートウェイの「最初の」インスタンスと見なすことができます。 初期の頃は、結局のところ、彼らは門番でした。 ネットワーク ファイアウォールがアクセスを許可した場合にのみ、企業ネットワークの外部からアプリにアクセスできます。 しかし、今日のゲートウェイははるかにアプリケーションに精通しており、セキュリティのニーズだけでなく、スケール、アクセス、相互運用性にも対応しています。
これらはすべて、IoT 時代が進むにつれて重要な懸念事項となります。 Vanson Bourne が最近実施した HCL 調査では、回答者の 93% がセキュリティ、86% が規模、83% が相互運用性について懸念していることがわかりました。 これらはどれも驚くべきことではありません。 データの収集、コマンドの交換、監視のためにアプリへのアクセスを必要とするデバイスの数が膨大になると、ネットワークに多大な影響が及ぶことは間違いありません。 企業が次の「もの」を市場に投入するようプレッシャーを受けるスピードは、セキュリティに悪影響を及ぼします。 また、意図された用途を実行するだけでなく、他のモノやアプリとの通信にも大きく依存する新しい市場では、相互運用性は常に課題となります。 新興市場は急速に分岐する傾向があり、さまざまな基準を中心にグループが集まり、ある日、1 つまたは 2 つの基準に落ち着きます。 しかし、初期段階では、選択肢が複雑でわかりにくいことがよくあります。 イノベーターたちは騒ぎが収まるのを待つつもりはない。 結局のところ、イノベーターは市場に参入することで勝利するのです。
問題は、新興技術が成熟し、標準が確立される間に、セキュリティ、規模、相互運用性にどのように対処するかになります。 その答えは、一般的にはゲートウェイです。
過去には、XML や SOAP などの他のテクノロジやプロトコルに関する同様の課題に対処するためにゲートウェイが登場しました。 Web サービスの「標準」としての RPC/ENC と DOC/LIT の争いを覚えている (そしておそらくうんざりする) のは私だけではないはずです。 そして、最近の JSON と XML の戦いを思い出すのは私だけではありません。 現在、IoT 分野では MQTT、CoAP、AMQP が主導権を争う綱引きが起こっています。
しかし、イノベーションは待てず、新しいテクノロジーやプロトコルから生じる課題に対処するためのゲートウェイが次々と登場しています。
HTTP2 ゲートウェイ
HTTP2 ゲートウェイは主に、 HTTP/1x と HTTP/2 間の相互運用性に関する課題に対処します。 これらのデバイスは、最新の HTTP 標準を使用するとより迅速に動作するモバイル デバイスや IoT デバイスをサポートするために、HTTP2 を「外部」で終了します。 これにより、イノベーターは、新しい標準をサポートするためにアプリやネットワーク インフラストラクチャをアップグレードする際に必要となる大規模な混乱を招くことなく、消費者やモノに HTTP2 のサポートを提供できるようになります。 確かに、いつか誰もが HTTP2 を実行するようになることが期待されていますが、それまでの間、HTTP2 ゲートウェイはイノベーターが全力で前進するために必要な相互運用性を提供します。
APIゲートウェイ
API ゲートウェイの出現は、繭から蝶が出てくることに似ています。 それは芋虫（SOA ゲートウェイ）でしたが、今では蝶（API ゲートウェイ）になっています。 さて、このカテゴリにまったく新しい参入者がいないと言っているわけではありません。確かに存在します。しかし、両方の基盤が HTTP にあるため、主に多くの類似点があります。 SOA ゲートウェイは主に XML と SOAP に重点を置いていましたが、API ゲートウェイは HTTP エンドポイントを使用して実装された JSON と RESTful API に重点を置いています。
これらのデバイスは、セキュリティとスケールを提供し、場合によっては相互運用性サービスも提供します。 アプリの言語に精通しており、JSON と HTTP を同じように簡単に使用して、アプリケーション間だけでなく環境間でも API 呼び出しを分散できるマイクロサービスやサーバーレスなどの新しいアプリ モデルをサポートするための強力な基盤を提供します。 API ゲートウェイは、クォータ (呼び出しのレート制限) を適用し、API キー管理を介してアクセスを制御することで、スケーラビリティを保護する役割も果たします。
これらは単なる「ロード バランサー」ではありませんが、ロード バランシングによるスケールは確かに API ゲートウェイの重要な特性です。 これらの優れた機能は、単純な古い負荷分散を超えて、一貫した消費者向けエクスペリエンスを実現すると同時に、開発者と企業がクラウドとサーバーレスを活用できるようにする必要があります。 API ゲートウェイは、API を保護および拡張する場合、「スマート」である必要があります。つまり、リクエストと応答を検査できるだけでなく、OAuth2 や JWT などの外部認証プロバイダーと統合できる必要があります。
IoTゲートウェイ
IoT ゲートウェイは、今日のゲートウェイの中で最も新しいものですが、すでに存在しており、それぞれの市場における他のゲートウェイよりも IoT イニシアチブの成功にとって極めて重要です。 これはプロトコルに関係しており、Web にまったく適していないプロトコルです。 多くの消費者向けガジェットは「Web」を話しますが、デバイス上でより効率的でコンピューティングの消費が少ないため、モノのメーカーは MQTT や CoAP などの IoT 固有のプロトコルに依存するケースが増えています。 しかし、そのデータを受信するアプリは必ずしも MQTT に対応しているわけではなく、対応している場合でも、（おそらく膨大な）需要を満たすために独自に拡張することはできません。
こうして、IoT と Web の言語に精通し、拡張とアクセスのセキュリティ保護を同時に実現できるIoT ゲートウェイが誕生しました。 これらのゲートウェイは、API ゲートウェイと同様に、リクエストと応答を変換してルーティングするだけでなく、異常や不正な動作を検出して悪用を防ぐのに十分な「スマート」である必要があります。
アーキテクチャ的には、ゲートウェイはネットワークとアプリケーションへのアクセスを提供します。 リクエストはそれらを経由して送られ、アクセスを制御し、翻訳を提供し、セキュリティを強化するための戦略的な制御ポイントになります。 これらは、新しいテクノロジーやプロトコルが既存のビジネスやアプリへの混乱やリスクを少なくして登場したときに発生する自然な移行期間中に、組織がイノベーションを起こす能力を提供するため、新しいテクノロジーの重要な実現要因となります。
ゲートウェイは、アーキテクチャ上の構成要素として見られる傾向がありますが、今日では、企業が新興テクノロジーの力を活用できるようにするイノベーションの重要な推進要因であることも同様に多くなっています。