Las API son la nueva CLI. Pero, a la hora de decidir qué tipo de API crear, el enfoque declarativo es el que manda.
Una API —una interfaz de programación de aplicaciones— es una capacidad esencial hoy en día. Las organizaciones disponen de ellas en la capa de negocio para fomentar la integración de socios y la innovación por parte de los llamados «desarrolladores ciudadanos». Las aplicaciones también cuentan con ellas para facilitar la integración y desacoplar la lógica de negocio —que puede cambiar con frecuencia— de las interfaces —que no deberían cambiar tan a menudo—. Y la infraestructura también las incorpora. Desde conmutadores hasta routers, y desde servicios de aplicaciones hasta middleware y bases de datos, la infraestructura que conforma los canales de entrega y despliegue está habilitada mediante API.
Eso, por sí solo, debería ser motivo para detenerse a reflexionar sobre lo que implica para la emergente comunidad de NetOps. Porque, aunque las organizaciones tienden a estandarizar unos pocos componentes clave de la infraestructura de aplicaciones, no es tan habitual que hagan lo mismo con unos pocos componentes clave de la infraestructura de red y de servicios de aplicaciones.
De los dieciséis servicios de aplicaciones diferentes que utilizan de media las organizaciones para que sus aplicaciones sean más rápidas y seguras, es indudable que estos se prestan mediante más de un puñado de componentes de infraestructura. Si asumimos generosamente una proporción de tres servicios de aplicaciones por componente, seguiríamos teniendo cinco dispositivos diferentes, con cinco API distintas.
El problema es que, a menudo, los proveedores de infraestructura se tomaron demasiado al pie de la letra la afirmación «La API es la nueva CLI». Es decir, la API no es más que un reflejo de la CLI habilitado para REST.
Cualquiera que haya trabajado con interfaces de línea de comandos (CLI) en distintos componentes de infraestructura sabe que la navegación por la CLI se corresponde estrechamente con el modelo de objetos de la infraestructura. A menudo, las API se limitan a trasladar este diseño a HTTP sin apenas cambios. Esto significa que quienes intenten aprovechar la API también tendrán que aprender necesariamente el modelo de objetos del dispositivo en cuestión.
Este nivel de abstracción está obstaculizando el avance de la automatización y la orquestación, porque ahora no solo necesitamos encontrar profesionales especializados en automatización, sino que además deben contar con cierto grado de experiencia en cinco o más modelos distintos de infraestructura de red. El nivel de especialización requerido suele exigir también conocimientos específicos del ámbito, que abarcan desde nociones básicas sobre la configuración de VLAN y el enrutamiento hasta las relaciones entre servidores virtuales, direcciones IP virtuales, nodos, miembros y grupos.
Exponer la complejidad subyacente de la infraestructura dificulta su adopción y la automatización. El propósito de las interfaces debería ser abstraer los modelos y la lógica para proteger a los usuarios y operadores de dicha complejidad. La interfaz gráfica lo consigue al eliminar la necesidad de navegar por jerarquías de objetos para configurar un servicio sencillo.
Por eso, a menudo resulta frustrante descubrir que la API ha vuelto a introducir esta pesadilla de navegación.
Este problema no es exclusivo de la infraestructura de redes y aplicaciones. De hecho, MuleSoft, en su estudio «El creciente valor de las API», constató que la principal demanda de clientes y socios en materia de integración de API —señalada por el 47 % de los encuestados— era disponer de «API personalizadas que respondan a una necesidad empresarial específica». Le seguían una mejor documentación (19 %), plantillas de integración «sin código» (19 %) y envoltorios de SDK para las API que necesitan y utilizan (13 %).
Todo ello puede resumirse en una petición de simplificación. Y, en tecnología, simplificar significa abstraer.
Y eso nos lleva al tema central de esta publicación: las interfaces declarativas constituyen esa abstracción. Al simplificar las interfaces que se utilizan actualmente para aprovisionar, configurar, gestionar e integrar la infraestructura, las interfaces declarativas democratizan la infraestructura y abren nuevas oportunidades.
Declarativo frente a imperativo
En términos generales, tanto el enfoque declarativo como el imperativo pueden considerarse tipos de API. Las API imperativas son las que suelen venir a la mente cuando alguien habla de una API. Indican al sistema de destino exactamente cómo debe hacer algo. Si va a añadir un servidor virtual, tendrá que indicarle exactamente cómo hacerlo, aunque para ello sean necesarias cinco, diez o más llamadas independientes a la API.
Eso significa indicarle que cree un objeto específico con los atributos adecuados, por ejemplo, un nodo con una dirección IP. Después, hay que indicar por separado al sistema que cree, con un nombre, el grupo al que se asignará. A continuación, hay que… bueno, a estas alturas ya se entiende la idea. Las API imperativas obligan al usuario a comprender no solo el sistema y su modelo de objetos, sino también los pasos necesarios para obtener los resultados deseados.
Ese es el coste de las API imperativas.
Ahora bien, las API imperativas no son algo malo en general. Son muy importantes cuando se crea una interfaz gráfica de usuario o se integran otros sistemas que necesitan el nivel de granularidad que ofrece una API imperativa. También necesitamos API imperativas, pero no para la automatización y la integración orientadas a NetOps y DevOps.
Pero los demás no necesitamos conocer ese nivel de detalle. De hecho, exigir unos conocimientos tan profundos puede resultar desalentador y ralentizar las iniciativas de automatización y orquestación. Desde luego, no contribuye a democratizar la infraestructura ni a habilitar modelos de autoservicio para los equipos de DevOps y los desarrolladores, y mucho menos para los equipos de NetOps ajenos al ámbito específico de la infraestructura.
Ahí es donde entran en juego las API declarativas.
Las interfaces declarativas especifican qué quieres hacer y dejan que el sistema determine la lógica y el flujo de trabajo. Así, en lugar de indicarle expresamente al sistema que cree un nodo y un grupo y que aplique toda la lógica adecuada a los objetos necesarios, tú describes dichos objetos y sus relaciones.
Algunas interfaces declarativas utilizan JSON, otras XML y algunas incluso siguen recurriendo a simples datos de formulario. Todas ellas tienen en común que presuponen que los datos describen los objetos de forma sencilla y directa, por lo que apenas es necesario comprender los modelos de objetos y las jerarquías del sistema.
Por ejemplo, esta declaración resulta bastante fácil de entender. Presupone un conocimiento básico del modelo de objetos, pero no tanto como para que sea necesario contar con una certificación en un producto específico para redactarla:
"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }
Aquí es donde se hace evidente el valor de las interfaces declarativas: en la reducción de los conocimientos específicos necesarios y de la complejidad del aprovisionamiento y la configuración de la infraestructura. Al reducir el nivel de especialización requerido, los equipos de NetOps no solo pueden trabajar con mayor rapidez y eficiencia, sino que ahora también pueden animar a los equipos de DevOps y a los desarrolladores a aprovechar esta capacidad.
La adopción de interfaces declarativas como método estándar para gestionar la infraestructura amplía de inmediato la reserva de talento a la que se puede recurrir para ofrecer capacidades de autoservicio y automatización avanzada. La interfaz declarativa anterior apenas requiere explicación para que los equipos de DevOps y los desarrolladores puedan entenderla y utilizarla. En cambio, una interfaz imperativa exigiría dedicar mucha más atención al aprendizaje del modelo y los flujos de trabajo específicos de la infraestructura antes de poder esperar resultados.
Las interfaces declarativas democratizan la infraestructura al simplificar el aprovisionamiento, la configuración y la gestión necesarios para automatizar los procesos de despliegue e integrar los sistemas con otros servicios de infraestructura. Y democratizar la infraestructura se traduce en una automatización más rápida e inteligente, así como en la capacidad de fomentar la colaboración y la cooperación entre los distintos ámbitos operativos, necesarias para aprovechar las ventajas de los movimientos NetOps y DevOps.
Sobre el autor
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 VittieArtículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.