Nachdem ich gestern über BusinessModelle und Finanzierungen geschrieben habe und diese Hürde genommen würde geht es weiter mit der Infrastruktur.

Gerade hier zeigt sich, ob es sich beim Startup um eine Klitsche handelt, die gerade so überleben wird oder ein Startup das für mehr zu haben ist.

Inhalt:

• Serversicherheit für Startups
• Ausfallsicherheit von Web2.0 Startups
• Entwicklungs-, Test-, Produktionsumgebungen
• Automatisierte Tests
• Automatisches Deployment

Hört sich vielleicht erstmal hochtrabend an, aber es wird sicherlich jeder verstehen auch die VC’s und Unternehmensberater – quasi “Unternehmensberater ready”

Serversicherheit

Angriffe von Hackern, Crackern oder was auch immer, ob von innen oder außen. Hierüber muss man eigentlich keine Worte verlieren, außer vielleicht, wenn der Server nicht erreichbar ist, dann sind die Einnahmen gleich NULL. Sei dies nun durch einen Angriff oder aus irgendwelchen anderen Gründen.

Ausfallsicherheit

“Hast du für dein Startup eine Verfügbarkeitsanalyse?” oder noch schöner “Wie lange dürfen deine Seiten offline sein” oft wird dann mit Begriffen wie NIE oder “das geht gar nicht” hantiert.
Aber eine Hochverfügbare Weblösung braucht dann gewisse standards, die sich Web-Startups so gut wie nie leisten können. Hochverfügbarkeit hat ihren Preis. Die Administratoren hierfür auch. Redundante Server, Redundante Switche, doppelte Stromversorgung, USV, Backup und und und.
Also muss man irgendwo abstriche machen. Entweder an der Verfügbarkeit oder man muss sich eine andere Lösung überlegen mit der man halbwegs Leben kann

Entwicklungs- und Testumgebungen

Einige der neuen Web2.0 Startups arbeiten mit RubyonRails. Der Vorteil dieses Frameworks ist die Geschwindigkeit mit der entwickelt werden kann und vor allem viele kleine Tools, die bereits im Framework enthalten sind, die man bei anderen Sprachen, wie z.B. J EE das Tools ANT, extra mit in die Entwicklungsenviroments einbinden muss.

Auch die Entwicklungs und Testumgebunden bringt Rails von Hause aus schon mit. So kann man jeweils eine Datenbank für Development, Test und Produktion anlegen und auch verwenden.

Rails bringt sogenannte Migrations mit, die passend zu jeder Datenbanktabelle eine Migrationsscript mitbringt mit dem man auf die entsprechende Datenbankversion migrieren kann und weitere Tests durchführen kann/sollte !

Rundum sauber und sicher ist es dann wenn man mit den entsprechenden automatisierten Tests arbeitet. Jedes Modul, jede Funktion hat seinen eigenen Test. Verwendet man externe Module, dann kann man in der Regel davon ausgehen, dass diese bereits ausgiebig getestet wurden. Oder einfach erneut die mitgelierten Tests starten. Vertrauen ist gut – Kontrolle ist besser.

Automatisierte Tests

Integrtionstest, Modultests sind mehr als wichtig. Denn jedes Modul sollte bevor es von der Entwicklungsumgebung über die Test auf die Produktion kommt aus

Automatisches Deployment

Das automatische Deployment also die Anwendung vom Testserver auf den Staging Server und dann auf die Produktion zu spielen kann ganz easy mit GIT und Rake bzw. Capistrano gemacht werden. Manche Leute kennen sich mit Git,Rake,Capistrano wirklich verdammt gut aus. Sind aber im wirklichen Leben unbezahlbar – Danke