Flujos de trabajo versus API
Hoy tengo un trabajo para ti. Quiero que tú –sí, tú ahí mismo– deposites un cheque en el banco. Tienes que subirte al coche, conducir hasta el banco, entrar, hacer eso con el cajero y luego volver a casa.
¿Irritado? Deberías hacerlo, especialmente cuando puedes usar tu aplicación de banca móvil para hacerlo sin todos los pasos adicionales.
Y eso, amigos míos, es la diferencia entre un flujo de trabajo (un proceso) y una API.
Existe algo muy real (el nombre lo inventé yo, pero no su existencia) llamado impuesto API . Ese es el tiempo y la deuda técnica que se genera al ejecutar procesos complejos mediante llamadas API individuales. Es como ir físicamente al banco en lugar de usar la aplicación móvil para hacer ese depósito.
Este impuesto crece a medida que se expanden los procesos. Si tiene un proceso largo que requiere diez o veinte llamadas API diferentes, el código (los scripts también son código) se vuelve cada vez más complicado, lo que afecta la resolución de problemas y hace que sea más difícil realizar cambios en el futuro. Osificar los procesos mediante llamadas API individuales es lo opuesto a la agilidad. Es la fragilidad la que congela la oportunidad de mejorar la eficiencia a través de la optimización.
Los flujos de trabajo son básicamente procesos predefinidos para tareas que se ejecutan comúnmente. La mayoría de los procesos empresariales (e incluso operativos) entran en esta categoría. Son los comandos que utiliza para iniciar sesión, navegar a la parte derecha del sistema, cambiar el control de acceso en el puerto y luego confirmar el cambio. Cada vez que haces esta tarea es lo mismo. Es un proceso comúnmente ejecutado y que podría codificarse fácilmente. Hay muchos procesos de este tipo en las operaciones y, al integrarlos en un flujo de trabajo, no solo podemos eliminar el impuesto de API, sino también mejorar la calidad y la sostenibilidad de los scripts que los invocan.
Esto se debe a que el uso de flujos de trabajo en lugar de API significa un código menos complejo que es más fácil de administrar y más fácil de cambiar. Son más ágiles y menos frágiles.
Considere este ejemplo completamente inventado. En primer lugar, tenemos un enfoque basado en API. Cada paso de ese proceso representa una llamada API. Esto significa que es necesario desarrollar, probar y mantener a lo largo del tiempo un script con casi veinte llamadas diferentes. Eso es deuda técnica. Está vinculado a la versión API del sistema con el que está funcionando en el momento en que fue escrito. Si una de esas llamadas cambia, el guión también tiene que cambiar.
A la derecha tienes un enfoque basado en flujo de trabajo. Todavía puede iniciar el proceso a través de una llamada API (probablemente preferible en muchas organizaciones), pero los pasos reales del proceso se ejecutan en función de los parámetros (variables) enviados con la llamada inicial. Es posible que tengas que limpiar y confirmar, pero aun así habrás reducido el código necesario a dos interacciones o menos.
Eso no quiere decir que usar API y plantillas sea algo malo. Que no es. Pero a menudo ocurre –sobre todo en el mundo de las redes– que el uso de API requiere conocimientos específicos del sistema y de la red en general. Esto dificulta que DevOps o los desarrolladores trabajen con las API. Un enfoque de flujo de trabajo elimina la suposición de conocimiento o experiencia, lo que significa que DevOps se sentirá cómodo al usarlos y NetOps mantiene la seguridad laboral.
En entornos donde la automatización se está consolidando (y tal vez incluso tomando el control), un enfoque basado en el flujo de trabajo puede ofrecer un alivio sustancial a NetOps al permitir que DevOps tenga la capacidad de invocar tareas sin requerir una gran cantidad de conocimientos específicos del dominio.
Y además pueden evitar esos molestos impuestos API. ¿Y a quién no le gusta evadir impuestos?