CIO: Dirige el Centro de Excelencia en la Nube de Betclic. ¿En qué consiste exactamente?

Guillermo Lannebère: En 2018 tomamos la decisión de pasarnos a la nube y en 2020 empezamos a hacerlo. Empezamos la migración con AWS durante el primer confinamiento y la implementación tardó dos años. En aquel momento solo teníamos un proveedor, pero hoy también utilizamos Azure de Microsoft. Y hace dos años se creó el Cloud Center of Excellence (CCoE) para apoyar a todos los equipos de TI en la transición a la nube. Somos un equipo de 5 personas dentro de un departamento de TI que cuenta con unas 400 personas. En total, Betclic emplea a unas 1200 personas, internas y externas, con una facturación de más de mil millones de euros. La mayor parte de la plantilla es de TI.

¿Entonces ya casi terminaste con la migración a la nube hoy?

De hecho, nos hemos comprometido a abandonar por completo el modelo local para finales de 2024 y estamos terminando la migración de nuestros proyectos entre AWS y Azure. Antes, teníamos 3 centros de datos y AWS, que tratábamos como un cuarto centro de datos, de alguna manera. Para pasar a la nube, "rediseñábamos" nuestra plataforma para satisfacer las necesidades de nuestro negocio, que están evolucionando. Por eso, adoptamos un enfoque de microservicios con mucha asincronía para gestionar los picos de carga. En realidad, se trata de "escalar" e ir mucho más rápido para adaptarnos a la actividad en nuestra plataforma. Me refiero a cómo gestionamos el tráfico durante un evento excepcional como un Mundial o la Eurocopa de fútbol, ​​como ahora mismo.

¿Por qué elegiste dos proveedores?

Por supuesto, para no poner todos los huevos en la misma cesta, pero también nos permitirá beneficiarnos de lo mejor de ambos mundos. Podemos utilizar los servicios gestionados de AWS y los servicios gestionados de Azure. Y, además, empezamos con AWS, pero resulta que tenemos un gran legado de Microsoft: una gran base de datos SQL Server y mucho .Net. Como tenemos un programa de migración a la nube muy ambicioso, Azure nos permitirá no tener que rediseñar todas las aplicaciones. Microsoft gestiona SQL Server mucho mejor que AWS, por ejemplo. Nuestra idea es también elegir el proveedor de nube adecuado para el uso adecuado.

La plataforma online Betclic.

Con Azure haremos rehosting, o incluso lift and shift. Esta última opción la utilizaremos para pago, por ejemplo, cuya arquitectura ya está adaptada. El módulo ya está desarrollado con herramientas de Microsoft, es más fácil hacerlo compatible con Azure.

¿Y qué pasa con tu negocio principal, las apuestas deportivas?

El tráfico en la parte directamente relacionada con el deporte es a la vez previsible e imprevisible. Por ejemplo, sé que la selección francesa va a jugar esta noche. Sé la hora de inicio del partido y aproximadamente la hora de finalización, con o sin prórroga. En cambio, el resultado y la fisonomía del partido no son previsibles. Si nuestros jugadores ganan, todos se conectarán al final del partido y todos ganarán dinero, pero por el contrario, por desgracia, si el resultado es desfavorable, nuestros clientes se conectarán menos porque saben que han perdido. Y esta es la parte que no es en absoluto previsible. Esta parte "deportiva" está en AWS, porque necesita precisamente esta adaptabilidad, esta escalabilidad.

Para los juegos de casino también necesitamos escalabilidad, pero de una forma un poco menos lineal. Los comportamientos son más similares a los que se observan en los sitios de comercio electrónico. Los usuarios jugarán cuando lleguen a casa del trabajo por la noche hasta la hora de dormir. Mucho menos durante el día o los fines de semana, por ejemplo. Es una actividad más predecible, por eso la alojamos en Azure. Lo mismo ocurre con el inicio de sesión, también en Azure. Cuando uno de nuestros clientes gana, lo primero que hace es iniciar sesión para recibir el pago.

¿Es también porque tienes muy pocas actividades predecibles que has desarrollado tu propio calendario de escalamiento?

Tenemos Adoptamos este calendario de colores específico para nuestra actividad.En AWS o Azure, el principio es el mismo, porque nuestro tráfico no es completamente predecible y nuestros picos de carga llegan en apenas unos segundos. Por eso no podemos trabajar con los cambios automáticos de un proveedor. Nos basamos en colores. Está inspirado en nuestro marketing en Betclic, que siempre habla de semanas verdes, rojas o negras. Hicimos lo mismo en el lado de TI y hablamos de escalar en verde, rojo o negro. Por ejemplo, durante el día, entre las 8:00 y las 18:00, sabemos que no se juegan partidos de fútbol, ​​por lo que estamos en verde. Nuestra cantidad de instancias estará en el nivel más bajo porque no hay mucha actividad.

Por otro lado, si durante el Mundial hay un partido de Francia programado por la noche, nos apagaremos a las 19:00, es decir, pasaremos de 3 a 50 máquinas. Siempre tomamos un pequeño margen. Al final del partido, el árbitro pita y cada uno coge su aplicación para comprobar si ha ganado o perdido. No sabemos exactamente cuándo pitará el árbitro, aunque tenemos una idea de la franja horaria en la que lo hará. Sabemos aproximadamente la duración del partido, pero dentro de esta duración, nada es previsible. Sabemos que, por ejemplo, de 20:00 a 23:30, tendremos que ser reactivos, pero que a partir de las 23:30, de repente, el tráfico bajará porque los usuarios estarán dormidos. Cambiamos de color de media hora a una hora antes del partido y hasta media hora a una hora después, para tener en cuenta los posibles goles o la prórroga.

¿A qué corresponden estos colores?

Precisamente, hemos optado por colores y no directamente números, precisamente para probar los valores límite que necesitamos. Si un servicio empieza a llamar a muchos otros servicios a su vez, en realidad colapsará estos servicios relacionados. Los colores nos permiten mantener un punto de vista global, para probar el color asociado a un valor y estar seguros del impacto global en Betclic.

Los colores corresponden a la cantidad máxima de instancias. Dependerá del servicio que se use, pero generalmente son 3 instancias para el verde. El negro estará en un rango alrededor de 50 o más, y el rojo en un punto intermedio. Pero es más un porcentaje. Para algunos servicios, el negro podría corresponder a 10 instancias. También hacemos escalado en bases de datos. En el verde, solo necesitamos una base con poca potencia. Para procesar grandes volúmenes, en cambio, tendremos algo mucho más potente.

¿Ya has medido ciertos indicadores desde tu paso a la nube, como el aumento de la productividad, la eficiencia en relación con los clientes, la reducción de costos...?

Es demasiado pronto, sobre todo porque pasamos directamente de on-premise a la nube y no sabemos el coste on-premise. Por otro lado, hacemos finops, gestión de costes y control de costes. Nos ha preocupado esto desde el principio. Es una parte integral de la gestión de nuestro enfoque de escalado. Por ejemplo, analizamos si estamos tomando demasiado margen o no. Porque claro, al principio, los equipos la mayoría de las veces eligen una configuración negra cuando con roja sería suficiente. Son elementos que monitorizamos, pero sin métricas comparativas, porque llegamos a la nube con hábitos que vienen de on-premise.

Precisamente, ¿colaboras en el control de costes con tu CFO?

Sí, hemos trabajado mucho nada más pasarnos a la nube hace 4 años. Formamos directamente a los equipos de CFO y de control de gestión. Pasamos por Gekko (ahora Accenture), un partner de AWS. Los equipos de finanzas tienen acceso a nuestras plataformas AWS y Azure. Ellos dan formato a su propio cuadro de mando y hablo con ellos al menos una vez al mes para estudiar los costes. Pero también para que entiendan técnicamente por qué a veces vemos desbordamientos. La nube no perdona cuando cometes un error, pero lo importante es reaccionar a tiempo. Y explicar lo que ha pasado. Lo que llamamos error en este caso sería, por ejemplo, un desarrollador que activa un servicio pero se olvida de desactivarlo. Lo que puede salir caro rápidamente en la nube. Hemos puesto en marcha mecanismos de alerta.

¿Ha desarrollado un método específico para medir los costes?

Hemos definido un marco de trabajo para todos los nuevos proyectos que se nos presentan en el CCoE, para pasar a la nube. Preguntamos al equipo interesado qué arquitectura, qué servicios van a utilizar, cómo han pensado en seguridad, resiliencia, escalabilidad, backup, en fin, todo lo que hoy está incluido en los pilares del Well Architectured Framework de Microsoft y Amazon. Todo ello con una calculadora de costes.

A partir de estos elementos, etiqueto su servicio y hago un seguimiento con todos los equipos cada dos semanas. A veces, un equipo se asusta un poco y comienza su proyecto con demasiados recursos reservados. Si son demasiado altos en términos de costos, analizamos con ellos y tratamos de entender las razones de su cálculo de costos.

¿Significa esto que tenéis habilidades puras de finops en vuestros equipos?

Dentro del CCoE, sólo tenemos competencias informáticas, pero que dominan a la perfección la nube en todas sus vertientes y conocen muy bien a los proveedores. Tenemos desarrolladores, gente que viene de infraestructura, arquitectos de TI, etc. El CCoE son competencias cloud, finops, greenops, etc. Y nuestro papel es definir las mejores prácticas en cuanto al uso de la nube.