Français
Deutsch
English
Español
Per Infomaniak, l’innovazione non significa solo creare nuovi prodotti performanti, ma renderli anche più efficienti, sostenibili e responsabili. In questo articolo, i nostri ingegneri Matthieu e Tristan raccontano come hanno ripensato Custom Brand, una funzionalità di kSuite che permette alle aziende di usare i propri strumenti di collaborazione online (Messaggistica istantanea, Drive, Mail, Calendario, ecc.) con il proprio dominio e la propria identità visiva. Grazie a Go, a Kubernetes e a un approccio di eco-design, il servizio è passato da 2 855 pod a soli 2, diventando al tempo stesso più affidabile, più scalabile e più sostenibile.
Di Tristan Smagghe (Software Engineer) e Matthieu Mabillard (Engineering Manager) di Infomaniak.
Perché cambiare?
All’inizio si trattava di un nuovo servizio, lanciato con pochissimi utenti. L’obiettivo era offrire un modo semplice per personalizzare le applicazioni kSuite con il proprio dominio (ksuite.tuo-dominio.com invece di ksuite.infomaniak.com).
L’architettura scelta era volutamente semplice: un cliente = un pod Kubernetes, con un server Apache incaricato di riscrivere gli indirizzi e fare da ponte tra i domini dei clienti e le applicazioni kSuite.
Questo modello ha funzionato bene all’inizio, ma con l’adozione rapida di questa funzionalità di personalizzazione da parte delle aziende sono emersi dei limiti:
- Migliaia di pod da gestire
- Grandi quantità di risorse CPU e RAM riservate ma inutilizzate
- Un sistema di monitoraggio saturo, fino a risultare fortemente perturbato
- Il team di reperibilità regolarmente svegliato durante la notte
In altre parole, ciò che all’inizio sembrava robusto è diventato un ostacolo.
Il nuovo approccio: condividere, semplificare e modernizzare
L’idea centrale della riformulazione è stata semplice: condividere ciò che era duplicato. Invece di un pod Kubernetes per cliente, ora bastano pochi pod per gestire centinaia di istanze personalizzate.
Per riuscirci, abbiamo riscritto il sistema in Go, un linguaggio pensato per le prestazioni e la concorrenza. Adesso, ogni pod si comporta come un reverse proxy intelligente, capace di instradare dinamicamente le richieste in base al traffico e di adattarsi automaticamente al carico.
L’infrastruttura non è più rigida: si auto-adatta. Nei periodi di bassa attività bastano pochi pod; durante i picchi di massima attività, Kubernetes ne distribuisce altri, per poi rilasciarli. Questa elasticità permette di usare solo le risorse necessarie al momento giusto.
Un altro cambiamento importante riguarda la configurazione e la gestione dei certificati SSL/TLS, che sono stati centralizzati. Questo semplifica l’amministrazione, migliora la sicurezza e rende gli aggiornamenti più semplici.
«Siamo passati da un sistema rigido e costoso a un modello agile, scalabile e sobrio», riassume Matthieu Mabillard, Engineering Manager di Infomaniak.
I risultati parlano da soli
Oltre all’impressionante riduzione delle risorse, la riformulazione ha portato un vero guadagno operativo. Anche se le richieste non vengono elaborate più velocemente di prima, abbiamo migliorato le prestazioni riguardanti le operazioni di manutenzione, le implementazioni e le capacità di far evolvere il servizio senza rischi.
Monitoraggio Grafana del numero di pod necessari in tempo reale dopo la migrazione
- Pod Kubernetes: da 2 855 a ~2 in media (-99,93%)
- RAM riservata: da 748 GB a ~2 GB (-99,73%)
- CPU riservata: da 28,55 a ~0,2 (-99,30%)
- Monitoraggio ripristinato e reso affidabile
- Compatibilità multi-cluster e preparazione per il multi-datacenter
Queste crescite in termini di efficienza non si limitano alle prestazioni. Permettono di riallocare le risorse verso altri progetti strategici, riducendo in modo significativo l’impronta di carbonio complessiva dell’infrastruttura.
Un impatto diretto su ecologia e affidabilità
Meno server, meno calore generato, meno energia consumata. Al di là dei numeri, si tratta di un vero approccio di eco-design: pensare ai consumi fin dalla progettazione del servizio.
Prima della riformulazione, il monitoraggio non riusciva più a stare al passo. Oggi abbiamo una visione chiara di ogni richiesta: quante risorse vengono utilizzate, quali componenti ne consumano di più e dove intervenire per continuare a migliorare.
Questa visibilità ci permette di regolare continuamente e di anticipare i bisogni senza compromettere la stabilità.
Una migrazione totalmente trasparente
La migrazione è stata realizzata in modo progressivo, iniziando dai nostri servizi interni. Grazie a un approccio canary, il passaggio è stato trasparente: nessuna interruzione significativa e nessuna perdita di performance lato utente.
Nel giro di una settimana, l’intero servizio è passato alla nuova architettura, con un solo piccolo incidente risolto rapidamente. Il risultato: una riformulazione invisibile per gli utenti, ma spettacolare per i team tecnici.
5 consigli per evitare il debito tecnico
Meno server, meno calore generato, meno energia consumata. Al di là dei numeri, si tratta di un vero approccio di eco-design: pensare ai consumi fin dall’inizio del servizio.
Questa riformulazione mette in evidenza alcune buone pratiche:
1. Condividere ciò che può esserlo
Lo scaling orizzontale non è un problema di per sé, deve solo essere progettato in modo intelligente. Nella vecchia architettura, ogni cliente era isolato nel proprio pod. Nella nuova versione lo scaling orizzontale esiste ancora, ma i clienti condividono le risorse, il che permette di scalare in modo molto più efficiente.
2. Non sovra-progettare al momento del lancio
Ma prevedere una traiettoria di evoluzione. L’eco-design è spesso la conseguenza logica di una buona architettura, non uno sforzo separato.
3. Scegliere la tecnologia giusta per un buon utilizzo
Apache/PHP aveva senso per partire velocemente, ma in questo contesto Go si è dimostrato molto più efficace su larga scala.
4. Centralizzare configurazione e monitoraggio
Per evitare di operare alla cieca. È impossibile ottimizzare senza capire cosa succede realmente.
5. Favorire migrazioni progressive
Canary, feature flag e implementazioni incrementali riducono i rischi e accelerano l’apprendimento.
Un’avventura umana e una svolta culturale
Questo progetto ha anche una forte dimensione umana. È stato affidato a Tristan Smagghe, allora stagista. Guidato da Matthieu e dai team, ha portato avanti questa riformulazione dall’inizio alla fine. Assunto in seguito, oggi lavora sulla nostra nuova piattaforma di hosting basata su Node.js e Go, che sarà il fondamento della futura offerta WordPress ottimizzata di Infomaniak.
«Questo progetto dimostra che uno stagista ben affiancato può avere un vero impatto. Da Infomaniak non forniamo solo modelli da testare, ma infrastrutture da far evolvere», sottolinea Matthieu Mabillard.
Questa trasformazione si inserisce anche in un cambiamento culturale più ampio. Storicamente eravamo concentrati su Laravel/PHP e Angular, ma oggi abbiamo le dimensioni e le competenze per usare il linguaggio giusto per il giusto utilizzo: Go per il cloud, Node.js per il tempo reale e PHP, che resta un linguaggio strategico, affidabile e maturo.
Questo approccio ci permette di allineare le nostre ambizioni tecniche con i nostri valori: efficienza, sostenibilità e sovranità.
Conclusione
Ridurre di cento volte l’impronta di un’infrastruttura senza sacrificare le prestazioni non è un miracolo: è il risultato di un’architettura ripensata, di un team coinvolto e di una visione a lungo termine. È anche la prova che l’eco-design non è un compromesso, ma una fonte di innovazione.
Questa riformulazione ci permette di continuare la nostra missione: costruire un cloud europeo etico, performante e rispettoso dell’ambiente.
