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.
Sur le plan opérationnel, la taxe API entraîne des coûts en termes de ressources et de temps consommés par des appels API excessifs. Même quelque chose d’aussi simple conceptuellement qu’un service d’équilibrage de charge nécessite la création, la configuration et l’activation de plusieurs objets. La surveillance, les pools, les algorithmes, les adresses IP et les attributs réseau doivent tous être configurés, et chacun de ces objets nécessite plusieurs étapes (appels API) pour le faire. Additionnez-les tous et même un simple service d’équilibrage de charge nécessite plusieurs appels d’API pour démarrer. Appels qui prennent du temps à exécuter. 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 utilisant Python, PowerShell, etc…) pour automatiser ces tâches de déploiement courantes. Cela entraîne une dette technique inévitable. Changer la tâche nécessite de changer le code (parce que les scripts sont du code, que nous aimions l'admettre ou non) et de le tester, ce qui prend du temps et des ressources qui s'ajoutent à de vrais dollars sur le résultat net.
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.