Software Evaluation: am Beispiel Loadbalancer
Interview mit Ibrahim Takouna, Research & Development, zur Weiterentwicklung des gridscale Loadbalancer-as-a-Service. Dabei wurde auch die Software selbst auf den Prüfstand gestellt.
As a Service bedeutet: Wir kümmern uns darum. Auf unserer Cloud Plattform laufen eine ganze Reihe von Services und Diensten, die ihr mit wenigen Klicks aktivieren und nutzen können. Mehr wollen die meisten Kunden damit auch nicht zu tun haben.
Damit unsere Infrastruktur so schnell und fehlerfrei läuft, wie ihr das von uns erwarten könnt, ist eine Menge Entwicklungsarbeit notwendig. Wir wissen, welche Services und Möglichkeiten wir in den kommenden Jahren noch umsetzen wollen. Jede Entscheidung, die wir heute treffen, ist deshalb immer auch eine Entscheidung darüber, was in Zukunft möglich sein wird. Besser also, man denkt genau nach, bevor man sich für eine Alternative entscheidet.
Einer der Menschen, die bei uns für dieses Nachdenken und Bewerten zuständig sind, ist Ibrahim Takouna, unser Research & Development Engineer.
Ibrahim, du hast das Projekt geleitet. Was war der Auslöser, sich einmal grundlegend mit unserem Loadbalancer zu beschäftigen?
Der Loadbalancer-as-a-Service ist ein wichtiger Bestandteil unseres Produktportfolios. Um seine Stabilität, Geschwindigkeit und Sicherheit weiter zu erhöhen, veränderten wir im letzten Jahr die darunterliegende Architektur. Nun hat jeder Kunde seine eigenen getrennten Loadbalancer auf dem eigenen Server. Im Zuge dieses Umstellungsprozesses haben wir uns auch Gedanken darüber gemacht, welche Anforderungen wir in Zukunft abdecken wollen. Passt unser aktueller Loadbalancer noch zu unserer Roadmap und unseren Zielen? Wird er den Anforderungen zukünftiger Produktbausteinen gerecht? Das wollten wir überprüfen.
Welche Software hast du verglichen und wie seid ihr vorgegangen?
Wir haben uns die drei Loadbalancer Lösungen Traefik, Envoy und HAProxy angesehen. HAProxy ist die Software, die wir bereits seit Jahren nutzen. Mit einem umfangreichen Anforderungskatalog haben wir die drei Loadbalancer getestet und verglichen. Danach haben wir die für uns optimale Lösung in die neue Struktur implementiert, wieder getestet und schließlich für unsere Infrastruktur freigegeben. Der letzte Schritt war dann die Migration in die neue Loadbalancer Architektur. Der ganze Prozess hat etwa ein halbes Jahr gedauert.
Für welchen Loadbalancer habt ihr euch entschieden und was waren die entscheidenden Kriterien?
HAProxy hat das Rennen gemacht. Ein wichtiger Grund war, dass die Data-Plane-API das dynamische Hinzufügen und Konfigurieren von Frontends, Backends und Traffic-Routing-Algorithmen ermöglicht. Außerdem bewältigt HAProxy auch großen Datenverkehr mit einer niedrigen Latenz. Die Software unterstützt SSL-Terminierung und Offloading sowie mehrere Protokolle und Routing-Algorithmen.
HAProxy lässt sich optimal in den aktuellen gridscale stack einbinden, vor allem integriert es sich komplett in Kubernetes. Kubernetes spielt in unserer Roadmap eine sehr wichtige Rolle. Wir wollen den Loadbalancer mit dem Kubernetes-Cluster für den Kunden verwalten.
Was war besonders schwierig oder spannend für dich bei diesem Projekt?
Eine Herausforderung lag zum Beispiel in der Implementierung des Certbot Service zur Handhabung von Let’s Encrypt Zertifikaten. Auch wollten wir unbedingt die Ressourcen der unterstützenden Dienste und Container auf ein Minimum beschränken, um zusätzliche Kosten zu vermeiden. Am Schluss war die nahtlose Migration der Legacy-LBaaS in die neue Architektur natürlich auch ein großer Schritt.