blog.marekventur.de

Wer -wie ich- einen leichten(?) Faible für Schriften hat, der kommt beim Webdesign nicht mehr um @font-face herum. Google macht seit einigen Monaten die Sache mit Font Directory noch ein wenig leichter und besser indem es eine immer größer werdende Auswahl an freien Schriftarten auf ihren Servern hostet. Das hat (wie auch bei JS-Libraries via Google CDN) nicht nur den Vorteil, dass die Schriften immer aktuell sind und sie rasend schnell ausgeliefert werden, sondern auch dass die HTTP-Request auf eine fremde Domain verweisen und so von einigen älteren Browsern schneller dargestellt werden, da diese sich oft noch an die antiquierte Grenze von 2 parallelen Request pro Domain halten. Auch der Vorteil durch Caching sollte bei einem Anbieter wie Google nicht vergessen werden, den wer schon einmal auf einer Seite war, die Google Font Directory einsetzt, dessen Browser wird bei der nächsten Begegnung mit der Schriftart nur noch im Cache kramen.

Vor zwei Tagen fiel mir auf, dass Google das Directory weiter ausgebaut hat (es gibt jetzt wieder ein paar Schriften mehr und internationale Glyphen werden unterstützt) und dabei einen neuen Google-Dienst einsetzt der sich Moderator nennt. Moderator ist ein kostenloser, bisher werbefreier Dienst der ursprünglich nur intern verfügbar war, nun über App-Engine gehostet wird und es beliebigen Nutzern (mit und ohne Google Account) erlaubt, Vorschläge zu einem Thema abzugeben und über die Ideen anderer abzustimmen. Das ganze ist schön schlank gehalten, begrenzt Vorschläge auf 160 Zeichen länge (wohl damit die ganze Sache übersichtlich bleibt) und ist Google-typisch technisch auf einem hohen Niveau. Enstanden ist es übrigens während der 20% Arbeitszeit, die Google-Mitarbeiter für eigene Projekte aufwenden dürfen.

Während die bei Font Directory verlinkte Variante inzwischen einfrig genutzt wird um neue Schriften vorzuschlagen kann der Service “Moderator” an sich für beliebige Seiten verwendet werden. Der Dienst erlaubt es jedem einen eigene “Serie” zu erstellen und diese für eigene Projekte zu nutzten. Ambitioniert z.B. ist “Ask a world leader”, unter anderem mit Fragen an Angela Merkel.

PS: Als “Test” könnt ihr gerne meinen Vorschlag ein wenig hochvoten

… oder wie Cloud-Computing kleinen Webseiten über Lastspitzen hilft.

Gestern hat Ehrensenf unser Webprojekt RapidLetter vorgestellt. Wortopia wurde dort auch schon einmal vorgestellt – mit dem Ergebnis dass der Server im Nu nicht mehr ansprechbar war.  Sowas ist nicht nur nervig, sondern deprimiert potenzielle Besuchern, die wahrscheinlich nie wieder vorbeikommen werden.

Es wäre also schön, wenn man bei Bedarf einfach von seinem kleinen VServer zu einem dicken Vielkerner mit ausreichend RAM wechseln könnte. Daher habe ich schon vor einiger Zeit ein Ubuntu AMIs (ein Image) für Amazon EC2 vorbereitet, welches hauptsächlich aus einem Apache und ein paar Extensions besteht. Dieser Aufbau hat sich jetzt bewert: Jeder der knapp 600 konnte ohne Probleme eigen Briefe generieren. Keine Downtime, keine langsamen Seiten, kein 500-er Fehler.

Die Idee dahinter ist, dass die Datenbank ruhig weiter auf dem ursprünglichen Server liegen bleiben kann, solange die Cloud-Instanz von extern auf sie zugreifen kann. Da die meiste Arbeit bei durchschnittlichen Webseiten hauptsächlich beim HTTP-Server liegt, lässt auf diese Weise in begrenzten Maßen schnell und günstig skalieren.

Wer sich auch auf den nächsten Peak einrichten will, hier eine grobe Anleitung:

Vorbereitung:

1. Einen AWS-Account anlegen. Dafür brauchst du eine gültige Kreditkarte.
2. Ein einfaches Image eines beliebigen Linux-Betriebssystems bei Amazon starten (Ich bevorzuge Ubuntu oder Debian). Wichtig: Zone “Europe” auswählen – AMIs lassen sich nicht zwischen verschiedenen Zonen verschieben.
3. Apache und PHP (und evtl. Extensions) installieren.
4. Die Configs möglichst so einrichten, wie sie auch auf dem “normalen” Server eingestellt sind.
5. Wenn du keine Lust auf dauerndes Public-Key-Mitrumschleppen hat (nämlich genau der fehlt immer wenn es kritisch wird), kannst du mit passwd ein Rootpasswort festlegen. Das ist zwar nicht ganz soooo sicher, aber bei ausreichender Passwortstärke durchaus akzeptabel.
6. Jetzt wird es kompliziert: das Image muss gebundled werden, das heißt es wird ein Image der Instanz erzeugt und auf Amazon S3 gepseichert. Das ist ein wenig frickelig, aber mit der richtigen Anleitung durchaus machbar.
7. Die Instanz noch nicht herunterfahren! Erst sollte das neue Image getestet werden – es wäre nicht das erste mal, das es beim Bundlen Probleme gibt.
8. Jetzt die Instanz herunterfahren und auf die paar Cent bei der nächsten Kreditkartenabrechnung warten.
9. Richte deinen normalen Datenbank-Server so ein, dass er Zugriffe von externen Hosts zulässt. Achte auf ein sichers Passwort und gewähre nur einem eingeschränkten Datenbankbenutzer dieses Recht.
10. Öffne den passenden Port in den IPTables. Du kannst dann die Datenbank mit einer GUI wie HeidiSQL testen.

Am Tag X stellst du nun fest, das xyz auf deine Seite linkt und die Zugriffe nach oben schnellen. Nun heißt es schnell sein:

1. Das AMI mit einer möglichst großen Instanz starten.
2. Kopiere alle Dateien deiner Webseite. Passe die Einstellungen der Datenbank auf die Adresse der Datenbank (die ja immer noch auf deinem normalen Server liegt) an. Setze sie passenden Dateiberechtigungen und teste Alles einmal kurz durch.
3. Ermittle aus der externe Adresse der Instanz die IP und trage sie bei deinem Domain-Hoster anstelle deines normalen A-Records ein.
4. Freue dich, dass du auf einmal ein vielfaches deiner normalen Besucher hast.