Cómo evitar pagar impuestos por las API este año

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Es hora de hacer la declaración de la renta en Estados Unidos, y ya sabes lo que eso significa, ¿verdad? Sí, todos buscamos formas de reducir esa carga fiscal.

Lamento decir que, aunque en su día trabajé como desarrollador para una empresa de software fiscal, no estoy realmente cualificado para asesorarte en ese ámbito. Pero si buscas consejos sobre cómo evitar pagar el impuesto de las API este año (o el que viene), has llegado a la página adecuada de Internet.

Un impuesto de API es el coste adicional que se asume al utilizar API para automatizar el aprovisionamiento y la configuración de la infraestructura como parte del proceso de despliegue. El impuesto de API (como todos los impuestos) no es fácil de calcular porque, en realidad, tiene dos vertientes: la operativa y la técnica.

Desde el punto de vista operativo, el coste adicional de las API se traduce en recursos y tiempo consumidos por un número excesivo de llamadas a la API. Incluso algo tan sencillo conceptualmente como un servicio de equilibrio de carga requiere crear, configurar y habilitar varios objetos. Es necesario configurar la supervisión, los grupos, los algoritmos, las direcciones IP y los atributos de red, y cada uno de estos objetos requiere varios pasos (llamadas a la API). En conjunto, hasta un simple servicio de equilibrio de carga necesita múltiples llamadas a la API para ponerse en marcha. Llamadas que tardan en ejecutarse. Llamadas que consumen recursos de red.

Los arquitectos e ingenieros utilizan esas llamadas a la API para escribir scripts (con Python, PowerShell, etc.) que automaticen estas tareas habituales de despliegue. Esto genera una deuda técnica inevitable. Cualquier modificación de la tarea exige cambiar el código (porque los scripts son código, queramos admitirlo o no) y probarlo, lo que requiere tiempo y recursos que se traducen en costes reales para la empresa.

Estos costes —de desarrollar, probar y mantener los sistemas y scripts— son los impuestos técnicos derivados del uso de esa API. Esto significa que los scripts generan costes a largo plazo en forma de deuda técnica, que se refiere a los costes asociados al mantenimiento del código necesario para automatizar mediante esas API y al coste de modificar no solo la automatización, sino quizá también la infraestructura.

Todo esto acaba suponiendo una factura considerable que, al igual que los impuestos «reales», es prácticamente inevitable. Si quiere disfrutar de las ventajas de un proceso de despliegue más fluido y automatizado, tendrá que incluir la infraestructura, es decir, todo lo que se encuentra entre el usuario y la aplicación y garantiza que ambos puedan comunicarse de forma fluida y segura.

Bien, dicho todo esto, prometí explicar cómo puedes evitar pagar estos impuestos, así que allá vamos.

Si ha estado siguiendo el ámbito de la orquestación (incluidos los actores de SDx como VMware, Cisco y OpenStack), habrá observado que cada vez se hace más hincapié en el uso de plantillas. Las plantillas se parecen mucho a los archivos de configuración, ya que codifican una gran cantidad de información necesaria para crear y configurar algún «elemento». Si, por ejemplo, puede crear una única plantilla que abarque el despliegue de ese servicio de equilibrio de carga, en teoría puede reducir las llamadas a la API a una sola: la necesaria para enviar la plantilla al lugar en el que se alojará dicho servicio.

Usar una sola llamada a la API en lugar de, bueno, muchas simplifica la automatización y permite reutilizar el script o el sistema que envía la plantilla. Esto es importante porque, al utilizar APIs, hay que escribir scripts que no solo sean específicos para el servicio, sino también para la aplicación que se está desplegando. Eso significaría que, por cada aplicación que se despliegue, habría que escribir otro script para automatizar el despliegue de los servicios que necesita, como el balanceo de carga.

Pero si, en cambio, utilizas plantillas, puedes usar el mismo script y simplemente enviar una plantilla diferente. Eso significa menos tiempo esperando un nuevo script para cada aplicación y menos errores que localizar, como cuando Bob copió y pegó por decimoquinta vez y se olvidó de cambiar la línea 33.

Las plantillas son infraestructura como código, el santo grial de DevOps.

Sigues necesitando las API, pero no tienes que usarlas para todo. Y si puedes evitarlo utilizando plantillas, podrás ahorrarte los costes asociados a ellas y destinar ese ahorro a otra cosa.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie