Hosting im Vergleich: Welche Lösung passt zu Ihrem Projekt?

World4You und Host Europe für überschaubare Websites

Für viele kleinere Websites ist ein Webhosting-Paket die vernünftige Wahl. Webserver, PHP und Datenbanken sind vorgegeben und werden vom Anbieter betrieben. Das ist Arbeit, die ein Unternehmen für seine Website meist gar nicht selbst übernehmen will.

Vor der Auswahl prüfen wir, ob die benötigte CMS-Version unterstützt wird, welche Ressourcen zur Verfügung stehen und wie sich Änderungen ausliefern lassen. SSH-Zugriff, geplante Aufgaben und eine getrennte Testumgebung sind dabei oft wichtiger als noch mehr Speicherplatz.

Die Grenzen zeigen sich, wenn eine Anwendung zusätzliche Laufzeiten, dauerhaft laufende Prozesse oder spezielle Servereinstellungen braucht. Dann verbiegen wir nicht die Anwendung, damit sie in ein ungeeignetes Paket passt, sondern vergleichen andere Angebote. Umgekehrt muss eine funktionierende Website nicht umziehen, nur weil es inzwischen eine aufwendigere Hosting-Lösung gibt.

mittwald und Hetzner: unterschiedliche Aufgaben im Betrieb

Bei mittleren Website-Projekten arbeiten wir mit mittwald und der Verwaltungsoberfläche mStudio. Projekte, Zugänge und Ressourcen werden dort an einer Stelle verwaltet. CLI und API erlauben die Anbindung an automatisierte Abläufe, und in den dafür geeigneten Tarifen stehen Container zur Verfügung. Das zahlt sich aus, wenn mehrere Beteiligte am Projekt arbeiten und neben dem CMS weitere Dienste gebraucht werden.

Hetzner Cloud nutzen wir für Webanwendungen, bei denen wir die Serverumgebung selbst zusammenstellen. Virtuelle Server lassen sich mit den benötigten Laufzeiten und Diensten einrichten. Diese Freiheit hat einen Preis: Betriebssystem, Konfiguration, Updates und Überwachung des Gastsystems muss jemand übernehmen, und das ist mit dem Anlegen des Servers nicht erledigt.

Deshalb vergleichen wir mehr als die Monatspreise. Eine stärker betreute Umgebung kann insgesamt günstiger sein als eine billige virtuelle Maschine, für die das Team laufend Administration zukaufen muss. Hat die interne IT diese Aufgaben ohnehin im Griff, sieht die Rechnung anders aus.

AWS und Kubernetes, wenn die Architektur davon profitiert

AWS kommt für uns infrage, wenn eine Anwendung mehrere Cloud-Dienste braucht oder in eine bestehende AWS-Umgebung eingebunden werden soll. Datenbanken, Speicher und weitere Dienste lassen sich dort direkt mit der Anwendung verbinden. Welche davon wir einsetzen, richtet sich nach dem Projekt und dem Team, das die Umgebung später betreibt.

Kubernetes verwaltet Container-Anwendungen, verteilt sie auf mehrere Rechner und tauscht laufende Versionen aus. Es ist kein AWS-Produkt und läuft genauso in anderen Clouds oder im eigenen Rechenzentrum. Auf AWS heißt der zugehörige Dienst EKS. AWS betreibt dabei die zentrale Cluster-Steuerung, die weiteren Zuständigkeiten hängen vom gewählten Betriebsmodell ab. Die Anwendung selbst, ihre Berechtigungen und ihre Konfiguration bleiben Aufgabe des zuständigen Teams.

Für eine einzelne Website verursacht dieser Aufbau meist mehr Aufwand, als er einspart. Interessant wird er bei mehreren zusammengehörigen Diensten oder wenn im Unternehmen bereits eine Kubernetes-Plattform etabliert ist. Wie sich ein solches Projekt vorbereiten lässt, beschreiben wir im Artikel zur TYPO3-Cloud-Migration.

On-Premise: im Rechenzentrum des Kunden

Ein Teil unserer Anwendungen läuft direkt in der Infrastruktur unserer Kunden. Das passt, wenn wichtige Systeme ohnehin dort betrieben werden, interne Zugriffsregeln einzuhalten sind oder ein erfahrenes IT-Team die Umgebung betreut.

Die Anwendung stimmen wir dann mit den vorhandenen Netzen, Zugängen und Betriebsabläufen ab. Dazu gehört der Weg einer neuen Version vom Entwicklungsteam in die Produktion samt den nötigen Freigaben. Die Zusammenarbeit mit der internen IT beginnt deshalb vor der Implementierung, nicht bei der Inbetriebnahme.

Vorhandene Server machen diesen Betrieb nicht kostenlos. Kapazität, Wartung, Ersatzhardware und Personal gehören in die Rechnung. Auch ein Server im eigenen Haus braucht geschützte Backups und einen erprobten Weg zurück in den Betrieb. Der Standort allein sagt noch nicht, wie gut Daten und Zugänge geschützt sind.

Cloudflare für spezialisierte Webservices

Nicht jede zusätzliche Funktion braucht einen eigenen Server. Über Cloudflare lassen sich etwa kleine API-Dienste mit Workers bereitstellen oder Inhalte über ein CDN ausliefern. Wir verwenden Cloudflare für solche spezialisierten Webservices, auch ergänzend zum Hosting der eigentlichen Website.

Diese Aufteilung ist oft praktisch: Das CMS bleibt beim bisherigen Anbieter, eine einzelne Funktion läuft separat. Dafür muss die Funktion zur Laufzeit passen. Workers sind keine frei konfigurierbaren virtuellen Server. Ausführungsgrenzen, unterstützte Schnittstellen und angebundene Datendienste müssen schon bei der Entwicklung berücksichtigt werden.

Auch ein kleiner Dienst braucht einen klaren Platz im Betrieb. Es muss festgelegt sein, wer Zugriff hat, welche Daten er verarbeitet, wie er überwacht wird und was bei einem Fehler passiert. Jeder zusätzliche Dienst ist eine weitere Stelle, die bei Änderungen mitgedacht werden muss.

Was „Managed Hosting“ abdeckt und was nicht

Aus dem Begriff allein geht nicht hervor, wer ein veraltetes CMS aktualisiert oder eine fehlerhafte Erweiterung repariert. Ein Anbieter kann Server und Laufzeitumgebung betreuen, während die Wartung der Anwendung gesondert vereinbart werden muss.

Vor dem Start halten wir deshalb fest, wer welche Updates übernimmt, wer Warnmeldungen erhält und wer bei einer Störung reagiert. Bei Backups reicht uns die Information, dass es sie gibt, nicht. Wir klären, welche Daten gesichert werden, wie weit die Sicherungen zurückreichen und wie die Wiederherstellung abläuft. Eine Anwendung mit vielen Änderungen braucht andere Sicherungsintervalle als eine Website, die selten bearbeitet wird.

Auch Datenschutzanforderungen prüfen wir an der gesamten Lösung. Zum eigentlichen Hosting kommen oft Speicher-, Mail-, Analyse- und Supportdienste dazu. Mit den zuständigen Personen im Unternehmen klären wir, welche Daten wohin gelangen und welche vertraglichen Vorgaben gelten. Unsere Arbeitsweise dazu steht im Beitrag über Web-Security und Verantwortlichkeiten.

Die laufenden Kosten und der spätere Wechsel

Für einen ehrlichen Kostenvergleich rechnen wir Einrichtung und laufende Betreuung mit. Bei Cloud-Angeboten kommen je nach Nutzung Rechenleistung, Speicher, Datenverkehr, Backups und weitere Dienste dazu.

Wir prüfen außerdem, was ein späterer Wechsel bedeuten würde. Eine Anwendung mit verbreiteten Laufzeiten und einer üblichen Datenbank zieht leichter um als eine, die eng mit speziellen Plattformdiensten verwoben ist. Solche Dienste können trotzdem die richtige Entscheidung sein. Ihr Nutzen und der spätere Umbauaufwand gehören nur beide in die Bewertung.

Unsere Kunden schließen die Hosting-Verträge direkt mit den Anbietern ab. Wir betreiben keine eigene Hosting-Infrastruktur für Kunden und erhalten keine Vermittlungsprovisionen. Wir unterstützen bei Auswahl, Einrichtung und der Abstimmung des Betriebs. Konten, Daten und Zugänge bleiben unter der Kontrolle des Kunden, auch bei einem späteren Agenturwechsel.

Wenn Sie eine neue Website planen oder mit dem bisherigen Hosting unzufrieden sind, sehen wir uns Anwendung und Betrieb gemeinsam an. Am Ende kann ein Anbieterwechsel stehen, eine andere Konfiguration oder die Entscheidung, die bestehende Lösung weiterzuverwenden. Sprechen wir über Ihr Projekt.