Daydeal.ch ist eine Dealseite wie jede andere spezialisiert auf Gadgets/Tools und sonstiges Geekzeugs. Jeden Tag gibts ein Angebot zwischen 9:00 Uhr und 9:00 Uhr und so lange Vorrat. Heute gabs einen Spezialdeal: Jede Stunde ein Angebot. Coole Sache, das haben sich wohl einige Gedacht: Daher kam immer mal wieder die Nachricht: "Site not available". Heute muss so etwas nicht mehr sein.
Rechenpower oder Manpower
Eine erste Lösung könnte natürlich sein, die Webseite zu überarbeiten und zu optimieren, damit sie mit den verfügbaren Ressourcen performt. Dagegen sprechen jedoch folgende Gründe:
- Die Applikation ist bereits 100% optimiert und optimal für den Zweck gebaut, so dass sie Ressourcen zu 100% auslastet (fraglich, ob so etwas je der Fall ist).
- Ein Programmierer braucht 100 Stunden (ca. 2 Wochen), um ein paar Tweaks und Optimierungen zu machen, welche notwendig sind -> Kosten: 200×100 = 20'000.-
- Gegebenenfalls die Applikation komplett neu schreiben, Technologie neu evaluieren (PHP ist vielleicht nicht die optimale Lösung) -> Kosten: massiv höher.
- Risiko, gravierende Änderungen zu machen sind nie zu vernachlässigen. Beim Relaunch einer neuen Plattform gibt es immer hier und da kleine Patzer
Betrachten wir das alles mit den Kosten für ein paar neue Server, welche für 1 Tag benötigt werden, ist der Fall klar: Rechenpower ist günstiger: Ein paar zusätzliche Amazon Server in der Cloud, ein CDN… und schon ist das Problem mit ein paar wenigen Franken gelöst.
Wie könnte die Cloud Abhilfe schaffen
Einen besseren Grund für eine Cloud Infrastruktur gibt es fast nicht, denn daydeal hätte offensichtlich für eine kurze Zeit (wohl für den heutigen Tag) mehr Rechenpower benötigt, um die zusätzliche Last zu bewältigen.
Wären die Server virtualisiert und liegen in einer Cloud Umgebung, hätte der Sysadmin heute morgen lediglich ein paar zusätzliche Instanzen hochgefahren und hinter den Loadbalancer gehängt und schon wäre das Problem gelöst gewesen. Morgen früh kann der Sysadmin dann die zusätzlichen Servers wieder runterfahren. Kostenpunkt: ein paar zusätzliche Franken.
Alles wäre stressfrei gewesen. Ich gebe zu, dass dafür bereits gewisse voraussetzungen gegeben sein müssen: Loadbalancer muss bereits vorhanden sein und DB und Applikationsserver müssen separiert sein… doch auch das lässt sich im Normalfall relativ schnell einrichten (wenn ich in einer virtualisierten Umgebung bin)
Was aber auch der Grund sein könnte
Der Marketing Director hat die geniale Idee, 24 Deals an einem Tag aufzuschalten. Er fragt seinen Praktikanten, ob sich das System entsprechend "verbiegen" lässt, so dass jede Stunde ein neues Produkt rausgeht. Dieser bejaht und schon steht der Deal. Ein Datum wird festgelegt und alle sind glücklich… nur weiss die IT nichts davon.
Der grosse Tag rückt näher, im Marketing sind alle nervös: Es ist 9 Uhr, los gehts. Natürlich ist in der IT noch niemand im Büro, da die immer erst um 10 Uhr kommen. Um 9:05 Uhr läuft nichts mehr: Server ist down. Marketing Fuzzy ruft frustriert in der IT an… irgend ein Helpdeskler startet Apache neu. Problem gelöst. 15 Minuten später wieder das Gleiche. Marketing Fuzzy wird langsam nervös, Helpdeskler hilflos.
Endlich 10 Uhr, der Programmierer erscheint im Büro: Alle Warnlämpchen auf rot und der Sysadmin kommt erstmals in Schwitzen. Helpdesk erzählt ihm, dass es Probleme mit der Webseite gibt… wirklich? Helpdesk meint nur, dass der Marketing Fuzzy ziemlich aufgebracht ist. IT Fuzzy schaut sich mal die Seite an… oha… was ist denn das für eine Kampagne? Scheisse, warum hat das niemand gesagt? Rödel, rödel, fluch, fluch… und 3 neue Server sind bereit…. 11 Uhr: Das System läuft wieder ruhig.
Die Cloud löst nicht magisch alle Probleme
Die Geschichte ist frei erfunden, könnte aber genau so passieren. Kommunikation zwischen Business und IT sind unerlässlich. Das Marketing mag zwar die Ideen haben, die IT muss diese ermöglichen und ausführen, doch soll das Business nicht erwarten, dass die IT Systeme einfach magisch laufen (auch wenn diese in der Cloud sind). Viele Pannen liessen sich vermeiden, wenn mehr Kommunikation wäre (und das gilt übrigens auch für die IT bezüglich Systemwartungen!)