Comment éviter de payer les taxes API cette année
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 de réduire ce fardeau.
Je suis désolé de dire que même si j’ai déjà travaillé comme développeur pour une société de logiciels fiscaux, je ne suis pas vraiment qualifié pour vous donner des conseils à ce sujet. Mais si vous cherchez des conseils sur la manière d’éviter de payer les taxes API cette année (ou l’année prochaine), vous avez téléchargé la bonne page sur Internet.
Une taxe API correspond aux frais généraux que vous payez lorsque vous utilisez des API pour automatiser le provisionnement et la configuration de l'infrastructure dans le cadre du processus de déploiement. La taxe API (comme toutes les taxes) n’est pas simple à calculer car elle est en fait double : opérationnelle et technique.
Opérationnellement, la taxe API entraîne des coûts en ressources et en temps provoqués par un nombre excessif d'appels API. Même un service d'équilibrage de charge, aussi simple soit-il, demande de créer, configurer et activer plusieurs objets. Vous devez configurer la surveillance, les pools, les algorithmes, les adresses IP et les attributs réseau, chaque objet nécessitant plusieurs étapes (appels API). Au total, un simple service d'équilibrage requiert plusieurs appels API pour démarrer. Des appels qui demandent du temps pour s'exécuter. Des appels qui mobilisent des ressources réseau.
Les architectes et ingénieurs utilisent ces appels d’API pour écrire des scripts (en Python, PowerShell, etc.) et ainsi automatiser ces tâches courantes de déploiement. Vous engagez ainsi une dette technique inévitable. Modifier une tâche impose de changer le code (les scripts sont du code, que vous le reconnaissiez ou pas) et de le tester, ce qui mobilise du temps et des ressources, impactant directement votre budget.
Ces coûts (développement, test et maintenance des systèmes et des scripts) sont les taxes techniques sur l’utilisation de cette API. Cela signifie que les scripts entraînent 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 et au coût de modification non seulement de l’automatisation, mais peut-être aussi de l’infrastructure.
Tout cela représente une facture assez conséquente qui, comme les « vrais » impôts, est pratiquement inévitable. Si vous souhaitez bénéficier 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 garantir que les deux peuvent communiquer de manière transparente et sécurisée.
Bon, tout cela étant dit, j'ai promis de vous expliquer comment vous pouvez éviter de payer ces impôts, alors voilà.
Si vous avez observé l'espace d'orchestration (et cela inclut les acteurs SDx comme VMware, Cisco et OpenStack), vous remarquerez qu'il y a un accent croissant sur l'utilisation de modèles. Les modèles ressemblent beaucoup aux fichiers de configuration dans la mesure où ils codifient un grand nombre d’informations nécessaires pour créer et configurer quelque chose. Si vous pouvez créer un modèle unique qui englobe le déploiement de ce service d'équilibrage de charge, par exemple, vous pouvez apparemment réduire les appels d'API requis à un seul : celui qui permet de pousser le modèle vers l'instance sur laquelle ce service va résider.
L’utilisation d’un seul appel d’API au lieu de beaucoup simplifie l’automatisation et vous permet de réutiliser le script ou le système qui envoie le modèle. C’est important, car lorsque vous utilisez des API, vous devez écrire des scripts qui sont non seulement spécifiques au service, mais également spécifiques à l’application en cours de déploiement. Cela signifierait que pour chaque application que vous déployez, vous devriez écrire un autre script pour automatiser le déploiement des services dont elle a besoin, comme l’équilibrage de charge.
Mais si vous utilisez des modèles, vous pouvez utiliser le même script et simplement envoyer un modèle différent. Cela signifie moins de temps d'attente pour un nouveau script pour chaque application et moins d'erreurs à rechercher, comme lorsque Bob a copié et collé pour la quinzième fois et a oublié de modifier la ligne 33.
Les modèles sont une infrastructure en tant que code, le Saint Graal de DevOps.
Vous avez toujours besoin d’API, mais vous n’êtes pas obligé de les utiliser pour tout. Et si vous pouvez l’éviter, en utilisant des modèles, vous pourrez éviter de payer les impôts qui y sont associés et transférer ces économies ailleurs.