Les ingénieurs DevOps écrivent des politiques Kubernetes en Rego. Newton écrit 5 millions $ de règles de conformité financière dans le même langage.
Ce choix de conception m’a fait tiquer quand je l’ai lu dans la documentation officielle de Newton sur blog.newton.xyz : « Rego est le même langage que les équipes IT utilisent déjà pour la conformité et l’application des politiques au sein d’entreprises traditionnelles. »
La logique est documentée et simple. Les développeurs d’entreprise connaissent déjà Rego. Les institutions peuvent écrire et auditer leurs propres politiques de conformité sans apprendre une nouvelle syntaxe. Moins de friction à l’adoption signifie une intégration plus rapide.
Cet argument est réel. Le contre-argument est tout aussi réel.
Rego a été conçu pour le contrôle d’accès dans l’infrastructure logicielle. « Autoriser ce service à lire ce secret » et « bloquer ce transfert vers ce bénéficiaire sanctionné » sont écrits dans le même langage, mais ce ne sont pas les mêmes problèmes. Le contrôle d’accès échoue avec une requête refusée. Les défaillances de conformité financière font parvenir l’argent à des endroits où il ne devrait pas aller, déclenchent des actions réglementaires et exposent les institutions à une responsabilité juridique. Les profils de conséquences diffèrent de plusieurs ordres de grandeur.
Le SQL a été conçu à l’origine pour interroger des bases de données relationnelles. Lorsque les institutions financières ont commencé à l’utiliser pour la surveillance des transactions en temps réel, elles ont passé des années à découvrir des cas limites que le langage n’était jamais conçu pour gérer à ce niveau de risque. Des outils familiers dans un nouveau domaine ne signifient pas automatiquement qu’ils conviennent parfaitement à l’objectif.
Newton parie que Rego est suffisamment expressif pour couvrir des cas limites de conformité financière pour lesquels il n’avait jamais été conçu. L’avantage, c’est la familiarité des développeurs d’entreprise. L’adéquation du domaine, non vérifiée, est la partie que personne n’examine.
$NEWT #Newt @NewtonProtocol
Ce choix de conception m’a fait tiquer quand je l’ai lu dans la documentation officielle de Newton sur blog.newton.xyz : « Rego est le même langage que les équipes IT utilisent déjà pour la conformité et l’application des politiques au sein d’entreprises traditionnelles. »
La logique est documentée et simple. Les développeurs d’entreprise connaissent déjà Rego. Les institutions peuvent écrire et auditer leurs propres politiques de conformité sans apprendre une nouvelle syntaxe. Moins de friction à l’adoption signifie une intégration plus rapide.
Cet argument est réel. Le contre-argument est tout aussi réel.
Rego a été conçu pour le contrôle d’accès dans l’infrastructure logicielle. « Autoriser ce service à lire ce secret » et « bloquer ce transfert vers ce bénéficiaire sanctionné » sont écrits dans le même langage, mais ce ne sont pas les mêmes problèmes. Le contrôle d’accès échoue avec une requête refusée. Les défaillances de conformité financière font parvenir l’argent à des endroits où il ne devrait pas aller, déclenchent des actions réglementaires et exposent les institutions à une responsabilité juridique. Les profils de conséquences diffèrent de plusieurs ordres de grandeur.
Le SQL a été conçu à l’origine pour interroger des bases de données relationnelles. Lorsque les institutions financières ont commencé à l’utiliser pour la surveillance des transactions en temps réel, elles ont passé des années à découvrir des cas limites que le langage n’était jamais conçu pour gérer à ce niveau de risque. Des outils familiers dans un nouveau domaine ne signifient pas automatiquement qu’ils conviennent parfaitement à l’objectif.
Newton parie que Rego est suffisamment expressif pour couvrir des cas limites de conformité financière pour lesquels il n’avait jamais été conçu. L’avantage, c’est la familiarité des développeurs d’entreprise. L’adéquation du domaine, non vérifiée, est la partie que personne n’examine.
$NEWT #Newt @NewtonProtocol