¿Cómo pueden los CSP acelerar su innovación con DevOps?

Para mantener su nivel competitivo, los proveedores de servicios de comunicaciones (CSP) deben adoptar una nueva mentalidad que les lleve a operar con procesos más eficientes, de una forma mucho más transparente, colaborativa y flexible. Una vía para lograrlo podría consistir en sumergirse dentro de la cultura DevOps.

Nadie dice que sea un camino sencillo, especialmente para los CSPs, que en muchas ocasiones arrastran la herencia de unas infraestructuras excesivamente especializadas. La parte buena es que este trayecto hacia DevOps ya ha sido recorrido con éxito por multitud de compañías, proveedores de servicios o líderes de Internet, de las que los CSPs pueden extraer valiosas experiencias. Si bien puede que no sea posible adoptar plenamente todos principios y mejores prácticas, está demostrado que mediante la implementación de tan solo algunas de sus metodologías y herramientas podrían lograrse mejoras a corto plazo, tanto en el desarrollo de servicios como en las operaciones.

Los CSP del futuro

En su afán por convertirse en proveedores de servicios totalmente digitalizados, los CSPs se están transformando en desarrolladores de software, con todas las ventajas y desventajas que esto conlleva. Esta realidad no se produce únicamente porque el futuro nos trae más virtualización, funciones de red (NFV) y redes definidas por software (SDN) –que, francamente hablando, es algo que aún tiene que despegar entre los CSPs, al menos en Europa- sino porque la digitalización es una tendencia generalizada y estrechamente relacionada con la transición hacia redes todo IP, que implica mover servicios a la nube, la necesidad de llevar a cabo analíticas avanzadas en tiempo real que sean capaces de responder con mayor rapidez y eficacia a las demandas del mercado.

Convertirse en un desarrollador de software también tiene implicaciones económicas. La forma más tradicional de organizar el trabajo en grupos y proyectos aislados resulta rígida y costosa y, sobre todo, estas estructuras no invitan a la colaboración entre departamentos. Las estructuras tradicionales no serán sostenibles a largo plazo, y los CSPs del futuro no presentarán las mismas divisiones de trabajo y responsabilidades que son comunes hoy en día, con procesos que van desde el diseño hasta el desarrollo, las pruebas, el lanzamiento, las operaciones y el mantenimiento claramente delimitados. De hecho, en algunos casos están dejando de existir los laboratorios dedicados, ya que su configuración y funcionamiento suponen un alto coste.

Pero lo que es más importante, podríamos ver cómo muchos de los procesos y funciones actuales se fusionan y se transforman en una nueva cadena de producción en la que el desarrollador es tan responsable del funcionamiento de un servicio como lo son los responsables de operaciones. Lo ideal es que  haya la máxima confianza y corresponsabilidad, una filosofía de trabajo que aspire a que las cosas funcionen y a que los lanzamientos se produzcan con agilidad, independientemente del rol de cada uno en la compañía. Debería ser posible solicitar a un desarrollador que participe en las operaciones o los servicios de software que él mismo haya creado, algo que aumentaría el sentido de responsabilidad compartida.

¿Por dónde comenzar la transformación?

DevOps viene de la unión de "Desarrollo de Software" y "Operaciones TI", y nació como una respuesta a la cultura agile y sus múltiples metodologías. Con DevOps se adquiere una visión holística del desarrollo e implementación del software, para convertirlos en una cultura y en una forma de crear y desplegar código incorporando la iteración y retroalimentación continua.

¿No es eso lo que un operador móvil moderno necesita? Creo que sí. Ahora bien, ¿por dónde empezar? Pues tal como yo lo veo, la automatización de pruebas podría ser un comienzo inteligente a partir del cual poder expandir la consecuente transformación. Lo ideal sería que los CSPs implementaran una herramienta de orquestación de pruebas para sus laboratorios con la que pudieran mapear la topología de los mismos, incluyendo recursos físicos, virtuales y activos -tales como nodos-, además de equipos de prueba, funciones de red virtual (NFV), conexiones y recursos humanos, como testers.

En este punto, existen tres aspectos clave a tener en cuenta antes de embarcarse en un proyecto de automatización:

1 - Automatizar todo

El primer paso es adoptar el enfoque DevOps a través de la automatización de procedimientos. La intervención manual significa errores humanos, ineficiencia y tiempos desperdiciados. Un entorno de pruebas moderno debe tender al paradigma de la integración continua, y ahí no  caben procesos manuales innecesarios.

Todo comienza con la instalación del entorno y su configuración. Las pruebas son, a menudo, intrusivas, y pueden llegar a dañar la configuración, dejando inutilizables las infraestructuras para pruebas posteriores. Eso supone la necesidad de reinstalaciones frecuentes desde cero, a fin de asegurar entornos limpios para nuevas pruebas. Por lo tanto, este debe ser uno de los primeros elementos en los que intervenir. La experiencia nos ha demostrado que en proyectos de despliegue de laboratorios con cierta complejidad el tiempo de reinstalación de los entornos puede pasar de una semana a cinco horas, lo que supone una mejora en la eficiencia del 97%.

Además, con la automatización de procesos no sólo se mejoraran los entornos de laboratorio, sino que también se puede proporcionar a los clientes las herramientas necesarias para que sus despliegues resulten más sencillos, elegantes y  robustos. Esto es especialmente relevante en entornos en la  nube en los que no solo se incluye en el proceso la capa de software tradicional, sino también la definición y despliegue de la infraestructura definida por software.

2 - La monitorización centralizada permite focalizarse en tareas de valor añadido

La migración de los procedimientos de pruebas manuales tradicionales se logra capturando los logs generados por cada paso individual que, una vez incluidos en la herramienta de automatización, pueden ser incorporados a un servidor de logs centralizado.

Cuando los procesos de automatización de pruebas se desarrollan sobre entornos virtualizados o en la nube, la naturaleza especialmente volátil en este tipo de infraestructuras hace que este servidor de logs centralizado sea mucho más crítico, pues sin él, las trazas de los eventuales errores se eliminarían junto con todo el entorno de pruebas.

Disponer de toda la información relevante almacenada en un servidor significa que el análisis de los resultados de las baterías de pruebas no va a tener que realizarse in situ. Eso permite reutilizar los recursos de forma inmediata, cambiar el enfoque y priorizar  tareas de más valor,  lo que ya supone una mejora de la productividad.

En una configuración de pruebas automatizada, cada paso se captura a medida que se ejecutan las pruebas. Por lo tanto, se proporciona automáticamente una traza completa para el posterior diagnóstico y optimización. Además, esta característica puede configurarse para que esté disponible para todos los miembros del equipo de pruebas, que podrían estar trabajando desde diferentes ubicaciones. Eso les permite centrarse en la colaboración del equipo y compartir sus mejores prácticas de manera eficiente, todo en línea con la cultura DevOps.

3 - Conozca sus fuerzas y limitaciones

Esa centralización inicial de la información permite realizar un análisis de registros de forma algorítmica en las fases posteriores de la automatización de pruebas. Esto no sólo posibilita la automatización del análisis de los resultados de pruebas, sino también el análisis de causa raíz impulsado por analíticas avanzadas basadas en técnicas de machine learning e inteligencia artificial. Asimismo, también proporcionará información estadística de valor sobre multitud de problemas, desde puntos comunes de error, uso de recursos o consumo de tiempo de los diferentes canales de prueba, lo que a posteriori permitiría mejorar y optimizar el rendimiento de las baterías de pruebas.

Una comprensión profunda del nivel de intrusividad y de las necesidades de recursos para cada uno de los canales de prueba permite adicionalmente aprovechar de forma óptima el uso de las instalaciones de prueba las 24 horas y siete días por semana.

Innovar y lanzar nuevos productos con mayor rapidez

Con la implementación de un entorno de pruebas automatizado se conseguirán importantes ahorros de tiempo y costes. Eso es porque las pruebas podrán llevarse a cabo en etapas mucho más tempranas del proceso de desarrollo del producto, lo que permite, por ejemplo, incrementar la frecuencia de liberación de productos y actualizaciones integrando conjuntos mínimos de mejoras o nuevas funcionalidades. Cualquier CSP que adopte la cultura y los procesos DevOps en su departamento de pruebas no solo verá cómo se incrementa la productividad en esta área, sino que también será capaz de acelerar el proceso de innovación en sí. Esto resultará en una mejora del “time to market” y en la capacidad real de dar respuesta a las cambiantes demandas del mercado.

Las nuevas versiones de los servicios existentes podrían basarse en un 95% en el servicio original, incorporando solo actualizaciones menores, pero mucho más frecuentes y graduales, algo también necesario si los CSPs desean poder responder eficazmente a las demandas del estilo de vida digital “siempre conectado”.

A partir de aquí, los equipos de pruebas podrían comenzar a enseñar a otros departamentos cómo introducir la automatización y el enfoque DevOps con éxito, ayudando al resto de la organización a transformarse.

Llegados a este punto, solo cabe preguntarse si los CSP pueden permitirse el lujo de no introducir la automatización en sus procesos de pruebas a través de un enfoque DevOps.

El artículo ha sido escrito por Pablo Manuel García, solutions architect de Blue Telecom Consulting