Comment éviter de payer des taxes sur les API cette année

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

C’est la période des impôts aux États-Unis, et vous savez ce que cela signifie, n’est-ce pas ? Oui, nous cherchons tous des moyens d’alléger cette charge.

Je suis désolé de vous dire que, même si j’ai autrefois travaillé comme développeur pour une entreprise de logiciels fiscaux, je ne suis vraiment pas qualifié pour vous conseiller en la matière. Mais si vous cherchez des conseils pour éviter de payer la taxe sur les API cette année (ou l’année prochaine), alors vous êtes sur la bonne page Internet.

Une taxe d’API correspond au surcoût engendré par l’utilisation d’API pour automatiser le provisionnement et la configuration de l’infrastructure dans le cadre du processus de déploiement. La taxe d’API (comme toutes les taxes) n’est pas simple à calculer, car elle comporte en réalité deux volets : opérationnel et technique.

Sur le plan opérationnel, la taxe liée aux API entraîne des coûts en ressources et en temps en raison d’un nombre excessif d’appels d’API. Même un service conceptuellement aussi simple que l’équilibrage de charge nécessite la création, la configuration et l’activation de plusieurs objets. La supervision, les pools, les algorithmes, les adresses IP et les attributs réseau doivent tous être configurés, et chacun de ces objets requiert plusieurs étapes (appels d’API). Au total, même un simple service d’équilibrage de charge nécessite plusieurs appels d’API pour être opérationnel. Des appels dont l’exécution prend du temps. Des appels qui consomment des ressources réseau.

Ces appels d’API sont utilisés par les architectes et les ingénieurs qui écrivent des scripts (en Python, PowerShell, etc.) afin d’automatiser ces tâches de déploiement courantes. Cela génère une dette technique inévitable. La moindre modification de la tâche nécessite de modifier le code (car les scripts sont du code, que nous voulions l’admettre ou non) et de le tester, ce qui mobilise du temps et des ressources et finit par avoir un coût financier bien réel.

Ces coûts – liés au développement, aux tests et à la maintenance des systèmes et des scripts – constituent la taxe technique inhérente à l’utilisation de cette API. Autrement dit, les scripts engendrent des coûts à long terme sous la forme d’une dette technique, qui correspond aux coûts associés à la maintenance du code nécessaire à l’automatisation via ces API, ainsi qu’aux coûts liés à la modification non seulement de l’automatisation, mais aussi, éventuellement, de l’infrastructure.

Au bout du compte, la facture est plutôt salée et, comme les « vrais » impôts, pratiquement inévitable. Si vous voulez profiter d’un processus de déploiement plus fluide et automatisé, vous devrez inclure l’infrastructure, c’est-à-dire tout ce qui se trouve entre l’utilisateur et l’application et permet aux deux de communiquer de manière fluide et sécurisée.

Bon, cela étant dit, j’ai promis de vous expliquer comment éviter de payer ces taxes, alors allons-y.

Si vous suivez le domaine de l’orchestration (y compris les acteurs du SDx comme VMware, Cisco et OpenStack), vous aurez remarqué que l’utilisation des modèles prend une importance croissante. Les modèles ressemblent beaucoup aux fichiers de configuration, car ils formalisent une grande quantité d’informations nécessaires pour créer et configurer un « élément ». Si, par exemple, vous pouvez créer un modèle unique couvrant le déploiement de ce service d’équilibrage de charge, vous pouvez en principe réduire le nombre d’appels d’API à un seul : celui qui transmet le modèle à l’environnement sur lequel ce service sera hébergé.

Le fait de n’utiliser qu’un seul appel d’API au lieu d’un grand nombre simplifie l’automatisation et permet de réutiliser le script ou le système qui transmet le modèle. C’est important, car lorsque vous utilisez des API, vous devez écrire des scripts qui sont non seulement propres au service, mais aussi à l’application en cours de déploiement. Cela signifie que, pour chaque application déployée, vous devriez écrire un nouveau script afin d’automatiser le déploiement des services dont elle a besoin, comme l’équilibrage de charge.

En revanche, si vous utilisez des modèles, vous pouvez conserver le même script et simplement déployer un modèle différent. Vous perdez ainsi moins de temps à attendre un nouveau script pour chaque application et avez moins d’erreurs à traquer, comme lorsque Bob a fait un copier-coller pour la quinzième fois et a oublié de modifier la ligne 33.

Les modèles constituent une infrastructure en tant que code, le Graal du DevOps.

Vous avez toujours besoin d’API, mais vous n’avez pas besoin de les utiliser pour tout. Et si vous pouvez éviter d’y recourir grâce à des modèles, vous pourrez vous épargner les coûts qui leur sont associés et réaffecter ces économies ailleurs.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie