Fragen, die ich stelle, bevor ich einen VPS-Anbieter empfehle

"Welchen VPS-Anbieter sollen wir nutzen?" ist eine Frage, die ganz am Anfang von praktisch jedem einzelnen neuen Projekt auftaucht.

Es gibt dafür niemals nur die eine richtige Antwort. Der richtige Provider für eine High-Traffic-Applikation mit europäischem Publikum ist fundamental anders als der richtige für ein internes Reporting-Tool mit minimalem Traffic. Und das ist wiederum völlig anders als der richtige Provider für einen Kunden, der verzweifelt die absolut niedrigsten monatlichen Kosten will und für den es völlig in Ordnung ist, mehr manuelle Serververwaltung selbst zu übernehmen.

Was hingegen immer völlig konstant bleibt, ist das exakte Set an Fragen, das die Auswahl tatsächlich eingrenzt. Überraschenderweise haben die meisten dieser Fragen absolut nichts mit den CPU-Benchmarks auf der glänzenden Vergleichsseite zu tun.

Wo sind Ihre Nutzer im Verhältnis zu den Rechenzentrums-Optionen?

Latenz (Latency) zu einem Rechenzentrum auf der anderen Seite des Planeten ist ein harter, unveränderlicher Kostenfaktor, den kein noch so gutes Server-Tuning oder Caching jemals reparieren wird.

Wenn das Publikum eines Kunden stark in einer bestimmten Region konzentriert ist, sind die physischen Rechenzentrumsstandorte des Providers in Bezug auf diese Region weitaus wichtiger als künstliche CPU-Benchmarks. Ein Server, der technisch gesehen rasend schnell ist, aber drei Zeitzonen von den meisten Nutzern entfernt steht, wird sich in der Praxis langsamer anfühlen als ein bescheidener, durchschnittlicher Server, der geografisch nah dran ist. Ein enorm aussagekräftiger Teil der gefühlten Ladezeit ist schlicht und ergreifend Round-Trip Netzwerk-Latenz, keine reine Server-Verarbeitungszeit.

Was genau bedeutet ein "Resize" in der Praxis?

"Kann ich den Server später noch vergrößern?" ist eine Frage, auf die die Antwort fast universell "Ja" lautet.

"Was beinhaltet dieses Resize tatsächlich?" hat je nach Provider völlig unterschiedliche Antworten. Einige Provider vergrößern einen VPS mit einem simplen Neustart (Reboot), der in zwei Minuten abgeschlossen ist. Andere zwingen Sie dazu, auf völlig andere zugrunde liegende Hardware zu migrieren, was mit erheblicher Downtime verbunden ist und manchmal sogar bedeutet, dass sich Ihre öffentliche IP-Adresse ändert.

Für ein Projekt, das mit hoher Wahrscheinlichkeit wachsen wird, ändert das Wissen, ob "Skalieren" einen Fünf-Minuten-Neustart oder eine aufwendig geplante, stressige Migration bedeutet, schlichtweg alles. Es diktiert, wie viel zusätzlichen Puffer (Headroom) Sie von vornherein mit einkaufen müssen, versus wie entspannt Sie damit sind, klein anzufangen und hineinzuwachsen.

Was genau ist in "Backups" eigentlich enthalten?

Viele Anbieter bewerben "Backups" prominent als automatisches, zeitgesteuertes Add-on. Die Fragen, die man wirklich stellen sollte, lauten: Werden diese Backups auf exakt demselben physischen Storage-Array gespeichert wie der VPS selbst (was bedeutet, dass ein Ausfall auf Storage-Ebene beides gleichzeitig zerstört)? Wie viele tägliche oder wöchentliche Backups werden vorgehalten (Retention)? Können Sie selbst auf einen Button klicken, um eines wiederherzustellen, oder müssen Sie dafür ein Support-Ticket eröffnen und warten?

Ein Snapshot-Feature, das auf der Preis-Seite unglaublich beruhigend klingt, kann sich schnell als ein einzelner täglicher Snapshot entpuppen, der nur 24 Stunden aufbewahrt wird und auf exakt demselben physischen Array liegt. Das ist natürlich besser als gar nichts, aber es ist absolut keine verlässliche Backup-Strategie. Es ist lediglich ein etwas schnellerer Weg dorthin, wo man sich selbst ein vernünftiges Backup aufbaut.

Wie sieht der Support eigentlich aus?

Bei Providern am extremen Budget-Ende des Marktes läuft der Support strikt über Tickets, und die Reaktionszeiten werden in vielen Stunden oder gar Tagen gemessen. Für eine nicht dringende Frage zur Rechnung ist das völlig in Ordnung. Deutlich weniger in Ordnung ist es, wenn das Produktionssystem zu einer höchst ungünstigen Zeit komplett stillsteht.

Bei High-End-Anbietern sind dedizierter Telefon-Support oder garantierte 15-Minuten-Reaktionszeiten bei Tickets genau das, wofür dieser massive Aufpreis bezahlt wird. Keines der Modelle ist per se falsch, aber es ist von kritischer Bedeutung zu wissen, für welches ein Kunde eigentlich unterschreibt, bevor es zu einem akuten Vorfall (Incident) kommt, und nicht erst mittendrin.

Ein brutal schneller Weg, um ein Gefühl für die Realität zu bekommen: Suchen Sie den Namen des Anbieters zusammen mit dem Wort "Support" auf Reddit oder Twitter. Schauen Sie, was bestehende Kunden über ihre tatsächliche Erfahrung in der echten Welt berichten, anstatt blind zu vertrauen, was die Sales-Seite aggressiv verspricht.

Ist das Abrechnungsmodell für den Kunden wirklich vorhersehbar?

Ein pauschaler, vorhersehbarer monatlicher Preis für eine feste Menge an CPU, RAM und Speicherplatz ist für einen Kunden unglaublich einfach zu budgetieren.

Alles, was rein nach Nutzung abgerechnet wird – wie Bandbreitenüberschreitungen (Overages), Festplatten-IOPS oder zusätzliche IPs – kann sich sehr schnell in eine erschreckende Rechnung verwandeln, die von Monat zu Monat unmöglich vorherzusagen ist. Das ist für einen Kunden, der ein festes Jahresbudget streng verwalten muss, weitaus wichtiger als für ein riesiges Projekt, bei dem variable Skalierungskosten vollkommen erwartet und genauestens überwacht werden.

Dies ist kein Argument gegen nutzungsbasierte Abrechnung im Allgemeinen; sie hat absolut ihre Daseinsberechtigung. Aber es ist etwas, das im Vorfeld explizit zur Sprache gebracht werden muss, anstatt den Kunden ein halbes Jahr später brutal über eine massive Rechnung stolpern zu lassen.

DDoS-Schutz: Inklusive oder nur "verfügbar"?

Grundsätzliche DDoS-Mitigation ist mittlerweile für die meisten modernen Provider absoluter Standard. Aber das Wort "verfügbar" bedeutet manchmal, dass es sich um eine zusätzliche kostenpflichtige Premium-Stufe handelt, oder um ein komplett separates Produkt, das explizit aktiviert und konfiguriert werden muss. Bei anderen Providern ist es einfach standardmäßig für jeden einzelnen Server im Netzwerk eingeschaltet.

Für alles, was öffentlich erreichbar (public-facing) ist, lohnt es sich, genau zu wissen, in welche Kategorie ein Provider fällt – und welche Größenordnung von Angriffen die Mitigation tatsächlich abfängt. Fünf Minuten Lesezeit bevor man unter aktivem Beschuss verzweifelt danach sucht, sind hier Gold wert.

Die eigentliche Erkenntnis

Keine dieser spezifischen Fragen hat eine universell richtige oder falsche Antwort. Sie sind kritische Faktoren für eine Entscheidung, die massiv von der spezifischen Realität des jeweiligen Projekts abhängt.

Was sie alle gemeinsam haben: Keine von ihnen taucht klar und deutlich auf einer glänzenden Specs-Vergleichsseite auf. Und ausnahmslos alle davon sind Dinge, die man viel lieber klar wissen möchte, bevor man eine Kreditkarte eintippt, anstatt sie auf die harte Tour während eines Incidents, einer Migration oder durch eine schockierend hohe Rechnung herauszufinden.

Sie im Vorfeld zu klären, dauert exakt fünf Minuten und verwandelt die unmögliche Frage "Welcher Provider ist der beste?" in "Welcher Provider ist für dieses spezifische Projekt der beste?". Das ist nämlich die einzige Frage, auf die es tatsächlich eine gute Antwort gibt.