Seguramente todos estamos de acuerdo en que uno de los temas más mencionados últimamente en el mundo de la tecnología es la automatización. Esto se debe básicamente a tres tendencias que influyen en el contexto actual del mundo del networking e IT: mayor demanda de agilidad y velocidad; cambio cultural que busca una experiencia de usuario interno/externo del tipo auto servicio; complejidad tecnológica cada vez mayor. Estas tendencias son justamente las que apalancan una necesidad cada vez mayor de automatización extremo a extremo.
Estos cambios están vinculados a la irrupción de la llamada “cuarta revolución industrial” en nuestro propio sector, que paradójicamente ha sido y será a su vez un impulsor de la misma. Pero más allá de los cambios a nivel de tecnología que estamos viendo, nos surgen dudas o cuestionamientos sobre cómo éstos van a impactar en nuestra profesión a futuro; ¿cómo van a ser los ingenieros de red en el futuro? ¿Qué será de nuestras vidas profesionales? ¿Cuál será el impacto en los típicos network engineers? Es muy probable que nos veamos sumamente afectados y creo que muchos estaremos de acuerdo en que va a haber cambios.
En el área típica de networking, en los últimos años el modelo operativo se ha caracterizado por ser los fabricantes quienes identifican una necesidad, solución o funcionalidad y desarrollan un nuevo producto. Pero los vendors no pueden hacer productos/soluciones exactamente a medida de las necesidades de cada cliente, por lo cual construyen soluciones para un común denominador de necesidades de una base grande de clientes. De más está decir que muchos de los productos nuevos de los vendors tienen una relación directa o indirecta con la intención de automatizar un área definida. Por ejemplo, SD WAN intenta automatizar la WAN, Cloud la infraestructura IT en general, etc.
Este aumento de automatización requiere de nuevos skills y profesionales que mantengan estos sistemas, y sin dudas va a ir provocando una disminución de una determinada cantidad de recursos necesarios para tareas tradicionales. Esto puede ser visto como una ventaja a nivel de costos para empresas y organizaciones, pero impone un cambio profundo en nuestras profesiones y actividades, ya que tareas de nivel más bajo, repetitivas, van a dejar de existir y deben transformarse.
En paralelo a la automatización, un tema que ha venido desarrollándose fuertemente es la programabilidad, que si bien existe hace décadas, hoy ha tomado mayor relevancia. Quizás, una de las principales razones sea, justamente, que la programabilidad es el más notable impulsor de la automatización. Cuando hablamos de programabilidad de un sistema, típicamente nos referimos a que el sistema implementa “APIs”, que son formas de que una aplicación externa pueda controlar u obtener información del sistema.
Hoy en día, un 90% de los sistemas implementan REST like APIs, un tipo de APIs basadas en tecnologías de la web. Esto hace que requiera mucho menos esfuerzo programático a que una aplicación controle externamente a un sistema.
En este contexto, da la impresión de que desarrollar skills de programación sería estratégicamente correcta para nosotros, pero ¿para qué? Claramente suena grandilocuente pretender que vamos a desarrollar “in-house” las soluciones que proveen y desarrollarán los vendors.
Sin embargo, a través del concepto de cross domain automation surge la oportunidad para nosotros, los ingenieros, de transformarnos ya que podemos desarrollar automatización de extremo a extremo en nuestras organizaciones.
Por ejemplo, un proceso ante un pedido externo/interno de un nuevo servidor web, en una nueva zona DMZ de un firewall, implica que nosotros tradicionalmente ejecutemos acciones tales como instalar y configurar un firewall, definir la DMZ, instalar y configurar el web server, etc.
Todo este proceso puede involucrar distintos grupos de trabajo (IT, seguridad de red, internet, etc), y puede requerir órdenes de trabajo cruzadas entre ellos, lo que hace que el proceso completo pueda tomar días o semanas.
Sin embargo, podemos empezar a automatizarlo, generando un proceso automático para la creación de las DMZs y las reglas en los firewalls. Podríamos incluso virtualizar el web server y el firewall para crearlos y configurarlos de forma programática. A esto podríamos agregarle un portal web que dispare automáticamente todo el proceso para grupos internos de operación (incluyendo pasos de aprobación interna) e incluso podríamos crear un portal web de uso directo del cliente interno/externo para solicitar el proceso, enviando automáticamente un reporte de ejecución. El servicio quedaría operativo en pocos minutos.
Además de la reducción de tiempos, lograríamos beneficios tales como evitar los errores humanos, tendríamos la posibilidad de realizar pruebas extensivas en laboratorios antes de disponibilizar la nueva versión (incluso hasta podemos automatizarlo); obtener mayor visibilidad de los recursos utilizados (RAM, CPU, Disco, direcciones IP usadas, etc) y qué instancia de servicio lo utilizó (trazabilidad). De esta forma se puede lograr un contexto de agilidad en la introducción de nuevas funcionalidades, pero sin afectar la calidad de los servicios (modelo DevOps)
Hoy las organizaciones, como parte de su proceso de negocio o productivo, cuentan con una serie de sistemas y grupos de trabajo muy heterogéneo (sistemas de gestión comercial, CRMs, sistemas de gestión de fuerzas de trabajo, infraestructura de cómputo y storage, la red, etc). Automatizar completamente estos procesos puede ser complejo, y demandar mucho tiempo. Pero podemos empezar de a poco, e ir gradualmente agregando capas y capas de automatización.
Los productos de los vendors que apuntan a la automatización de un área (por ejemplo, SD WAN) sin lugar a duda ayudarán en el proceso. Sin embargo, será difícil conseguir un “producto” con una automatización de extremo a extremo, debido a la enorme diversidad y combinación de vendors de infraestructura y tecnologías existentes. Por eso, desarrollar la automatización de estos procesos “in-house” tiene sentido, pero, sobre todo le da un sentido interesante al desarrollo de nuestros skills de programabilidad.
Ahora bien, por más que los desarrollos apuntados a cross domain automation sean mucho más sencillos que el desarrollo completo de un producto, podemos aprovechar algunas metodologías del mundo de desarrollo de software a nuestro favor para mejorar distintos aspectos del proceso.
Por ejemplo, en el esquema CI (Continuos Integration), cada vez que se desarrolla una nueva funcionalidad, se desarrolla también un test automático de la misma. Cuando surge una nueva versión de código, se ejecutan todos los tests acumulados hasta el momento y si todos resultan OK, se aprueba la nueva versión de software. En el esquema CD (Continuos Deployment), automáticamente después que estos cambios fueron aprobados, pasan a producción. Lo que logramos con este esquema es calidad de servicio, mínima disrupción por cambios de versión, volviendo más fácil y poco traumático agregar funcionalidades a los desarrollos ya existentes, logrando así un ciclo virtuoso continuo. A demás de esto, si sumamos metodologías ágiles como Scrum nos ayudarán a determinar justamente qué hacer, con rapidez y agilidad.
¡Entonces aquí tenemos la luz al final del túnel! Los ingenieros de red podemos convertirnos en “NetDevOps” y así tener más chances de sobrevivir a la cuarta revolución industrial.
Según el neurocientífico David Eagleman la creatividad es innata al cerebro. Pero para que se den las condiciones para la creatividad, es necesario que el cerebro reciba muchos “inputs” diferentes y diversos. Desde ese punto de vista, si nosotros en nuestras disciplinas mezclamos nuestros nuevos “inputs” de programabilidad con nuestros ya existentes “inputs” de networking e IT, tendremos la receta para una nueva ola de creatividad. Esto, a mi entender, agranda fuertemente la dimensión de creatividad en nuestras profesiones y las mejora notablemente. ¿Será fácil hacer esta transición? Seguro que no, pero por lo menos, tenemos una dirección en la cual apuntar.
