Y otras ideas de la encuesta NetDevOps Otoño 2016 realizada por la comunidad NetworkToCode
La comunidad NetworkToCode está llena de personas apasionadas por las redes y el código. Aunque parezca un cliché, estas personas han estado automatizando redes desde antes de que empezara a ponerse de moda (y ser un imperativo ejecutivo) hacerlo.
Durante el otoño de 2016, la comunidad realizó una encuesta sobre una amplia gama de preguntas que se centraron, apropiadamente, en redes y código. Los resultados brutos (enlazados arriba) están disponibles públicamente. La naturaleza de las herramientas de encuesta en línea es tal que los conjuntos de datos resultantes pueden ser difíciles de analizar a menos que se normalicen los datos (lo que requiere trabajo). Afortunadamente para ti, querido lector, he hecho ese trabajo por ti y puedo ofrecerte ideas de una manera más gráfica y colorida.
Los lectores astutos notarán que durante mucho tiempo he defendido la aplicação de lo que normalmente se conoce como principios “DevOps” a la red y, como era de esperar, fue ahí donde concentré mucha energía mientras analizaba estos datos.
No sorprende que en un grupo centrado en código y redes las opiniones sobre DevOps fueran al menos mayoritariamente positivas. Solo el 6,75% no tenía “ningún interés” en DevOps, mientras que el 25,74% señaló que ya estaba en producción. La mayoría de los demás al menos estaban pensando en ello (39,24%), si no evaluando (28,27%).
Los autores de esta encuesta formularon algunas preguntas bastante detalladas sobre este tema, incluida la perspectiva de NetOps sobre la infraestructura como código. Esto generó un poco más de desinterés: casi el 10% dijo "no tener interés". Lo interesante fue que solo el 19,35 % afirmó que la infraestructura como código "ya estaba en producción", pero un 54 % de los encuestados indicó que utilizaba la automatización para la implementación de la configuración y otro 66 % automatizaba el archivo de la configuración. Exactamente un NetOps está automatizando la gestión de la configuración (y estoy bastante seguro de que no es el único NetOps que usa con orgullo vimdiff para gestionar los cambios de configuración).
La primera pregunta que suele venir a la mente es: “¿Qué es Infraestructura como Código?” Lo cual probablemente sea la raíz del porqué muchos más están “haciendo”, aunque en su mayoría se identifican como “evaluando” o “pensando” en ello. La definición de fatiga es real, muchachos , y sin definiciones claras en estos días es difícil sacar conclusiones sobre la terminología efímera (aunque lo haremos de todos modos, porque eso es lo que hacemos, ¿no?).
Entonces, ¿qué está automatizando NetOps? Seguimos diciéndoles que es necesario hacerlo para que el tren de la transformación digital siga avanzando sin demoras, pero también sabemos que las redes empresariales, en particular, no son exactamente un entorno en el que se pueda jugar con la automatización. Se trata de redes serias, de las que depende hoy en día todo el negocio. Resulta que NetOps se está automatizando bastante.
La generación, el archivado y la implementación de la configuración son las tres operaciones más importantes que se automatizan hoy en día. La recopilación y presentación de datos también parece estar ganando impulso.
De hecho, con la excepción de la gestión de la configuración (y aquella, la aventurera NetOps), todas las operaciones parecen estar automatizadas en un número respetable de organizaciones de los encuestados.
Pero, por supuesto, la automatización de las tareas relacionadas con la configuración plantea la pregunta: ¿con qué frecuencia ocurre y, por lo tanto, justifica la automatización? Yo diría (probablemente en contra del pensamiento actual sobre el tema) que cuanto menos frecuentemente se implementen cambios en producción , más valiosa será en realidad la automatización. Claro, uno nunca “olvida” cómo andar en bicicleta, pero con meses o años de diferencia, ese primer paseo de nuevo sobre el sillín, por así decirlo, puede ser una experiencia dolorosa (llena de errores). Lo mismo puede suceder con las implementaciones. Pero ese es un tema para otro día.
Resulta que NetOps se implementa de manera bastante regular: aproximadamente la mitad (50,92 %) implementa cambios menores más de una vez al día en el entorno de producción, y el 37,59 % implementa cambios importantes entre 1 y 5 veces al mes. Esto no se acerca al extraordinario "200 veces al día" que promocionan los proveedores de tecnología nativos de la web, que principalmente admiten una sola aplicación (pensemos en Netflix, PayPal o Facebook), pero aún así está moviendo las aplicaciones a un ritmo bastante bueno para una empresa que admite en promedio más de 200 aplicações (según nuestras propias encuestas sobre el estado de la entrega de aplicação ).
Por último, ¿hay que preguntarse cómo gestionan todos estos cambios? Como se indica en el título, realmente hubo un único y orgulloso NetOps que afirma utilizar únicamente vimdiff para gestionar los cambios. Dada la estructura de los datos, es difícil correlacionarlos con la frecuencia de los cambios en la producción, pero realmente quiero hablar con este NetOps porque él o ella es mi héroe por aferrarse con orgullo a lo que les funciona, sin importar la presión externa.
¿En qué se basa el resto de NetOps? Resulta que muchos de ellos utilizan Github. 47% para ser exactos. Y otro grupo grande (39%) está usando Rancio/Oxidado. Rancid (que no debe confundirse con la banda de punk rock estadounidense formada en Berkeley, California en 1991) es una herramienta de red que administra copias de seguridad de configuración. Oxidized también es una herramienta de red para gestionar copias de seguridad de configuración, que suele promocionarse como alternativa a RANCID. Existen subreddits dedicados a ella, por si te interesa saber más.
Un aterrador 8% no realiza ningún seguimiento de los cambios de configuración. Hice eso una vez en el laboratorio y terminé con un enlace entre redes terriblemente asimétrico que era de 100 Mbps en un sentido y 1,5 Mbps en el otro. Sí, accidentalmente recreé el modelo moderno de cable de banda ancha en un laboratorio en Green Bay hace casi 11 años. No, desafortunadamente no recibo regalías, pero la buena noticia es que tampoco recibo mensajes de odio. De nuevo, es difícil entender ese razonamiento sin la capacidad de realizar tablas cruzadas con el tamaño de la organización. Curiosamente, el 11,91 % administra entre 0 y 50 dispositivos de red, por lo que es plausible especular que ese 8 % tiene una cantidad manejable de dispositivos para administrar y les va bien. El grupo más grande de NetOps (38,63 %) administra más de 1000 dispositivos, y otro 28,23 % administra entre 251 y 1000, por lo que es justo decir que la mayoría de NetOps son responsables de muchos dispositivos (casi con certeza heterogéneos) y, por lo tanto, el seguimiento de los cambios de configuración se vuelve necesario no solo para la buena salud continua de la red, sino también para la cordura de sus operadores.
En términos generales, disfruté mucho esta inmersión en el mundo de NetDevOps, su etiqueta y la visión de lo que utilizan, lo que consideran importante y cómo son los entornos en los que operan, aunque solo sea desde una perspectiva general.
NetOps es la columna vertebral de la organización de TI y es cada vez más responsable de mantener todo funcionando mientras las empresas emprenden transformaciones digitales que prometen aumentar la carga sobre la red y los operadores que la mantienen funcionando de manera segura.
No creo que sea posible transformar por completo las operaciones de red desde un modelo tradicional a un modelo más ágil, similar a DevOps. Al igual que la transformación digital de los negocios, la transformación digital de TI ocurre en etapas con el objetivo de no interrumpir los procesos existentes que podrían descarrilar el tren del negocio. Esta encuesta muestra que claramente se está produciendo una transformación que, si bien quizás no esté etiquetada como “DevOps” ni satisfaga por completo las nociones de los puristas de lo que eso implica, definitivamente está haciendo avanzar la red empresarial en su propio viaje de transformación digital .