Français
English
Italiano
Español
Bei Infomaniak bedeutet Innovation nicht nur, neue leistungsfähige Produkte zu entwickeln, sondern sie auch effizienter, nachhaltiger und verantwortungsvoller zu machen. In diesem Artikel erzählen unsere Ingenieure Matthieu und Tristan, wie sie Custom Brand, eine Funktion von kSuite, neu konzipiert haben. Damit können Unternehmen ihre Online-Collaboration-Tools (Instant Messaging, Drive, Mail, Kalender usw.) mit ihrer eigenen Domain und ihrem eigenen visuellen Auftritt nutzen. Dank Go, Kubernetes und eines Ökodesign-Ansatzes ist der Dienst von 2 855 Pods auf nur noch 2 Pods geschrumpft – und gleichzeitig zuverlässiger, skalierbarer und nachhaltiger geworden.
Von Tristan Smagghe (Software Engineer) und Matthieu Mabillard (Engineering Manager) bei Infomaniak.
Warum eine Veränderung?
Am Anfang handelte es sich um einen neuen Dienst, der mit sehr wenigen Nutzern gestartet war. Ziel war es, eine einfache Möglichkeit zu bieten, kSuite-Anwendungen mit der eigenen Domain zu personalisieren (ksuite.deine-domain.com statt ksuite.infomaniak.com).
Die gewählte Architektur war bewusst einfach: ein Kunde = ein Kubernetes-Pod, mit einem Apache-Server, der die Adressen umschreibt und die Kundendomains mit den kSuite-Anwendungen verbindet.
Dieses Modell funktionierte anfangs gut, aber mit der schnellen Verbreitung dieser Personalisierungsoption in Unternehmen traten Grenzen zutage:
- Tausende von Pods, die gewartet werden mussten
- Zahlreiche reservierte CPU- und RAM-Ressourcen, die ungenutzt blieben
- Ein überlastetes Monitoring, das dadurch stark beeinträchtigt war
- Ein Bereitschaftsteam, das nachts regelmässig geweckt wurde
Mit anderen Worten: Was anfangs robust wirkte, wurde beim Scaling zum Bremsklotz.
Der neue Ansatz: bündeln, vereinfachen und modernisieren
Die zentrale Idee des Neuaufbaus war einfach: alles bündeln, was dupliziert war. Statt eines Kubernetes-Pods pro Kunde genügen jetzt wenige Pods, um Hunderte personalisierter Instanzen zu betreiben.
Dafür haben wir das System in Go neu geschrieben, einer Sprache, die für Performance und Nebenläufigkeit entwickelt wurde. Jeder Pod fungiert jetzt als intelligenter Reverse Proxy, der Anfragen dynamisch je nach Traffic routet und sich automatisch an die Last anpasst.
Die Infrastruktur ist nicht mehr statisch: Sie passt sich selbst an. In Schwachlastphasen genügen wenige Pods; bei Spitzenlast stellt Kubernetes zusätzliche Pods bereit und baut sie danach wieder ab. Diese Elastizität ermöglicht es, genau so viele Ressourcen zu nutzen, wie zum jeweiligen Zeitpunkt nötig sind.
Eine weitere grosse Änderung: Die Konfiguration und Verwaltung der SSL/TLS-Zertifikate wurde zentralisiert. Das vereinfacht die Administration, erhöht die Sicherheit und erleichtert Updates.
„Wir sind von einem starren und teuren System zu einem agilen, skalierbaren und schlanken Modell übergegangen“, fasst Matthieu Mabillard, Engineering Manager bei Infomaniak, zusammen.
Die Ergebnisse sprechen für sich
Über die beeindruckende Reduktion der Ressourcen hinaus hat der Neuaufbau echte operative Vorteile gebracht. Auch wenn Requests nicht schneller verarbeitet werden als zuvor, haben wir bei Wartungsarbeiten, Deployments und der Fähigkeit, den Dienst ohne Risiko weiterzuentwickeln, deutlich an Performance gewonnen.
Grafana-Tracking der benötigten Pod-Anzahl in Echtzeit nach der Migration
- Kubernetes-Pods: von 2 855 auf ~2 im Durchschnitt (-99,93 %)
- Reservierter RAM: von 748 GB auf ~2 GB (-99,73 %)
- Reservierte CPU: von 28,55 auf ~0,2 (-99,30 %)
- Monitoring wiederhergestellt und stabilisiert
- Multi-Cluster-Kompatibilität und Vorbereitung auf Multi-Datacenter
Diese Effizienzgewinne beschränken sich nicht auf die Performance. Sie ermöglichen es, Ressourcen auf andere strategische Projekte umzuschichten und gleichzeitig den gesamten CO₂-Fussabdruck der Infrastruktur deutlich zu senken.
Direkte Auswirkungen auf Ökologie und Zuverlässigkeit
Weniger Server, weniger Abwärme, weniger Energieverbrauch. Hinter den Zahlen steht ein echter Ökodesign-Ansatz: den Verbrauch bereits bei der Konzeption des Dienstes mitzudenken.
Vor dem Neuaufbau kam das Monitoring nicht mehr hinterher. Heute haben wir eine klare Sicht auf jede Anfrage: wie viele Ressourcen sie benötigt, welche Komponenten am meisten verbrauchen und wo wir ansetzen können, um weiter zu optimieren.
Diese Transparenz ermöglicht es uns, kontinuierlich nachzusteuern und Bedarf vorauszusehen, ohne die Stabilität zu gefährden.
Eine vollkommen transparente Migration
Die Migration wurde schrittweise durchgeführt, beginnend mit unseren internen Diensten. Dank eines Canary-Ansatzes verlief der Wechsel transparent: keine nennenswerten Unterbrechungen und keine Performance-Verluste auf Nutzerseite.
Innerhalb einer Woche lief der gesamte Dienst auf der neuen Architektur, mit lediglich einem kleineren Zwischenfall, der schnell behoben war. Das Ergebnis: ein für Nutzer unsichtbarer, für die Technikteams jedoch spektakulärer Neuaufbau.
5 Tipps zur Vermeidung technischer Schulden
Weniger Server, weniger Abwärme, weniger Energieverbrauch. Hinter den Zahlen steht ein echter Ökodesign-Ansatz: den Verbrauch von Anfang an mitzudenken.
Dieser Neuaufbau macht mehrere Best Practices deutlich:
1. Bündeln, was gebündelt werden kann
Horizontales Scaling ist an sich kein Problem – es muss nur intelligent entworfen sein. In der alten Architektur war jeder Kunde in einem eigenen Pod isoliert. In der neuen Version gibt es weiterhin horizontales Scaling, aber die Kunden teilen sich nun die Ressourcen, was wesentlich effizienteres Scaling ermöglicht.
2. Zum Start nicht überdesignen
Aber eine Entwicklungsperspektive einplanen. Ökodesign ist oft die logische Folge einer guten Architektur, nicht ein separater Zusatzaufwand.
3. Die richtige Technologie für den richtigen Einsatzzweck wählen
Apache/PHP war sinnvoll, um schnell zu starten, aber Go hat sich in diesem Kontext im Grossbetrieb als deutlich effizienter erwiesen.
4. Konfiguration und Monitoring zentralisieren
Um nicht im Blindflug zu agieren. Optimieren ist unmöglich, wenn man nicht versteht, was tatsächlich passiert.
5. Schrittweise Migrationen bevorzugen
Canary-Releases, Feature Flags und inkrementelle Deployments senken das Risiko und beschleunigen das Lernen.
Ein menschliches Abenteuer und ein kultureller Wendepunkt
Dieses Projekt hat auch eine starke menschliche Komponente. Es wurde Tristan Smagghe übertragen, der damals Praktikant war. Unter der Leitung von Matthieu und den Teams hat er diesen Neuaufbau von Anfang bis Ende durchgeführt. Inzwischen fest angestellt, arbeitet er heute an unserer neuen Hosting-Plattform auf Basis von Node.js und Go, die das Fundament für das künftige optimierte WordPress-Angebot von Infomaniak bilden wird.
„Dieses Projekt zeigt, dass ein gut betreuter Praktikant echten Impact haben kann. Bei Infomaniak geben wir keine Mock-ups zum Testen, sondern Infrastrukturen, die weiterentwickelt werden sollen“, betont Matthieu Mabillard.
Diese Transformation ist auch Teil eines breiteren kulturellen Wandels. Historisch lagen unsere Schwerpunkte auf Laravel/PHP und Angular. Heute sind wir gross und erfahren genug, um die passende Sprache für den passenden Einsatzzweck zu wählen: Go für Cloud-Workloads, Node.js für Echtzeit-Anwendungen und PHP, das eine strategische, zuverlässige und ausgereifte Sprache bleibt.
Dieser Ansatz ermöglicht es uns, unsere technischen Ambitionen mit unseren Werten in Einklang zu bringen: Effizienz, Nachhaltigkeit und Unabhängigkeit.
Fazit
Den Infrastruktur-Fussabdruck um den Faktor 100 zu senken, ohne Performance einzubüssen, ist kein Wunder, sondern das Ergebnis einer neu gedachten Architektur, eines engagierten Teams und einer langfristigen Vision. Es ist auch ein Beleg dafür, dass Ökodesign kein Kompromiss ist, sondern eine Quelle für Innovation.
Dieser Neuaufbau ermöglicht es uns, unsere Mission weiterzuverfolgen: eine ethische, leistungsfähige und umweltfreundliche europäische Cloud aufzubauen.
Mehr erfahren
Photo Collect garantiert seine digitale Unabhängigkeit dank der Public Cloud von Infomaniak
Freitag 31 Oktober 2025
