En Infomaniak, la innovación no consiste solo en crear nuevos productos de alto rendimiento, sino también en hacerlos más eficientes, más sostenibles y más responsables. En este artículo, nuestros ingenieros Matthieu y Tristan cuentan cómo rediseñaron Custom Brand, una funcionalidad de kSuite que permite a las empresas utilizar sus herramientas de colaboración en línea (mensajería instantánea, Drive, Mail, Calendario, etc.) con su propio dominio y su propia identidad visual. Gracias a Go, Kubernetes y a un enfoque de ecodiseño, el servicio ha pasado de 2855 pods a solo 2, y al mismo tiempo se ha vuelto más fiable, más escalable y más sostenible.

De Tristan Smagghe (Software Engineer) y Matthieu Mabillard (Engineering Manager) en Infomaniak.

¿Por qué cambiar?

Al principio se trataba de un servicio nuevo, con muy pocos usuarios. El objetivo era ofrecer una forma sencilla de personalizar las aplicaciones kSuite con un dominio proprio (ksuite.tu-dominio.com en lugar de ksuite.infomaniak.com).

La arquitectura elegida era deliberadamente sencilla: un cliente = un pod de Kubernetes, con un servidor Apache encargado de reescribir las direcciones y hacer de enlace entre los dominios de los clientes y las aplicaciones de kSuite.

Este modelo funcionó bien al principio, pero a medida que las empresas fueron adoptando rápidamente esta opción de personalización, empezaron a aparecer limitaciones: personalizar las aplicaciones kSuite con un dominio propio

  • Miles de pods que mantener
  • Grandes recursos de CPU y RAM reservados, pero sin uso
  • Un sistema de monitorización saturado, hasta el punto de verse seriamente afectado
  • El equipo de guardia que debía despertarse por la noche una y otra vez

En otras palabras, lo que parecía robusto al principio se convirtió en un freno al escalar.

El nuevo enfoque: unificar, simplificar y modernizar

La idea central del rediseño fue sencilla: unificar todo lo que estaba duplicado. En lugar de un pod de Kubernetes por cliente, ahora basta con unos cuantos pods para administrar cientos de instancias personalizadas.

Para conseguirlo, reescribimos el sistema en Go, un lenguaje diseñado para el rendimiento y la concurrencia. Cada pod actúa ahora como un reverse proxy inteligente, capaz de enrutar las peticiones de forma dinámica según el tráfico y de ajustarse automáticamente a la carga.

La infraestructura ya no es rígida: se autoajusta. En los periodos de baja actividad bastan unos pocos pods; en los picos de tráfico, Kubernetes despliega más y luego los libera. Esta elasticidad permite utilizar solo los recursos necesarios, en el momento adecuado.

Otro cambio importante ha sido la configuración y gestión de los certificados SSL/TLS, que se han centralizado. Esto simplifica la administración, mejora la seguridad y facilita las actualizaciones.

«Hemos pasado de un sistema rígido y costoso a un modelo ágil, escalable y ligero», resume Matthieu Mabillard, Engineering Manager en Infomaniak.

Los resultados hablan por sí solos

Más allá de la impresionante reducción de recursos, el rediseño ha aportado una verdadera ganancia operativa. Aunque las peticiones no se procesan más rápido que antes, hemos ganado en rendimiento en las operaciones de mantenimiento, en los despliegues y en la capacidad de hacer evolucionar el servicio sin riesgos.

Seguimiento en Grafana del número de pods necesarios en tiempo real tras la migración

  • Pods de Kubernetes: de 2855 a ~2 de media (-99,93%)
  • RAM reservada: de 748 GB a ~2 GB (-99,73%)
  • CPU reservada: de 28,55 a ~0,2 (-99,30%)
  • Monitorización restaurada y estabilizada
  • Compatibilidad multiclúster y preparación para varios data centers

Estas ganancias de eficiencia no se limitan al rendimiento. Permiten reasignar recursos a otros proyectos estratégicos y, al mismo tiempo, reducir de forma significativa la huella de carbono global de la infraestructura.

Un impacto directo en la ecología y la fiabilidad

Menos servidores, menos calor generado, menos energía consumida. Más allá de las cifras, se trata de un verdadero enfoque de ecodiseño: pensar en el consumo desde la propia concepción del servicio.

Antes del rediseño, la monitorización ya no podía seguir el ritmo. Hoy disponemos de una visión clara de cada petición: cuántos recursos utiliza, qué componentes consumen más y dónde actuar para seguir mejorando.

Esta visibilidad nos permite ajustar de forma continua y anticipar las necesidades sin poner en peligro la estabilidad.

Una migración totalmente transparente

La migración se realizó de forma progresiva, empezando por nuestros propios servicios internos. Gracias a un enfoque canary, el cambio fue transparente: sin interrupciones significativas y sin pérdida de rendimiento para quienes lo usaban.

En una semana, todo el servicio pasó a la nueva arquitectura, con un único incidente menor que se corrigió rápidamente. El resultado: un rediseño invisible para quien lo usa, pero espectacular para los equipos técnicos.

5 consejos para evitar la deuda técnica

Menos servidores, menos calor generado, menos energía consumida. Más allá de las cifras, se trata de un verdadero enfoque de ecodiseño: pensar en el consumo desde el inicio del servicio.

Este rediseño pone de relieve varias buenas prácticas:

1. Unificar todo lo que se pueda

El escalado horizontal no es un problema en sí mismo, solo tiene que estar bien diseñado. En la arquitectura anterior, cada cliente estaba aislado en su propio pod. En la nueva versión, el escalado horizontal sigue existiendo, pero ahora los clientes comparten recursos, lo que permite escalar de forma mucho más eficiente.

2. No sobrediseñar el lanzamiento

Pero sí prever una trayectoria de evolución. El ecodiseño suele ser la consecuencia lógica de una buena arquitectura, no un esfuerzo separado.

3. Elegir la tecnología adecuada para cada caso de uso

Tenía sentido usa Apache/PHP para lograr un arranque rápido, pero, en este contexto, Go ha demostrado ser mucho más eficaz a gran escala.

4. Centralizar la configuración y la monitorización

Para evitar operar sin una visión clara. Es imposible optimizar sin entender realmente lo que está ocurriendo.

5. Favorecer las migraciones progresivas

Los canary, los feature flags y los despliegues por fases reducen los riesgos y aceleran el aprendizaje.

Una aventura humana y un cambio cultural

Este proyecto también tiene una fuerte dimensión humana. Se confió a Tristan Smagghe, que en aquel momento estaba en prácticas. Guiado por Matthieu y por los equipos, llevó este rediseño de principio a fin. Desde que fue contratado, trabaja en nuestra nueva plataforma de alojamiento basada en Node.js y Go, que será la base de la futura oferta optimizada de WordPress de Infomaniak.

«Este proyecto deja claro que alguien en prácticas, con el apoyo adecuado, puede tener un impacto real. En Infomaniak no damos solo maquetas para probar, sino infraestructuras que hacer evolucionar», subraya Matthieu Mabillard.

Esta transformación forma parte también de un cambio cultural más amplio. Históricamente nos hemos centrado en Laravel/PHP y Angular, pero hoy tenemos el tamaño y las competencias para utilizar el lenguaje adecuado para cada uso: Go para el cloud, Node.js para el tiempo real y PHP, que sigue siendo un lenguaje estratégico, fiable y maduro.

Este enfoque nos permite adaptar nuestras ambiciones técnicas con nuestros valores: eficiencia, sostenibilidad y soberanía.

Conclusión

Reducir por cien la huella de una infraestructura sin sacrificar el rendimiento no es un milagro: es el resultado de una arquitectura revisada a fondo, de un equipo implicado y de una visión a largo plazo. También es la prueba de que el ecodiseño no es un compromiso, sino una fuente de innovación.

Este rediseño nos permite seguir con nuestra misión: construir un cloud europea ético, de alto rendimiento y respetuoso con el medio ambiente.

Más información