Damit die gewünschte Technik auch läuft, braucht ein Web-Unternehmen den passenden Provider. Marcus Kuhn erklärt seinen Entscheidungsprozess.


von Marcus Kuhn, Gründer connex.io

Startup-Tagebuch: Marcus Kuhn

Als Web-Startup sind für uns die Zuverlässigkeit und Geschwindigkeit unserer Server essentiell. Sind unsere Dienste einmal nicht erreichbar, schädigt das nicht nur unsere Kunden sondern auch deren Vertrauen in uns. Ist unsere Webapp zu langsam, verlieren wir potentielle und existierende Kunden. Deshalb lohnt es sich, sorgfältig nach dem richtigen Provider zu suchen.

Bis wir unseren Provider schliesslich gefunden hatten, dauerte es eine Weile und wir haben einige Dienstleister ausprobiert. Doch von Anfang an: Als wir connex.io im Januar starteten, benötigten wir einen möglichst günstigen aber dennoch leistungsfähigen Server um unsere Anwendung zu testen. Wir trafen unsere Entscheidung hauptsächlich gestützt auf eine Quelle und entschieden uns für eines der kleinsten Linode Slices. Dieses betreiben wir noch heute, allerdings laufen darauf mittlerweile nicht mehr unsere Anwendung sondern unsere Website und einige andere Produktivitäts-Tools wie zum Beispiel Jira. Auch unsere Alphaversion, welche wir im März starteten lief problemlos auf zwei Linode Slices. Doch dieser Test zeigte, dass Linode – wie wir eigentlich vermutet hatten – längerfristig nicht die richtige Lösung für uns war. Wir brauchten eine flexiblere und leistungsfähigere Lösung und machten uns deshalb daran, weitere Optionen anzuschauen.

Skalierbarkeit ist Trumpf

Ein wichtiger Anhaltspunkt bei der Suche nach dem passenden Provider sind die Technologien die man selbst einsetzt. Sowohl für Python (Google App Engine) als auch Ruby (Heroku), PHP (z.B. cloudControl) oder .net (Azure) gibt es Lösungen, welche das Skalieren einer Webapplikation stark vereinfachen. Eine Abstraktion des Hardwarelayers wie sie die oben genannten Lösungen anbieten wäre von uns zwar bevorzugt worden, aber da unser System hauptsächlich in Python geschrieben ist wäre lediglich die Google App Engine in Frage gekommen. Die fiel wegen zu vieler negativer Aspekte – wie z.B. Einschränkungen bei der Wahl der Datenbank oder Googles berühmt-berüchtigt schlechtem Kundendienst – allerdings durch und wir mussten weiter suchen.

Intensives Testing

Eine weitere Option für ein automatisch skalierendes und somit sehr flexibles System haben wir in Scalr entdeckt welches auf Amazons Servern aufbaut (wie z.B. das oben genannte Heroku auch). Scalr passt die Anzahl der genutzten Server automatisch den Bedürfnissen an und ermöglicht es so, Lastspitzen abzufedern. Leider fiel auch Scalr durch unseren Test. Nicht weil es seinen Zweck nicht erfüllte, sondern weil es auf Amazons Infrastrukturangebot aufbaut. Ein intensiver Test unserer Applikation auf Amazons Servern hat gezeigt, dass unsere Lösung auf Amazons Systemen aus irgend einem Grund nicht performen wollte.

Schlussendlich sind wir nun bei einem relativ neuen Schweizer Cloudhoster gelandet. Cloudsigma bietet Infrastructure-as-a-Service und erfüllt unsere Anforderungen vollkommen. In einem kostenlosen 14-Tage-Test war es uns möglich, die Systeme auf Herz und Nieren zu testen und Cloudsigma stand uns dabei mit Rat und Tat zur Seite. Auch wenn das Billing (Vorauszahlung) und das Setup (erster Login via VNC) nicht ganz dem Standard entsprechen, waren dies keine Faktoren die uns abgehalten haben. Die gute Performance, der ausserordentliche Service, die Möglichkeit Server individuell zu spezifizieren, der Standort Schweiz, die Möglichkeit den Speicher zu verschlüsseln und der faire Preis (z.B. kostenloser eingehender Traffic) haben uns schlussendlich überzeugt.