La virtualización y las licencias flexibles impulsan la profunda modernización de CSG

La mayoría de las empresas están inmersas en un proceso de transformación de sus operaciones de TI: de entornos locales a la nube y de infraestructuras físicas a virtuales. Además, con la llegada de la COVID-19, prácticamente todas las empresas están acelerando su proceso de modernización.

Este es el caso de CSG, una empresa con 35 años de trayectoria que presta servicios de interacción con el cliente para los sectores de las telecomunicaciones y la televisión por cable. La empresa proporciona a los mayores proveedores de televisión por cable de Norteamérica soluciones digitales para gestionar de forma más eficiente las relaciones con los clientes, la facturación y las operaciones.

Hace unos años, CSG se veía lastrada por las limitaciones de unos procesos obsoletos, agravadas por la falta de implicación de los nuevos responsables de las aplicaciones. Al igual que CSG ayuda a sus clientes a modernizarse, había llegado el momento de transformar sus propias operaciones.

A Erica Morrison, vicepresidenta de ingeniería de software de CSG, se le encomendó ayudar al equipo de Ingeniería Operativa de CSG a establecer una organización y una cultura DevOps, a pesar de que hasta entonces solo había trabajado en el ámbito del software.

«Para un desarrollador, verse de repente inmerso en el mundo de las operaciones y conocer de primera mano los retos a los que se enfrentan supone un auténtico choque», afirma. «Sin duda, me hizo valorar mucho más todo lo que hacen nuestros equipos de operaciones».

La incorporación de las mejores prácticas de desarrollo a un equipo que históricamente se había dedicado exclusivamente a las operaciones permitió a CSG afrontar numerosos retos: aprovechar funcionalidades de F5 que no había utilizado anteriormente, incorporar nuevas herramientas y adoptar un acuerdo de licencias empresariales que proporcionaba la flexibilidad necesaria.

Una serie de desafíos

Erin Garrigan era por aquel entonces la scrum master del equipo. Ahora, como supervisora, recuerda varias iniciativas que, en conjunto, conformaban lo que CSG concibió en 2016 como un plan a cinco o incluso diez años.

«Desde un punto de vista técnico, teníamos demasiados procesos manuales relacionados con los cambios y no contábamos con suficiente visibilidad sobre quién hacía qué», afirma. «Muchos equipos distintos tenían acceso a nuestros dispositivos y no disponíamos de los controles sólidos que necesitábamos para gestionarlo».

Estos no eran los únicos problemas. Había inestabilidad en toda la infraestructura y, debido a la falta de supervisión general del estado y de alertas, el equipo a menudo no sabía que los dispositivos se encontraban en mal estado hasta que los clientes informaban de los problemas. Modernizar el hardware era otra cuestión importante.

Transformación mediante la infraestructura como código

El primer proyecto del equipo, y también el de mayor envergadura, consistió en trasladarlo todo a código fuente mediante F5 iApps. Dado que los procesos de CSG habían sido manuales, comenzaron implantando una exportación nocturna de las configuraciones de los dispositivos, lo que permitió al equipo tener visibilidad sobre ellas. Con el tiempo, evolucionaron hacia un nuevo paradigma en el que el código fuente determina ahora lo que hay en los dispositivos.

«En un año creamos más de 100 iApps a partir de cambios manuales y del concepto de infraestructura como código», afirma Garrigan. «El enorme esfuerzo necesario para convertir en código cada configuración manual mediante iApps fue considerable, pero creamos algunas herramientas y fuimos abordando la tarea poco a poco».

Con la infraestructura ya definida como código, el equipo pudo separar las funciones de sus aplicaciones. El equipo de Ingeniería de Operaciones presta asistencia a decenas de equipos de aplicaciones en un entorno de servidores dinámico que recibe varias solicitudes de cambio al día. La implantación de un proceso de autoservicio permitió a los usuarios internos de los equipos de aplicaciones de CSG utilizar un dispositivo BIG-IP de entorno aislado para configurar los cambios, comprobarlos y enviarlos a través de un flujo de trabajo para su validación y revisión del código. También crearon otra herramienta que permite a esos usuarios implementar los cambios en producción por sí mismos.

«En ese momento, lo que ofrecíamos realmente era el balanceo de carga y la entrega de aplicaciones como servicio», afirma Phil Todd, director de desarrollo de software de CSG. «Utilizamos Jenkins para gestionar la mayoría de nuestras funciones de autoservicio de automatización, así como las de generación de informes. Además, hemos escrito parte de nuestro propio código en C# para implementar esa funcionalidad entre bastidores».

Visibilidad y gestión de cambios con BIG-IQ

Dar visibilidad a esos cambios era otra necesidad fundamental en el amplio y diverso conjunto de aplicaciones de CSG. En el entorno manual anterior, los equipos de aplicaciones podían interferir entre sí al realizar cambios que se solapaban. Localizar código defectuoso era un rompecabezas más complejo de lo necesario.

«Simplemente había algo raro en el entorno», afirma Garrigan. «No sabíamos por qué no funcionaba bien; solo que alguien debía de haber hecho algo».

Los procesos manuales también implicaban que, una vez identificado un problema, el equipo a menudo tenía que localizar a la persona que había realizado el cambio para comprenderlo por completo.

Para resolver el problema, el equipo implementó F5 BIG-IQ y comenzó a transformar el propio proceso de gestión de cambios mediante la introducción de informes automatizados sobre el estado del sistema y el impacto general de los cambios. También creó un panel de Grafana para supervisar más de mil puntos finales y facilitar la validación de los cambios. Al disponer de la configuración como código, junto con la automatización de los despliegues, CSG pudo obtener una visibilidad real de todos los cambios realizados.

Según Todd, esto ha dado lugar a una de las mayores diferencias entre el entorno actual de CSG y los procesos manuales que utilizaban en el pasado: si un cambio provoca algún fallo, el tiempo medio de reparación puede ser ahora de minutos, mientras que antes podía ser de horas mientras el equipo investigaba y resolvía el problema.

«Al iniciar sesión en Kibana, quedan registrados todos los cambios: qué versión se desplegó y cuál era la versión anterior», explica. «Así, en lugar de quedarnos ahí preguntándonos por qué no funciona, simplemente desplegamos la versión anterior del código pulsando un botón en Jenkins».

La virtualización es clave

El siguiente paso en la evolución consistió en abordar la escalabilidad, la flexibilidad y la estabilidad de la infraestructura. Aunque utilizaban decenas de dispositivos físicos de hardware, incluidos F5 VIPRION, la mayoría de las aplicaciones pasaban únicamente por dos de ellos: uno para el tráfico externo procedente de Internet y otro para el tráfico interno.

Esto dio lugar a grupos de gran tamaño, lo que suponía un mayor riesgo para la organización en caso de fallo. «Si uno de esos dispositivos dejaba de funcionar, afectaba prácticamente a todos los productos y a todos los clientes», afirma Todd.

Al mismo tiempo, las aplicaciones de CSG estaban empezando a trasladarse tanto a la nube privada de la empresa como a nubes públicas, pero el sistema ofrecía una capacidad limitada para expandirse a esos entornos y no permitía la migración a AWS.

La virtualización también fue fundamental para abordar estos problemas. Disponer de infraestructura como código en iApps proporcionó la flexibilidad necesaria para reducir el tamaño total de los grupos de fallos y, de este modo, establecer un equilibrio de carga más específico para cada aplicación. También abrió la puerta a una futura evolución hacia la nube pública cuando fuera necesario.

«Hace poco sufrimos una interrupción del servicio que afectó a un producto», afirma Morrison. «Hace poco más de un año, habría afectado a todos los productos. Al distribuir más instancias en grupos más pequeños, también tenemos la posibilidad de conmutar por error si es necesario, y el radio de impacto es muy reducido. Así que la inversión en estabilidad ya ha dado buenos resultados para nuestros clientes internos y externos».

Las licencias empresariales aportan la flexibilidad necesaria

CSG obtuvo una mayor flexibilidad operativa y redujo costes al pasar de F5 BIG-IP Virtual Editions a un nuevo acuerdo de licencias empresariales (ELA) de F5. Anteriormente, el grupo operaba principalmente desde un único centro de datos en la sede de la empresa en Omaha. Su solución de recuperación ante desastres consistía simplemente en poner en marcha sus servicios en un centro de datos de terceros si las circunstancias lo exigían.

Cuando el equipo puso en marcha un segundo centro de datos hace un par de años, pudo plantearse la implementación de alta disponibilidad entre ambos centros, pero el anterior acuerdo de licencia y el hardware físico limitaban sus opciones. Al contar con hardware fijo, la empresa se enfrentaba a dificultades en materia de escalabilidad, disponibilidad y capacidad de expansión a la nube pública.

«Pasarnos a un contrato de licencia empresarial de F5 y a la solución virtual nos dio la libertad de implementar lo que queramos, cuando queramos, y añadir ese segundo centro de datos», afirma Todd. «También nos ha dado la libertad de explorar nuevas posibilidades y responder con gran agilidad a las necesidades de nuestros clientes internos».

Hoy, el equipo dispone de mayor flexibilidad para evolucionar y garantizar una alta disponibilidad de diversos servicios.

De cara al futuro: entrega de aplicaciones en la nube

Tras modernizar su entorno, el equipo de Ingeniería de Operaciones de CSG dispone ahora de margen para planificar el futuro. El equipo quiere aprovechar aún más las capacidades de seguridad de F5, crear arquitecturas de referencia para el uso de BIG-IP y Amazon Web Services (AWS), e incorporar nuevas funcionalidades con NGINX. Además, gracias a un ELA, la empresa ha podido reasignar el presupuesto existente a nuevas arquitecturas y conjuntos de funcionalidades.

Morrison también está trabajando con los responsables de producto de CSG en una nueva hoja de ruta para seguir avanzando a partir de los logros alcanzados hasta ahora, mejorar la supervisión y las alertas del sistema, añadir nuevos monitores y desarrollar un modelo de centro de excelencia para la entrega de aplicaciones.

Desde una perspectiva global, afirma, es una situación muy favorable. A estas alturas, el equipo ha materializado casi todos los proyectos contemplados en su visión original a cinco años. Gracias a las alianzas, las funciones de autoservicio y las configuraciones que han desarrollado, solo queda otorgar a los propios equipos de aplicaciones un mayor control sobre ellas.

«Por primera vez nos preguntamos: “¿Y ahora qué hacemos?”», afirma. «Hemos avanzado tanto que ya no estamos intentando salir del atolladero. Ahora se trata de ser proactivos y seguir construyendo sobre los sólidos cimientos que hemos establecido».