Comment les API floues refont le Web

Depuis presque aussi longtemps que le Web existe, le développement Web a été confronté à de grandes difficultés pour trouver la bonne manière de connecter les composants sur le réseau. C’est la question de l’API distante. Cela influence tous les aspects des logiciels que nous construisons. Nous sommes en quelque sorte parvenus à un compromis tolérable avec les API JSON. Bien que ceux-ci aient leurs limites, vous devez apprécier leur simplicité sous-jacente.

Mais l’avènement de points de terminaison compatibles avec l’IA, capables de servir d’intermédiaires dans les intentions, modifie le fonctionnement de base d’Internet. Ce changement réveille progressivement un vieux rêve, l’architecture orientée services (SOA). Cette fois-ci, avec de la chance, nous obtiendrons enfin la découverte de services automatisée flexible, détectable et maintenable dont nous rêvions. On croise les doigts.

Pourquoi la SOA à l’ancienne a échoué

Appelons cette influence naissante de l’IA sur l’architecture Web SOA 2.0.

Pour comprendre pourquoi SOA 2.0 est différent de SOA 1.0, nous devons nous rappeler le traumatisme des années 2000. (Cela peut être douloureux mais aussi cathartique.) Le rêve initial de la SOA était magnifique : un monde où des services métier disparates (inventaire, facturation, expédition, etc.) pourraient se découvrir automatiquement, comprendre leurs capacités et orchestrer des tâches complexes sans intervention humaine.

Pour y parvenir, nous avons construit un monument de la complexité. Nous avions SOAP (Simple Object Access Protocol) pour la messagerie, WSDL (Web Services Description Language) pour définir les contrats et des registres UDDI pour la découverte de services. Au centre de tout cela se trouvait l’Enterprise Service Bus (ESB), un énorme middleware censé acheminer tout de manière gracieuse et transparente. Au cas où vous, les jeunes, seriez confus, tout est basé sur XML.

Au moment où vous avez fini de comprendre suffisamment l’infrastructure pour savoir comment faire quelque chose, vous aviez oublié ce que vous aviez prévu de faire.

Cela a échoué. C’était extrêmement lourd. Juste pour faire quelque chose de simple comme créer un point de terminaison « Nouvel élément », vous deviez immédiatement commencer à escalader un mur de définitions rigides.

Parce que les ordinateurs exigeaient historiquement une perfection déterministe absolue, si une seule balise XML dans une enveloppe SOAP manquait, ou si un service mettait à jour son WSDL sans que chaque client ne génère à nouveau ses stubs, l’ensemble du pipeline de plusieurs millions de dollars s’effondrerait violemment. Certains d’entre nous connaissent peut-être un défi similaire dans les microservices conteneurisés (comme Kubernates), où essayer de déterminer l’origine d’un problème dans le maillage est… délicat.

La SOA classique était un château de cartes, trop fragile pour survivre à la réalité floue d’Internet.

L’API JSON typique d’aujourd’hui est une réaction contre la SOA. (C’est peut-être une réaction excessive.) Nous avons abandonné SOA au profit de la relative simplicité de REST, abandonnant le rêve d’une orchestration autonome des services en échange d’intégrations manuelles qui juste travailler.

Le nouveau middleware d’intention d’exécution

Un changement radical est déjà en train de se produire avec l’architecture au niveau des applications.

L’effet des points de terminaison d’IA dans le profil de service d’une application va au-delà d’une simple nouvelle fonctionnalité. Cela change la façon dont les autres services fonctionnent ensemble. L’effet global est comme si l’application prenait conscience d’elle-même et de ce qu’elle pouvait faire. Ce n’est pas différent de ce que WSDL était censé accomplir. Mais au lieu d’un descripteur codé en dur, où une personne devait garder ce qui était disponible et ce qui était décrit synchronisé, vous disposez désormais d’une couche qui peut accepter des descripteurs produits dynamiquement et les unir avec l’intention floue de l’utilisateur et produire une action significative.

Vous associez des points de terminaison d’IA pour établir un lien entre ce que l’utilisateur essaie d’accomplir et les différentes fonctionnalités strictes disponibles. Ces fonctionnalités peuvent exister au sein de l’application au niveau du back-end, du front-end ou au niveau d’une autre couche de service. L’essentiel est qu’il existe une couche d’IA flexible qui atténue le besoin de coder en dur les liens entre les services.

Dans la SOA classique, le contrat était un document WSDL rigide et impitoyable. Dans la pratique courante moderne, le contrat est un point de terminaison RESTful fortement couplé. Dans SOA 2.0, le contrat présente un degré de flexibilité jusqu’alors inconnu, grâce aux capacités en langage naturel d’un LLM.

Lorsqu’un utilisateur ou un système exprime une intention, par exemple « Fournir un nouvel environnement de test pour le service de facturation », le middleware d’IA ne recherche pas une intégration point à point codée en dur. Au lieu de cela, il digère l’intention et effectue un routage sémantique, en consultant un registre et en sélectionnant les outils appropriés. Ce registre, plutôt qu’un UDDI lourd, pourrait être une base de données vectorielle de points de terminaison d’API internes disponibles ou un ensemble de fonctions disponibles.

Les LLM modernes équipés de capacités d’appel de fonctions agissent comme les orchestrateurs dynamiques ultimes. Ils lisent le schéma JSON d’une API REST cible, comprennent ses paramètres et mappent dynamiquement l’intention floue et non structurée de l’utilisateur dans une charge utile JSON parfaitement formatée. Si un champ est manquant, le LLM peut soit le déduire du contexte, soit suspendre l’exécution pour demander des éclaircissements à l’utilisateur.

La fragilité du SOA 1.0 est remplacée par un amortisseur. Si l’API cible modifie le nom d’un paramètre de customerID à clientIdle middleware IA peut lire le schéma mis à jour et ajuster son mappage à la volée. Aucun code client ne doit être recompilé. Aucun stub ne doit être régénéré. Le pipeline de plusieurs millions de dollars survit.

Quand le logiciel devient intelligent

Ce ne sont pas seulement des idées abstraites. J’ai récemment fait mes impôts en utilisant un service grand public populaire que je ne nommerai pas. J’avais plusieurs domaines inhabituels et grincheux à gérer, notamment la nouvelle réglementation crypto. Ce n’était pas joli.

Mais ce qui m’a le plus frappé, c’est à quel point le logiciel était stupide, comparé au chatbot IA que j’utilisais pour me guider. Je voulais pouvoir dire au logiciel (stupide) ce que j’essayais de faire. Comme « Portez mon NOL de l’année dernière ! » Ou « Je ne sais pas si j’ai besoin d’un horaire K, tu me le dis ! »

Je ne veux pas d’un autre chatbot. Je veux dire, j’ai déjà un bon chatbot. Je souhaite que l’application soit bien intégrée aux services d’IA qui comprennent l’application, comprennent ma situation actuelle au sein de l’application et me rencontrent au niveau de l’intention, en appliquant les leçons apprises par d’autres qui ont utilisé les mêmes outils.

Ce type de mise à niveau ciblée et intelligente des intentions est, d’après ce que je peux voir, la prochaine étape du développement logiciel, et elle va être massive.

Latence, non-déterminisme et autres défis

Nous troquons la fragilité déterministe de la SOA classique contre le flou probabiliste de la SOA 2.0. Et cet échange va être réclamé avec toujours plus d’insistance par les utilisateurs. Mais cela s’accompagne d’un nouvel ensemble de compromis.

Il y a d’abord la taxe de latence. L’ancien bus de services d’entreprise était lourd à configurer, mais au moment de l’exécution, la messagerie était simplement acheminée en XML. L’injection d’un LLM dans le chemin critique d’une application ajoute des centaines de millisecondes, voire des secondes, de latence. Pour les tâches asynchrones ou les orchestrations complexes, c’est un compromis bienvenu. Pour les microservices en temps réel à haut débit, c’est une rupture.

Deuxièmement, il y a le problème du non-déterminisme. Nous avons passé des décennies à nous entraîner (ainsi qu’à nos systèmes) à nous attendre à ce qu’étant donné l’entrée A, un système produira toujours la sortie B. Cette équation déterministe était notre foi fondamentale. La couche d’intention ne fonctionne pas de cette façon. Un LLM peut acheminer magnifiquement une requête 99 fois, puis halluciner un paramètre la 100ème fois. Ou encore, il peut choisir un chemin d’exécution totalement différent, basé sur un changement subtil dans la formulation de l’utilisateur.

Un troisième problème concerne ce que l’on appelle les exigences non fonctionnelles, ou NFR. Ce sont vos problèmes secondaires embêtants qui refusent d’être ignorés, comme la sécurité et la fiabilité.

Les problèmes de sécurité sont amplifiés par les capacités du modèle telles que l’appel de fonction (ou « passage de fonction »). Si vous associez les désirs d’un utilisateur à ce que l’IA peut faire, et que vous laissez ensuite l’IA décider, ce qui se passe ensuite est clairement un acte de foi à moins que des garde-fous ne soient mis en place. Ces garde-fous doivent aller au-delà de la sécurité Web classique (c’est-à-dire s’assurer que les appels de fonctions importants sont renforcés sur le serveur et non exposés sur le client) et doivent être internalisés par l’IA ou (plus probablement) imposés depuis une couche extérieure à l’IA. Il existe plusieurs façons de procéder, dont le degré de puissance et de complexité varie.

Nous continuerons certainement à utiliser des pratiques standard (telles que RBAC et SSO) pour appliquer l’authentification. Nous continuerons à mettre en œuvre des techniques d’autorisation standard (comme OAUTH et JWT). Mais nous les appliquerons dans le contexte de cette couche d’intention et de ses capacités.

La fiabilité est un autre défi. Par exemple, j’ai récemment rencontré un problème avec l’API Imagen de Google. Tout fonctionnait à merveille, puis tout à coup, certaines images ont cessé de se générer. Il n’y a eu aucune erreur dans les journaux du client ou du serveur ; cependant, il y a eu 500 erreurs sur le réseau. Après un examen plus approfondi, l’invite s’est transformée (entre le contexte de l’application et le contenu de l’utilisateur) pour inclure ce que les règles de l’API Imagen considéraient comme un contenu dangereux. Il ne s’agissait pas d’une incitation manifestement signalée. Il s’agissait d’une écriture créative assez banale, dans le sens de « Un paysage cyberpunk sombre, surréaliste et glitch avec des personnages menaçants… ». Ce genre de chose.

Voici quelques-unes des façons dont même une utilisation simple et directe des API LLM peut vous surprendre. La question à laquelle je réfléchis est la suivante : quels seront les résultats inattendus sur les logiciels en général ?

L’aube d’un web probabiliste

Depuis sa création, la nature imprévisible et probabiliste d’Internet provenait principalement des humains qui l’utilisaient (et des transistors renversés par le rayonnement de fond, des pannes de réseau, des effets géopolitiques sur le terrain, etc.). Mais les API médiées par l’IA introduisent une forme de probabilité intentionnelle et sémantiquement contrôlée.

En tant que développeurs, nous découvrirons naturellement les techniques qui rendent la consommation des points de terminaison d’IA plus efficace. Ici, je pense à des pratiques telles que les réponses structurées et les appels de fonctions. Mais la plus grande question est de savoir quelle sera la nature du logiciel ?

Dans un monde d’états binaires, de protocoles stricts et d’URI rigides, si vous envoyez un GET demande à un point de terminaison spécifique, vous attendez une réponse exacte et prévisible. Nous avons passé les 40 dernières années à traiter le Web comme une vaste machine à états d’une complexité inimaginable.

Mais à mesure que les API médiées par LLM imprègnent notre architecture de stochastiques, le tissu même d’Internet commence à changer. En injectant l’IA dans les couches de routage et de découverte, nous introduisons une dose massive de probabilité dans les fondations de nos réseaux. Lorsqu’une requête n’est plus un appel URI codé en dur mais une intention en langage naturel analysée par un LLM, la connexion entre le nœud A et le nœud B cesse d’être un fil rigide. Cela devient une probabilité pondérée.

Essentiellement, nous refaisons Internet pour refléter l’architecture des modèles d’IA que nous déployons. Tout comme un réseau neuronal repose sur le déclenchement probabiliste de synapses plutôt que sur des instructions if/then déterministes, la prochaine itération du Web reposera sur une découverte sémantique fluide. Les services ne seront pas simplement « liés » les uns aux autres ; ils graviteront les uns vers les autres en fonction de la proximité conceptuelle de leurs capacités au sein d’un espace latent partagé.

Cela modifie le caractère du génie logiciel. Nous perdons (l’illusion) d’être entièrement en contrôle. Son étrange paradoxe est que l’ingénierie utilisant des composants explicitement probabilistes peut conduire à un système plus résilient. Il existe un débat de longue date sur la meilleure métaphore pour le développement de logiciels. Pendant très longtemps, la construction d’un bâtiment a toujours semblé être une analogie appropriée, ou peut-être la mécanique d’un véhicule. Mais de nos jours, la métaphore du jardinage ou de la culture semble de plus en plus pertinente.

Malgré les défis posés par l’insertion de l’IA dans la pile, nous revenons enfin à la promesse initiale du début des années 2000. Cette fois, croisons les doigts, nous sommes équipés des bons outils pour le travail.

Nous avons essayé de créer une découverte de services autonome en utilisant une logique rigide et du XML déterministe, et elle s’est effondrée sous son propre poids. Maintenant, nous le construisons avec des réseaux de neurones qui comprennent « l’intention » derrière l’intégration. Nous sommes toujours en train de créer un middleware, mais au lieu d’un bus de services d’entreprise, nous construisons un bus de raisonnement d’entreprise.

L’ère du codage manuel en dur de chaque intégration entre chaque microservice touche peut-être à sa fin.