Ce qui a changé à Oran 3.6

Chaque version d'Oran a ajouté une chose. L'attribution des coûts en 3.1, les budgets qui bloquent en 3.2, l'évaluation en 3.3, l'optimisation en 3.4, l'Agent Hub en 3.5. Individuellement utile, et jusqu'à récemment encore cinq choses qu'une équipe devait assembler.

3.6 est la version où ils cessent d'être assemblés et commencent à être supposés.

Intégrations multiples

Le plus grand changement pratique est la portée. Un agent qui ne peut agir qu'au sein d'un seul système est une démonstration d'un flux de travail plutôt qu'un participant à celui-ci, et la plupart du travail réel traverse trois ou quatre systèmes avant d'être terminé.

3.6 élargit ce à quoi un agent peut être connecté, avec la même gouvernance s'appliquant à chaque frontière. Une connexion n'est pas une autorisation : un agent bénéficiant d'un accès en lecture à un référentiel et d'aucun accès en écriture ne peut pas effectuer de push, et cela est appliqué là où l'action se produit plutôt que demandé dans une invite.

Conscience de la situation

Les versions antérieures exécutaient un plan. 3.6 garde une trace de ce qui s'est déjà produit au cours d'une exécution et de ce qui a changé en dessous pendant que l'exécution était en cours.

Cela compte pour l’échec peu glorieux qui gaspille le plus d’argent : un agent qui continue d’exécuter un plan construit sur un État qui a depuis bougé. Repeating a step that already succeeded, or acting on a record someone else has since changed, produces work that has to be undone by a person. Le remarquer coûte moins cher que réparer.

Gestion avancée des agents

La consolidation est ici la plus visible. Un agent arrive désormais avec la propriété, les limites, le budget et l'évaluation en tant que propriétés plutôt que sous forme d'exercices de configuration séparés.

En pratique, c’est ce qui change le modèle de quatre-vingt-dix jours sur lequel nous continuons d’écrire. L’étalement qui apparaît au cours de la quatrième semaine n’est un problème que lorsque l’attribution et la propriété sont ensuite adaptées. Lorsqu'ils constituent la forme par défaut d'un agent, trente agents constituent un inventaire plutôt qu'un mystère.

Visibilité et contrôle des coûts, ensemble

3.1 a rendu les dépenses visibles. 3.2 l'a rendu arrêtable. 3.6 met les deux à la même place que l’évaluation qui détermine si une économie était réelle.

Cette combinaison est le point. Réduire les coûts sans évaluation produit une production moins chère et de qualité inconnue, ce qui ne constitue pas une économie mais un report. L'Optimiseur propose des modifications de modèle, d'invite et d'outil, et chaque proposition est évaluée par rapport à vos propres évaluations avant d'être validée.

Ce qu'il ne fait pas

Il ne fusionne pas votre code, n'approuve pas vos dépenses et ne décide pas qu'un chèque échoué est acceptable. Les actions ayant des conséquences réelles restent en suspens pour une personne, et nous considérons qu'il s'agit d'un choix de conception plutôt que d'un écart à combler dans la version 3.7.

Cela ne rend pas non plus gouverné un déploiement non gouverné. La version que vous exécutez importe beaucoup moins que le fait que les agents aient des propriétaires, des limites, des budgets et des critères. Une équipe avec ces quatre sur une ancienne version est en meilleure forme qu’une équipe sans eux sur celle-ci.

Mise à niveau

Les déploiements existants sont déplacés sans reconstruire les agents. Là où les données ne peuvent pas quitter votre infrastructure, 3.6 fonctionne de manière auto-hébergée, dans votre propre cloud ou entièrement isolé, avec la même gouvernance.

Suivant

La page des versions répertorie toutes les versions à partir de Keter 1.0 et ce que chacune a ajouté. Les pages du système d'orchestration d'agent couvrent la couche d'exploitation que cette version consolide.