Aujourd'hui, j'ai un travail pour toi. Je veux que tu – ouais, toi là – déposes un chèque à la banque. Vous devez monter dans la voiture, vous rendre à la banque, entrer et faire cette chose avec le caissier, puis rentrer chez vous.
Irrité ? Vous devriez l’être, surtout lorsque vous pourriez simplement utiliser votre application bancaire mobile pour le faire sans toutes les étapes supplémentaires.
Et c’est là, mes amis, la différence entre un workflow (un processus) et une API.
Il existe une chose très réelle (j’ai inventé le nom, mais pas l’existence) appelée taxe API . Il s’agit du temps et de la dette technique engendrés par l’exécution de processus complexes à l’aide d’appels API individuels. C'est comme aller physiquement à la banque au lieu d'utiliser votre application mobile pour effectuer ce dépôt.
Cette taxe augmente à mesure que les processus se développent. Si vous avez un processus long qui nécessite dix ou vingt appels d'API différents, le code (les scripts sont également du code) devient de plus en plus compliqué, ce qui a un impact sur le dépannage et rend plus difficile toute modification future. L’ossification des processus par des appels d’API individuels est l’opposé de l’agilité. C’est la fragilité qui gèle l’opportunité d’améliorer l’efficacité grâce à l’optimisation.
Les workflows sont essentiellement des processus prédéfinis pour les tâches couramment exécutées. La plupart des processus commerciaux (et même opérationnels) entrent dans cette catégorie. Ce sont les commandes que vous utilisez pour vous connecter, naviguer vers la bonne partie du système, modifier le contrôle d’accès sur le port, puis valider la modification. Chaque fois que vous effectuez cette tâche, c'est la même chose. Il s’agit d’un processus couramment exécuté qui pourrait facilement être codifié. Il existe de nombreux processus de ce type dans les opérations, et en les regroupant sous forme de flux de travail, nous pouvons non seulement éliminer la taxe API, mais également améliorer la qualité et la durabilité des scripts qui les invoquent.
C’est parce que l’utilisation de workflows au lieu d’API signifie un code moins complexe, plus facile à gérer et à modifier. Ils sont plus agiles et moins fragiles.
Considérez cet exemple complètement inventé. Dans le premier cas, vous avez une approche basée sur les API. Chaque étape de ce processus représente un appel d’API. Cela signifie qu'un script avec près de vingt appels différents doit être développé, testé et maintenu au fil du temps. C’est une dette technique. Il est lié à la version de l’API du système avec lequel il fonctionne au moment où il a été écrit. Si l’un de ces appels change, le script doit également changer.
Sur la droite, vous avez une approche basée sur le workflow. Vous pouvez toujours lancer le processus via un appel API (probablement préférable dans de nombreuses organisations), mais les étapes réelles du processus sont exécutées en fonction des paramètres (variables) envoyés avec l'appel initial. Vous devrez peut-être nettoyer et valider, mais vous aurez tout de même réduit le code nécessaire à deux interactions ou moins.
Cela ne veut pas dire que l’utilisation d’API et de modèles est une mauvaise chose. Ce n’est pas le cas. Mais il arrive souvent – notamment dans le monde des réseaux – que l’utilisation des API nécessite des connaissances spécifiques au système et au réseau en général. Cela rend difficile pour DevOps ou les développeurs de travailler avec les API. Une approche de workflow élimine l’hypothèse de connaissances ou d’expertise, ce qui signifie que DevOps sera à l’aise avec leur utilisation et que NetOps conservera la sécurité de l’emploi.
Dans les environnements où l'automatisation prend de l'ampleur (et peut-être même prend le dessus), une approche basée sur les flux de travail peut offrir un soulagement substantiel à NetOps en permettant à DevOps d'appeler des tâches sans nécessiter une tonne de connaissances spécifiques au domaine.
Et puis, ils peuvent également éviter ces ennuyeuses taxes API. Et qui n’aime pas éviter de payer des impôts ?