ソフトウェア アプリケーション開発者は、孤独な環境での作業を好む、一匹狼で、異端者で、隠遁的なタイプだと思われがちですが、エッジでの生活に類似するものがあるとすれば、プログラマーはすでにそれを体現しており、ソフトウェア エンジニアはエッジ コンピューティング環境でのコーディングに自然な親和性を持っているはずです。
開発者は皆同じだ。これは議論の余地のある発言だが、少なくとも、ソフトウェアアプリケーション開発者は皆、習慣の生き物であるという点に同意すれば、この言葉は当てはまる。彼らは皆、細部にまで徹底的にこだわり、問題解決能力に長けた分析的な脳の持ち主であり、そして大半の開発者は、ソーダとピザという、少々不安になるほどの偏愛を持っている。
しかしもちろん、すべての開発者が同じではありません。上位の「プレゼンテーション層」インターフェースに重点を置く開発者もいれば、ネットワークの専門家、機能性とパフォーマンスに重点を置くコアプラットフォームの専門家、そしてシステムアーキテクト、ペネトレーションテスター、データサイエンスの専門家など、多岐にわたります。
参照:採用キット: Python 開発者(TechRepublic Premium)
しかし、開発者はエンジニアリングの専門分野の性質だけでなく、その仕事が適用される実装面によっても区別されます。スマートフォンに特化する開発者もいれば、デスクトップに特化する開発者もいれば、組み込みシステムに特化する開発者もいれば、あらゆるドメインにまたがる可能性のあるクラウドネイティブアプリケーションに特化する開発者もいます。
進化するエッジを埋め込む
最後のコーダー陣営の中には、しばしば不遇な立場に立たされる組み込みコンピューティングの達人たちがいます。エッジ開発者に近い考え方を持つ組み込み開発者ですが、その役割はエッジ開発者とは全く異なります。彼らの役割は、家庭用暖房システムからフィットネストラッカー、そしておそらくテレビのリモコンに至るまで、あらゆるものに焦点を当てるように歴史的に定義されてきたからです。
しかし、ご存知の通り、これらの組み込みデバイス自体が今やIoT（モノのインターネット）の領域にまたがっています。空港のキオスクのコンピューターはリアルタイムで処理を行い、車載システムはWeb接続に接続され、交通機関や運賃徴収機はクラウドと断続的に接続され、工場のロボットや医療システムは常時接続のデータプレーン上で稼働しています。
一部の組み込みコンピューティングは依然として組み込みコンピューティングと呼ばれていますが、これらのデバイスの多く、特にそれらの内部にあるセンサーやゲージは、私たちがコンピューティングエッジと呼ぶ構造を形成するようになります。これが、エッジが組み込みコンピューティングや分散コンピューティングと異なる点です。これらは単にデータセンターから移動してきたマシンではなく、特定のジョブを実行するマシンなのです。
TechRepublic が既に教えてくれたように、「エッジコンピューティングは、リモートセンサー、スマートフォン、タブレット、そして機械から収集される IoT データに結び付けられるという点で、（分散コンピューティングとは異なり）異なります。このデータはリアルタイムで分析・レポートされ、その結果が現場の担当者に即座に活用される必要があります。」
これまでの説明をすべて終えて、これがソフトウェア コードが存在するための新しい運用基盤である場合、エッジ デベロッパーとなるのは何でしょうか。
エッジ開発者になるには何が必要ですか?
「エッジデバイスについて語るとき、もちろんデータ処理と分析をデバイスに近づけることを意味します」と、エンタープライズ・データ・プラットフォーム企業Tibcoのデジタル化戦略担当ディレクター、アレッサンドロ・キメラ氏は述べています。「これにより、レイテンシを削減し、エッジソフトウェアの応答時間を短縮することが可能になります。」
コネクテッドカーには膨大な数のエッジデバイスが搭載されていることを踏まえ、キメラは、こうした環境ではクラウドサービスへの接続に遅延が大きすぎると指摘しています。そもそも、トンネル内にいる場合は接続が不可能になります。つまり、これは多くの点で、常時接続コンピューティングという現代の概念を覆すものと言えるでしょう。
「つまり、エッジ開発者は、ある時点でクラウドデータセンターにどれだけのデータを送り返しているか、そしてどのデータがローカルで処理できるかについて、より慎重に考える必要があるということです」とキメラ氏は付け加えた。「エッジデバイスの電力が制限されている場合、エッジ開発者はエッジアプリケーションの設計と構築において、バッテリー使用量を考慮する必要があります。クラウドへの送信は電力を大量に消費するため、アプリケーションが接続を15分ごとから1時間ごとに延期できる場合、特にアプリケーションの機能上、タイムクリティカルまたはミッションクリティカルでない場合は、エンジニアリングの観点から理にかなっています。」
MongoDB の開発者関係担当シニアディレクターの Joe Drumgoole 氏は、Chimera 氏の意見にほぼ同意しているが、以前にも同じ状況に陥ったことがあると考えている。
「エッジ開発者。なんて古風で空想的な概念なのでしょう」とドラムグール氏は言う。「私はAdaプログラミング言語で育ちました。この言語は、エッジ開発者という概念のために特別に作られたものです。当時、私たちは彼らをリアルタイムエンジニアや組み込みシステム開発者と呼んでいました。Ada言語はほぼ過去のものとなりましたが、エッジ開発には今でも多くの制約が残っています。しかし、今ではツールは進化し、言語も多様化し、世界中でエッジ開発者向けのツールキットが構築されています。」
しかし、ドラムグール氏はソフトウェアの進化と進歩全般について哲学的な見解を示し、変わらないものがあると考えています。ご存知の通り、エッジセンサーは比較的単純な単一のプログラムを実行するハードウェアユニットであることが多いです。メモリの制約は確かに存在します。今日、Pythonプログラムを実行する人がメモリ消費を気にするでしょうか？しかし、画面、キーボード、マウスのないハードウェアで作業することの難しさは依然として残っています。
「これがエッジプログラミングの苦痛と喜びの源です」とドラムグール氏は語った。「プログラマブルな読み出し専用メモリデバイスを焼き付ける作業には、非常に誠実な側面があります。動作するか動作しないかのどちらかであり、動作しない場合のコストは劇的なものです。優れたエッジプログラマーは、ハードウェアとソフトウェアを理解し、多少のはんだ付けを厭わず、オシロスコープの読み取りが可能で、オームの法則も忘れません。」
大規模なマイクロクラスターを管理する方法
この分野では多くの変化が起きています。今日、エッジ開発者はクラウドネイティブ開発のベストプラクティスをネイティブレベルで理解する必要があります。さらに根本的な問題として、エッジの独自性に対応するためにどのような適応が必要になるかを認識することが求められます。
SUSEのエッジ担当ゼネラルマネージャー、キース・バジル氏は、これは非常に難しい課題だと考えています。彼によると、通常は異なる業界のスキルセットをすべて1つのチームに統合する必要があるためです。専任のエッジチームを擁するSUSEは、この分野で豊富な経験を有しています。「エッジゾーン」という用語を新たに定義すべきではないかという意見さえあります。
「DevOpsの観点から見ると、エッジを大規模な『マイクロクラスター』の集合体とみなすという考え方は非常に影響力があります」とバジル氏は述べた。「コンテナ内でソフトウェアを構築する場合、開発者は新たな制約の中で作業を進める必要があり、エッジのハードウェアでは異なるCPUアーキテクチャ、限られたメモリ、そしてより小さなディスク容量といった要素を考慮する必要があります。」
エッジでは、Kubernetes クラスターはリモートの場所で実行され、産業用 IoT デバイスは同じネットワーク上のピアになります。
「エッジ開発者として最初に頭に浮かぶ疑問の一つは、これらのIIOTデバイスへの接続性です」とバジル氏は述べた。「IIOTプロトコルのサポートをアプリケーションに組み込むのか、それとも既存のオープンソースプロジェクトを拡張してデバイスアクセスの管理を任せるのか？」
これがエッジ コンピューティングの難しいところです。多くの導入がまだ初期段階にあるため、この議論の一部はまだ議論の余地があります。
優位性：スピード、リソース、理解しやすさ
エッジセンサーは、非常に制約のあるコンピューティングスペース内で、リアルタイムまたはほぼリアルタイムで極めて高速にデータを送信するように設計されており、実際にそのように要求されているため、1マイクログラムの電力消費も非常に重要になることは明らかです。セルフサービス分析およびデータサイエンス企業Alteryxの最高データ・分析責任者であるアラン・ジェイコブソン氏によると、エッジ開発者が重視する主な領域は、速度、限られたコンピューティングリソース、そして理解しやすさの3つです。
Alteryxの技術パートナーであるマクラーレン・レーシングの場合、F1レースカー1台には約300個のテレメトリセンサーが搭載されており、レースウィークエンドを通して10万点を超えるトラックサイドのパラメータが提供されます。膨大なデータセットは、特定の分析のために数秒で世界中に送信され、場合によっては、データはトラックサイドで使用されたり、車両上で分析されたりします。
エッジセンサーから生成される膨大なデータ量を考えると、必ずしも分析にデータを取り込むことが現実的ではありません。大規模データ、高速コンピューティング、そして回復力のあるシステムが求められる現代社会においては、ユーザーが必要な場所にコンピューティングパワーを移動できる分析プラットフォームが不可欠です。こうした大規模データセットの分析こそが、Alteryxの真髄です。
「このスピード要件には、開発者とドメインエキスパートの両方が理解できるテクノロジーが不可欠です」とジェイコブソン氏は説明します。「得られた洞察は、現場のエンジニアが容易に理解できなければ役に立ちません。洞察を得るまでのスピードが鍵となるエッジコンピューティングでは、結果の品質保証に費やす時間はほとんどありません。得られた洞察はすぐに役立つか、捨てられるかのどちらかです。コンピューティングを外部にプッシュし、データを取り込むタイミングを判断できる柔軟な開発者が求められます。」
エッジ開発は依然として開発である
もし私たちが、エッジ開発者がはるかに臨床的にきめ細かな方法で仕事をし、たまに原始の沼地から這い上がってきてピザやソーダを食べるような、新しいディストピアのコンピューティング ゾーンを描いていたとしたら、それは間違いです。
参照:採用キット: バックエンド開発者(TechRepublic Premium)
エッジ開発は実際には依然としてソフトウェア アプリケーション開発であると、EMEA ソリューションおよびクラウド ネイティブ API 企業 Kong の VP である Chris Darvill 氏は言います。
「エッジ開発者に求められる要件は、ある意味では従来の開発者と大きく変わりません。将来的にはどちらか一方ではなく、市場にソリューションを提供するには両方の要件が求められるでしょう」とダービル氏は述べた。「エッジ開発者は、既存のエッジAPIや集中型APIを再利用することで、新しいアプリケーションやサービスの構築を加速するために、明確に定義されたAPIを特徴とする最新の開発手法を活用する必要があります。また、セキュリティ、ガバナンス、可観測性を重視し、開発中のアプリケーションに適切な標準が適用されるようにするために、一貫性のあるツールも活用する必要があります。」
はい、エッジソフトウェアプログラミングにおけるマイクロサービス、コンテナ、Kubernetesの利用は今後増加するでしょう。そして、オンプレミスコンピューティングが利用されている場合でも、この分野のほぼすべてのソフトウェアエンジニアリング業務はクラウドネイティブ化に向けて推進されるべきであることは間違いありません。
しかし、エッジ開発は依然としてコードであり、おそらく 10 年後には、モバイル開発が今日の確立された概念の一部となっているのと同じように、すべての開発者が披露し、実行できることが期待されるコーディング能力の範囲の一部として受け入れられるでしょう。
最先端のコードは、ツールやツールセットと同様に鋭くなってきています。そのため、全天候型手袋を必ず持参してください。
