La adopción de redes abiertas es una aspiración que muchas empresas habrán tenido mucho antes de la pandemia mundial. Y hay una gran cantidad de contenido que destaca cómo la red abierta que no solo puede aumentar la productividad de los ingenieros de redes, sino también reducir el costo total de propiedad (TCO). Pero con el bloqueo de Covid-19 obligando a miles de empresas a trabajar de forma remota, las redes abiertas ahora son más importantes que nunca. Desafortunadamente, muchos no estaban listos para ello.
La adopción exitosa de una arquitectura de red abierta a menudo requiere una importante revisión del modelo de negocio, tanto desde el punto de vista técnico como cultural. Desde las pruebas hasta la implementación y la mejora de los equipos de TI: uno de los mayores errores cometidos es aplicar los métodos y expectativas tradicionales a la nueva infraestructura. Una clavija cuadrada en un agujero redondo. Los flujos de trabajo empresariales deben realinearse para que coincidan con los beneficios de la red abierta en tres puntos de contacto comunes; documentación, solicitud de cambio y educación y capacitación. Solo una vez que esto se haya hecho, las empresas estarán realmente preparadas para la arquitectura de red abierta.
Documentación
En las redes tradicionales, la documentación se divide en tres áreas; Diseño de alto nivel (HLD), diseño de bajo nivel (LLD) y pruebas de aceptación del usuario (UAT). Y generalmente se escribe fuera del flujo de trabajo, lo que requiere que los ingenieros dejen de desarrollar contenido para documentar lo que están haciendo. Pero esto es muy ineficiente, ya que el documento está desactualizado inmediatamente. La documentación estática no refleja con precisión los requisitos siempre cambiantes de una red.
El diseño de alto nivel (HLD) registra por qué cada característica específica se selecciona para una infraestructura de red propuesta. Pero en redes abiertas, en lugar de simplemente usar HLD como referencia para comprender la historia de la implementación actual de redes; se usa como una lista de derechos de red que hace cumplir las reglas de cómo las aplicaciones deben diseñarse e implementarse en la red.
Además, se requiere un cambio de paradigma completo con respecto a LLD. En lugar de simplemente acompañar al HLD tomando características elegidas para la infraestructura y proporcionando las mejores prácticas para cada uno; el LLD debe convertirse en la simulación y la configuración y almacenarse en un repositorio centralizado de git. Las redes abiertas alinean el LLD más estrechamente con las configuraciones finales, aliviando una gran ineficiencia encontrada en las redes tradicionales.
En redes abiertas, el LLD puede fluir de forma nativa a la UAT, una serie de criterios de prueba que deben cumplirse para demostrar que una implementación está lista para la producción. Esto se debe a que una gran proporción de los criterios de prueba relacionados con la redundancia y la conectividad pueden abordarse en el entorno de prueba utilizado para el LLD.
La documentación debe ser una parte fundamental del proceso de diseño. Y al combinar código y simulación, estos dos flujos de trabajo estándar se convierten en una parte directa del proceso de documentación. Este proceso es significativamente más productivo y eficiente en el tiempo.
Solicitudes de cambio
Por lo general, las solicitudes de cambio consisten en agregar nuevas características o incorporar una nueva aplicación a la infraestructura existente. Pero los flujos de trabajo de redes tradicionales son altamente ineficientes, ya que dependen de que los ingenieros envíen correos electrónicos conjeturas educadas generadas de forma independiente y se ignoran principalmente hasta la ventana de mantenimiento. En ese momento, trabajar sin noticias debe ser una buena noticia, se aplican y se envían oraciones a los dioses de TI con la esperanza de que funcione. Esto deja a muchos pensando que debe haber una mejor manera de implementar las solicitudes de cambio.
Y ahí está. La construcción de tuberías de prueba automatizadas que se conectan a los sistemas CRM de las empresas significa que cualquier cambio realizado tiene un historial de compromiso completo; responsabilizar a las personas. Esto también pone en juego una cadena de aprobación para una responsabilidad adicional, gracias a todas estas tecnologías existentes de forma nativa en Git; La solución elegida para Infraestructura como Código. En la práctica, esto significa que todas las configuraciones propuestas se ejecutan contra una serie de validaciones, y el informe está vinculado al ticket de solicitud de cambio original.
Como tal, cuando se trata de incorporar nuevas aplicaciones, la solicitud de cambio es un caso simple de aplicar cambios de configuración que ya han sido validados y examinados según el HLD y LLD. La automatización empleada aquí garantiza que solo los cambios validados se puedan insertar en la red.
A medida que más empresas buscan migrar a entregas remotas dadas las limitaciones actuales en torno a los viajes, es esencial que las solicitudes de cambio puedan ser examinadas más fácilmente. Ya no es una opción "ir al laboratorio" para resolver problemas. Al igual que los ingenieros de la NASA que verifican tres veces su trabajo antes de enviar instrucciones a satélites remotos, las solicitudes de cambio de red de TI necesitan el mismo nivel de verificación.
Formación
El mayor error que cometen las empresas al adoptar una red abierta es no capacitar adecuadamente a su personal. Para lograr todos los beneficios de la red abierta, se requiere más que simplemente comprar soluciones de red abierta y esperar que el equipo de redes continúe con ella. Requiere un nivel sólido de comprensión técnica de cómo aprovechar al máximo las redes abiertas; especialmente cuando se trata de alcanzar objetivos comerciales específicos.
Esto tiene que ser proactivo. Como se vio en el reciente cambio hacia el trabajo remoto durante el bloqueo forzado por Covid-19, las compañías que han sido más resistentes fueron las que tenían la mano de obra cualificada que era capaz de hacerlo. Cada empleado estaba debidamente capacitado en prácticas de trabajo modernas y remotas que permitían que la productividad permaneciera a través de principios de redes abiertas.
Para las empresas con recursos presupuestarios y de tiempo, la capacitación formal es un excelente punto de partida y debe ser un requisito obligatorio. Especialmente en grandes empresas que normalmente tienen grandes equipos de red que requieren capacitación. Esto crea un piso de habilidades, que impide que el equipo de ingeniería retroceda de las responsabilidades. Desde los fundamentos de la red abierta hasta los contenedores, VMWare, Openstack y Linux como sistema operativo central en los negocios, esta capacitación debe abordar múltiples temas más allá de las redes.
Además de no pagar por la capacitación adecuada, el mayor error que cometen las empresas es no asignar adecuadamente el tiempo para que sus equipos de ingeniería de redes aprendan u optimicen naturalmente su cartera de tecnología de redes abiertas. Con el aumento de las demandas de las redes modernas, con demasiada frecuencia los equipos terminan empantanados en la maleza de las operaciones diarias, tratando de forzar una solución de red abierta en los flujos de trabajo tradicionales.
La implementación inicial de la red abierta requerirá más tiempo, ya que el equipo de la red necesita tiempo para reestructurar los flujos de trabajo adecuadamente. Al permitir más tiempo por adelantado, el negocio finalmente será más productivo a largo plazo.
Los beneficios de las redes abiertas están bien documentados, pero si no se implementan correctamente, las empresas corren el riesgo de ser aún más ineficientes que cuando usan redes tradicionales. Al centrarse en la formación de equipos de ingeniería de redes, junto con la automatización de la documentación y las solicitudes de cambio, las empresas pueden estar seguras de que estarán bien preparadas para cosechar los beneficios de las redes abiertas.
Por Rama Darbha, Director de servicios de consultoría en Cumulus Networks