DevOps para NetOps se trata de escala
Y la escala conduce a la velocidad. Y la velocidad conduce al éxito.
Supongamos que un ingeniero puede procesar una solicitud de cambio en dos horas. Supongamos que otro ingeniero puede procesar esa solicitud de cambio en 1,5 horas. Si trabajan juntos, ¿cuánto tiempo les tomará procesar doscientas solicitudes de cambio?
Sí, la respuesta obviamente es cerveza.
Probablemente todos recordamos (con no poca dosis de miedo y repugnancia) los infames problemas de palabras sobre “trenes” o “pinturas” en las clases de matemáticas, que fueron diseñados para enseñarnos sobre relaciones fraccionarias. En realidad, esa era su intención, aunque lo que muchos de nosotros obtuvimos de ellos fue un rechazo a la pintura y a los viajes en tren. Y muchos memes. No olvidemos los memes.
El problema es que este tipo de mediciones formuladas se están convirtiendo en un requisito en el centro de datos, particularmente en la red. Eso se debe a que los presupuestos son limitados (lo sé, ¿verdad?). ¿Qué tan loco es eso?) y sólo puedes contratar a X ingenieros para hacer el trabajo Y. En un mundo de aplicação donde los ciclos de lanzamiento rápidos y frecuentes son la norma, la cantidad de “X” que puede contratar para lograr lanzamientos oportunos es limitada.
Es por esto que la escala es un impulsor principal de “devops” en la red, también conocido como “netops”. Al aplicar los principios operativos de DevOps a la red, se cree que NetOps puede lograr la escala operativa necesaria para que los ingenieros “X” puedan hacer el trabajo “Y” a tiempo y dentro de las limitaciones presupuestarias, incluso cuando la relación entre X e Y es exponencial (traducción simple: realmente desequilibrada).
El problema de la solicitud de cambio es real; lo presentó un ingeniero de red que se enfrentó a un número cada vez mayor de solicitudes de cambio (definidas como crear un punto final de balanceador de carga para una aplicação, agregarlo al DNS y crear una regla de firewall para permitir el acceso) que, en última instancia, amenazaron con abrumar al personal disponible y, al mismo tiempo, aumentar el tiempo para completarlas.
La respuesta se encontró, por supuesto, en la automatización y en la aplicación de los principios de DevOps y en ofrecer una interfaz de autoservicio que permitiera a otros ingenieros realizar solicitudes que luego se documentaban en el sistema de tickets y se llevaban a cabo a través de varias API de servicios de aplicação y redes.
Esta adopción de la automatización (y la orquestación, porque en realidad todo el proceso también se está automatizando) no solo permite a los ingenieros existentes escalar operativamente, sino que también ha hecho que el proceso sea más rápido . Procesar una solicitud de cambio ya no toma hasta dos horas; ahora toma tan sólo cinco minutos.
Sí, lo leíste bien. Cinco minutos en lugar de hasta dos horas.
Se trata de una mejora significativa en la velocidad que surge de la capacidad de escalar a través de la automatización y la orquestación. Y si bien no es un proyecto ambicioso que abarque todo el centro de datos, sí aborda un problema específico que tanto los ingenieros como los propietarios de aplicação experimentaban con frecuencia. En este caso, aparentemente hasta 200 veces por semana.
Así es exactamente como NetOps debería abordar la automatización y la orquestación dentro de la red de producción. Encontrar tareas que sean repetibles y que el comité de revisión de cambios considere triviales (es decir, que se pueda demostrar que no son disruptivas y que la mayoría de los ingenieros pueden hacer mientras duermen) puede generar oportunidades significativas de escalar que resulten en la velocidad que, según nos dicen los propietarios de aplicação y negocios, debemos lograr en la red.
Desenterrar esos fragmentos de información que se pueden automatizar con el menor riesgo de interrupción posible deja a los ingenieros libres para centrarse en aquellas tareas que no se consideran maduras para la automatización. Ese enfoque también se traduce en tiempos más rápidos para implementar otros servicios, ya que se liberan de gastar una cantidad excesiva de su tiempo en tareas más simples y repetibles.
No puedo enfatizar lo suficiente lo importante que es adoptar un enfoque de CPR para la automatización de la red: una automatización consistente, predecible y repetible permitirá una escala más eficiente y un tiempo de entrega más rápido, con menos riesgo de interrupción debido a errores. Se trata de la unión de los modelos operativos denominados “modo 1” y “modo 2”, donde priman la fiabilidad y la estabilidad pero la agilidad sigue siendo deseable. Al habilitar un enfoque de CPR para la automatización y orquestación en la red, las organizaciones pueden mejorar la agilidad con mucho menos riesgo de perturbar la confiabilidad de una red encargada de entregar muchas, muchas (un promedio de alrededor de 200) otras aplicações.
Las redes de centros de datos están compuestas de tecnologías heredadas y emergentes, a menudo unidas mediante técnicas al estilo MacGyver que requieren chicle y un hilo de pescar. Estas redes deben soportar simultáneamente aplicações que han estado en producción durante casi cincuenta años (los mainframes aún existen) y aplicaciones emergentes creadas con tecnología recién salida de los pañales (como los contenedores). Debe entregar todas las aplicações y hacerlo de forma confiable y segura. Estos estándares no pueden ignorarse en favor de la velocidad y frecuencia requeridas por aplicações más nuevas y brillantes.
Pero netops puede lograr un equilibrio que permita que ambos coexistan, si puede identificar y posteriormente automatizar aquellas tareas y opciones de entrega de servicios que no son disruptivas y que son consideradas tareas de verificación por el control de cambios y otros aprobadores.
Después de todo, nuestra ecuación favorita para determinar el momento de pintar una casa cambia drásticamente cuando a los pintores involucrados se les dan rodillos de pintura automáticos en lugar de pinceles accionados manualmente.
No te preocupes tanto por cambiar la red, simplemente cambia la ecuación.