以下のシナリオに頭を包む：
救急車が高速道路を駆け抜け、心臓発作の疑いのある被害者を危篤状態で輸送しています。 患者が病院に到着するずっと前に、医師たちは、5Gワイヤレス接続を介して救急車から送信されたセンサーや動画フィードから最大2番目のデータを注ぎ込み、彼の状態を遠隔で検査しています。 彼が緊急治療室に運ばれる前でも、主治医は既に問題の詳細な画像を持っており、仕事に行く準備ができています。 あるいは、さらにエキサイティングなことに、救急車にいる間に遠隔治療を受けることで患者の命が救われました。
素晴らしいことですが、それは来るべき魅力だけです。
当社は、リアルタイムイベント駆動型技術の展開により、膨大な量のデータを実用可能な情報に変え、コマースからパーソナルセキュリティまであらゆる点で根本的な改善につながる変革の時代を迎えています。 たとえば、セントラルパークで子供が迷子になった場合、彼女の写真は、AI認識を搭載した何千ものビデオカメラに自動的に送信され、検索者が彼女を見つけることができるようになります。
あるいは、スーパーマーケットを通って買い物客を導くインテリジェントショッピングカートを使って食料品リストを記入し、ルートを最適化して、購買習慣について知っていることに基づいて提案したりすることを考えてください。 （実際、これらのインテリジェントショッピングカートはイスラエルで既にテストされており、その結果、それらを使用している買い物客は、1回の訪問あたり平均20％多く支出していることがわかります）。
それは、私たちの未来を垣間見ることができます。 しかし、私たち自身からあまり先を行き過ぎないようにしましょう。 クールに聞こえるが、この種の高度な機能は複雑であり、大量の情報転送のために高速帯域幅を保証できる信頼性の高いインフラストラクチャが必要です。
エッジを得る
この移行を迅速化する1つの進歩は、マルチアクセスエッジコンピューティング（MEC）の出現であり、本質的にコンピューティングとクラウドライクな機能がネットワークのエッジに押し出される分散アーキテクチャです。 これが鍵となるのは、私たちが話している新しいアプリケーションが、特に低遅延、高帯域幅、リソース消費に関してネットワーク機能に余分な要求を課すためです。 通信事業者は、ここでの道をリードするのに最適な位置にあり、今後数年間でより多くのことを聞くことができると期待しています。
これらのシステムが瞬時に反応して重要なイベントを管理するのに役立つため、大量のデータが実際のリアルタイムでエッジでフィルタリングされ処理されることで、発生する可能性について考えてください。 接続された救急車の例を考えてみましょう。 システムは、救急車の患者を監視する生体認証システムと通信しています。 彼らの状態についての何かが変化した場合、病院の緊急担当者は、エッジで収集された大量で複雑なデータの分析をすぐに転送します。
この展開は、分散エッジ対応ネットワークにおけるデータの動的な移動をサポートしなければならないため、バックグラウンドでは多くのことが起こっています。 救急車が道路を下る間、その車両から送信されたデータは確実に転送されなければなりません。 救急車との継続的な接触を維持することは、文字通り生死の問題となり、システムは、道路の次のMECによって情報が収集されることを保証しなければなりません。
開発者のジレンマ
エッジでシームレスに動作するアプリケーションを設計することになると、すぐに2つの問題に遭遇します。 1つは開発上の課題、2つ目は運用上の課題です。
開発の観点から、すべてのことを結びつけることで、関心のある状況を本質的に検知、分析、対応するリアルタイムシステムを作成する必要があります。 それは簡単ではありません。 運用面では、この建物をどのように展開し、稼働させ続けるのですか？ また、より多くの容量が必要であるため、インフラストラクチャが負荷を処理できるようにするにはどうすればよいですか？
また、分散環境（コネクテッドビークルがあるネットワークから次のネットワークに変更した場合など）のイベント駆動型アプリケーションでは、複数の管理ドメイン間でデータを共有できるようにする必要があります。 これにより、新しいマルチテナントの問題を提起します。 複数の管理ドメイン間でデータを共有しますか？ それをどうやるか？ 会社内または会社外を共有していますか？ 私のポイントは、分散環境では、これらの開発と運用上の問題は、急いで非常に複雑になります。
病院にスピードを上げるにつれて、救急車がMECを次々に通過する例についてもう一度考えてみましょう。 MECは、本質的にミニクラウドとして機能するロジックを実行し、EKGなどの患者のストリーミングデータを分析しています。 しかし、車両が別のMECから別のMECに移動する場合、救急車から「状態情報」と呼ぶものは、救急車が新しいMECに接続するときに、ゼロから再計算するのではなく、シームレスに転送する必要があります。
シンプルにする
これらのタイプのアプリケーションは、非常に複雑であり、単純なアプリケーションの作成に数ヶ月以上かかる従来の開発プラットフォームでは動作しません。 分散システムを構築している私のキャリアで3回目です。 私はIngres and Forte、そして今度はVantiqでそれをしました。 ハードコードをするには物事が複雑になりすぎています。 エリートコーダーでさえ、この種のタスクはほぼ不可能であり、仕事を完了するために一連の個別の製品が必要になることに気付いています。
率直に言って、コーディングをずっとシンプルにする必要があります。開発者が高レベルの運用プロセスを実際のデジタルアプリケーション向けのフレームワークに変換するのを支援する方法を見つける必要があります。
このハードルを克服する1つの方法は、開発者がこの種のシナリオで直面する複雑さを処理できるようにする抽象化されたローコードフレームワークを採用することです。 これらのローコードツールは、開発者がソリューションをより迅速に作成するために使用できる、よりアジャイルなフレームワークを可能にします。 しばらくの間、さまざまな形のローコードが存在していましたが、パンデミックにより企業が計画を加速するにつれて、2020年を通じて急増したデジタル化に対する市場の需要のおかげで、このアプローチは急速にスピードを上げています。 また、成熟したアジャイルDevOpsプラクティスに見られる速度の必要性にもうまく適合します。
これが実際にどのように展開するかについてはまだ不明ですが、最良のアプローチに関する議論は、後ではなく早く表面化する必要があります。 私たちは、IoT、AI、機械学習、エッジコンピューティングの最新の進歩を活用できるアプリケーションが必要になる未来に急速に近づいています。 そして、私たちは急いでそこに行くでしょう。
