ジェネレーティブ AI とは何ですか? AIOps への道ですか?

インフラストラクチャにおける課題の 1 つは、単一のアプリケーションを配信して保護するために必要な無数のデバイス、サービス、およびシステムを構成することです。 組織は、「サービスとしての」提供を除くと、平均 23 種類のアプリ サービスに依存しています。 

さて、Web アプリと API 保護サービスの構成が、従来の単純な負荷分散サービスの構成とは異なることは言うまでもありません。 つまり、アプリ サービスの構成と運用を担当する人は、12 種類の異なる「言語」の専門家である必要がある可能性があるということです。 

業界は長年にわたり、この問題に対処しようと努めてきました。 API があらゆるものを構成する主な手段となったとき、アプリ配信とセキュリティ サービスも例外ではありませんでした。 誰もが命令型 API から始めましたが、これは単にコマンドの発行方法を変更しただけです。 CLI でコマンドを入力する代わりに、HTTP 経由で API コマンドを送信しました。 

すぐに、命令型 API に依存することで発生するAPI 税が高すぎることが明らかになり、業界は宣言型 API に移行しました。 しかし残念なことに、業界のほとんどは、宣言型とは「JSON としての構成」を意味すると判断しました。 つまり、宣言型の背後にある意図（この言葉は重要なので覚えておいてください）である「何をしたいのかを教えてくれれば、私が代わりにやります」ではなく、「これが私が望む構成です。それを実行する大変な作業を行ってください」という形になってしまいました。 

まったく同じというわけではなく、特定のソリューションに特有の運用モデルに関して、同じレベルの専門知識が必要でした。 ロード バランサーが「プール」を使用するか「ファーム」を使用するかについて業界が合意に達したかどうかはわかりませんが、仮想サーバーが実際のサーバーやアプリケーション インスタンスとどのように対話するかというより複雑な詳細については言うまでもありません。 したがって、業界が宣言型で行ったことは、コマンド レベルの作業をオペレーターからシステムにオフロードすることだけでした。

現在、Generative AI が実現しているのは、ローコード/ノーコードの形式です。 これらは、結果の生成を導く適切に形成された仕様に基づいているため、一部の結果よりも信頼性が高くなります。 結局のところ、「hello world」と書く方法は限られていますが、質問に答える方法は数百万通りあります。

つまり、トレーニング済みのモデルに「ロード バランサーを構成して App A をスケーリングしたい」と伝えることができ、システムが構成を出力できるはずです。 しかし、それ以上に、「Z を使用してシステム Y で X を実行するスクリプトをください」と指示すれば、すぐに実行できるはずです。 構成を生成するだけでなく、適切なシステムに展開するために必要な自動化も生成する必要があります。 

ああ見て。 すでにそうなっている。

しかし、これは簡単なことです。 さらに、「ああ、ところで、デプロイしてください」と指示できるはずです。 そして、私が朝のコーヒーを楽しんでいる間に、それが完了するはずです。 そして、もしかしたら私にもちょっとした歌を歌ってくれるかもしれません。 

でも待ってください、まだあります! 後で生成 AI システムに「グリーンベイのユーザーが頻繁にログインしていてパフォーマンスが低下しているので、アプリ A を複製してミルウォーキーのサイトに移動してください」と指示できるとしたらどうでしょうか。 

そしてそれはそうなるのです。 なぜなら、内部的にはこれらすべてが単なる API、構成、コマンドのネットワークであり、今日ではスクリプトによって自動化できることが多くあるからです。 これらのスクリプトは多くの場合パラメータ化されており、これは私の AI プロンプトのパラメータと大まかに相関しています。 グリーンベイ、ミルウォーキー、App A。そこで変わるのは発電機と、発電機を発電できる速度です。 

私はよく、AI と自動化は力の倍増をもたらすものだと言います。 テクノロジーは何をすべきか分からないので、私たちが知っています。 しかし、AI と自動化により、はるかに迅速かつ効率的に作業を実行できるようになり、生産性が効果的に向上し、価値実現までの時間が短縮され、専門家が戦略的な意思決定やプロジェクトに集中する時間が確保されます。 そして、時間が経つにつれて、AI は私たちから学び、私たちの能力をさらに高め、新たな可能性を明らかにします。 

これはもはやSFではなく、コンピューターサイエンスの現実です。