En un blog anterior, escribí que los ingenieros de redes tocaban el segundo violín (¡no importa que mencionara a las filarmónicas de Nueva York y Viena de Leonard Bernstein!) y, si consulta mi LinkedIn, me valió el desprecio de algunos contactos (seguimos siendo amigos).
Siguió un sano debate y se admitió que los ingenieros de redes deben adoptar patrones «NetOps» en esta era Cloud-First en la que nos encontramos.
Pero para mí, el hecho de que intentemos cambiar el nombre de una disciplina de TI al aplicarla al trabajo en red (DevOps tiene que convertirse de algún modo en NetOps) demuestra que en el trabajo en red seguimos pensando que somos diferentes.
Discrepo categóricamente de que el trabajo en red sea diferente y, por lo tanto, cuanto más rápido adoptemos los modelos DevOps (en lugar de NetOps), mejor nos irá.
Devops gobierna el entorno de aplicaciones e infraestructuras Cloud-First, de ahí que la red tenga que seguir su ejemplo. 
Esto es lo que pasa con NetOps: siempre que sale a colación, la atención se centra en la programabilidad de la red con Python, la automatización de la configuración o la definición de políticas.
Los términos técnicos dominan la discusión sobre NetOps.
La discusión sobre DevOps, en cambio, se centra en la transformación empresarial, la cultura y la filosofía.
NetOps está ocurriendo -y eso es genial- pero el verdadero cambio de juego en las redes sería elevar la discusión y adoptar una verdadera filosofía DevOps.
Para ello, los profesionales de las redes deben liderar con la intención y la cultura empresarial, ante todo, no con las herramientas tecnológicas.
Repasemos rápidamente la historia de la informática de aplicaciones y cómo condujo a DevOps.
Entonces, como ingeniero de redes, tendrá que admitir a regañadientes que hay sorprendentes familiaridades, y que estamos reflejando exactamente la misma trayectoria, y seguramente llegaremos al mismo resultado: DevOps.
Al principio, había hierro.
En el mundo de las aplicaciones, se pasó de los mainframes a los servidores.
Usted tenía que cuidar con cariño a sus mascotas (también conocidas como servidores): instalarlos, configurarlos, parchear su sistema operativo mientras se aseguraba de que seguía siendo compatible con la aplicación o aplicaciones que ejecutaba en él, actualizar manualmente la CPU o la memoria o la unidad de disco cuando el rendimiento empezaba a degradarse.
Entonces llegó la virtualización.
De repente, surgió el «poder de la abstracción» (consulte la legendaria conferencia de Barbara Liskov), y usted pudo dedicar más tiempo a innovar en el código y menos a ocuparse de los problemas del servidor.
Esta separación permitió los modelos as-a-Service, y ahora vemos cosas como la computación sin servidor, la infraestructura como código, etc.
«Ganado, no mascotas» es una de las frases de moda cuando se trata de una infraestructura de aplicaciones que entre contenedores y orquestación se ha abstraído por completo.
Como Dev(eloper), usted sólo empuja su código a la orquestación, quiere que se despliegue muy rápidamente y a la escala requerida para que sus usuarios tengan una gran experiencia de usuario.
Pero a usted no le importa dónde y cómo ocurre, eso es cosa de la(s) Op(eración(es).
Ponga ambas cosas juntas: DevOps crea una cultura que impulsa la innovación y los resultados empresariales.
En redes, debemos admitir que seguimos cuidando de nuestras mascotas: routers, switches y -sí, tengo que decirlo- SD-WAN «Hágalo usted mismo».
Echemos un vistazo a la historia de la WAN empresarial: cuando me incorporé al sector, estábamos desplegando infraestructuras ATM.
Luego llegaron los routers IP, y eso fue divertido.
Luego empezamos a integrar todo tipo de aplicaciones en el SO del router, como VoIP, funciones de seguridad y muchas más.
Esas «mascotas» llegaron a tener un mantenimiento muy elevado y, sin embargo, la esperanza de vida de un hámster.
Cada dos o tres años, más o menos, parecían necesitar alguna actualización importante de hardware: CPU más grandes, interfaces más rápidas, nuevo tejido de conmutación.
Lo que se le ocurra.
Algunas personas del mundo de las redes miraron por encima de la valla con cierta envidia lo que el mundo de las aplicaciones había logrado con la virtualización, y los visionarios de la SDN empezaron a hablar de abstracciones de red.
La virtualización de redes empezó a suceder.
La gran mayoría de las SD-WAN se construyen como una superposición virtual. Es genial porque esa superposición es bastante ágil, a diferencia de la infraestructura de red física subyacente en la que se apoya para ofrecer SLA de nivel empresarial (escribí sobre el dilema superposición-subyacente aquí).
Y sí, el aprovisionamiento sin intervención existe.
Pero pregunte a las personas que han implementado una SD-WAN global «Hágalo usted mismo» si fue tan fácil como distribuir código para un desarrollador de aplicaciones.
¡Desde luego que no lo es(enlace al artículo de Network World)!
Hay varias guías de diseño que tienen varios cientos de páginas una vez que se comprueba el resto de documentación a la que hace referencia la guía de diseño.
Las políticas que tiene que definir el Día 0 son bastante complejas, y más vale que las haga bien.
Ah, y seguirá necesitando MPLS para las aplicaciones críticas para la empresa y, en muchos casos, tendrá que procurarse usted mismo esos enlaces a través de distintos países y parchearlo todo usted mismo.
Volviendo a DevOps: se hizo posible gracias a los modelos de entrega X-as-a-Service.
Que es exactamente lo que Aryaka hace para las redes.
Me gusta llamarlo redes sin enrutador, tomándolo prestado de la informática sin servidor para hacer un punto.
Olvídese de la configuración y de los ajustes constantes.
Nunca deje que un vendedor de routers le diga que ha salido un hardware nuevo y mucho mejor y que hay una promoción especial.
Obtenga resultados empresariales directos, no se preocupe por definir políticas de red complejas, ni por cómo ofrecer SLA entre límites administrativos, ni por ajustar constantemente su red para mantenerse al día con las cargas de tráfico IaaS y SaaS en constante cambio.
Aryaka simplemente resuelve su intención empresarial: díganos dónde están sus sitios, qué redundancia necesita, cuáles son sus aplicaciones principales, cómo quiere priorizarlas… y vea cómo la red que imaginó se materializa mágicamente en 48 horas o menos.
Y no sólo eso, sino también ver cómo su red como servicio se adapta constantemente a las necesidades cambiantes de su negocio.
Aryaka procesa y supervisa constantemente los datos de su red global de capa 2, así como todos los enlaces de última milla que conectan con la red central, para detectar macrotendencias y ofrecer a los clientes opciones de optimización constantes.
Hace falta un gran cambio cultural, sí.
DevOps es una nueva filosofía e inevitablemente llegará a imperar también en las redes.
Aryaka se construyó como una WAN Cloud-First para llevar la cultura DevOps a las redes: una nueva forma de conectar globalmente su empresa global con una WAN empresarial Cloud-First que ofrece agilidad y resultados empresariales.
Más de 800 empresas se han unido a nosotros.
¿Por qué no se une a nosotros para una demostración de nuestra cartera de SmartServices?
