¿Por qué es importante un modelo declarativo para la automatización de NetOps?

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Si vas a automatizarlo todo, te conviene adoptar un enfoque declarativo. Te explicamos por qué.

Llevamos bastante tiempo insistiendo en el enfoque declarativo cada vez que hablamos de automatización, especialmente en lo que respecta a NetOps y los servicios de aplicaciones. Sin embargo, aún no hemos profundizado realmente en por qué es importante ni en cuáles son sus ventajas. Me propongo remediarlo ahora mismo.

Para refrescaros la memoria, actualmente se utilizan dos modelos para automatizar la configuración y el despliegue de, bueno, prácticamente todo.

El primero es el modelo imperativo, en el que indicamos al sistema de destino exactamente cómo debe hacer lo que queremos. Si alguna vez has abierto un túnel SSH hacia un sistema y has introducido un conjunto específico de comandos en la CLI, has utilizado el modelo imperativo de configuración.

El segundo modelo (y el preferido) es el declarativo, en el que indicamos al sistema de destino qué debe hacer, pero no cómo. Este es el modelo adoptado por la mayoría de las soluciones de automatización de redes por diversos motivos, entre los que destaca el enorme coste y tiempo necesarios para conocer e integrar los cientos de dispositivos y sistemas posibles que puede haber en un entorno determinado.

Así pues, en un modelo imperativo, tenemos que especificar cada comando (o llamada a la API) necesario para configurar un sistema. En un modelo declarativo, normalmente solo especificamos pares clave-valor que describen lo que queremos y dejamos que otro sistema se encargue de ejecutar los comandos necesarios para conseguirlo.

Pan comido.

Ahora, para responder a la pregunta de por qué esto es importante, adoptar un modelo declarativo cuando se pretende automatizarlo todo ofrece cuatro ventajas principales.

1. Reducir los errores humanos

Sabemos que aproximadamente el 22 % de las interrupciones en producción se deben a errores humanos. Algunos incidentes de bastante repercusión, en los que no volveré a entrar, se han atribuido directamente a simples errores humanos. En un modelo imperativo basado en llamadas a API, cada una de ellas es un incidente potencial a la espera de ocurrir. Si no se verifica una variable, se olvida comprobar un código de error o se da cualquiera de otros cien escenarios posibles, puede producirse un incidente que obligue a actualizar el currículum. Y eso no es nada bueno.

Un modelo declarativo se basa en algún tipo de plantilla o archivo de configuración que se analiza y valida antes de utilizar llamadas a la API para ejecutarlo. Aunque, por supuesto, aún se pueden cometer errores en un archivo de configuración o una plantilla, las posibilidades de que esto ocurra son menores porque se reduce la cantidad de código necesario. Y menos código suele significar menos oportunidades de cometer errores.

2. Reducir la deuda técnica

La deuda técnica es esa divertida metáfora que tomamos prestada del desarrollo y que nos recuerda el coste a largo plazo de nuestras decisiones. Con los modelos imperativos, la deuda técnica se acumula de varias formas. En primer lugar, está el acoplamiento de los scripts a la API de nuestro sistema de destino. Es poco probable que esa API sea compatible con cualquier otra cosa, lo que significa que desarrollamos scripts específicos para cada sistema. También es probable que los pasos de configuración varíen de una aplicación a otra: no todo utiliza HTTP ni todas las aplicaciones basadas en HTTP requieren exactamente la misma configuración de servicio. Así que ahora creamos scripts específicos para cada aplicación y cada sistema. Son muchos scripts y mucha deuda acumulada como consecuencia de esa decisión.

Por el contrario, un método declarativo puede utilizar el mismo script y sistema para el proceso de despliegue. Aunque la plantilla o configuración probablemente seguirá siendo específica de cada aplicación y sistema, se trata de un único archivo. Esto elimina la complejidad y reduce el número de scripts, disminuyendo así drásticamente la deuda técnica. La realidad es que nuestras decisiones siempre generarán cierta deuda; el objetivo es minimizarla.

3. Elimina los conflictos de versiones

Cuando vinculas tus procesos de configuración e implementación a una API, quedas ligado a esa versión de la API. En Internet hay muchas comunidades llenas de desarrolladores hostiles y enfadados que protestan por los cambios en una API y por el trabajo necesario para adaptar sus aplicaciones. Lo mismo puede ocurrir (y ocurrirá) con los servicios de red y de aplicaciones. Así que, si estás ligado a una versión de la API y algo cambia, ¿adivina qué? Tendrás que actualizar (o quizá reescribir) scripts hasta que las vacas vuelvan a casa*.

Pero, si ha adoptado un modelo declarativo, probablemente podrá ignorar cualquier cambio en la API. Al fin y al cabo, no utiliza la API para indicar al sistema cómo implementar un servicio, sino que simplemente le indica qué debe implementarse.

4. Reduzca los requisitos de conocimientos especializados del dominio

Seamos sinceros: si voy a utilizar una API para un servicio de red o de aplicaciones, tengo que entender el sistema. Si no conoce la diferencia entre una IP virtual y un servidor virtual, ya tiene un problema, y apenas hemos empezado a hablar de la diferencia entre nodos y miembros. Los métodos imperativos basados en API requieren que conozca el sistema de destino lo suficientemente bien como para desenvolverse por su configuración.

Al utilizar un modelo declarativo, se necesitan menos conocimientos especializados sobre el sistema de destino, lo que facilita que tanto los desarrolladores como los equipos de DevOps puedan utilizar este método para gestionar aplicaciones en régimen de autoservicio. Por supuesto, seguirá siendo necesario contar con expertos, pero se reducen las exigencias para los consumidores de los servicios y la carga del aprovisionamiento y el despliegue se distribuye entre un conjunto más amplio de partes interesadas.

Hay otras razones por las que podría interesarle adoptar un modelo declarativo para sus iniciativas de automatización de NetOps, pero estas cuatro son las más convincentes. Esto se debe a que benefician a NetOps, a la empresa y al creciente número de usuarios que necesitan acceso de autoservicio a los servicios de red y de aplicaciones que permiten que las aplicaciones funcionen de forma más rápida y segura.

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