Technical Blueprint — Low-Latency-SaaS-Infrastruktur

In diesem Artikel skizziere ich die technischen Hürden, vor denen jeder steht, der verteilte SaaS-Anwendungen mit niedriger Latenz umsetzen möchte – und wie sich diese Hürden zumindest teilweise meistern lassen.

Erfolgskriterien sind zustandsbehaftete Anwendungen mit der geringstmöglichen Latenz für eine Gruppe geografisch nah beieinander liegender Nutzer. Die Anwendung muss vom SaaS-Anbieter gehostet werden – aus zwei Gründen: zur Validierung der Berechnungen durch den Anbieter und für hohe Verfügbarkeit für alle Beteiligten.

Wie Sie sich denken können, wird dieses Problem aktuell auf mehreren Wegen angegangen: über Cloud-Anbieter, die Rechenleistung in einigen dicht besiedelten Regionen bereitstellen, über Content Delivery Networks, die Verbindungen in entlegenere Gebiete bringen, sowie über On-Premises-Standorte in Regionen, die Cloud-Anbieter nicht abdecken.

Ein solches System aufzubauen und zu betreiben, ist allerdings ein Kraftakt, den nur die größten Unternehmen wie Valve auf sich nehmen. Das könnte sich bald ändern – und ich zeige Ihnen, wie.

Die harte Grenze für Low-Latency-Anwendungen sind physische Netzwerke. CDNs eignen sich zwar hervorragend, um Verbindungen zwischen vielen Anbietern herzustellen, doch die Nutzer bleiben weitgehend auf sich gestellt: Jeder zusätzliche Traffic-Hop erhöht die Latenz und nimmt ihnen ein hochwertiges Erlebnis. Das ist eine harte Grenze – in manchen Regionen lassen sich diese Probleme nur mit neuen Infrastrukturprojekten an Land und unter dem Meer lösen. Bahnbrechende Technologien wie Starlink schaffen Konnektivität auch in weit entlegenen Gebieten, doch ihre Latenz ist für Low-Latency-Anwendungen weiterhin zu hoch.

Eine weiche Grenze ist die Aufgabe, Traffic zwischen verschiedenen Cloud-Anbietern, CDNs und Hardware zu verknüpfen. Diese Hürde ist bereits genommen und frei verfügbar.

Um die harte Grenze aus Netzwerkgeschwindigkeit und Konnektivität zu überwinden, müssen wir SaaS-Anwendungen so nah wie möglich an den Nutzern hosten. Das kostet – und wirft die Frage auf, wie sich eine solche Infrastruktur steuern lässt.

Ein universeller Ansatz wäre ein Kubernetes-Cluster mit Nodes an vielen Standorten. Laut diesen Benchmarks liefen Container nur 0,12 % langsamer als native Prozesse.

Um Nodes bedarfsgerecht bereitzustellen, müssten Sie eine Infrastrukturlösung wie Terraform betreiben, die die APIs von Cloud-Anbietern (AWS, GCP, Azure) sowie Rechenzentren mit VMware und anderen Hypervisoren anspricht. Ein großer Teil der Arbeit würde in die Pflege dieser Lösung fließen.

Ein Fortschritt der Cloud-Anbieter, der heute selbstverständlich erscheint, ist das Pay-as-you-go-Modell. Auf AWS können Sie eine virtuelle Maschine nutzen, sobald Sie Ihre Kreditkarte hinterlegt haben – ganz ohne Verpflichtungen.

Viele klassische Rechenzentren holen dagegen erst nach und nach auf, wenn es darum geht, ihre Umgebung online über Private-Cloud-Tools bereitzustellen. Eine der größten Hürden ist dabei die Performance dieser Maschinen und die Frage nach dem Preis-Leistungs-Verhältnis. Am aussagekräftigsten ist ohnehin ein Pilotprojekt, um einen Benchmark speziell für Ihren Workload zu erhalten.