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

Si vas a automatizar todas las cosas, tendrás que hacerlo de forma declarativa. He aquí el porqué.

Hemos estado haciendo hincapié en el concepto declarativo durante bastante tiempo cada vez que hablamos de automatización, particularmente con respecto a NetOps y los servicios de aplicação . Pero realmente no hemos profundizado en por qué es importante y cuáles son los beneficios. Mi intención es rectificar eso ahora mismo.

Para refrescar la memoria, actualmente se utilizan dos modelos para automatizar la configuración y la implementación de, bueno, todo.

El primero es imperativo, en el cual le decimos al sistema de destino exactamente cómo hacer lo que queremos hacer. Si alguna vez abrió un túnel SSH a un sistema y escribió un conjunto específico de comandos en la CLI, habrá participado en el modelo imperativo de configuración.

La segunda (y preferida) es declarativa, en la que le decimos al sistema de destino qué hacer, pero no cómo. Este es el modelo adoptado por la mayoría de las soluciones de automatización de red por varias razones, la más importante de las cuales es el enorme costo y tiempo que se requieren para aprender e integrar los cientos de dispositivos y sistemas posibles que podrían existir en un entorno determinado.

Entonces, en un modelo imperativo, tenemos que especificar cada comando (o llamada API) necesaria para configurar un sistema. En un modelo declarativo, simplemente especificamos pares clave-valor (generalmente) que describen lo que queremos y dejamos que otro sistema se preocupe por los comandos necesarios para hacerlo realidad.

Fácil y rápido, solo exprime un limón.

Ahora, respondamos a la pregunta de por qué esto es importante. Hay cuatro beneficios principales al adoptar un modelo declarativo cuando se avanza hacia la automatización de todas las cosas.

1.Reducir el error humano

Sabemos que aproximadamente el 22% de los incidentes de interrupciones en la producción ocurren debido a errores humanos. Algunos incidentes bastante notorios, que no voy a analizar más a fondo, han sido atribuidos directamente a simples errores humanos. En un modelo imperativo, basado en llamadas API, cada una es un incidente potencial a punto de ocurrir. Si no verificó una variable, olvidó verificar un código de error o hay cientos de otros escenarios posibles, es posible que experimente un evento que genere un currículum. Eso es algo malo.

Un modelo declarativo se basa en una plantilla o un archivo de configuración de algún tipo que se analizará y validará antes de que se utilicen llamadas API para ejecutarse en él. Si bien es cierto que aún es posible arruinar un archivo de configuración o una plantilla, las oportunidades de hacerlo son limitadas porque estás reduciendo el código requerido. Y menos código generalmente significa menos oportunidades de cometer un error.

2.Reducir la deuda técnica

La deuda técnica es esa metáfora divertida que aprendimos del desarrollo y que nos recuerda el costo a largo plazo de nuestras decisiones. La deuda técnica aumenta con los modelos imperativos de varias maneras. En primer lugar, está el acoplamiento de los scripts a la API de nuestro sistema de destino. Es poco probable que esa API admita nada más , lo que significa que estamos desarrollando scripts para cada sistema. Los pasos de configuración probablemente también variarán de una aplicación a otra: no todo es HTTP y no todas las aplicação basadas en HTTP requieren exactamente la misma configuración de servicio. Ahora estamos creando scripts para cada aplicación y cada sistema. Son muchos guiones y mucha deuda acumulada a partir de esa elección.

Por el contrario, un método declarativo puede utilizar el mismo script y sistema de proceso de implementación. Si bien es probable que la plantilla/configuración siga siendo específica de la aplicação y del sistema, se trata de un archivo único. Elimina la complejidad y la cantidad de scripts y, por lo tanto, reduce drásticamente la deuda técnica. La realidad es que siempre habrá alguna deuda generada por nuestras decisiones; minimizarla es el objetivo. 

3.Eliminar conflictos de versiones

Al vincular sus procesos de configuración e implementación a una API, se vincula a esa versión de la API. Existen numerosas comunidades en internet con desarrolladores hostiles y enfadados que se quejan de los cambios en una API y del trabajo necesario para adaptar su aplicación. Lo mismo puede ocurrir (y ocurrirá) con los servicios de red y aplicação . Entonces, si estás atado a una versión de la API y algo cambia, ¿adivina qué? Estarás actualizando (o quizás reescribiendo) guiones hasta el cansancio*.

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

4.Reducir los requisitos de experiencia en el dominio

Seamos realistas, si voy a utilizar una API para un servicio de red o aplicação , tengo que entender el sistema. Si no conoce la diferencia entre una IP virtual y un servidor virtual, bueno, ya está en problemas y apenas hemos llegado a la cuestión de los nodos frente a los miembros. Los métodos imperativos basados en API requieren que usted comprenda el sistema de destino lo suficientemente bien como para navegar por su configuración.

Al usar un modelo declarativo, se necesita menos experiencia en el sistema de destino, lo que significa que tanto los desarrolladores como los de DevOps tienen más probabilidades de poder usar el método para autoservicio de aplicações. Por supuesto, todavía se necesitarán expertos, pero las demandas de los consumidores de los servicios se reducen y la carga de aprovisionamiento e implementación se distribuye entre un conjunto más amplio de participantes.

Existen otras razones por las que podrías querer adoptar un modelo declarativo para tus iniciativas de automatización de NetOps, pero estas cuatro son las más convincentes. Esto se debe a que benefician a NetOps, al negocio y a los constituyentes en expansión que necesitan acceso de autoservicio a la red y a los servicios de aplicação que hacen que las aplicaciones funcionen de forma más rápida y segura.